Брейншторм дизайна: вопрос за вопросом

Борис установил SPP ещё в модуле 1. А зачем они нужны, понял только сейчас, в модуле 6.

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

Теперь он хочет перейти к первому этапу, где решения записываются в дизайн-документ: брейншторму.

У Бориса уже есть docs/discovery.md: боль, сегмент, ограничения, выбранный MVP. Задача не в том, чтобы снова придумать идею продукта. Стек выбирать или писать код — тоже рано.

Надо понять другое: как именно устроен первый MVP JobTrack.

Борис открывает агента и хочет написать:

Давай уже сделаем JobTrack.

И вот тут он останавливается.

Этот промпт не запускает работу над MVP. Он перепрыгивает через решения, которых ещё никто не принял.

Проблема в том, что даже маленький MVP всё ещё полон развилок. Какие статусы в первой версии. Какие поля у карточки вакансии. Нужен ли фильтр по статусу сразу или потом. Что делать со следующим шагом. Что точно не брать, даже если очень хочется.

Перескочишь через них — агент примет их сам. Не по злобе) Просто пустота в задаче всегда чем-то заполняется.

Короче, Борис оказался на границе между discovery и проектированием: боль понятна, но форма первого продукта ещё нет.

Следующий шаг — не код. Брейншторм, который превратит выбранный MVP JobTrack в набор конкретных продуктовых решений.

Кажется, что после discovery пора писать код. Нет.

В модуле 6 мы не запускали процесс разработки. Разобрали, зачем нужны SPP, которые поставили ещё в модуле 1, и проверили, что агент видит skills. Всё.

Модуль 7 — первый шаг, где решения начинают жить в документе, а не в чате. Это brainstorming, но не в смысле давай накидаем любых идей. Результат модуля — docs/design.md, черновик дизайна MVP.

Это ещё не финальная спецификация.

Здесь мы фиксируем продуктовые развилки первого MVP: статусы, поля, следующий шаг, что уходит в не сейчас. Стек выберем в модуле 8. А в модуле 9 черновик дизайна и решение по стеку сойдутся в принятую спецификацию — и только тогда планирование.

Короче: сначала черновик, потом review черновика против discovery, только потом дальше.

Что важно из 20 правил прямо сейчас

Перед брейнштормом — пять правил.

3. Один продукт — одна главная боль. Не расширяй JobTrack за пределы боли из discovery.

4. MVP — минимум, который даёт ценность. Разбирай только такие решения, остальное потом.

5. Сначала дизайн, потом план, потом код. Сейчас пишем черновик дизайна, не план реализации и не саму реализацию.

6. Каждый этап заканчивается артефактом. Результат живёт в docs/design.md, а не растворяется в чате.

7. Проверяй свежим взглядом. Нужен review: противоречия, серые зоны, лишний scope.

Что такое брейншторм в этом модуле

Не свободный полёт. Управляемый разговор с агентом: берём уже выбранный MVP и разбираем его на конкретные продуктовые решения.

У тебя уже есть docs/discovery.md, сегмент пользователя, главная боль, ограничения, выбранный MVP и первый сценарий. Значит, вопрос не такой:

Что бы нам вообще сделать?

А такой:

Как именно должен быть устроен первый MVP, чтобы проверить выбранную боль?

Для JobTrack это значит: не заново придумывать продукт поиска работы, а решить, как устроена первая версия трекера вакансий.

Брейншторм как design draft

В черновике дизайна должны быть:

• входной контекст из discovery;
• первый сценарий MVP;
• развилки, которые нужно решить до кода;
• варианты по каждой развилке;
• trade-offs и риски;
• выбранное решение;
• почему альтернативы не вошли в MVP;
• что остаётся в не сейчас;
• открытые вопросы.

Это дешевле, чем дать агенту написать код, а потом разбираться, почему он добавил 12 статусов, импорт из Telegram и dashboard.

Как запускается SPP-процесс

После установки SPP скилл руками угадывать не нужно. Начни с /spp.

В SPP нет отдельного скилла brainstorming. Брейншторм вопрос-за-вопросом делает фаза spec-writing. В модуле 7 мы запускаем её первый проход — черновик дизайна.

SPP держит память о проекте в docs/spp/pipeline-state.md: что за продукт, что уже сделано, какие решения приняты. Поэтому работу можно прервать и продолжить в новой сессии. Следующий модуль — это следующая фаза того же pipeline.

Prompt:

Ты работаешь над JobTrack.
Прочитай docs/discovery.md.

Мы переходим к первому этапу, где решения записываются в docs/design.md.
Нужно провести brainstorming и подготовить docs/design.md.
Не пиши код, не выбирай стек, не составляй implementation plan.

Сначала используй /spp или объясни, какой skill/workflow нужен.
Потом проведи brainstorming как подготовку design draft.
Работай вопрос за вопросом.

Хороший ответ агента:

Код не начинаю.
Для этой задачи нужен brainstorming: нужно разобрать design-развилки MVP,
записать решения в docs/design.md и потом провести review draft
против docs/discovery.md.

Первый вопрос: какой первый сценарий MVP фиксируем как основной?

Плохой ответ:

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

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

Какие развилки разбирать

Развилка — это место, где решений несколько, и выбор меняет MVP.

Для JobTrack хорошие развилки:

• статусы вакансии;
• поля карточки вакансии;
• как показывать следующий шаг;
• нужен ли фильтр по статусу в первой версии;
• как пользователь заберёт свои данные через экспорт;
• что выкинуть из MVP.

Это не значит, что нужно заново выбирать MVP. MVP уже выбран раньше. Сейчас мы уточняем его устройство.

Плохие развилки для этого модуля:

• Next.js или SvelteKit;
• Supabase или SQLite;
• где деплоить;
• как устроить API;
• как разбить задачи реализации.

Это следующие модули. Уходит туда сейчас — значит смешивает этапы.

Как разбирать одну развилку

Развилку разбираем так:

Развилка: <название>.
Контекст из docs/discovery.md: <сегмент, боль, MVP, первый сценарий>.

Дай 2-3 варианта решения.
Для каждого варианта покажи:
- что он даёт;
- чем усложняет MVP;
- какие риски создаёт;
- как связан с discovery;
- почему его стоит или не стоит брать сейчас.

В конце порекомендуй решение для docs/design.md.
Не пиши код и не выбирай стек.

Пример для JobTrack:

Развилка: статусы вакансии.
Контекст: первый сценарий JobTrack - вручную добавить вакансию,
видеть текущий этап и не забыть следующий шаг.

Дай 3 варианта набора статусов.
Покажи trade-offs, риски, связь с discovery и рекомендацию для MVP.

Нормальная рекомендация выглядит так:

Рекомендация: взять 4 статуса.

1. Интересно.
2. Откликнулся.
3. Интервью.
4. Отказ/закрыто.

Почему: этого достаточно, чтобы вручную вести активные вакансии
и понимать следующий шаг. 8-12 статусов точнее описывают HR-воронку,
но раздувают MVP и заставляют пользователя думать о классификации.
Детали вроде тестового задания можно временно писать в заметку.

Как записывать docs/design.md

Минимальная структура docs/design.md:

# JobTrack design draft

## Входной контекст

- Discovery: docs/discovery.md
- Сегмент:
- Боль:
- MVP:
- Первый сценарий:

## Решения

| Развилка | Варианты | Trade-offs / риски | Решение | Почему не альтернативы | Связь с discovery/MVP |
|---|---|---|---|---|---|

## В MVP входит

-

## Не сейчас

-

## Открытые вопросы

-

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

Review design draft

После брейншторма не надо сразу идти дальше.

Сначала нужен review docs/design.md против docs/discovery.md.

Prompt:

Проведи review docs/design.md против docs/discovery.md.
Не пиши код, не выбирай стек, не составляй план реализации.

Ищи:
- решения без связи с discovery;
- функции, которые расширяют MVP;
- противоречия между болью, MVP и решениями;
- скрытые допущения;
- альтернативы без причины отказа;
- места, где нужно уточнение, а не уверенное решение.

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

Review нужен не для галочки. Если в черновике есть противоречие, дальше оно превратится в лишний код. А лишний код потом будет жить, просить тесты, ломаться и делать вид, что он тут по делу.

Что пока не делаем

• Не выбираем стек;
• не выбираем хостинг;
• Не пишем код;
• Не составляем implementation plan;
• не делаем UI-макеты;
• не расширяем MVP функциями, которые не нужны первому сценарию.

Результат модуля

Результат модуля 7 — один файл, docs/design.md. В нём входной контекст из discovery, первый сценарий MVP, развилки с вариантами и trade-offs, выбранные решения, отклонённые альтернативы, список не сейчас, замечания review и правки после них.

Это ещё не принятая спецификация. Но продуктовые решения зафиксированы, и код теперь знает, что обслуживать. Стек выберем в следующем модуле.

В этом модуле ты не пишешь код. Вообще. Даже если агент очень убедительно предлагает сразу собрать экран.

Цель практики — запустить первый этап, где решения записываются в дизайн-документ: провести brainstorming, записать docs/design.md как design draft и сделать review против docs/discovery.md.

Это ещё не принятая спецификация. Принятая спецификация появится в модуле 9, когда design draft будет синхронизирован с выбранным стеком.

Шаг 1. Подними контекст

Открой проект первого MVP и проверь, что есть docs/discovery.md.

В нём должны быть:

• сегмент пользователя;
• главная боль;
• выбранный MVP;
• первый сценарий;
• ограничения;
• не сейчас.

Если этих разделов нет, не начинай brainstorming. Вернись к модулям 1–3 и допиши discovery. Иначе дальше ты будешь принимать решения на воздухе.

Шаг 2. Запусти /spp и brainstorming

Напиши агенту:

Ты работаешь над моим MVP.
Прочитай docs/discovery.md.

Мы на первом этапе, где решения записываются в docs/design.md.
Нужно провести brainstorming и подготовить docs/design.md как design draft.

Сначала используй /spp или объясни, какой skill/workflow нужен.
Потом проведи brainstorming как подготовку design draft.

Не начинай код.
Не выбирай стек.
Не составляй implementation plan.
Работай вопрос за вопросом.

Если агент сразу предлагает код, останови:

Стоп. Не начинай код.
Мы сейчас пишем design draft через brainstorming.
Вернись к docs/discovery.md и задай первый вопрос по design-развилке MVP.

Шаг 3. Разбери design-развилки MVP

Попроси агента предложить 3–5 развилок на базе docs/discovery.md.

Для JobTrack это могут быть:

• статусы вакансии;
• поля карточки вакансии;
• как показывать следующий шаг;
• нужен ли фильтр по статусу в первой версии;
• что выкинуть из MVP.

Prompt:

На базе docs/discovery.md предложи 3-5 design-развилок для уже выбранного MVP.
Не придумывай новый MVP.
Не выбирай стек и архитектуру.

Для каждой развилки коротко объясни, почему её нужно решить до кода.
Потом задай один вопрос по первой развилке.

Шаг 4. Прими решения по одной развилке за раз

Шаблон для каждой развилки:

Развилка: <название>.
Контекст из docs/discovery.md: <сегмент, боль, MVP, первый сценарий>.

Дай 2-3 варианта решения.
Для каждого варианта покажи trade-offs, риски и связь с discovery.
В конце порекомендуй решение для docs/design.md.
Объясни, почему альтернативы не берём в MVP.
Не пиши код и не выбирай стек.

Не принимай решение, если агент не связал его с discovery. Попроси переписать ответ. Красивое решение без связи с болью — просто декор.

Шаг 5. Запиши docs/design.md

Создай или обнови docs/design.md.

Минимальный шаблон:

# Design draft

## Входной контекст

- Discovery: docs/discovery.md
- Сегмент:
- Боль:
- MVP:
- Первый сценарий:

## Решения

| Развилка | Варианты | Trade-offs / риски | Решение | Почему не альтернативы | Связь с discovery/MVP |
|---|---|---|---|---|---|

## В MVP входит

-

## Не сейчас

-

## Открытые вопросы

-

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

Шаг 6. Проведи review design draft

Попроси агента проверить документ:

Проведи review docs/design.md против docs/discovery.md.
Не пиши код, не выбирай стек, не составляй план реализации.

Ищи:
- решения без связи с discovery;
- функции, которые расширяют MVP;
- противоречия между болью, MVP и решениями;
- скрытые допущения;
- альтернативы без причины отказа;
- места, где нужно уточнение, а не уверенное решение.

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

После review внеси правки в docs/design.md.

Шаг 7. Зафиксируй результат в файле

Проверь, что результат не остался только в чате.

Модуль закрывается, когда docs/design.md сохранён в проекте и после review в нём исправлены найденные проблемы.

Зафиксируй design draft как checkpoint. По правилу 13 из материала «20 правил работы с ИИ» каждый этап заканчивается сохранённым артефактом, поэтому сделай commit docs/design.md после подтверждения. Тяжёлых git-команд здесь не нужно — достаточно сохранить design draft в историю.