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

Участники и роли.

Список ролей с короткими описаниями: кто инициирует, кто подтверждает, кто администрирует, кто читает, кто имеет ограниченный доступ. Если ролей много, нужен хотя бы базовый список и ссылка на глоссарий ролей внутри документа.

Ключевые сущности данных.

Что является объектом изменения: заказ, заявка, пациент, визит, платеж, карточка, документ, комментарий, статус. ИИ должен уметь сверять, что эти сущности описаны одинаково в разных местах.

Источники правды.

Где хранится основной набор данных, какие системы являются первичными, какие вторичными, где возникают конфликты синхронизации. Даже если вы не раскрываете архитектуру полностью, ИИ должен знать, что «источник истины» для X – система A, а не B.

Ограничения и запреты.

Здесь важны «не делаем». Например: нельзя менять схему БД на этом этапе; нельзя менять публичный API; нельзя вводить новые зависимости; нельзя ломать обратную совместимость; нельзя трогать платежный контур без отдельного согласования. ИИ должен проверять требования с учетом этих ограничений.

Формат требований.

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

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

Глоссарий как фундамент: без него у вас не требования, а литературный текст

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

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

Хороший глоссарий для требований включает:

определение термина одним предложением; атрибуты сущности, если это сущность; допустимые статусы, если это объект со статусами; отличие от похожих терминов; примеры использования в тексте требований (не про выдуманных людей, а про формулировки: «в тексте используем так-то»).

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

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

Таксономия дефектов: как превратить «непонятно» в конкретный тип проблемы

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

Минимальная таксономия дефектов требований, которую полезно встроить в аудит ИИ:

Неопределенность. Есть слова или конструкции без измеримости и границ.

Неполнота. Не описаны важные сценарии: ошибки, исключения, альтернативные пути, ограничения.

Противоречие. В разных местах документа описано разное поведение для одного и того же случая.

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

Отсутствие критериев приемки. Нет проверки результата в форме, пригодной для тестирования.

Неопределенные роли и права. Не ясно, кто имеет доступ, кто может выполнять действие, кто видит данные.

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

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

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

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

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

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

Правило «ИИ не заполняет пробелы»: как защититься от самой опасной ошибки

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

Аудитор должен отличать два режима:

режим выявления дефектов и вопросов; режим проектирования решений.

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

Поэтому в стандарте работы с ИИ должно быть жесткое правило: ИИ не имеет права утверждать, что система должна делать X, если в документе это не указано. Он может только задавать вопрос: «что должно происходить в случае X?» и предлагать варианты как гипотезы, помеченные как варианты. Это делает процесс безопасным.

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

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

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

Инструкция аудитора обычно состоит из пяти частей.

Первая часть: роль и цель.

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

Вторая часть: контекст проекта.

Сюда вставляется паспорт проекта.

Третья часть: стандарт требований.

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

Четвертая часть: таксономия дефектов.

С описанием и примерами того, что считать дефектом каждого типа.

Пятая часть: формат результата.

Это важно. Если вы не задаете формат, вы получите «эссе». Вам нужен отчет: список дефектов, каждый дефект – с указанием места в тексте, типом дефекта, риском, вопросом и предложением формулировки уточнения (именно уточнения, а не окончательного решения). И отдельно – краткий итог: критические риски, блокеры, что обязательно исправить до передачи в разработку.

Формат результата – это половина успеха. Когда отчет структурирован, его можно использовать в работе. Его можно копировать в задачу, в комментарии, в чек-лист. Его можно сравнивать между версиями документа. ИИ становится не «собеседником», а инструментом контроля качества.

Сценарная дисциплина: почему аудит требований всегда должен начинаться со сценариев, а не с «описания функции»

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

Сценарии – это способ вернуть разговор в область поведения. Сценарий – это последовательность шагов и условий, где ясно:

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

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

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