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

Критерии приемки как договор: почему «готово» должно быть проверяемым

Пока критерии приемки не измеримы, «готово» – это мнение. А мнение всегда будет разным у разных людей. Один считает готовым, когда кнопка появилась. Другой – когда сценарий работает. Третий – когда учтены ошибки. Четвертый – когда аналитика фиксируется. Пятый – когда закрыты требования безопасности.

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

Слабые критерии приемки выглядят так:

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

Сильные критерии приемки отвечают на вопрос «как проверить»:

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

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

Роли и права: самая частая скрытая дыра в требованиях

Одна из самых дорогих категорий дефектов – это неописанные права доступа. Потому что когда вы их не описали, разработка либо делает слишком широко, либо слишком узко. Слишком широко – риск безопасности и комплаенса. Слишком узко – риск поломки бизнес-процесса и роста ручных обходов.

В зрелых требованиях любое действие связано с ролью. Любой просмотр данных связан с правом. Любое изменение статуса связано с ответственностью.

ИИ здесь полезен не тем, что он «знает безопасность», а тем, что он методично спрашивает: кто это делает? кто это видит? кто не должен видеть? что происходит при попытке без прав? как фиксируется событие? нужно ли логирование?

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

Данные и их жизненный цикл: требования заканчиваются не на экране

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

Поэтому аудит требований должен включать вопросы о данных:

какие поля используются; откуда они берутся; кто их вводит; какие валидации; какие форматы; что считается пустым значением; как обрабатываются ошибки; где хранится; как долго хранится; кто имеет доступ; как удаляется или обезличивается; как происходит экспорт; как фиксируются изменения.

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

Интеграции: то место, где даже хорошие требования ломаются

Интеграции сложны тем, что у вас всегда есть внешняя сторона: она может быть недоступна, она может отдавать ошибки, она может менять поведение, она может отвечать медленно, она может прислать невалидные данные. Внутри продукта вы можете контролировать многое. Снаружи – почти ничего.

Поэтому зрелое требование по интеграции обязано содержать не только «запрос-ответ», но и:

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

ИИ может проверить, что эти элементы хотя бы упомянуты и что поведение не противоречит бизнес-логике. Он не выберет правильный таймаут, но он спросит: «какой таймаут? что делаем при превышении?». И это уже огромная помощь, потому что большинство проблем интеграций – это не «плохой код», а «неоговоренное поведение».

Два контура: аудит до разработки и аудит после правок

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

Поэтому аудит должен быть циклом:

черновик требований; аудит; правки; повторный аудит; фиксация готовности.

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

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

Где заканчивается аудит и начинается проектирование

В зрелом процессе вы разделяете две активности.

Аудит: выявить дефекты, задать вопросы, определить, что не определено.

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

ИИ может помогать и там, и там, но режимы должны быть разными. В аудиторе вы запрещаете ему «решать». В проектировщике вы можете просить варианты и компромиссы, но тогда вы осознанно включаете режим генерации.

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

Как встроить аудит в командную привычку, чтобы это не стало «проверкой ради проверки»

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

Есть несколько практических принципов.

Первый: аудит начинается с автора и помогает автору. То есть отчет ИИ сначала идет аналитику или владельцу требования, чтобы он сам внес правки. А уже потом документ идет на командное обсуждение.

Второй: отчет используется как повестка встречи. Не «почитаем документ», а «разберем 12 вопросов по критическим дефектам».

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

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

Пятый: глоссарий и стандарт – живые. ИИ помогает поддерживать их в актуальном состоянии, но ответственность остается у команды.

Именно так ИИ превращается из игрушки в часть процесса.

Итоги

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

Глава 3. Машина проверок: чек-листы, правила и автоматический отчёт по качеству требований

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

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

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

Почему чек-лист важнее «умного текста»

Умный текст – это хорошо. Но любой умный текст превращается в мусор, если его нельзя применить одинаково два раза подряд. Чек-лист хорош тем, что он не спорит с настроением. Он не зависит от того, кто читает документ. Он состоит из вопросов «да/нет/не применимо» и из правил, которые можно проверять.