Вопросы выживания
Недавно консультировала коллегу, которому впервые пришлось составлять функциональные требования. Наш разговор свёлся к обсуждению ответов ИИ с точки зрения, что там “похоже на правду”. Мне было интересно, что коллега честно обратился за помощью, чтобы разобраться в нейро-ответах.
Давно думаю: как долго в отрасли будет держаться эта игра, когда описание от ИИ, передаётся в базу знаний или в бэклог? На этой волне в блоге IIBA встретилась статья “Артефакты, которые переживут ИИ окажутся совсем не теми, что вы ожидаете” (источник). Автор пишет, что фокус рассуждений об артефактах в эпоху ИИ нужно сместить в сторону целей этих самых артефактов. Часто говорят, стоит ли вообще производить сами артефакты, когда за пару часов можно сгенерировать прототип и за десять минут можно собрать пакет требований из маркированного списка правил? При этом теряется вопрос: что делали эти артефакты и нужно ли, чтобы эта работа всё ещё выполнялась?
У документации две основные задачи: координация и фиксация контекста. Первое - структурирование общения между продуктом и разработкой: фиксация задач, правил и определений. Есть понимание, что эта часть дешевеет, можно быстро составить маппинг, диаграмму или текстовое описание готовых правил. При этом фиксация контента становится более ценной и чувствительной к ошибкам. Потому что потребителем этих знаний становятся не только коллеги, но и ИИ-агенты, которые не имеют другого контекста, кроме того, что записан в артефактах. И они могут любую ошибку обыграть и оформить так убедительно, что обнаружить её очень сложно.
Ещё одно интересное наблюдение в том, что на первый план выходит навык оценки достоверности готового артефакта. Если раньше бизнес-аналитики много учились создавать документы и исключать неопределённость до того как что-то оформлено. Когда любой может за пару минут создать что-то похожее на аккуратные требования, учиться нужно оценивать уже готовое. Это другой навык, который требуется отдельно развивать.
В этом всем есть шанс выжить у пользовательских историй и критериев приёмки. Но не в формате, адаптированном для координации команд, что мы чаще всего применяли в последнее время.
Мы когда-то обсуждали с одним из гостей подкаста “Контекст, контракт и артефакт”, что под историей понимают всё, что угодно, включая use case. Но их исходное назначение было передавать контекст принятия решений и критерии для оценки готовности фичи. Задача пользовательской истории - служить краткой формулировкой того, кому что нужно, что они пытаются сделать и почему это важно. В таком формате информация полезна и коллеге, которому нужно оценить пять нейро-вариантов спецификаций. и агенту, которому поручено генерировать новые варианты.
Изменился конечный потребитель, но не требование к ясному, долговременному описанию контекста. Выживут те артефакты, которые сохраняют обоснование решений, а ключевой навык аналитика смещается от «написать правильно» к «понять, почему это правильно, и объяснить другим».
Так что на той консультации, где мы обсуждали достоверность нейро-ответов, направление было верным.🌱
