Александр Костин – AI для продакт-менеджера: PRD, требования и контроль качества (страница 6)

имеет потенциальный ущерб от ошибки выше заданного порога (по деньгам/репутации).

Если условий нет, достаточно Gate. Если есть – Deep.

Так машина проверок становится управляемой и не превращается в бюрократию.

Отчёт по качеству: два слоя, чтобы всем было удобно

Большая проблема отчётов ИИ в том, что они либо слишком длинные, либо слишком короткие. Чтобы отчёт реально жил в команде, он должен иметь два слоя.

Слой 1 – Summary для руководителя/продакта.

5–10 пунктов: блокеры, критические риски, сколько дефектов по типам, готовность (Ready/Not Ready), что обязательно исправить до разработки.

Слой 2 – Detail для автора требований.

Полный список дефектов, сгруппированный по таксономии, с указанием места в тексте, вопросами и шаблонами формулировок.

Это не «красивое оформление». Это способ внедрить инструмент. Руководителю нужен сигнал. Автору нужен список действий. Разработчику нужен список неопределённостей. Тестировщику нужны критерии приёмки и сценарии.

Если отчёт один и он «для всех», в итоге он не для никого.

Как бороться с повторяющимися замечаниями: библиотека правил и авто-обучение процесса

Когда ИИ повторяет одни и те же замечания, это не проблема ИИ. Это сигнал о системной слабости процесса. Значит, команда не встраивает исправления в стандарт.

Практическое решение – «библиотека правил» и шаблонов. Если у вас постоянно не хватает критериев приёмки, вы создаёте стандартный блок «как писать критерии приёмки» и добавляете его в шаблон требований. Если постоянно забывают роли, вы добавляете обязательный раздел «Роли и права». Если постоянно забывают негативные сценарии, вы добавляете раздел «Ошибки и исключения».

ИИ в этом контуре становится инструментом выявления повторяемых дефектов. Вы раз в месяц смотрите статистику: какие типы дефектов встречаются чаще всего, и улучшаете шаблон и стандарт. Через 2–3 итерации качество растёт само, потому что «правильная форма» встроена в документ.

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

Трассируемость: как связать требования с целями и тестами

Один из признаков зрелой системы требований – трассируемость. Это когда можно ответить на вопросы:

зачем это требование; какую цель закрывает; как проверить, что оно выполнено.

Практически это делается просто: у каждого требования или сценария есть ссылка на цель (например, идентификатор цели или метрики) и есть критерии приёмки, которые превращаются в тесты.

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

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

Техническая реализация машины проверок без кода: как настроить процесс в реальной команде

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

Единый шаблон требований.

Документ с обязательными разделами: цель, контекст, роли, сценарии, данные, интеграции, ошибки, критерии приёмки, ограничения.

Единый «паспорт проекта».

Короткий файл или блок текста, который вставляется в начало промпта аудитора.

Единый промпт аудитора Gate.

Короткий, направленный на блокеры.

Единый промпт аудитора Deep.

Длиннее, с таксономией дефектов и форматом отчёта.

Регламент: когда Gate, когда Deep.

Классификатор риска в явном виде.

Процедура: черновик → аудит → правки → повторный аудит → Ready.

И это фиксируется в чек-листе задачи в вашей системе управления (какая бы она ни была).

Хранилище отчётов.

Просто чтобы видеть прогресс и повторяемые дефекты. Это может быть папка, таблица, комментарии к задачам.

Этого достаточно, чтобы машина проверок заработала. А дальше вы можете усложнять: добавлять метрики, вводить пороги, вводить «обязательные блокеры», строить статистику.

Итоги

Машина проверок требований строится не из «умных ответов», а из стандартов: двух уровней проверок (Gate и Deep), чек-листов, таксономии дефектов и фиксированного формата отчёта. Отчёт должен иметь два слоя: краткий summary для руководителя и детальный список дефектов для автора требований. Каждое замечание оформляется как правило → симптом → вопрос → шаблон исправления, чтобы устранение было быстрым. Deep-аудит включается по классификатору риска, иначе процесс превращается в бюрократию. Повторяемые замечания лечатся не спором с ИИ, а улучшением шаблона требований и библиотеки правил. Когда это внедрено, качество требований становится воспроизводимым, задача реально становится Ready for Dev, а стоимость ошибок снижается за счёт раннего выявления дефектов.

Глава 4. Никаких «угадываний»: как запретить ИИ галлюцинировать и не потерять пользу

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

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

Что такое галлюцинация в контексте требований и почему она встречается чаще, чем кажется

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

Типовые формы галлюцинаций в требованиях:

Добавление новой бизнес-правила. Например, появляется лимит, штраф, условие, порядок действий, которого никто не обсуждал.

Подмена источника данных. ИИ «решает», что данные берутся из конкретной системы, потому что так обычно бывает.

Выбор технического решения. ИИ начинает описывать кэширование, очередь, базу данных, формат хранения, не имея архитектурного контекста.

Неверное расширение ролей. Он предполагает, что роль X имеет права Y, потому что «логично», но это может противоречить комплаенсу.

Смена терминов. ИИ заменяет слова на синонимы, ломая глоссарий.

Добавление «красивых» критериев приёмки с числами. Он подставляет метрики «на глаз», и это превращается в ложный договор.

Эти вещи редко вскрываются сразу. Они вылезают уже на реализации: «почему мы вообще так сделали?» или «а кто сказал, что так должно быть?» В итоге – переделки, конфликты и потеря доверия к документу.

Почему ИИ вообще угадывает: механика «закрытия гештальта»

ИИ устроен так, что он пытается завершить мысль. Когда он видит текст, который «как будто не закончен», он естественным образом стремится сделать его законченным: добавить условия, добавить обработку ошибок, добавить правила. Для литературного текста это благо. Для требований – риск.

Если вы не ставите ограничение «не дополняй», ИИ будет дополнять. Не потому что «обманывает», а потому что такова его нормальная стратегия: строить связный, правдоподобный ответ.

Значит, запрет угадывания – это не просьба «пожалуйста, не фантазируй». Это инженерное ограничение, которое вы встраиваете в промпт, в формат отчёта и в процесс работы.

Золотое правило аудита: ИИ утверждает только то, что прямо есть в тексте

В режиме аудитора ИИ должен жить по принципу юридической экспертизы: он не интерпретирует «как правильно», он фиксирует «что написано» и «чего не хватает».

Практическая формула:

если поведение описано в документе – ИИ может проверить его на непротиворечивость и ясность;

если поведение не описано – ИИ задаёт вопрос и предлагает варианты только как варианты, без утверждения, что так и будет.

Это правило лучше всего работает, если вы заставляете ИИ отвечать в структуре, где физически невозможно «дописать требования». Например: «Дефект → место → почему дефект → вопрос → варианты уточнения». В такой структуре «варианты» автоматически воспринимаются как гипотезы, а не как решение.

Три режима работы с ИИ и почему их нельзя смешивать