AI-подход к сбору требований. Часть 1

Месяц назад мы начали проектировать одну систему, и, конечно же, все началось со сбора требований. На сегодняшний день у нас 285 пронумерованных решений, 70 use case, 20 сквозных процессов и шесть раундов вопросов к заказчику. Кода — по прежнему ноль строк.

Это не провал планирования. Это осознанный размен, который стал возможен из-за одной вещи: стоимость инструмента, которым спрашивают, упала почти до нуля.

Расскажу, что именно поменялось, что мы из этого получили и какой новый класс ошибок пришёл вместе с этим. Последнее — самое интересное, потому что о нём не пишут.

Проблема, которая была всегда Требования собирают двумя способами, и оба плохие.

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

Способ второй: прототип. Вы рисуете кликабельный макет, и заказчик реагирует на конкретику: «нет, тут не так». Работает гораздо лучше. Но макет дорог: неделя дизайнера на сценарий, и переделка каждого раунда — ещё неделя. Поэтому макетов делают два-три и показывают один раз.

Экономика убивала второй способ. Но его польза - очевидна.

Что изменилось Мы собрали десять кликабельных сборок, по одной на сквозной сценарий, которые определили с заказчиком на самой первой встрече. Не макеты — работающие экраны с состоянием, переключателями и развилками. Все сборки имеют единое ядро с логикой управления экранами, и единый набор экранов, чтобы для заказчика каждая сборка была похожа на предыдущую.

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

Полный набор пересобирается за ночь. За две недели мы прошли шесть раундов: показали, получили замечания, разобрали, пересобрали, показали снова.

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

Пять приёмов, которые из этого выросли

1. Вопрос стоит у экрана, а не в конце. Никакой итоговой анкеты ,потому что человек отвечает на вопрос о том, что у него перед глазами. Вопрос «а что ещё мы забыли?» в конце не отвечает никто и никогда.

2. У каждого вопроса есть умолчание, и молчание — это ответ. К каждому вопросу мы пишем: «если промолчите, мы сделаем так». Это меняет экономику ответа для заказчика: он отвечает только там, где мы не угадали. Из восемнадцати вопросов пятого раунда он ответил на тринадцать — и пять умолчаний прошли молча, как и задумано.

3. Каждое решение — с дословной цитатой и пометкой, чьё оно. 285 решений, у каждого: формулировка, дословная цитата источника (с опечатками заказчика — их мы не правим) и пометка `[П]` или `[В]` — сказал заказчик или вывели мы. Через месяц это единственное, что позволяет отличить требование от собственной догадки, которая успела показаться фактом.

4. Прототип проверяется автоматически — как код. На десять сборок — 534 автоматических утверждения, прогон в настоящем браузере. Плюс стоп-лист из 35 запрещённых формулировок.

Продолжение в следующей части.