Между одной строкой в чате и работающей функцией - четыре фазы: расширение пространства решений, разбор на части и крайние случаи, выбор варианта, документ-контракт. Вопрос только в том, пройдёт ли их команда в документе за день - или в коде за две недели разгребания последствий.
Аналогия архитектора
Архитектор не начинает с чертежей. Если он садится за чертежи в первый день - это плохой архитектор.
Сначала бриф с заказчиком: кто будет жить, какой бюджет, какие соседи, что планируется через десять лет. Этот разговор может занять несколько встреч и заканчивается не картинками, а текстом - записью требований.
Потом концепция: сколько этажей, где кухня, где спальни, где входная зона. Три-четыре варианта, в обсуждении с заказчиком выбирается один. На этом этапе чертежей ещё нет - только условные схемы.
Потом материалы: железобетон или клеёный брус, какие окна, чем утеплять. Это уже инженерный выбор с компромиссами: дешевле, но шумнее; дороже, но теплее.
И только потом - чертежи для рабочих, по которым будут строить.
Если пропустить любую фазу - получишь либо дом без фундамента (пропустили концепцию, начали с чертежей), либо кухню без окна (пропустили бриф, не учли как живёт семья), либо ванную над спальней соседа снизу (пропустили выбор материалов и схему водоотведения).
В разработке продукта те же четыре фазы. Разница в том, что в архитектуре их прохождение принудительно - невозможно положить кирпич без чертежа. В разработке кирпич можно положить в любой момент, и это создаёт иллюзию, что фазы можно пропустить. Не можно - они всё равно пройдут, просто либо в документе за день, либо в коде за две недели разгребания последствий.
Те же четыре фазы для продуктовых функций
Четыре фазы для функции, которую вы добавляете в продукт, имеют простые имена: расширение, структуризация, выбор, документ.
Расширение пространства решений. На входе - одна формулировка задачи из чата. На выходе - три-четыре способа её решить, каждый с краткими плюсами-минусами. Это та же логика «три версии», что и в посте про диагностику, только на уровне продуктовых решений. Эта фаза занимает 30 минут до часа. Главное - не позволить мозгу сразу схватиться за первый очевидный способ.
Структуризация: разбор на части и крайние случаи. Выбранную область разбиваем на компоненты. Что отдельно, что вместе. Какие сценарии - основные, какие - крайние. Что происходит, если пользователь делает «не то». Эта фаза вылавливает 80% будущих багов на этапе документа. На один час разбора крайних случаев приходится десять часов сэкономленной работы.
Выбор варианта с компромиссами. Из трёх вариантов первой фазы выбираем один. С чётко проговоренными причинами выбора и условиями, при которых выбор был бы другим. Это та же логика, что в DDR - только применённая на уровне функции, а не одного архитектурного решения.
Документ-контракт. Финальная фаза - PRD, продуктовый документ из 13 разделов. То, что команда будет читать, когда садится реализовывать. То, что заказчик будет проверять, когда принимает работу.
Четыре фазы для дома - это месяцы. Для функции - день или два работы продукт-менеджера. Но они должны быть пройдены до того, как начат код, иначе кирпич уже положен на неподготовленный фундамент.
Конкретный пример: «теги для заметок»
Возьму конкретный пример. Команда делает приложение для заметок (назову его Vault). Появилось требование: «добавить теги к заметкам».
Без четырёх фаз разработчик идёт писать. Сначала добавляет колонку tags в таблицу заметок, хранит как JSON-массив строк. Запускает за два дня. Через две недели появляется требование «искать заметки по тегу». Внезапно оказывается, что JSON-поиск в базе медленный - надо переделывать на отдельную таблицу many-to-many. Ещё две недели. Через месяц - «удалить тег у всех заметок одновременно». Снова перестройка. К двум месяцам функция «теги» съела четыре недели работы вместо изначальной оценки в два дня.
С четырьмя фазами эта же функция выглядит иначе.
Расширение (30 минут). Три варианта: теги как массив строк в JSON; отдельная таблица с many-to-many; иерархическая система тегов с родителями. Краткие плюсы-минусы каждого.
Структуризация (один час). Крайние случаи: что если тег уже существует? Что если тег используется в десяти тысячах заметок и его нужно удалить? Что если два пользователя добавили один и тот же тег с разной капитализацией («Работа» vs «работа»)? Что если тег нужно переименовать? Видно сразу - JSON-вариант проваливает три из четырёх вопросов.
Выбор (30 минут). Берём вариант 2 (отдельная таблица many-to-many) с обоснованием: единственный, который выдерживает поиск и массовые операции. Иерархия (вариант 3) откладывается до подтверждения спроса - добавить можно надстройкой, без переделки основы.
Документ (один час). PRD с 13 разделами. В разделе «не делаем в MVP» явно: не делаем цвета тегов, не делаем иерархию, не синхронизируем между устройствами. Эти четыре строки спасают команду от того, что задача «добавить теги» через две недели разрастётся до полноценной системы тегирования.
Итого три часа на четыре фазы. Реализация - два дня без переделок. Через два месяца - функция стабильно работает, никаких аварийных переделок.
Это не теория. Я видел эту разницу в десяти командах. Часы на этапе документа - это десятки часов на этапе кода.
Тринадцать разделов PRD - это не бюрократия
PRD-документ из 13 разделов часто воспринимается как «отдельная работа, которая отнимает у инженеров время». В реальности это проверочный лист пилота перед взлётом.
Перед взлётом пилот проходит сорок пунктов. Не сорок один, не тридцать девять. Каждый пункт - это какой-то отказ, который убил людей в прошлом. Если пропустить любой - может случиться то же самое. Сорок пунктов кажутся бюрократией, пока вы не понимаете, что это коллективный опыт авиации за сто лет - отмеренный в катастрофах.
PRD из 13 разделов - то же самое для продуктовых функций. Каждый раздел - это вопрос, который команды забыли в прошлом, и забывание стоило им переделок. «Давайте упростим до пяти» - это значит вернуть восемь известных классов ошибок.
Тринадцать разделов делятся на три группы. Первая (цель, аудитория, метрики успеха, рамки) - отвечает на «зачем это вообще». Вторая (функциональные требования, нефункциональные, крайние случаи, дизайн) - отвечает на «что именно делаем». Третья (риски, открытые вопросы, не-цели, план) - отвечает на «что может пойти не так».
Третья группа - самая редко заполняемая и самая важная.
Три раздела, которые пропускают рефлекторно
Три раздела из тринадцати команды пропускают чаще всего, и именно они дают защиту от расползания рамок.
Не-цели. Что мы явно не делаем в этой функции, чтобы рамки задачи были понятны. «Не поддерживаем иерархию тегов в MVP. Не делаем цвета тегов. Не синхронизируем между устройствами». Четыре строки. Без них через две недели приходит дизайнер с «а давайте цвета добавим, это же логично». Команда тратит ещё неделю на цвета. Затем приходит заказчик с «а на телефоне тоже теги нужны, синхронно». Ещё две недели. Изначальная оценка «два дня на теги» в реальности - два месяца. Не из-за плохой оценки, а из-за расползания рамок.
Открытые вопросы. Что не ясно прямо сейчас и требует решения до начала кода. «Не решено: сколько максимум тегов на заметку. Не решено: поддерживаем ли английский и русский в одном теге или разделяем». Эти вопросы будут заданы во время реализации - лучше задать их сейчас и получить ответ, чем встретить в середине спринта и встать.
Риски. Что может сломаться в случае запуска. «Риск: миграция существующих заметок к новой структуре тегов может занять до тридцати минут на пользователя - нужен либо поэтапный rollout, либо план миграции в фоне». Список рисков - это страховка от «уже выкатили, теперь чиним в продакшене».
Три раздела. Десять-пятнадцать минут на заполнение. Эффект - две-три недели сэкономленной работы по разгребанию недосказанного.
Кто пишет, кто читает
PRD пишет продукт-менеджер. Не разработчик, не дизайнер, не генеральный директор. Разработчик может помочь с техническими ограничениями, дизайнер - со схемами интерфейсов, но ответственность за документ - на продукт-менеджере.
Это важно, потому что PRD - это контракт. Разработчик читает и говорит «вот это понятно, по этому я могу начать работу». Дизайнер читает и говорит «вот тут мне нужны три макета». Заказчик читает и говорит «да, это то, что я хотел».
Если PRD написал разработчик - он будет заполнен «технически», без бизнес-контекста. Если написал заказчик - без крайних случаев. Если написал дизайнер - без чисел и метрик. Один человек, отвечающий за весь документ, - это страховка от того, что документ будет с дырами.
AI-агент (BMAD-агент) генерирует первую версию PRD за минуту из формулировки задачи и контекста проекта. На вход даём «функция теги для заметок» + ссылки на смежные функции (поиск, фильтры, организация заметок). На выход получаем заполненный шаблон с заметками «здесь нужно уточнить» и «здесь нужны метрики». Дальше работа продукт-менеджера - заполнить, выкинуть лишнее, уточнить расплывчатое.
Разбор в чистой сессии
Финальный шаг перед утверждением PRD - разбор в чистой сессии.
Автор не видит свои опечатки. Не из лени - это устройство восприятия. Когда вы писали документ, у вас был внутренний контекст, и фразы кажутся ясными. Через двадцать минут после написания контекст уходит, и те же фразы становятся «можно прочитать двумя способами».
Эту проблему не решает обычное вычитывание. Её решает обзор в чистой сессии - то есть либо другим человеком, который не участвовал в обсуждении, либо новой AI-сессией с явной установкой «найти минимум три проблемы, не хвалить, не предлагать улучшения».
В чистой сессии находятся 5-7 проблем. После фильтрации - 2-3 реальные правки. Двадцать минут работы - два-три бага, которые не дойдут до кода.
Установка важна: без неё AI-сессия начинает «хвалить документ» (это её базовый режим). С установкой «оппонент» - она ищет дыры, как пишут разбор кода люди.
Что отдать AI-агенту, что - себе
BMAD-агент хорошо делает первую версию PRD: собрать контекст из связанных документов, заполнить шаблон, предложить три варианта на этапе расширения. Это работа, на которую человеку нужен час, агент делает за минуту.
Три ручных проверки качества стоят за человеком:
- Плотность смысла. В каждом разделе не должно быть «воды». Если из десяти строк можно выкинуть пять без потери смысла - выкидываем.
- Измеримость. Метрики успеха должны быть числами с порогами, а не «улучшим пользовательский опыт». «Конверсия в активацию выше 35% за первую неделю» - это метрика. «Пользователям станет удобнее» - это не метрика.
- Не утекает ли реализация в требования. PRD говорит «что», а не «как». «Поиск по тегу за 200 мс» - это требование. «Использовать PostgreSQL full-text search» - это решение, оно в RFC, не в PRD.
Если AI заполняет PRD на 100% - у вас красивый шаблон с тремя проблемами, которые человек должен был поймать.
Что почитать дальше
Это пятый пост в серии. Предыдущие:
- Кладбище решений
- Перед тем как чинить - выпишите три версии
- Среднее обманывает
- Мотивировочная часть для архитектурного решения
Дальше:
- Чем спецификация отличается от PRD и почему эта разница огромна на практике.
- Что такое Forgeplan и как он держит четыре методологии в одной плоскости.
К посту прилагается интерактивный калькулятор уровня глубины задачи: вводишь короткое описание, получаешь рекомендацию «тактически» / «стандарт» / «глубоко» / «критически» с пояснением, какие записи нужны. Лежит в /guides.