Разминка. ROI из XVIII века
В семейной библиотеке нашла ещё одну книгу с задачами. «Старинные занимательные задачи», второе издание, 1988 год.
Это сборник задач из рукописей и книг, изданных в России до 1800 года. Автор одной из них “Арифметика, сиречь наука числительная…” - Леонтий Филиппович Магницкий, математик, которого Пётр I лично наградил фамилией в 1700 году, а о его образовании ничего не известно.
Я пока изучила только первую часть - по материалам рукописей и той самой «Арифметики» 1703 года. Выбрала задачу, которая, как мне показалось, имеет прямое отношение к бизнес-анализу. Что-то вроде подсчёта ROI от покупки кур.
В книге сохранён стилизованный старый текст и в некоторых местах приведены тексты в оригинале, чтобы можно было оценить всю сложность языка. Я оставила это на картинках.
В подсказке оставлю пояснение из книги. Но хочу предупредить: рассуждения XVIII века, кажется, отличаются от моих.
Когда разберётесь, напишите, совпал ли ваш ход мыслей с подсказкой? Мне очень интересно, окажется ли кто-то ближе к книжному ответу?
👇
#разминка
В семейной библиотеке нашла ещё одну книгу с задачами. «Старинные занимательные задачи», второе издание, 1988 год.
Это сборник задач из рукописей и книг, изданных в России до 1800 года. Автор одной из них “Арифметика, сиречь наука числительная…” - Леонтий Филиппович Магницкий, математик, которого Пётр I лично наградил фамилией в 1700 году, а о его образовании ничего не известно.
Я пока изучила только первую часть - по материалам рукописей и той самой «Арифметики» 1703 года. Выбрала задачу, которая, как мне показалось, имеет прямое отношение к бизнес-анализу. Что-то вроде подсчёта ROI от покупки кур.
В книге сохранён стилизованный старый текст и в некоторых местах приведены тексты в оригинале, чтобы можно было оценить всю сложность языка. Я оставила это на картинках.
В подсказке оставлю пояснение из книги. Но хочу предупредить: рассуждения XVIII века, кажется, отличаются от моих.
Когда разберётесь, напишите, совпал ли ваш ход мыслей с подсказкой? Мне очень интересно, окажется ли кто-то ближе к книжному ответу?
👇
#разминка
❤2
Вопросы выживания
Недавно консультировала коллегу, которому впервые пришлось составлять функциональные требования. Наш разговор свёлся к обсуждению ответов ИИ с точки зрения, что там “похоже на правду”. Мне было интересно, что коллега честно обратился за помощью, чтобы разобраться в нейро-ответах.
Давно думаю: как долго в отрасли будет держаться эта игра, когда описание от ИИ, передаётся в базу знаний или в бэклог?
На этой волне в блоге IIBA встретилась статья “Артефакты, которые переживут ИИ окажутся совсем не теми, что вы ожидаете” (источник). Автор пишет, что фокус рассуждений об артефактах в эпоху ИИ нужно сместить в сторону целей этих самых артефактов. Часто говорят, стоит ли вообще производить сами артефакты, когда за пару часов можно сгенерировать прототип и за десять минут можно собрать пакет требований из маркированного списка правил? При этом теряется вопрос: что делали эти артефакты и нужно ли, чтобы эта работа всё ещё выполнялась?
У документации две основные задачи: координация и фиксация контекста. Первое - структурирование общения между продуктом и разработкой: фиксация задач, правил и определений. Есть понимание, что эта часть дешевеет, можно быстро составить маппинг, диаграмму или текстовое описание готовых правил. При этом фиксация контента становится более ценной и чувствительной к ошибкам. Потому что потребителем этих знаний становятся не только коллеги, но и ИИ-агенты, которые не имеют другого контекста, кроме того, что записан в артефактах. И они могут любую ошибку обыграть и оформить так убедительно, что обнаружить её очень сложно.
Ещё одно интересное наблюдение в том, что на первый план выходит навык оценки достоверности готового артефакта. Раньше бизнес-аналитики много учились создавать документы и исключать неопределённость до того как что-то оформлено. Когда любой может за пару минут создать что-то похожее на аккуратные требования, учиться нужно оценивать уже готовое. Это другой навык, который требуется отдельно развивать.
В этом всем есть шанс выжить у пользовательских историй и критериев приёмки. Но не в формате, адаптированном для координации команд, что мы чаще всего применяли в последнее время.
Мы когда-то обсуждали с одним из гостей подкаста “Контекст, контракт и артефакт”, что под историей понимают всё, что угодно, включая use case. Но их исходное назначение было передавать контекст принятия решений и критерии для оценки готовности фичи. Задача пользовательской истории - служить краткой формулировкой того, кому что нужно, что они пытаются сделать и почему это важно. В таком формате информация полезна и коллеге, которому нужно оценить пять нейро-вариантов спецификаций. и агенту, которому поручено генерировать новые варианты.
Изменился конечный потребитель, но не требование к ясному, долговременному описанию контекста. Выживут те артефакты, которые сохраняют обоснование решений, а ключевой навык аналитика смещается от «написать правильно» к «понять, почему это правильно, и объяснить другим».
Так что на той консультации, где мы обсуждали достоверность нейро-ответов, направление было верным.🌱
#мысливслух #ai
Недавно консультировала коллегу, которому впервые пришлось составлять функциональные требования. Наш разговор свёлся к обсуждению ответов ИИ с точки зрения, что там “похоже на правду”. Мне было интересно, что коллега честно обратился за помощью, чтобы разобраться в нейро-ответах.
Давно думаю: как долго в отрасли будет держаться эта игра, когда описание от ИИ, передаётся в базу знаний или в бэклог?
На этой волне в блоге IIBA встретилась статья “Артефакты, которые переживут ИИ окажутся совсем не теми, что вы ожидаете” (источник). Автор пишет, что фокус рассуждений об артефактах в эпоху ИИ нужно сместить в сторону целей этих самых артефактов. Часто говорят, стоит ли вообще производить сами артефакты, когда за пару часов можно сгенерировать прототип и за десять минут можно собрать пакет требований из маркированного списка правил? При этом теряется вопрос: что делали эти артефакты и нужно ли, чтобы эта работа всё ещё выполнялась?
У документации две основные задачи: координация и фиксация контекста. Первое - структурирование общения между продуктом и разработкой: фиксация задач, правил и определений. Есть понимание, что эта часть дешевеет, можно быстро составить маппинг, диаграмму или текстовое описание готовых правил. При этом фиксация контента становится более ценной и чувствительной к ошибкам. Потому что потребителем этих знаний становятся не только коллеги, но и ИИ-агенты, которые не имеют другого контекста, кроме того, что записан в артефактах. И они могут любую ошибку обыграть и оформить так убедительно, что обнаружить её очень сложно.
Ещё одно интересное наблюдение в том, что на первый план выходит навык оценки достоверности готового артефакта. Раньше бизнес-аналитики много учились создавать документы и исключать неопределённость до того как что-то оформлено. Когда любой может за пару минут создать что-то похожее на аккуратные требования, учиться нужно оценивать уже готовое. Это другой навык, который требуется отдельно развивать.
В этом всем есть шанс выжить у пользовательских историй и критериев приёмки. Но не в формате, адаптированном для координации команд, что мы чаще всего применяли в последнее время.
Мы когда-то обсуждали с одним из гостей подкаста “Контекст, контракт и артефакт”, что под историей понимают всё, что угодно, включая use case. Но их исходное назначение было передавать контекст принятия решений и критерии для оценки готовности фичи. Задача пользовательской истории - служить краткой формулировкой того, кому что нужно, что они пытаются сделать и почему это важно. В таком формате информация полезна и коллеге, которому нужно оценить пять нейро-вариантов спецификаций. и агенту, которому поручено генерировать новые варианты.
Изменился конечный потребитель, но не требование к ясному, долговременному описанию контекста. Выживут те артефакты, которые сохраняют обоснование решений, а ключевой навык аналитика смещается от «написать правильно» к «понять, почему это правильно, и объяснить другим».
Так что на той консультации, где мы обсуждали достоверность нейро-ответов, направление было верным.🌱
#мысливслух #ai
www.iiba.org
The Artefacts That Will Survive AI Aren’t the Ones You Think | Analyst Catalyst Blog
The debate about which business analysis artefacts survive AI is asking the wrong question. The more important question is what those artefacts were actually doing—and whether that work still needs to happen.
👍1💯1
Чем аналитик DWH отличается от других аналитиков?
Такие вопросы мы обсуждали в новом выпуске, который записали в Воронеже. Вместе с соавтором проделали около 467 километров пути, чтобы встретиться с Татьяной Половинкиной - опытным аналитиком DWH и спикером.
Разговор с увлечённым опытным экспертом в смежной сфере знаний - это всегда большое удовольствие и новые вопросы к размышлению. Я задумалась вот о чем:
📍Существует ли понятие MVP в работе с данными? В каком значении ни взять этот термин Minimum Viable Product или Minimum Valuable Product - в основе лежит проверка гипотезы, что задача реализуема или что она может приносить ценность. Конечно, не очень умно залить в витрину наугад сырые данные или предложить регулятору попробовать MVP его отчёта, но, наверное, реально выбрать базовые метрики и данные для них или организовать “песочницу”? А что об этом рассказала наша гостья лучше послушать в выпуске 👇
📍Как оценивается качество данных? До недавнего времени я руководствовалась тем, что есть понятные общие критерии: дату и время не стоит хранить строкой с непонятным часовым поясом, серию и номер паспорта не хранить числом, нейминг должен быть адекватным… При этом у большинства аналитиков бывают случаи, когда задачу решить нужно в срок, а смежная система не готова дать данные в хорошем формате, на преобразование нет ресурсов и заказчика вполне устраивает та условная строка, что имеется - приходится соглашаться на компромисс. Может быть, критерии оценки должны быть привязаны больше к бизнес-цели или к техническому пониманию качества? 🤔
После разговора мы ещё собрали ссылки на статьи доклады по теме работы с данными, они доступны в сообществах подкаста в ВК и в Телеграмм.
Выпуск доступен по ссылкам 👇
Яндекс.Музыка
Podster.fm
Telegram
VK
#подкаст
Такие вопросы мы обсуждали в новом выпуске, который записали в Воронеже. Вместе с соавтором проделали около 467 километров пути, чтобы встретиться с Татьяной Половинкиной - опытным аналитиком DWH и спикером.
Разговор с увлечённым опытным экспертом в смежной сфере знаний - это всегда большое удовольствие и новые вопросы к размышлению. Я задумалась вот о чем:
📍Существует ли понятие MVP в работе с данными? В каком значении ни взять этот термин Minimum Viable Product или Minimum Valuable Product - в основе лежит проверка гипотезы, что задача реализуема или что она может приносить ценность. Конечно, не очень умно залить в витрину наугад сырые данные или предложить регулятору попробовать MVP его отчёта, но, наверное, реально выбрать базовые метрики и данные для них или организовать “песочницу”? А что об этом рассказала наша гостья лучше послушать в выпуске 👇
📍Как оценивается качество данных? До недавнего времени я руководствовалась тем, что есть понятные общие критерии: дату и время не стоит хранить строкой с непонятным часовым поясом, серию и номер паспорта не хранить числом, нейминг должен быть адекватным… При этом у большинства аналитиков бывают случаи, когда задачу решить нужно в срок, а смежная система не готова дать данные в хорошем формате, на преобразование нет ресурсов и заказчика вполне устраивает та условная строка, что имеется - приходится соглашаться на компромисс. Может быть, критерии оценки должны быть привязаны больше к бизнес-цели или к техническому пониманию качества? 🤔
После разговора мы ещё собрали ссылки на статьи доклады по теме работы с данными, они доступны в сообществах подкаста в ВК и в Телеграмм.
Выпуск доступен по ссылкам 👇
Яндекс.Музыка
Podster.fm
Telegram
VK
#подкаст
❤1👍1
Контекст решает всё. JTBD для аналитика
После того как написала здесь об артефактах в эпоху ИИ и важности фиксации контекста, я поймала себя на мысли: а как мы вообще описываем контекст, в котором эти артефакты рождаются?
Перерыла стандарты, заглянула в старые конспекты с курсов по CX и собрался список подходов, которые стоит разобрать. Первым в очереди оказался метод Jobs To Be Done. О нём и расскажу.
JTBD - не новая наработка, это обобщение практик, которое давно рассматривается в маркетинге. В ИТ-индустрии этот термин чаще звучит в управлении продуктом, но с точки зрения анализа и описания контекста есть вещи, которые важно понимать и аналитику.
Сначала о контексте. BABOK определяет контекст так: “Обстоятельства и условия, которые влияют на изменение, которые находятся под влиянием изменения, или которые способствуют пониманию изменения.“ Дальше в стандарте большое перечисление факторов, включая настроение человека и демографию. Но здесь есть нюанс. Могут ли внутренние поиски человека рассматриваться как контекст? Всегда ли именно демография (пол, возраст, местность) исчерпывающе говорит о поведении людей?
JTBD говорит, что люди выбирают решения не обязательно из-за своего пола или возраста, а из-за того, какую задачу им нужно решить. И настроение человека, безусловно, влияет на то как он принимает решения, но как однозначную характеристику его сложно определить и измерить - например, выбрать всех, кому грустно. Поэтому JTBD опирается прежде всего на ситуацию, а контекст чаще описывается внешними обстоятельствами. Петя съел бургер не потому, что ему 30 лет, а потому что это удобный способ перекусить на бегу между встречами.
Работа в JTBD - это изменение к лучшему, на которое человек рассчитывает в определённых обстоятельствах. Формулировка “Играть в приставку по вечерам” - это не описание работы во всех смыслах, потому что мы не видим обстоятельств и изменений 😊 “Внедрить выбор из списка”, “Настроить топик” - тоже не говорит о контексте и работе. Чтобы задать работу нужно определить обстоятельства и ожидаемые улучшения.
Важно, что при формулировке работы отсутствует решение. Работа описывается достаточно абстрактно, чтобы на неё можно было нанять разные продукты. Есть известное высказывание Клейтона М. Кристенсена: «Людям не нужна дрель на четверть дюйма. Им нужно отверстие такого же размера.» Здесь мне вспоминается самый частый сценарий в работе аналитика: заказчик приходит с готовым решением, со временем это решение может оказаться неработающим или не масштабируемым, потому что контекст потерян или определён ошибочно. Метод JTBD как раз предлагает сместить фокус с функции на задачу в конкретных обстоятельствах.
Что не так в User Story? Классическая постановка через «я как пользователь хочу…» фокусируется на том, кто просит. Это не ответ на вопрос «почему и в какой момент». По сути не так важно анализирует ли вашу постановку ИИ-агент или коллега - без этого знания он не сможет предложить релевантные варианты или оценить, подходит ли предложенное решение.
Во втором случае мы видим человека в конкретной ситуации - он отвечает на внезапный вопрос, у него нет времени, ему нужна мгновенная сводка. Именно это определяет, какой интерфейс ему нужен.
Какие вопросы задать для хорошей job story? Как это работает?
Чтобы описать контекст задачи и передать его другим (включая ИИ), можно задать вопросы для выяснения ситуации и социальной, эмоциональной, функциональной ценности изменений.
📍Когда возникает потребность? Что триггерит задачу?
📍Какую именно задачу пользователь пытается решить сейчас (не функционально, а в целом)?
📍Есть ли существующее решение или обходной путь? Почему оно не устраивает?
📍Что удерживает пользователя от перехода на новое решение? Страх риска, привычка, непонятная выгода?
Результат применения JTBD - Job Story, короткое описание, которое можно использовать как основу для требований. Формат такого описания обычно выглядит так:
Например: Когда в команду приходит новый аналитик, я хочу дать ему не 50-страничный регламент, а короткую памятку с ответами на самые частые вопросы и схемой основных процессов, чтобы он начал работать самостоятельно уже на второй день.
Если такая информация предназначена ИИ можно добавить к этому описанию ещё ограничения и допущения, чтобы получить более достоверный ответ. Например: «Я предполагаю, что данные всегда доступны, но бывают задержки синхронизации”
Что почитать:
- Что такое Jobs to Be Done (JTBD): как понять, какой продукт нужен клиенту
- Jobs To Be Done концепция - как привлечь новых пользователей
- Заменяем User Story на Job Story
#инструменты
После того как написала здесь об артефактах в эпоху ИИ и важности фиксации контекста, я поймала себя на мысли: а как мы вообще описываем контекст, в котором эти артефакты рождаются?
Перерыла стандарты, заглянула в старые конспекты с курсов по CX и собрался список подходов, которые стоит разобрать. Первым в очереди оказался метод Jobs To Be Done. О нём и расскажу.
JTBD - не новая наработка, это обобщение практик, которое давно рассматривается в маркетинге. В ИТ-индустрии этот термин чаще звучит в управлении продуктом, но с точки зрения анализа и описания контекста есть вещи, которые важно понимать и аналитику.
Сначала о контексте. BABOK определяет контекст так: “Обстоятельства и условия, которые влияют на изменение, которые находятся под влиянием изменения, или которые способствуют пониманию изменения.“ Дальше в стандарте большое перечисление факторов, включая настроение человека и демографию. Но здесь есть нюанс. Могут ли внутренние поиски человека рассматриваться как контекст? Всегда ли именно демография (пол, возраст, местность) исчерпывающе говорит о поведении людей?
JTBD говорит, что люди выбирают решения не обязательно из-за своего пола или возраста, а из-за того, какую задачу им нужно решить. И настроение человека, безусловно, влияет на то как он принимает решения, но как однозначную характеристику его сложно определить и измерить - например, выбрать всех, кому грустно. Поэтому JTBD опирается прежде всего на ситуацию, а контекст чаще описывается внешними обстоятельствами. Петя съел бургер не потому, что ему 30 лет, а потому что это удобный способ перекусить на бегу между встречами.
Работа в JTBD - это изменение к лучшему, на которое человек рассчитывает в определённых обстоятельствах. Формулировка “Играть в приставку по вечерам” - это не описание работы во всех смыслах, потому что мы не видим обстоятельств и изменений 😊 “Внедрить выбор из списка”, “Настроить топик” - тоже не говорит о контексте и работе. Чтобы задать работу нужно определить обстоятельства и ожидаемые улучшения.
Важно, что при формулировке работы отсутствует решение. Работа описывается достаточно абстрактно, чтобы на неё можно было нанять разные продукты. Есть известное высказывание Клейтона М. Кристенсена: «Людям не нужна дрель на четверть дюйма. Им нужно отверстие такого же размера.» Здесь мне вспоминается самый частый сценарий в работе аналитика: заказчик приходит с готовым решением, со временем это решение может оказаться неработающим или не масштабируемым, потому что контекст потерян или определён ошибочно. Метод JTBD как раз предлагает сместить фокус с функции на задачу в конкретных обстоятельствах.
Что не так в User Story? Классическая постановка через «я как пользователь хочу…» фокусируется на том, кто просит. Это не ответ на вопрос «почему и в какой момент». По сути не так важно анализирует ли вашу постановку ИИ-агент или коллега - без этого знания он не сможет предложить релевантные варианты или оценить, подходит ли предложенное решение.
User Story: «Как менеджер, я хочу видеть статусы заявок, чтобы контролировать процесс».
Job Story: «Когда я получаю неожиданный вопрос от руководителя о статусе проекта, я хочу собрать сводку по заявкам за 10 секунд, чтобы ответить уверенно, не перерывая чаты и почту».
Во втором случае мы видим человека в конкретной ситуации - он отвечает на внезапный вопрос, у него нет времени, ему нужна мгновенная сводка. Именно это определяет, какой интерфейс ему нужен.
Какие вопросы задать для хорошей job story? Как это работает?
Чтобы описать контекст задачи и передать его другим (включая ИИ), можно задать вопросы для выяснения ситуации и социальной, эмоциональной, функциональной ценности изменений.
📍Когда возникает потребность? Что триггерит задачу?
📍Какую именно задачу пользователь пытается решить сейчас (не функционально, а в целом)?
📍Есть ли существующее решение или обходной путь? Почему оно не устраивает?
📍Что удерживает пользователя от перехода на новое решение? Страх риска, привычка, непонятная выгода?
Результат применения JTBD - Job Story, короткое описание, которое можно использовать как основу для требований. Формат такого описания обычно выглядит так:
Когда [ситуация], я хочу [мотивация/цель], чтобы получить [ожидаемый результат].
Например: Когда в команду приходит новый аналитик, я хочу дать ему не 50-страничный регламент, а короткую памятку с ответами на самые частые вопросы и схемой основных процессов, чтобы он начал работать самостоятельно уже на второй день.
Если такая информация предназначена ИИ можно добавить к этому описанию ещё ограничения и допущения, чтобы получить более достоверный ответ. Например: «Я предполагаю, что данные всегда доступны, но бывают задержки синхронизации”
Что почитать:
- Что такое Jobs to Be Done (JTBD): как понять, какой продукт нужен клиенту
- Jobs To Be Done концепция - как привлечь новых пользователей
- Заменяем User Story на Job Story
#инструменты
🔥3👍1👏1
- Опять пишешь? Три года уже пишешь и зачем это? Кто тебя просит?
Это к рабочему столу пришла кошка. Её где-то нашёл сын, когда учился в школе, и привычки у неё не аристократические. Например, привычка бесцеремонно требовать внимания в любой момент, когда ей это интересно. Моё мнение при этом не учитывается, так что нужно продолжать разговор. Тем более, что она права - скоро три года как я создала этот канал.
- Понимаешь, если бы я знала ответ на этот вопрос сразу, я бы, наверное, не начала. А начала потому, что хотела проверить: могу ли я сказать что-то важное. И будет ли полезным кому-то мой опыт аналитика и преподавателя.
- Ну и как, проверила?
- В общем да. Я заметила, что некоторые знания, вроде дат конференций для аналитиков, мне кажутся очень легко доступными, а потом оказывается, что многим они нужны. И ещё заметила одну вещь: даже если подписчиков мало, среди них всегда есть те, кто действительно читает.
- И ты ради этого сидишь вечерами?
- Ну да. И еще чтобы работать с текстом, учиться лучше формулировать и объяснять. Я ради этого прошла целый курс по нон-фикшн, подписалась на хороших редакторов и читаю книгу о текстах.
Слушай, что ты тут о себе возомнила? Брысь со стола!
***
Иногда очень удобно поговорить с кошкой. Она для разговоров лучше, чем DeepSeek: выслушает что угодно, обязательно похвалит любую глупость, но не завалит своими ответами. К тому же она уже давно никуда не спешит от моих “брысь”👋
#истории
Это к рабочему столу пришла кошка. Её где-то нашёл сын, когда учился в школе, и привычки у неё не аристократические. Например, привычка бесцеремонно требовать внимания в любой момент, когда ей это интересно. Моё мнение при этом не учитывается, так что нужно продолжать разговор. Тем более, что она права - скоро три года как я создала этот канал.
- Понимаешь, если бы я знала ответ на этот вопрос сразу, я бы, наверное, не начала. А начала потому, что хотела проверить: могу ли я сказать что-то важное. И будет ли полезным кому-то мой опыт аналитика и преподавателя.
- Ну и как, проверила?
- В общем да. Я заметила, что некоторые знания, вроде дат конференций для аналитиков, мне кажутся очень легко доступными, а потом оказывается, что многим они нужны. И ещё заметила одну вещь: даже если подписчиков мало, среди них всегда есть те, кто действительно читает.
- И ты ради этого сидишь вечерами?
- Ну да. И еще чтобы работать с текстом, учиться лучше формулировать и объяснять. Я ради этого прошла целый курс по нон-фикшн, подписалась на хороших редакторов и читаю книгу о текстах.
Слушай, что ты тут о себе возомнила? Брысь со стола!
***
Иногда очень удобно поговорить с кошкой. Она для разговоров лучше, чем DeepSeek: выслушает что угодно, обязательно похвалит любую глупость, но не завалит своими ответами. К тому же она уже давно никуда не спешит от моих “брысь”
#истории
Please open Telegram to view this post
VIEW IN TELEGRAM
🤗7❤3👍2
Матрица, которая не стареет?
Неделю назад провела лекцию для системных аналитиков, где среди прочего рассказывала про матрицу RACI. Каждый раз, когда доходит до неё, проживаю что-то вроде сцены в кино, где в герое просыпаются два персонажа-антагониста:
- Практик. Он видит скучающие глаза слушателей курса. В этот раз были черные квадратики выключенного видео, но мой внутренний практик все равно все понял. Он слышит вопрос, который никто не задал вслух: «Куда я это прикручу, тренер?» И где-то внутри понимает, что действительно, большинство никогда к RACI не вернётся.
- Преподаватель. Поправляет очки и строго напоминает: это мы не для галочки, это мы формируем образ мысли!
Матрица RACI появилась в 1960-х и в корпоративном мире стала способом договориться о правилах игры. Расскажу цитатой из BABOK, где RACI присутствует во всех трёх версиях, начиная с самой первой. Вот цитата из второй версии (в 3.0 мне показалось очень много слов):
Правила:
📍Для каждой задачи должен быть определён один и только один ответственный. Тот, кто принимает решения должен присутствовать, но если таких больше одного, то это уже не принятие решений, а пространство для хаоса. В реальности не всегда просто так точно зафиксировать, но полезно подумать кто в реальности несёт ответственность за задачу и на кого ориентироваться в спорных вопросах.
📍Должен быть определён один или несколько исполнителей. Это не обязательно тот же, что несёт ответственность. Бывало в старых документах указывали на титульном листе "отв. Иванов А.Т. ; исп. Неиванов А.Т.". Несколько разных ролей вполне могут исполнять каждый свою часть работ, при этом совсем не быть ни одного исполнителя в задаче не может. Если задачу некому делать, а все участники либо дают советы, либо принимают решения - это явно нездоровая картина, правда?
Эти правила делают процесс изучения ролей и ответственности гораздо более важным, чем формальная таблица в результате. Не так уж просто в большой компании разделить роли именно по заданным категориям, не дополняя никаких комментариев, сносок и оговорок. Бывает искушение добавить больше одного ответственного или сложно найти исполнителей. А бывает, что аналитик и вовсе не предполагает, что полезно как-то оценить полномочия. Эти правила работают как один из инструментов изучения контекста в формате “разложить по полочкам”. Так что преподаватель был прав насчёт образа мысли.
Говоря о сносках и оговорках дополню. Если не хватает букв RACI, есть альтернативы, например:
🏷 RASCI: Добавляет роль Support, которая помогает исполнителю ресурсами, но не несёт ответственности за итог.
🏷 ARPA: Approver, Responsible, Participant, Advisor.
🏷 DACI: Driver, Approver, Contributors, Informed.
Формальная таблица RACI, в составе регламентирующего документа, скорее всего, не будет работать и очень быстро устареет в активных, динамичных проектах. Отсюда появляется ощущение, что время потрачено, а результатом никто не пользуется. В этом прав практик.
Если заглянуть в программы учебных курсов и в описания вакансий, то буквы RACI там встречаются довольно часто. , смотрится странно наравне с владением нотациями моделирования и более сложными фреймворками анализа процессов. На мой взгляд, это признак не столько эффективности инструмента, сколько известности в менеджменте, системном и бизнес-анализе.
📚 Оставлю здесь пару статей:
- Что такое RACI-матрица и как она помогает управлять проектом
- Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?»
#инструменты
Неделю назад провела лекцию для системных аналитиков, где среди прочего рассказывала про матрицу RACI. Каждый раз, когда доходит до неё, проживаю что-то вроде сцены в кино, где в герое просыпаются два персонажа-антагониста:
- Практик. Он видит скучающие глаза слушателей курса. В этот раз были черные квадратики выключенного видео, но мой внутренний практик все равно все понял. Он слышит вопрос, который никто не задал вслух: «Куда я это прикручу, тренер?» И где-то внутри понимает, что действительно, большинство никогда к RACI не вернётся.
- Преподаватель. Поправляет очки и строго напоминает: это мы не для галочки, это мы формируем образ мысли!
Матрица RACI появилась в 1960-х и в корпоративном мире стала способом договориться о правилах игры. Расскажу цитатой из BABOK, где RACI присутствует во всех трёх версиях, начиная с самой первой. Вот цитата из второй версии (в 3.0 мне показалось очень много слов):
Матрица RACI описывает роли участников, вовлечённых в деятельность ... Она определяет, что для каждой конкретной задачи или результата (артефакта) стейкхолдеры могут выполнять одну или несколько из следующих обязанностей:
R (Responsible — Исполнитель) — выполняет работу.
A (Accountable — Ответственный) — принимает окончательное решение (только один человек).
C (Consulted — Консультируемый) — должен быть проконсультирован до выполнения работы и предоставляет свои рекомендации/входные данные.
I (Informed — Информируемый) — означает, что данное лицо должно быть уведомлено о результате работы.
Правила:
📍Для каждой задачи должен быть определён один и только один ответственный. Тот, кто принимает решения должен присутствовать, но если таких больше одного, то это уже не принятие решений, а пространство для хаоса. В реальности не всегда просто так точно зафиксировать, но полезно подумать кто в реальности несёт ответственность за задачу и на кого ориентироваться в спорных вопросах.
📍Должен быть определён один или несколько исполнителей. Это не обязательно тот же, что несёт ответственность. Бывало в старых документах указывали на титульном листе "отв. Иванов А.Т. ; исп. Неиванов А.Т.". Несколько разных ролей вполне могут исполнять каждый свою часть работ, при этом совсем не быть ни одного исполнителя в задаче не может. Если задачу некому делать, а все участники либо дают советы, либо принимают решения - это явно нездоровая картина, правда?
Эти правила делают процесс изучения ролей и ответственности гораздо более важным, чем формальная таблица в результате. Не так уж просто в большой компании разделить роли именно по заданным категориям, не дополняя никаких комментариев, сносок и оговорок. Бывает искушение добавить больше одного ответственного или сложно найти исполнителей. А бывает, что аналитик и вовсе не предполагает, что полезно как-то оценить полномочия. Эти правила работают как один из инструментов изучения контекста в формате “разложить по полочкам”. Так что преподаватель был прав насчёт образа мысли.
Говоря о сносках и оговорках дополню. Если не хватает букв RACI, есть альтернативы, например:
🏷 RASCI: Добавляет роль Support, которая помогает исполнителю ресурсами, но не несёт ответственности за итог.
🏷 ARPA: Approver, Responsible, Participant, Advisor.
🏷 DACI: Driver, Approver, Contributors, Informed.
Формальная таблица RACI, в составе регламентирующего документа, скорее всего, не будет работать и очень быстро устареет в активных, динамичных проектах. Отсюда появляется ощущение, что время потрачено, а результатом никто не пользуется. В этом прав практик.
Если заглянуть в программы учебных курсов и в описания вакансий, то буквы RACI там встречаются довольно часто. , смотрится странно наравне с владением нотациями моделирования и более сложными фреймворками анализа процессов. На мой взгляд, это признак не столько эффективности инструмента, сколько известности в менеджменте, системном и бизнес-анализе.
- Что такое RACI-матрица и как она помогает управлять проектом
- Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?»
#инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍3💯2
Кому-то еще нужно ТЗ?
Видимо меня одолела “предвзятость подтверждения”, та самая, когда человек во всем ищет подтверждение своих гипотез. Я снова думаю о том, насколько актуальны в наши дни документы, из чего они должны состоять и как долго продержатся в эпоху ИИ. Конечно, когда разбирала списки чтения, сами собой выбирались статьи о документации. Здесь собраны разные мнения: от «сжечь ваши системные требования» до «писать обязательно». Объединяет их поиск формата или процесса документирования.
📍Вопросы выживания Пост в этом канале, с которого началась подборка. О том почему артефакты не исчезнут, а просто поменяют роль.
📍ТЗ в 2026 году — писать или не писать? Автор статьи рассуждает, почему без внятного описания требований даже самая гибкая разработка рискует превратиться в угадайку.
📍Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту В моем канале этот доклад встречается пять раз с тех пор как я его услышала на Flow. Просто я очень с ним согласна. Спикер поделился наблюдением, что ТЗ обычно содержит 0,1% информации про проблему, еще 20% - пользовательские требования, а остальное — системные требования. А они точно нужны в таком количестве?
📍Эволюция подходов к работе со спецификациями: от бумажного ТЗ к Everything as Code В этой статье ретроспективный обзор, Requirements as Code и о том, что спецификации возвращаются, но в новом обличье.
📍Можно ли аналитику в 2026 году положиться на ИИ и агентов или ещё нет? Открывала эту статью с опасением обнаружить обнаружить обычное поверхностное описание попытки сгенерировать документацию, но кроме этого здесь есть пара интересных моментов: применение Spec Driven Development, изменение процесса подготовки документации под работу агентов.
#что_почитать
Видимо меня одолела “предвзятость подтверждения”, та самая, когда человек во всем ищет подтверждение своих гипотез. Я снова думаю о том, насколько актуальны в наши дни документы, из чего они должны состоять и как долго продержатся в эпоху ИИ. Конечно, когда разбирала списки чтения, сами собой выбирались статьи о документации. Здесь собраны разные мнения: от «сжечь ваши системные требования» до «писать обязательно». Объединяет их поиск формата или процесса документирования.
📍Вопросы выживания Пост в этом канале, с которого началась подборка. О том почему артефакты не исчезнут, а просто поменяют роль.
📍ТЗ в 2026 году — писать или не писать? Автор статьи рассуждает, почему без внятного описания требований даже самая гибкая разработка рискует превратиться в угадайку.
📍Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту В моем канале этот доклад встречается пять раз с тех пор как я его услышала на Flow. Просто я очень с ним согласна. Спикер поделился наблюдением, что ТЗ обычно содержит 0,1% информации про проблему, еще 20% - пользовательские требования, а остальное — системные требования. А они точно нужны в таком количестве?
📍Эволюция подходов к работе со спецификациями: от бумажного ТЗ к Everything as Code В этой статье ретроспективный обзор, Requirements as Code и о том, что спецификации возвращаются, но в новом обличье.
📍Можно ли аналитику в 2026 году положиться на ИИ и агентов или ещё нет? Открывала эту статью с опасением обнаружить обнаружить обычное поверхностное описание попытки сгенерировать документацию, но кроме этого здесь есть пара интересных моментов: применение Spec Driven Development, изменение процесса подготовки документации под работу агентов.
#что_почитать
👍3🔥2
Что и Как?
Где заканчивается ответственность продакта и начинается ответственность аналитика? Говорили об этом в подкасте и разговор неожиданно ушёл в тему доверия.
Сколько бы сил ни вкладывалось в стандарты и инструкции, границы ролей в IT-команде размываются. Всё чаще от разработчика ждут ответственности за продукт, к которой он не готов. А бывает, что аналитику не доверяют проектирование, которое он привык делать сам.
Когда продакт приносит задачу «сделайте как у них» и уходит, он передаёт аналитику поиск решения. Но достаточно ли доверия, чтобы потом не перепроверять каждый шаг? И не проще ли спрятаться за словами «это не моя сфера»?
Граница между ролями пересобирается в зависимости от контекста, зрелости команды и уровня доверия. Доверие приходится строить через выполнение обещаний, признание ошибок, вопросы вместо додумывания и обсуждение ожиданий. Если не получается - это не всегда ваша вина, потому что доверие в команде касается не только одного участника.
Ещё мы говорили о том, как планирование времени и эмоциональный интеллект влияют на эти границы и, конечно, нашли и разобрали пример.
🎧 Ссылки на выпуск 👇
Яндекс.Музыка
Podster.fm
Telegram
VK
#мысливслух
Где заканчивается ответственность продакта и начинается ответственность аналитика? Говорили об этом в подкасте и разговор неожиданно ушёл в тему доверия.
Сколько бы сил ни вкладывалось в стандарты и инструкции, границы ролей в IT-команде размываются. Всё чаще от разработчика ждут ответственности за продукт, к которой он не готов. А бывает, что аналитику не доверяют проектирование, которое он привык делать сам.
Когда продакт приносит задачу «сделайте как у них» и уходит, он передаёт аналитику поиск решения. Но достаточно ли доверия, чтобы потом не перепроверять каждый шаг? И не проще ли спрятаться за словами «это не моя сфера»?
Граница между ролями пересобирается в зависимости от контекста, зрелости команды и уровня доверия. Доверие приходится строить через выполнение обещаний, признание ошибок, вопросы вместо додумывания и обсуждение ожиданий. Если не получается - это не всегда ваша вина, потому что доверие в команде касается не только одного участника.
Ещё мы говорили о том, как планирование времени и эмоциональный интеллект влияют на эти границы и, конечно, нашли и разобрали пример.
🎧 Ссылки на выпуск 👇
Яндекс.Музыка
Podster.fm
Telegram
VK
#мысливслух
❤3💯2
Как я провела лето
Три года у меня лежали тезисы для доклада о принятии решений. Наконец этим летом тезисы превратились в доклад, и я везу его на конференцию, на «Стачку».
Сначала я хотела рассказать о том, как использовать данные пользовательского опыта. После встречи с программным комитетом решила сместить фокус на другое: что делать, когда данные есть, но их мало, а заинтересованные стороны не могут договориться. Так получилась тема «Как выбирать решения на основе критериев».
Давно не выступала и на репетициях обнаружила, что застряла в лекционном формате. В докладе важнее сразу попасть в точку и не отпускать внимание, а на лекции можно просто пункт за пунктом следовать программе. Хотя, когда на лекции все спят, это тоже обидно.
Сложность еще в том, что конференция мультидисциплинарная и в зале могут оказаться слушатели с очень разным опытом, не обязательно корпоративным и не обязательно в ИТ. Поэтому нужно ухитриться не пренебрегать деталями и контекстом, но и не закопаться в них настолько, чтобы зал заснул. Много работаю над этим 😊
На следующей неделе обязательно расскажу, как всё прошло, и поделюсь материалами доклада. Чтобы посмотреть, что обещано в программе “Стачки” 👉 вот ссылка
#конференции
Три года у меня лежали тезисы для доклада о принятии решений. Наконец этим летом тезисы превратились в доклад, и я везу его на конференцию, на «Стачку».
Сначала я хотела рассказать о том, как использовать данные пользовательского опыта. После встречи с программным комитетом решила сместить фокус на другое: что делать, когда данные есть, но их мало, а заинтересованные стороны не могут договориться. Так получилась тема «Как выбирать решения на основе критериев».
Давно не выступала и на репетициях обнаружила, что застряла в лекционном формате. В докладе важнее сразу попасть в точку и не отпускать внимание, а на лекции можно просто пункт за пунктом следовать программе. Хотя, когда на лекции все спят, это тоже обидно.
Сложность еще в том, что конференция мультидисциплинарная и в зале могут оказаться слушатели с очень разным опытом, не обязательно корпоративным и не обязательно в ИТ. Поэтому нужно ухитриться не пренебрегать деталями и контекстом, но и не закопаться в них настолько, чтобы зал заснул. Много работаю над этим 😊
На следующей неделе обязательно расскажу, как всё прошло, и поделюсь материалами доклада. Чтобы посмотреть, что обещано в программе “Стачки” 👉 вот ссылка
#конференции
👍7❤3
Со “Стачки”
Вернулась с конференции с чувством, что большая задача наконец закрыта. “Выгуляла” тему, которая долго ждала своей очереди, познакомилась с прекрасными людьми и погуляла по набережной Васильевского острова.
Общие впечатления от Стачки я бы уместила в несколько тезисов:
Организация. Что должно быть в тайминге - было в тайминге, помощь волонтеров - была бесценной, темы докладов - разнообразными.
Слушатели. Их было не много и по ощущениям, многие пришли на секцию CEO. Хотя и ИТ-секции совсем не пустовали, я проверяла.
Лингвистика. Записала себе очередную эволюцию слова “фича”: на одном из слайдов встретила “работу с фичёй” через “ё” и поняла, что что-то пропустила в правописании. Пора изучать фичеведение 😉
AI-практики. Они были заявлены основной темой конференции. Тема по-прежнему популярна и привлекает внимание, хотя временами звучали усталые голоса: “Спасибо за доклад, где ни слова об ИИ” .
Было здорово присоединиться к коммьюнити спикеров, оно оказалось душевным. Очень рада всем, кто подписался на наш канал после Стачки.
Теперь о докладах. Было много кейсов, где спикеры делились практическими наработками. Из тех, что я слышала, больше всего запомнился “SRE-трансформация в SmallTech”. Казалось бы, не совсем моя тема, но спикер настолько увлеченно рассказывал о своем опыте, что невозможно оставаться равнодушной. Об эволюции процессов фиксации и разбора инцидентов, выборе метрик качества сервисов. И о том, как сложно прийти к пониманию между инфраструктурной командой и бизнесом в плане метрик понятных и тем и другим.
Еще в моих заметках остался доклад Дмитрия Безуглого “Третий лишний: бизнес, ИТ и AI”, который провоцировал аудиторию вопросом: “Что выберете: Бизнес или ИТ?” и за полчаса доклада привел к мысли, что в условиях AI-трансформации зоной ответственности ИТ станет организация сред для агентских систем, а ключевая роль переходит на сторону бизнеса как владельца описаний контекста, определяющего работу агентов.
Выполняю обещание рассказать как прошло мое выступление. Прошло отлично, в 11 утра воскресенья зал был неполным, но я видела заинтересованные взгляды, фоткающие телефоны и потом слышала хорошие осмысленные вопросы. Волновалась, но не больше обычного - все-таки была уверена в материале и меня отлично поддерживали лидеры секции системного и бизнес-анализа. Правда, увлекалась рассказом и забывала то стоять в нужной точке, то правильно держать микрофон, он был не особенно чувствительный и за любое движение наказывал потерей звука.
О самом докладе расскажу подробнее в следующем посте. Хочу подготовить статью, а не просто опубликовать презентацию.
#конференции
Вернулась с конференции с чувством, что большая задача наконец закрыта. “Выгуляла” тему, которая долго ждала своей очереди, познакомилась с прекрасными людьми и погуляла по набережной Васильевского острова.
Общие впечатления от Стачки я бы уместила в несколько тезисов:
Организация. Что должно быть в тайминге - было в тайминге, помощь волонтеров - была бесценной, темы докладов - разнообразными.
Слушатели. Их было не много и по ощущениям, многие пришли на секцию CEO. Хотя и ИТ-секции совсем не пустовали, я проверяла.
Лингвистика. Записала себе очередную эволюцию слова “фича”: на одном из слайдов встретила “работу с фичёй” через “ё” и поняла, что что-то пропустила в правописании. Пора изучать фичеведение 😉
AI-практики. Они были заявлены основной темой конференции. Тема по-прежнему популярна и привлекает внимание, хотя временами звучали усталые голоса: “Спасибо за доклад, где ни слова об ИИ” .
Было здорово присоединиться к коммьюнити спикеров, оно оказалось душевным. Очень рада всем, кто подписался на наш канал после Стачки.
Теперь о докладах. Было много кейсов, где спикеры делились практическими наработками. Из тех, что я слышала, больше всего запомнился “SRE-трансформация в SmallTech”. Казалось бы, не совсем моя тема, но спикер настолько увлеченно рассказывал о своем опыте, что невозможно оставаться равнодушной. Об эволюции процессов фиксации и разбора инцидентов, выборе метрик качества сервисов. И о том, как сложно прийти к пониманию между инфраструктурной командой и бизнесом в плане метрик понятных и тем и другим.
Еще в моих заметках остался доклад Дмитрия Безуглого “Третий лишний: бизнес, ИТ и AI”, который провоцировал аудиторию вопросом: “Что выберете: Бизнес или ИТ?” и за полчаса доклада привел к мысли, что в условиях AI-трансформации зоной ответственности ИТ станет организация сред для агентских систем, а ключевая роль переходит на сторону бизнеса как владельца описаний контекста, определяющего работу агентов.
Выполняю обещание рассказать как прошло мое выступление. Прошло отлично, в 11 утра воскресенья зал был неполным, но я видела заинтересованные взгляды, фоткающие телефоны и потом слышала хорошие осмысленные вопросы. Волновалась, но не больше обычного - все-таки была уверена в материале и меня отлично поддерживали лидеры секции системного и бизнес-анализа. Правда, увлекалась рассказом и забывала то стоять в нужной точке, то правильно держать микрофон, он был не особенно чувствительный и за любое движение наказывал потерей звука.
О самом докладе расскажу подробнее в следующем посте. Хочу подготовить статью, а не просто опубликовать презентацию.
#конференции
❤5👍5
Как принимать решения на основе критериев
Что можно сделать, если техники приоритизации сломались о реальность? Почти дословно записала свой доклад на недавней конференции и получилась статья об опыте применения матрицы решений: четыре шага, которые превращают эмоциональный спор в обсуждение на основе критериев. В статье разбираю кейс с переходом ERP-платформы на новый стек, где нужно выбрать между сотней устаревших полей.
Даже если вы пока не сталкивались с таким хаосом, инструмент стоит взять на заметку - он пригодится и для выбора между двумя подрядчиками, и для планирования отпуска. Заходите почитать 👉 ссылка
#инструменты #что_почитать
Что можно сделать, если техники приоритизации сломались о реальность? Почти дословно записала свой доклад на недавней конференции и получилась статья об опыте применения матрицы решений: четыре шага, которые превращают эмоциональный спор в обсуждение на основе критериев. В статье разбираю кейс с переходом ERP-платформы на новый стек, где нужно выбрать между сотней устаревших полей.
Даже если вы пока не сталкивались с таким хаосом, инструмент стоит взять на заметку - он пригодится и для выбора между двумя подрядчиками, и для планирования отпуска. Заходите почитать 👉 ссылка
#инструменты #что_почитать
👍2🔥1
Прогнозы, которые не сбылись (и не могли сбыться)
Говорят, в эпоху ИИ умение проверять информацию становится важнее, чем умение её создавать. Пятница — прекрасный повод проверить это на практике, после рабочей недели мозг требует чего-нибудь этакого, необременительного 😊
Вот три цитаты с прогнозами развития технологичных продуктов. Одна из них действительно существовала, а две я сгенерировала и предлагаю вам угадать, где правда, а где художественный вымысел нейросети. Признаюсь честно, идею я подсмотрела недавно у бизнес-тренера Екатерины Лежневой на конференции Ed Tech Expo 2026, в докладе о критическом мышлении.
1️⃣...удалённый шопинг, хотя и возможен, никогда не станет популярным, потому что женщины любят выходить из дома, любят держать товар в руках, любят иметь возможность передумать.
Журнал Times, 1966 год
2️⃣Паровоз, конечно, вещь полезная, но зачем он нужен, если до дачи можно доехать на извозчике, а по дороге ещё и подумать о чём-нибудь хорошем? Прогресс не заменит человеку необходимости остаться наедине с собой.
А. П. Чехов, 1890-е годы
3️⃣Видеотелефония никогда не приживётся. Люди и так не любят смотреть друг другу в глаза, а уж платить за это удовольствие — тем более. Достаточно голоса.
Журнал Popular Mechanics, 1968 год
#разминка
Говорят, в эпоху ИИ умение проверять информацию становится важнее, чем умение её создавать. Пятница — прекрасный повод проверить это на практике, после рабочей недели мозг требует чего-нибудь этакого, необременительного 😊
Вот три цитаты с прогнозами развития технологичных продуктов. Одна из них действительно существовала, а две я сгенерировала и предлагаю вам угадать, где правда, а где художественный вымысел нейросети. Признаюсь честно, идею я подсмотрела недавно у бизнес-тренера Екатерины Лежневой на конференции Ed Tech Expo 2026, в докладе о критическом мышлении.
1️⃣...удалённый шопинг, хотя и возможен, никогда не станет популярным, потому что женщины любят выходить из дома, любят держать товар в руках, любят иметь возможность передумать.
Журнал Times, 1966 год
2️⃣Паровоз, конечно, вещь полезная, но зачем он нужен, если до дачи можно доехать на извозчике, а по дороге ещё и подумать о чём-нибудь хорошем? Прогресс не заменит человеку необходимости остаться наедине с собой.
А. П. Чехов, 1890-е годы
3️⃣Видеотелефония никогда не приживётся. Люди и так не любят смотреть друг другу в глаза, а уж платить за это удовольствие — тем более. Достаточно голоса.
Журнал Popular Mechanics, 1968 год
#разминка
👍1🔥1
Выберите ту цитату, что кажется вам настоящей
Anonymous Quiz
44%
Цитата 1 (предсказание о шоппинге)
34%
Цитата 2 (рассуждение писателя о паровозах)
13%
Цитата 3 (о людях и видеосвязи)
9%
Просто посмотрю ответ
Проверим на CRAAP?
В предыдущем посте-разминке я несколько дней наблюдала выбор между сгенерированными фразами и настоящей. Cгенерированная цитата от имени Чехова почти обошла реальный вариант. Критическое мышление в итоге победило, но с небольшим перевесом.
Чехова я выбрала потому, что я его «фанатка». Вряд ли он сказал бы такое о прогрессе, судя по опубликованным письмам, он рассуждал о нём совсем в другом ключе. Вот из письма к Суворину от 27 марта 1894 года:«Расчетливость и справедливость говорят мне, что в электричестве и паре любви к человеку больше, чем в целомудрии и воздержании от мяса». На этот раз точно-точно такое писал, я проверяла 😊
Чтобы ответить на разминку, многие, как и я, первым делом потянулись к поисковикам. Если решили проверить, можно пользоваться фреймворком CRAAP. Звучит как ребус, но на самом деле - это акроним из названий пяти критериев, придуманных для проверки источников:
📅 Currency (Актуальность). Дата публикации важна. Даже материал прошлого года может быть неактуален. Но для исторической цитаты Чехова это не главный критерий.
🎯Relevance (Уместность). Публикация действительно решает вашу задачу? Перед вами не пересказ, а источник? Скажем, тема прогресса близка чеховским размышлениям, но в моём примере не указано ни произведение, ни письмо и это должно настораживать.
👤Authority (Авторитетность источника). Автор публикации - эксперт в теме? Как бы я ни любила Чехова, я не литературовед. Будьте внимательны, когда я его цитирую 💁🏼♀️
✅ Accuracy (Точность). Можно ли проверить факты? Это ключевой критерий в истории с Чеховым. Его документированные взгляды на прогресс противоположны приписанной фразе. Сохранились и опубликованы письма, где он с энтузиазмом смотрел на развитие техники.
🎭 Purpose (Цель). Зачем создан материал? Не содержит ли конфликт интересов? В моём примере явная манипуляция, я попыталась создать иллюзию «глубокой мысли» от имени классика, чтобы придать вес сгенерированному тезису. И это сработало!
Вот статья с коротким описанием фреймворка и промптами. А можно просто написать: «Проверь по CRAAP-фреймворку следующее утверждение: <утверждение>» и посмотреть, что получится.
#инструменты #ai
В предыдущем посте-разминке я несколько дней наблюдала выбор между сгенерированными фразами и настоящей. Cгенерированная цитата от имени Чехова почти обошла реальный вариант. Критическое мышление в итоге победило, но с небольшим перевесом.
Чехова я выбрала потому, что я его «фанатка». Вряд ли он сказал бы такое о прогрессе, судя по опубликованным письмам, он рассуждал о нём совсем в другом ключе. Вот из письма к Суворину от 27 марта 1894 года:«Расчетливость и справедливость говорят мне, что в электричестве и паре любви к человеку больше, чем в целомудрии и воздержании от мяса». На этот раз точно-точно такое писал, я проверяла 😊
Чтобы ответить на разминку, многие, как и я, первым делом потянулись к поисковикам. Если решили проверить, можно пользоваться фреймворком CRAAP. Звучит как ребус, но на самом деле - это акроним из названий пяти критериев, придуманных для проверки источников:
📅 Currency (Актуальность). Дата публикации важна. Даже материал прошлого года может быть неактуален. Но для исторической цитаты Чехова это не главный критерий.
🎯Relevance (Уместность). Публикация действительно решает вашу задачу? Перед вами не пересказ, а источник? Скажем, тема прогресса близка чеховским размышлениям, но в моём примере не указано ни произведение, ни письмо и это должно настораживать.
👤Authority (Авторитетность источника). Автор публикации - эксперт в теме? Как бы я ни любила Чехова, я не литературовед. Будьте внимательны, когда я его цитирую 💁🏼♀️
✅ Accuracy (Точность). Можно ли проверить факты? Это ключевой критерий в истории с Чеховым. Его документированные взгляды на прогресс противоположны приписанной фразе. Сохранились и опубликованы письма, где он с энтузиазмом смотрел на развитие техники.
🎭 Purpose (Цель). Зачем создан материал? Не содержит ли конфликт интересов? В моём примере явная манипуляция, я попыталась создать иллюзию «глубокой мысли» от имени классика, чтобы придать вес сгенерированному тезису. И это сработало!
Вот статья с коротким описанием фреймворка и промптами. А можно просто написать: «Проверь по CRAAP-фреймворку следующее утверждение: <утверждение>» и посмотреть, что получится.
#инструменты #ai
👍1🔥1