Цикл одной функции · теория
BMAD · 13-step PRD · Adversarial Review
Как одна строка из Slack превращается в готовую к выпуску функцию без скоупа-монстра и пропущенных граничных случаев. Четыре фазы BMAD расширяют пространство решений и выбирают одно. Тринадцать секций PRD фиксируют контракт. Adversarial Review чужими глазами проверяет, что в PRD нет противоречий и wishful thinking.
«PRD = WHAT, не HOW. Если ты пишешь стек в PRD, ты пишешь не PRD, а ticket.»
- один из трёх тезисов из манифеста о процессе и модели
01 · BMAD - четыре фазы от идеи до сдачи
Архитектор не начинает с чертежей
Представьте архитектора, который проектирует жилой дом. Он не начинает с чертежей. Сначала - бриф с заказчиком: кто будет жить, какой бюджет, какие соседи. Потом концепция: сколько этажей, где кухня, какая конструкция несущих стен. Потом выбор материалов и систем - железобетон или клеёный брус, центральное отопление или тепловой насос. И только потом чертежи для рабочих.
Если пропустить любую фазу - получится дом без фундамента или кухня без окна. BMAD - это ровно такая последовательность, только для продуктовых фич.
- Brainstorming · расширение пространства решений. Одна строка из Slack превращается в 3-5 способов, как это можно сделать. Здесь уместен ADI: три гипотезы, каждая проверяема. Цель - не выбрать, а увидеть.
- Modeling · структурирование. Выбранное направление распадается на user stories (кто → что хочет → зачем), data model (какие сущности появляются), state machine. Здесь проявляются граничные случаи.
- Architecting · выбор решения. Из вариантов, прошедших modeling, вы честно берёте один. Trade-offs, risks, decisions.
- Delivery · артефакты. Финальный PRD, test plan, migration plan, чек-лист для выкатки. То, что можно передать команде и уйти пить кофе.
Фича «Tags + Saved Searches» сейчас выглядит как одна задача. На фазе Brainstorming распадается на три варианта: (1) теги как свободные строки в JSON-поле заметки, (2) теги как отдельная таблица с many-to-many связью, (3) теги как иерархия с родителями.
На Modeling появляются граничные случаи: «что если тег уже существует?», «можно ли иметь 100 тегов на заметке?», «как удалить тег, который больше никто не использует?». На Architecting вы явно выбираете вариант 2 (отдельная таблица) и фиксируете обоснование. На Delivery - PRD с 13 секциями, миграция, тесты.
3-5 вариантов с проверяемыми следствиями
User stories, data model, граничные случаи
Один вариант с trade-offs и risks
13-step PRD, миграция, тест-план
Четыре вопроса - что? как разложить? как реализовать? как сдать? - задаются в любом случае. В плохом процессе их задают в коде и находят ответы через инцидент в проде. В хорошем - задают в документе за день до начала работы.
02 · 13-step PRD - формат, который не пропустит граничные случаи
Тринадцать обязательных секций, без которых проект «забывает» граничный случай
Итак, BMAD дал четыре фазы. На выходе фазы Delivery появляется PRD (Product Requirements Document). Но PRD - не свободный текст. Это жёстко структурированный документ из 13 обязательных секций.
Аналогия - предполётный чек-лист пилота. Сорок пунктов, ни один не пропускается, потому что забытый = падение. Список не про бюрократию, а про то, что пилот физически не может держать 40 вещей в голове, и чтение чек-листа дешевле крушения. PRD работает так же: 13 пунктов, без которых проект «забывает» граничный случай и падает в проде.
Три секции из этих тринадцати - критичные, потому что инженеры их рефлекторно пропускают:
- 04 · Non-Goals · явный список того, чего не делаем. Для Tags это «не поддерживаем иерархию тегов в MVP», «не делаем цвета», «не синхронизируем между устройствами». Без него скоуп ползёт.
- 12 · Open Questions · то, что не ясно прямо сейчас. Если не зафиксировать, мозг делает допущения молча, и через неделю в код уезжает гипотеза, а не решение.
- 10 · Risks · что может сломаться. Без явных рисков первый инцидент в проде застаёт врасплох.
Четыре строки, но именно они спасают от скоупа-монстра.
PM-агент BMAD (John) генерирует первую версию за минуту. Но три контрольные точки качества -
Information Density (шаг 3), Measurability (шаг 5),
Implementation Leakage (шаг 7) - это ручной проход. Без него PRD
остаётся набором слов. Сравните: «система должна быть удобной» (пустышка) против
POST /notes/:id/tags возвращает 200 за < 50ms на базе 1000 заметок (измеримо).
Команда из пяти людей может работать со вторым. С первым - не может.
03 · Adversarial Review - как проверить PRD чужими глазами
Автор не видит свои опечатки - это устройство восприятия, не лень
Вы написали 13-step PRD, прошли три ручных гейта. Как понять, что в нём нет скрытых противоречий, пропущенных граничные случаи и wishful thinking? Ответ - никак, если будете проверять сами. Автор не видит свои опечатки - это физиологическое свойство восприятия, не слабость воли.
Решение - Adversarial Review. Открываете новую пустую сессию агента. Даёте ей роль критика этого PRD с явной установкой: найти минимум 3 проблемы, не хвалить, искать противоречия и пробелы.
Аналогия - red team в безопасности. Свою защиту не проверяют изнутри - зовут людей, чья работа её сломать. Они найдут дыры, которые строители защиты не видели, потому что думали в категориях «как это должно работать», а не «как это можно сломать».
Типичный результат - 5-7 находок. Ваша задача не принять всё, а классифицировать: РЕАЛЬНАЯ проблема / FALSE POSITIVE (агент пропустил, что AC это покрывает) / НИТПИК (стиль, не блокирует). Модель найдёт проблемы даже там, где их нет - фильтрация вручную.
Если сделать review в том же контексте, где писали PRD, модель защищает свой предыдущий ответ. Это не злой умысел - устройство внимания: свежий текст «убедительнее» абстрактного правила «ищи проблемы». Чистая сессия видит PRD как сторонний документ и читает его без bias.
Цикл на одной функции · Tags + Saved Searches
Как все три концепции складываются в один проход - от строки в Slack до PRD, прошедшего внешнее ревью.
Расширение пространства решений
«Нужны теги в заметках» из Slack распадается на три варианта: (1) свободные строки в JSON, (2) отдельная таблица с many-to-many, (3) иерархия с родителями. Каждая гипотеза с проверяемым следствием (см. ADI в отдельном разборе).
Граничные случаи вылезают
User stories («как пользователь, я хочу искать заметки по сочетанию тегов»), data model (таблицы tags, note_tags), state machine («тег с 0 заметок - удаляется автоматически или висит?»). Откладываются на Open Questions.
Один вариант с trade-offs
Выбран вариант 2 (отдельная таблица). Trade-off: миграция данных и +1 JOIN на каждый поиск, но возможность many-to-many и нормализация. Иерархия отложена в Non-Goals.
13-step PRD за минуту от PM-агента
PM-агент BMAD (John) генерирует PRD-074 со всеми 13 секциями. Вы делаете ручной проход по контрольным точкам качества - Information Density / Measurability / Implementation Leakage. Non-Goals и Open Questions заполнены.
Новая сессия находит 6 проблем
Промпт «найди минимум 3» возвращает 6 находок. После фильтрации: 2 РЕАЛЬНЫЕ (пропущен граничный случай «удаление тега во время поиска», нечёткое AC для производительности), 3 FALSE POSITIVE (закрыто в Section 8), 1 НИТПИК. Две реальные правки уходят в PRD. PRD-074 переходит в статус active.
Как читать этот разбор
- Сверху вниз, без скип-сечения. BMAD даёт фазы, PRD фиксирует контракт, Adversarial Review проверяет на честность. Каждая концепция строится на предыдущей.
- На схеме BMAD обратите внимание на цвета. Brainstorming - голубой (расширение), Modeling - зелёный (структура), Architecting - оранжевый (это точка выбора, самый важный момент), Delivery - серый (артефакты уходят команде).
- На карточке PRD три секции подсвечены оранжевым. Non-Goals, Risks, Open Questions - именно их инженеры пропускают рефлекторно. Если в вашем PRD они пустые - это сигнал.
- Сравните две колонки Adversarial Review. Левая (та же сессия) - 0 находок, скрытые проблемы остаются. Правая (новая сессия) - 5-7 находок, из которых 2 типично реальные. Разница не в модели, а в контексте.
- Пример «Tags + Saved Searches» - это шаблон. Подставьте на его место свою функцию и пройдите те же пять шагов. Если на каком-то шаге застряли - там и есть слабое место процесса.