Вопросы выживания

Недавно консультировала коллегу, которому впервые пришлось составлять функциональные требования. Наш разговор свёлся к обсуждению ответов ИИ с точки зрения, что там “похоже на правду”. Мне было интересно, что коллега честно обратился за помощью, чтобы разобраться в нейро-ответах.

Давно думаю: как долго в отрасли будет держаться эта игра, когда описание от ИИ, передаётся в базу знаний или в бэклог?
На этой волне в блоге IIBA встретилась статья “Артефакты, которые переживут ИИ окажутся совсем не теми, что вы ожидаете” (источник). Автор пишет, что фокус рассуждений об артефактах в эпоху ИИ нужно сместить в сторону целей этих самых артефактов. Часто говорят, стоит ли вообще производить сами артефакты, когда за пару часов можно сгенерировать прототип и за десять минут можно собрать пакет требований из маркированного списка правил? При этом теряется вопрос: что делали эти артефакты и нужно ли, чтобы эта работа всё ещё выполнялась?

У документации две основные задачи: координация и фиксация контекста. Первое - структурирование общения между продуктом и разработкой: фиксация задач, правил и определений. Есть понимание, что эта часть дешевеет, можно быстро составить маппинг, диаграмму или текстовое описание готовых правил. При этом фиксация контента становится более ценной и чувствительной к ошибкам. Потому что потребителем этих знаний становятся не только коллеги, но и ИИ-агенты, которые не имеют другого контекста, кроме того, что записан в артефактах. И они могут любую ошибку обыграть и оформить так убедительно, что обнаружить её очень сложно.

Ещё одно интересное наблюдение в том, что на первый план выходит навык оценки достоверности готового артефакта. Раньше бизнес-аналитики много учились создавать документы и исключать неопределённость до того как что-то оформлено. Когда любой может за пару минут создать что-то похожее на аккуратные требования, учиться нужно оценивать уже готовое. Это другой навык, который требуется отдельно развивать.

В этом всем есть шанс выжить у пользовательских историй и критериев приёмки. Но не в формате, адаптированном для координации команд, что мы чаще всего применяли в последнее время.

Мы когда-то обсуждали с одним из гостей подкаста “Контекст, контракт и артефакт”, что под историей понимают всё, что угодно, включая use case. Но их исходное назначение было передавать контекст принятия решений и критерии для оценки готовности фичи. Задача пользовательской истории - служить краткой формулировкой того, кому что нужно, что они пытаются сделать и почему это важно. В таком формате информация полезна и коллеге, которому нужно оценить пять нейро-вариантов спецификаций. и агенту, которому поручено генерировать новые варианты.

Изменился конечный потребитель, но не требование к ясному, долговременному описанию контекста. Выживут те артефакты, которые сохраняют обоснование решений, а ключевой навык аналитика смещается от «написать правильно» к «понять, почему это правильно, и объяснить другим».

Так что на той консультации, где мы обсуждали достоверность нейро-ответов, направление было верным.🌱

#мысливслух #ai

Чем аналитик DWH отличается от других аналитиков?

Такие вопросы мы обсуждали в новом выпуске, который записали в Воронеже. Вместе с соавтором проделали около 467 километров пути, чтобы встретиться с Татьяной Половинкиной - опытным аналитиком DWH и спикером.

Разговор с увлечённым опытным экспертом в смежной сфере знаний - это всегда большое удовольствие и новые вопросы к размышлению. Я задумалась вот о чем:

📍Существует ли понятие MVP в работе с данными? В каком значении ни взять этот термин Minimum Viable Product или Minimum Valuable Product - в основе лежит проверка гипотезы, что задача реализуема или что она может приносить ценность. Конечно, не очень умно залить в витрину наугад сырые данные или предложить регулятору попробовать MVP его отчёта, но, наверное, реально выбрать базовые метрики и данные для них или организовать “песочницу”? А что об этом рассказала наша гостья лучше послушать в выпуске 👇
📍Как оценивается качество данных? До недавнего времени я руководствовалась тем, что есть понятные общие критерии: дату и время не стоит хранить строкой с непонятным часовым поясом, серию и номер паспорта не хранить числом, нейминг должен быть адекватным… При этом у большинства аналитиков бывают случаи, когда задачу решить нужно в срок, а смежная система не готова дать данные в хорошем формате, на преобразование нет ресурсов и заказчика вполне устраивает та условная строка, что имеется - приходится соглашаться на компромисс. Может быть, критерии оценки должны быть привязаны больше к бизнес-цели или к техническому пониманию качества? 🤔

После разговора мы ещё собрали ссылки на статьи доклады по теме работы с данными, они доступны в сообществах подкаста в ВК и в Телеграмм.

Выпуск доступен по ссылкам 👇
Яндекс.Музыка
Podster.fm
Telegram
VK

#подкаст

Контекст решает всё. JTBD для аналитика

После того как написала здесь об артефактах в эпоху ИИ и важности фиксации контекста, я поймала себя на мысли: а как мы вообще описываем контекст, в котором эти артефакты рождаются?

Перерыла стандарты, заглянула в старые конспекты с курсов по 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

#инструменты

Кому-то еще нужно ТЗ?

Видимо меня одолела “предвзятость подтверждения”, та самая, когда человек во всем ищет подтверждение своих гипотез. Я снова думаю о том, насколько актуальны в наши дни документы, из чего они должны состоять и как долго продержатся в эпоху ИИ. Конечно, когда разбирала списки чтения, сами собой выбирались статьи о документации. Здесь собраны разные мнения: от «сжечь ваши системные требования» до «писать обязательно». Объединяет их поиск формата или процесса документирования.

📍Вопросы выживания Пост в этом канале, с которого началась подборка. О том почему артефакты не исчезнут, а просто поменяют роль.

📍ТЗ в 2026 году — писать или не писать? Автор статьи рассуждает, почему без внятного описания требований даже самая гибкая разработка рискует превратиться в угадайку.

📍Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту В моем канале этот доклад встречается пять раз с тех пор как я его услышала на Flow. Просто я очень с ним согласна. Спикер поделился наблюдением, что ТЗ обычно содержит 0,1% информации про проблему, еще 20% - пользовательские требования, а остальное — системные требования. А они точно нужны в таком количестве?

📍Эволюция подходов к работе со спецификациями: от бумажного ТЗ к  Everything as Code В этой статье ретроспективный обзор, Requirements as Code и о том, что спецификации возвращаются, но в новом обличье.

📍Можно ли аналитику в 2026 году положиться на ИИ и агентов или ещё нет? Открывала эту статью с опасением обнаружить обнаружить обычное поверхностное описание попытки сгенерировать документацию, но кроме этого здесь есть пара интересных моментов: применение Spec Driven Development, изменение процесса подготовки документации под работу агентов.

#что_почитать

Что и Как?

Где заканчивается ответственность продакта и начинается ответственность аналитика? Говорили об этом в подкасте и разговор неожиданно ушёл в тему доверия.

Сколько бы сил ни вкладывалось в стандарты и инструкции, границы ролей в IT-команде размываются. Всё чаще от разработчика ждут ответственности за продукт, к которой он не готов. А бывает, что аналитику не доверяют проектирование, которое он привык делать сам.

Когда продакт приносит задачу «сделайте как у них» и уходит, он передаёт аналитику поиск решения. Но достаточно ли доверия, чтобы потом не перепроверять каждый шаг? И не проще ли спрятаться за словами «это не моя сфера»?

Граница между ролями пересобирается в зависимости от контекста, зрелости команды и уровня доверия. Доверие приходится строить через выполнение обещаний, признание ошибок, вопросы вместо додумывания и обсуждение ожиданий. Если не получается - это не всегда ваша вина, потому что доверие в команде касается не только одного участника.

Ещё мы говорили о том, как планирование времени и эмоциональный интеллект влияют на эти границы и, конечно, нашли и разобрали пример.

🎧 Ссылки на выпуск 👇
Яндекс.Музыка
Podster.fm
Telegram
VK

#мысливслух

Как я провела лето

Три года у меня лежали тезисы для доклада о принятии решений. Наконец этим летом тезисы превратились в доклад, и я везу его на конференцию, на «Стачку».

Сначала я хотела рассказать о том, как использовать данные пользовательского опыта. После встречи с программным комитетом решила сместить фокус на другое: что делать, когда данные есть, но их мало, а заинтересованные стороны не могут договориться. Так получилась тема «Как выбирать решения на основе критериев».

Давно не выступала и на репетициях обнаружила, что застряла в лекционном формате. В докладе важнее сразу попасть в точку и не отпускать внимание, а на лекции можно просто пункт за пунктом следовать программе. Хотя, когда на лекции все спят, это тоже обидно.

Сложность еще в том, что конференция мультидисциплинарная и в зале могут оказаться слушатели с очень разным опытом, не обязательно корпоративным и не обязательно в ИТ. Поэтому нужно ухитриться не пренебрегать деталями и контекстом, но и не закопаться в них настолько, чтобы зал заснул. Много работаю над этим 😊

На следующей неделе обязательно расскажу, как всё прошло, и поделюсь материалами доклада. Чтобы посмотреть, что обещано в программе “Стачки” 👉 вот ссылка

#конференции

Со “Стачки”

Вернулась с конференции с чувством, что большая задача наконец закрыта. “Выгуляла” тему, которая долго ждала своей очереди, познакомилась с прекрасными людьми и погуляла по набережной Васильевского острова.

Общие впечатления от Стачки я бы уместила в несколько тезисов:
Организация. Что должно быть в тайминге - было в тайминге, помощь волонтеров - была бесценной, темы докладов - разнообразными.
Слушатели. Их было не много и по ощущениям, многие пришли на секцию CEO. Хотя и ИТ-секции совсем не пустовали, я проверяла.
Лингвистика. Записала себе очередную эволюцию слова “фича”: на одном из слайдов встретила “работу с фичёй” через “ё” и поняла, что что-то пропустила в правописании. Пора изучать фичеведение 😉
AI-практики. Они были заявлены основной темой конференции. Тема по-прежнему популярна и привлекает внимание, хотя временами звучали усталые голоса: “Спасибо за доклад, где ни слова об ИИ” .

Было здорово присоединиться к коммьюнити спикеров, оно оказалось душевным. Очень рада всем, кто подписался на наш канал после Стачки.

Теперь о докладах. Было много кейсов, где спикеры делились практическими наработками. Из тех, что я слышала, больше всего запомнился “SRE-трансформация в SmallTech”. Казалось бы, не совсем моя тема, но спикер настолько увлеченно рассказывал о своем опыте, что невозможно оставаться равнодушной. Об эволюции процессов фиксации и разбора инцидентов, выборе метрик качества сервисов. И о том, как сложно прийти к пониманию между инфраструктурной командой и бизнесом в плане метрик понятных и тем и другим.

Еще в моих заметках остался доклад Дмитрия Безуглого “Третий лишний: бизнес, ИТ и AI”, который провоцировал аудиторию вопросом: “Что выберете: Бизнес или ИТ?” и за полчаса доклада привел к мысли, что в условиях AI-трансформации зоной ответственности ИТ станет организация сред для агентских систем, а ключевая роль переходит на сторону бизнеса как владельца описаний контекста, определяющего работу агентов.

Выполняю обещание рассказать как прошло мое выступление. Прошло отлично, в 11 утра воскресенья зал был неполным, но я видела заинтересованные взгляды, фоткающие телефоны и потом слышала хорошие осмысленные вопросы. Волновалась, но не больше обычного - все-таки была уверена в материале и меня отлично поддерживали лидеры секции системного и бизнес-анализа. Правда, увлекалась рассказом и забывала то стоять в нужной точке, то правильно держать микрофон, он был не особенно чувствительный и за любое движение наказывал потерей звука.

О самом докладе расскажу подробнее в следующем посте. Хочу подготовить статью, а не просто опубликовать презентацию.

#конференции

Как принимать решения на основе критериев

Что можно сделать, если техники приоритизации сломались о реальность? Почти дословно записала свой доклад на недавней конференции и получилась статья об опыте применения матрицы решений: четыре шага, которые превращают эмоциональный спор в обсуждение на основе критериев. В статье разбираю кейс с переходом ERP-платформы на новый стек, где нужно выбрать между сотней устаревших полей.

Даже если вы пока не сталкивались с таким хаосом, инструмент стоит взять на заметку - он пригодится и для выбора между двумя подрядчиками, и для планирования отпуска. Заходите почитать 👉 ссылка

#инструменты #что_почитать

Прогнозы, которые не сбылись (и не могли сбыться)

Говорят, в эпоху ИИ умение проверять информацию становится важнее, чем умение её создавать. Пятница — прекрасный повод проверить это на практике, после рабочей недели мозг требует чего-нибудь этакого, необременительного 😊

Вот три цитаты с прогнозами развития технологичных продуктов. Одна из них действительно существовала, а две я сгенерировала и предлагаю вам угадать, где правда, а где художественный вымысел нейросети. Признаюсь честно, идею я подсмотрела недавно у бизнес-тренера Екатерины Лежневой на конференции Ed Tech Expo 2026, в докладе о критическом мышлении.

1️⃣...удалённый шопинг, хотя и возможен, никогда не станет популярным, потому что женщины любят выходить из дома, любят держать товар в руках, любят иметь возможность передумать.
Журнал Times, 1966 год

2️⃣Паровоз, конечно, вещь полезная, но зачем он нужен, если до дачи можно доехать на извозчике, а по дороге ещё и подумать о чём-нибудь хорошем? Прогресс не заменит человеку необходимости остаться наедине с собой.
А. П. Чехов, 1890-е годы

3️⃣Видеотелефония никогда не приживётся. Люди и так не любят смотреть друг другу в глаза, а уж платить за это удовольствие — тем более. Достаточно голоса.
Журнал Popular Mechanics, 1968 год

#разминка

Проверим на CRAAP?

В предыдущем посте-разминке я несколько дней наблюдала выбор между сгенерированными фразами и настоящей. Cгенерированная цитата от имени Чехова почти обошла реальный вариант. Критическое мышление в итоге победило, но с небольшим перевесом.

Чехова я выбрала потому, что я его «фанатка». Вряд ли он сказал бы такое о прогрессе, судя по опубликованным письмам, он рассуждал о нём совсем в другом ключе. Вот из письма к Суворину от 27 марта 1894 года:«Расчетливость и справедливость говорят мне, что в электричестве и паре любви к человеку больше, чем в целомудрии и воздержании от мяса». На этот раз точно-точно такое писал, я проверяла 😊

Чтобы ответить на разминку, многие, как и я, первым делом потянулись к поисковикам. Если решили проверить, можно пользоваться фреймворком CRAAP. Звучит как ребус, но на самом деле - это акроним из названий пяти критериев, придуманных для проверки источников:

📅 Currency (Актуальность). Дата публикации важна. Даже материал прошлого года может быть неактуален. Но для исторической цитаты Чехова это не главный критерий.

🎯Relevance (Уместность). Публикация действительно решает вашу задачу? Перед вами не пересказ, а источник? Скажем, тема прогресса близка чеховским размышлениям, но в моём примере не указано ни произведение, ни письмо и это должно настораживать.

👤Authority (Авторитетность источника). Автор публикации - эксперт в теме? Как бы я ни любила Чехова, я не литературовед. Будьте внимательны, когда я его цитирую 💁🏼‍♀️

✅ Accuracy (Точность). Можно ли проверить факты? Это ключевой критерий в истории с Чеховым. Его документированные взгляды на прогресс противоположны приписанной фразе. Сохранились и опубликованы письма, где он с энтузиазмом смотрел на развитие техники.

🎭 Purpose (Цель). Зачем создан материал? Не содержит ли конфликт интересов? В моём примере явная манипуляция, я попыталась создать иллюзию «глубокой мысли» от имени классика, чтобы придать вес сгенерированному тезису. И это сработало!

Вот статья с коротким описанием фреймворка и промптами. А можно просто написать: «Проверь по CRAAP-фреймворку следующее утверждение: <утверждение>» и посмотреть, что получится.

#инструменты #ai