Бизнес-запрос часто приходит в виде пожелания: «ускорить согласование», «снизить число ошибок», «сделать отчёт понятнее». Это ещё не требование. В нём нет наблюдаемого исхода, по которому можно проверить, что изменение помогло.

Я начинаю с вопроса: что должен увидеть пользователь после изменения и в какой ситуации? Например, не «ускорить оплату», а «покупатель получает подтверждение заказа не позднее чем через минуту после успешной авторизации». Такой исход можно связать со сценарием, источником и проверкой.

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

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

Такая карточка нужна и при изменении требования. Если владелец меняет ожидаемый результат или ограничение, команда сразу видит, какие сценарии и проверки потеряли основание. Без этой связи старый тест может оставаться зелёным для уже неактуальной задачи.

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

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

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