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

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

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

Два уровня проверок: базовые ворота и глубокий аудит

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

Уровень 1 – базовые ворота качества (Gate). Это минимальный набор проверок, без которых задача не может уйти в разработку. Он должен быть коротким, но жёстким. Обычно это 10–20 пунктов.

Уровень 2 – глубокий аудит (Deep). Это расширенный набор проверок для задач с риском: интеграции, платежи, персональные данные, критические процессы, сложные сценарии, большие изменения. Здесь чек-лист может быть 40–80 пунктов, и это нормально, потому что цена ошибки выше.

ИИ позволяет сделать оба уровня удобными. Для Gate – быстрый отчёт, который показывает блокеры. Для Deep – детальный отчёт с классификацией дефектов, рисками и списком уточняющих вопросов.

Если вы этого не разделите, вы получите либо бюрократию на всё подряд, либо поверхностность на критичных задачах.

Конструкция «правило → симптом → вопрос → исправление»

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

Правило – что должно быть по стандарту.

Симптом – что именно отсутствует или противоречит в тексте.

Вопрос – что нужно уточнить, чтобы закрыть пробел.

Исправление – как именно дописать/переформулировать, но в форме шаблона или примера формулировки, а не в виде выдуманного решения.

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

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

Базовый Gate-чек-лист: 16 проверок, которые закрывают 80% проблем

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

Цель изменения сформулирована. Что улучшаем и как поймём успех.

Область изменения ясна. Какие экраны/сервисы/процессы затронуты.

Роли перечислены. Кто выполняет действия и кто видит результат.

Основной сценарий описан шагами. Триггер → действия → результат.

Альтернативные сценарии перечислены. Что происходит при иных условиях.

Негативные сценарии описаны. Ошибка, отказ, недоступность, неверные данные.

Правила доступа указаны. Кто не должен иметь доступ и что при попытке.

Статусы и переходы описаны (если применимо). До → после → условия.

Данные определены. Какие поля, откуда, формат, валидации.

Интеграции перечислены (если есть). Какие внешние системы и контуры.

Поведение при сбое интеграции описано (если есть интеграция).

Критерии приёмки есть для ключевых сценариев. Проверяемые, однозначные.

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

Аналитика событий упомянута (если изменение влияет на воронку или метрики).

Ограничения и допущения зафиксированы. Что «не делаем» в рамках задачи.

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

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

Глубокий Deep-чек-лист: что добавляется для сложных и рискованных задач

Deep-аудит расширяет Gate и добавляет проверки, которые часто всплывают слишком поздно.

Нефункциональные требования.

Время отклика, нагрузка, ограничения по данным, SLA, устойчивость, деградация, кэширование, ограничения на частоту операций.

Безопасность и персональные данные.

Маскирование, хранение, сроки, удаление, обезличивание, права на экспорт, ограничения доступа в логах, требования комплаенса.

Идемпотентность и повторы.

Что происходит, если пользователь повторит действие; что происходит, если запрос придёт дважды; как система отличает дубль.

Конкурентные изменения.

Что если два пользователя меняют один и тот же объект; конфликт статусов; блокировки; правила разрешения конфликтов.

Согласованность данных.

Где источник истины; что является производным; как происходит синхронизация; как обрабатываются расхождения.

Миграции и обратная совместимость.

Если меняются форматы; если меняются статусы; как живут старые данные; как работает функциональность на старых версиях клиента.

Мониторинг.

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

UX-детали, которые критичны для поведения.

Тексты ошибок; подтверждения; предупреждения; пустые состояния; ограничения по вводу.

Управление доступом и аудит действий.

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

Deep-аудит не должен применяться ко всем задачам. Его нужно применять по признакам риска. Это тоже часть машины проверок: классификатор риска.

Классификатор риска: когда нужен Deep, а когда достаточно Gate

Чтобы команда не спорила каждый раз, нужен простой классификатор. Например, Deep обязателен, если выполняется хотя бы одно условие:

изменение затрагивает платежи/финансы;

затрагивает персональные данные или медицинские данные;

затрагивает авторизацию/права доступа;

включает новую интеграцию или меняет контракт существующей;

меняет критические статусы (заказ, заявка, запись);

затрагивает массовые операции;

затрагивает юридически значимые документы;