ИИ-инструменты бизнес и системного аналитика: промт для создания критериев приёмки User Story

Привет! На связи Егор Марюшко, в ИТ с 2014 года в роли: бизнес‑эксперта, бизнес и системного аналитика, руководителя отделов бизнес и системного анализа, архитектора решений.

Я не верю в то, что ИИ отберёт у бизнес и системных аналитиков работу.

Как сказал Крейг Винг в одном из своих выступлений:

«ИИ — это невероятно дорогостоящий галлюцинирующий попугай, комбинирующий лишь то, что увидел».

ИИ — это современный и перспективный инструмент, и им надо уметь пользоваться.

Большинство статей и докладов о применении ИИ системными аналитиками рассказывают о том, как исследовать новую для себя предметную область, составить опросник для общения с заказчиком, нарисовать бизнес‑процесс, UML sequence diagram, сгенерировать User Story и так далее. Но часто эти операции требуют:

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

Безусловно, есть варианты эффективного применения, подтверждённые метриками, но чаще это выливается в использование ИИ ради использования ИИ.

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

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

В данной статье разберём промт для создания критериев приемки (Acceptance Criteria — AC) для User Story (US).

Да, кто‑то скажет, что писать AC к US должны тестировщики, но если вы как аналитик хотите получить прогнозируемый результат реализации US, то ключевые AC вы напишете сами =)

В процессе подготовки промта я проверил его применимость на 5 наиболее распространённых и доступных сейчас ИИ‑моделях:

• ChatGPT
• DeepSeek
• Qwen
• Алиса (Яндекс GPT)
• GigaChat

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

Если любопытство взяло верх, то давайте продолжим.

Исследование проводилось на нескольких User Story. В качестве примера рассмотрим типовую User Story для интернет‑магазина:

Каждому ИИ отправляли основной промт, получив в ответ от 5 до 10 критериев приемки, после первого дополнительного запроса были получены от 10 до 18 AC и после второго дополнительного запроса были получены от 15 до 25 AC в зависимости от ИИ.

Все ответы ИИ вы можете найти в полной версии статьи на Хабр (ссылка на статью 👈)

Наблюдения:

1️⃣ Только DeepSeek и Qwen упоминают условие аутентификации/авторизации на регулярной основе.
ChatGPT и Алиса сделали это один или два раза, хотя для просмотра истории заказов авторизация является важным условием.
GigaChat порадовал использованием максимально русифицированной формулировки без иностранных заимствований: «При условии входа покупателя в личный кабинет», хотя есть ощущение, что он имел в виду именно вход, а не проверку доступов.
В защиту ChatGPT и Алисы скажу, что условие аутентификации/авторизации применительно к данной User Story и её критериям приемки можно вынести как базовое, чтобы не писать каждый раз — возможно, это и имелось в виду этими ИИ, так как у них обоих аутентификация/авторизация упомянуты в первом AC. Однако, как показывает практика, упрощение документации ведёт к увеличению количества ошибок и дыр в безопасности. Упомянешь проверку безопасности только при переходе на страницу — и не успеешь моргнуть, как все остальные операции с историей заказов пользователя можно выполнять из‑под любого другого пользователя или вообще без авторизации. Звучит абсурдно, но подобные уязвимости встречаются даже на сайтах крупных авиакомпаний, когда при наличии кода бронирования можно было напрямую зайти на список всех броней пассажира и дальше делать с ними всё, что угодно (реальный кейс, озвученный на недавней конференции по информационной безопасности).

AC с авторизацией / всего AC

• ChatGPT — 2/25
• DeepSeek — 19/19
• Qwen — 13/15
• Алиса (Яндекс GPT) — 1/25
• GigaChat — 0–1/16

2️⃣ Первый критерий приемки у всех связан со входом, переходом, открытием или выбором пункта меню «История заказов».

ChatGPT, Алиса и GigaChat с барского плеча предлагают сразу вывести пользователю список ВСЕХ его заказов, тем самым при наличии долгой истории покупок намертво повесив ЛК или отвалившись по timeout.
У DeepSeek и Qwen упомянуто ограничение выгрузки заказов за последние 30 дней, что улучшает ситуацию. В то же время у каждого ИИ во второй порции AC добавляется критерий приемки с упоминанием пагинации или бесконечной прокрутки.

ChatGPT, DeepSeek, Qwen полноценно указывают, что у страницы есть лимит на количество отображаемых заказов.

Qwen сразу предлагает варианты: пагинация или бесконечная прокрутка.

Алиса и GigaChat косвенно указывают на пагинацию, напрямую не упоминая про лимит записей на странице.

На мой взгляд, данный кейс хорошо показывает, как ИИ идёт от простых и общих формулировок к усложнению и детализации при дополнительных запросах. Однако «живой» аналитик чаще всего совместит два данных AC в одном первом, написав примерно следующее: «При условии: покупатель авторизован в системе, когда: покупатель инициирует отображение истории заказов, то: система отображает покупателю историю его последних NN записей».

3️⃣ Несмотря на явно указанное условие в промте «критерии приемки не повторяют друг друга», Qwen создал один дубль критерия приемки, немного его перефразировав:

• При условии, что покупатель авторизован в личном кабинете, когда открывает раздел «История заказов», то система отображает список всех его заказов по умолчанию за последние 30 дней.
• При условии, что покупатель авторизован и открывает историю заказов впервые, когда раздел загружается, то система автоматически устанавливает фильтр по дате на последние 30 дней и отображает соответствующие заказы (если есть).

4️⃣ Большинство корректных критериев приемки повторяются у всех ИИ, однако у Qwen, ChatGPT, DeepSeek и Алисы попадаются уникальные AC, не дублирующиеся у других ИИ.
Например:

• ChatGPT — При условии, что пользователь выполняет поиск заказов за большой период, когда время отклика превышает допустимое значение, то система отображает индикатор загрузки до завершения поиска.
• DeepSeek — При условии, что покупатель аутентифицирован и система отображает список заказов, когда он нажимает кнопку «Сбросить фильтры», то система возвращает отображение к состоянию по умолчанию (заказы за последние 30 дней).
• Qwen — При условии, что покупатель авторизован и копирует URL страницы с применённым фильтром по дате, когда открывает эту ссылку в новой сессии (после повторной авторизации), то система восстанавливает тот же период и отображает соответствующие заказы.
• Алиса — При условии изменения цены товара после покупки, когда пользователь просматривает историю, то система отображает исходную цену на момент заказа.

5️⃣ Все ИИ, кроме Qwen, предлагают то или иное количество AC, связанных с другими User Story, смежными с исходной

AC для других историй / всего AC:

• ChatGPT — 2/25

Пример User Story о просмотре деталей заказа: «При условии, что пользователь открывает детальную карточку заказа, когда она содержит несколько товаров, то система отображает полную информацию по каждому товару без усечения данных».

• DeepSeek — 4/19

Пример User Story об экспорте чеков: «При условии, что покупатель аутентифицирован и система отображает детали заказа, когда он нажимает кнопку „Скачать чек“, то система формирует и предоставляет для скачивания PDF‑файл с фискальным чеком».

• Qwen — 0/15

• Алиса (Яндекс GPT) — 13/25

Пример User Story об экспорте истории заказов: «При условии экспорта истории заказов, когда пользователь нажимает кнопку „Экспорт“, то система формирует файл в формате CSV/PDF с данными всех отображаемых заказов».

• GigaChat — 4/16

Пример User Story об экспорте истории заказов: «При условии экспорта истории заказов, когда покупатель нажимает кнопку „Экспорт“, то система генерирует файл формата CSV/XLSX с историей заказов».

6️⃣ Все ИИ, кроме Алисы, в некоторых AC фантазируют и додумывают детали, о которых не указано в исходных данных. Однако у Алисы больше всего AC, которые можно отнести к другим User Story.

• Додумывание деталей на примере DeepSeek: «При условии, что покупатель аутентифицирован и система отображает список заказов, когда он наводит курсор на иконку „i“ рядом с номером заказа, то система показывает всплывающую подсказку с основной информацией о заказе (дата, сумма, статус)».

7️⃣ DeepSeek создает AC после нового запроса как отдельный набор AC. ChatGPT, Qwen, Алиса, GigaChat добавляют новые критерии к ранее созданным и в каждом ответе формируют единый список со сквозной нумерацией.

Думаю, в данных результатах можно найти и другие закономерности и особенности — здесь перечислены наиболее существенные.

Инструкция по применению:

1️⃣ У вас уже сформирован список User Story, для которых вам необходимо написать критерии приемки. User Story должны максимально соответствовать критериям качества INVEST.

2️⃣ Выбираете любой удобный для вас ИИ.

3️⃣ Копируете основной промт в чат взаимодействия с ИИ:
1) заменяете в основном промте [ОТРАСЛЬ] на название вашей предметной области, для которой вы разрабатываете ПО, например:

• в e‑commerce
• в онлайн‑образовании
• в банковских операциях
• и так далее

2) заменяете [ВАША USER STORY] на текст вашей User Story, например: «Я как покупатель интернет‑магазина хочу иметь возможность видеть историю своих заказов за заданный период времени, для того чтобы иметь возможность найти информацию о ранее заказанных товарах».

4️⃣ Запускаете выполнение промта и получаете первую порцию критериев приемки.

5️⃣ Копируете дополнительный промт в чат взаимодействия с ИИ.

6️⃣ Запускаете выполнение дополнительного промта первый раз, ждёте ответа и запускаете второй раз.

• Двойной запуск дополнительного промта вместе с запуском основного промта позволяет получить в среднем от 15 до 25 критериев приемки.
• Ответ на основной промт чаще всего даёт основные базовые критерии приемки для User Story.
• Ответ на первый дополнительный промт чаще всего даёт от 40 до 80% новых хороших критериев приемки.
• Ответ на второй дополнительный промт чаще всего даёт от 10 до 50% новых хороших критериев приемки.
• В третьем и последующих запросах ИИ начинает активно галлюцинироватьфантазировать о том, что ещё может быть в вашей системе и как это может быть задействовано в вашей User Story, или уходить в критерии приемки смежных User Story, которые могут вытекать из вашей, которые он самостоятельно додумал, что существенно снижает полезность его ответов в диапазон 0–30%.

7️⃣ Копируете полученные результаты в свою документацию/базу знаний, удаляете избыточные и фантазийные критерии приемки и уточняете полезные.

Применимость:

Как показала практик, у опытного анлитика обдумывание и написание одного критерия приемки может занимать 4–6–10 минут, у начинающего — 5–10 и более минут. Создание критериев приемки через ИИ и последующая валидация в среднем занимает 1–3–5 минут на один критерий у опытного специалиста и 3–6 минут у начинающего. Таким образом, получаем примерно 30-50% сокращение трудозатрат на подготовку критериев приемки.

Выводы:

1. Данный промт можно применять как есть для сокращения своих трудозатрат.
2. Выбор того или иного ИИ незначительно влияет на качество исходного набора критериев приемки — в любом случае его необходимо валидировать.
3. Для улучшения качества исходного набора критериев приемки необходимо добавлять больше контекста в промт, как следствие — тратить на его подготовку больше времени, что усложняет и удорожает его использование.
4. Создание критериев приёмки через ИИ — это как дать задачу джуну и провести последующее ревью. Один из топ-10 российских банков ведёт активное внедрение ИИ во всех своих отделах и подразделениях, фактически заставляя сначала попробовать решить любую задачу через ИИ. Не везде это эффективно, но они пробуют — и очень быстро нарабатывают опыт, нащупывая верный путь.
5. Самое главное, что они позиционируют ИИ для сотрудников не как того, кто заменит вас на работе, а как вашего нового коллегу, которому можно делегировать часть рутинных и простых задач. Теперь у каждого сотрудника этого банка есть один виртуальный подчинённый — и это, на мой взгляд, гениальный ход!

Буду рад узнать примеры ваших промтов и обсудить особенности их применения в комментариях!

Надеюсь, материал будет вам полезен! До встречи в следующей статье!