Сбор требований с ИИ: как сократить документацию и ускорить ревью

ИИ-слой: правила внутри процесса аналитики

Обычно ИИ выполняет роль помощника конкретного члена команды: специалист просит ИИ сформулировать требование, проверяет, вставляет результат в документ. Это ускоряет отдельные операции, но не меняет сам процесс.

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

• Последовательность шагов для отслеживания, какой артефакт создаётся на каком шаге, что обязательно, что можно пропустить.
• Скиллы – инструкции, по которым ИИ создаёт конкретный артефакт.
• Шаблоны артефактов – правила детализации внутри каждого документа: нужные секции, колонки и другие элементы.
• Скрипты и хуки: автоматические действия внутри процесса.
• Проектная информация: контекст и данные, необходимые для работы.

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

Discovery Kit – не коробочное решение

Передав команде аналитиков готовый кит, мы увидели, что его нельзя просто перенести на любой проект. Набор правил нужно адаптировать под конкретные задачи.

В первую очередь приходится учитывать:

• процессы и стандарты команды;
• шаблоны и формат артефактов;
• проектный контекст и данные, особенно legacy;
• интеграции с GitLab, CI и трекером;
• доступы к моделям.

Отдельно нужно обучить сотрудников применять правила. Иначе ИИ-слой начинает конфликтовать со сложившимся процессом, и команда возвращается к привычному способу работы.

Ниже – как мы адаптировали Discovery Kit на одном из госпроектов.

‍

Специфика аналитики на госпроектах

Мы реализуем проект по автоматизации процессов контроля на подведомственных объектах для органа муниципального управления.

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

Поэтому процесс требует:

• стандартизации;
• единых шаблонов;
• подробной фиксации требований в документации.

При внедрении Discovery Kit мы столкнулись с несколькими проблемами, которые помогли пересмотреть изначальный набор правил использования ИИ в аналитике.

Проблема 1. ИИ создавал огромные объёмы текста с ненужными данными

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

Решения

• Зафиксировали жесткие правила вместо рекомендаций, например:
  
  • Ничего сверх шаблона. Секций и столбцов, которых в шаблоне нет, в артефакте не появляется.
  • Запрещена секция «Вне scope» (т.е. задача за пределами согласованного объема работ по проекту). 
  • Терминология фиксируется структурированно. Вместо свободного описания используется связка «термин → строка глоссария».
    

• Задали правило гранулярности
  Например, «Просмотр реестра» — одна история. В неё входят фильтрация, сортировка, пагинация, переход в карточку и другие связанные действия. Отдельными историями не становятся валидации, лимиты, формат и размер файла, тексты ошибок и другие детали. Они фиксируются как acceptance criteria той истории, внутри которой применяется правило, а затем переходят в функциональные требования.

В результате: меньше историй означает меньше юзкейсов, меньше групп функциональных требований и меньше сценариев BDD (Behavior-Driven Development – разработки на основе поведения).

Проблема 2. ИИ дублировал правила в нескольких документах

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

Решение

Каждый факт описывается в одном документе-владельце, а остальные артефакты ссылаются на него.

Для push-уведомлений владельцем алгоритма адресации стал процесс диспетчеризации. В нём зафиксированы типы адресации, исключение инициатора и рассылка нескольким получателям. Бриф, требования и юзкейсы теперь ссылаются на этот документ.

Проблема 3. Изменения было сложно отследить

После нескольких итераций было сложно восстановить, что именно изменилось в фиче и почему. Ревьюеру приходилось заново перечитывать документацию.

Решение
Сделали так, чтобы ревьюер читал список правок, а не всю фичу заново.

Для отслеживания изменений мы собрали для Discovery Kit два новых артефакта:

-Секция «История изменений» внутри документа. В описании обязательно называются конкретные затронутые блоки, поля и кнопки. Формулировки вроде «доработан экран» не принимаются, потому что по такой формулировке нельзя понять, что именно изменилось и почему.

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

Что еще мы зашили в Discovery Kit

Санкции: правило без последствий остаётся пожеланием

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

Формулировки, которые звучат как пожелания («запрашивать ссылку на Figma», «сверять анализ влияния») легко пропустить, и этого никто не заметит. То же происходит, когда в процессе нет обязательного шага, который возвращает аналитика к ранее созданному документу и заставляет проверить его по факту.

Теперь выполнение требований встроено в сам процесс, и их нарушение блокирует следующий этап. К примеру, если не сверен анализ влияния с фактом, ревью не запускается.

Как создать набор правил по работе с ИИ для аналитиков

Если вы строите похожий слой над своим процессом, вот последовательность, которая работает у нас.

1. Найдите дефект на живом артефакте. Не «шаблон плохой», а «ошибка в шаблоне такая-то»: лишняя секция, колонка с одинаковыми значениями во всех строках, пересказ вместо ссылки и т.п. 
2. Сформулируйте, как должно быть. Одной фразой в терминах артефакта: что писать в колонку, чего в ней не бывает, кто владеет фактом, а кто ссылается.
3. Положите правило в нужный файл. Правила по заполнению документа (какие секции, что писать в колонку) фиксируются в шаблоне этого документа. Правила о том, какие документы вообще существуют, идут в конфигурацию кита.
4. Напишите, зачем правило и что будет за нарушение. Рядом с правилом в шаблоне оставьте комментарий с причиной, иначе его отменят при первом же неудобстве. И укажите последствие: например, пока поле пустое, фича не проходит ревью.
5. Меняйте шаблон отдельной задачей, не вместе с правкой по фиче. Так видно, когда именно правило появилось и кто его принял.

Что в итоге

Наш опыт показал: Discovery Kit нельзя просто передать команде и ожидать, что он сразу встроится в процесс.

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

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

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

‍