Границы MVP: что режем

Теперь, после кастдева, самое неприятное — не добавлять идеи, а резать.

Борис открывает учебный черновик docs/discovery.md, а там уже не одна идея JobTrack, а список всего, что хочется сделать.

Google Sheets, Telegram, потерянные вкладки, статусы откликов, follow-up, сопроводительные письма, напоминания, аналитика, импорт из job-сайтов, теги, канбан, фильтры, умные рекомендации.

Список внушительный. И каждая штука по отдельности реально полезная.

Вот тут и ловушка.

Соберёшь всё сразу — и проверишь не гипотезу, а собственную выносливость: сколько недель подряд можно собирать большой интерфейс. Главная боль и основной сценарий утонут в бантиках, а JobTrack станет не MVP, а комбайном для всего хорошего.

Опаснее всего вот такой промпт — выглядит невинно:

Собери MVP JobTrack со всеми важными функциями из discovery.

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

Короче, проблема не в том, что идей мало. Их слишком много, и почти все идеи надо отложить. Оставить один кусок JobTrack, который бьёт в главную боль — остальное за дверь. Даже полезное. Особенно полезное.

Зачем резать scope

После preflight и discovery идей обычно становится не меньше, а больше. Ты увидел альтернативы, услышал людей, наткнулся на ограничения и новые сценарии. Первый порыв — запихнуть всё это в первую версию. Плохой порыв.

MVP — это не бедная версия большого продукта. Это быстрая проверка гипотезы: главный сценарий, он же основной сценарий, работает или нет?

На этом этапе SPP ведёт тебя через фазу mvp-scoping.

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

Главная задача тут — выбрать функции, которые закрывают главную боль из discovery. Не самые красивые. Те, что закрывают.

Для JobTrack после разговоров главная боль звучит так:

Активному соискателю дорого добавлять вакансии и поддерживать статусы актуальными, поэтому список быстро разваливается.

Короче, MVP должен проверять ровно это. Не аналитику, не сложные фильтры, не Telegram-бота, не генератор сопроводительных писем — всё это потом.

Если главный сценарий не работает, никакие бантики его не вытянут.

Например: если итогом продукта должен быть сложный документ в конкретном формате, первый MVP доказывает одно — что файл в этом формате вообще получается, и сначала научись генерировать файл. Потом уже интерфейс, роли, шаблоны, история версий и оплата. Сделаешь наоборот — и на финале выяснится, что формат стабильно не генерируется. Всё, время потеряно.

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

Фильтр MVP

Каждую хотелку гоняй через фильтр:

• Какой сценарий мы проверяем?
• Какую боль из discovery закрывает эта функция?
• Можно ли проверить гипотезу без этой функции?
• Что пользователь сможет сделать, когда она появится?
• Какой самый рискованный результат должен получиться?
• Какой риск она снимает прямо сейчас?
• Это must-have или бантик?
• Можно ли в первой версии заменить автоматизацию ручным шагом?

Если функция полезная, но гипотеза проверяется и без неё, она уходит в не сейчас. Полезное не значит необходимое. Вот и весь фильтр.

Ошибка начинающих вайб-кодеров

Самая частая ошибка начинающих вайб-кодеров — описать агенту максимальную задачу и сразу поставить её на реализацию.

То есть не ставить агенту максимальную задачу — это не осторожность ради осторожности, а способ сохранить контроль.

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

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

И даже её не нужно ставить агенту целиком, потому что дальше мы будем декомпозировать MVP на маленькие части: сначала сценарий, потом артефакты, потом план, потом реализация. Спецификацию, план и slice тут в детали не тащим — спецификация в модуле 9, план в модуле 10, первый slice в модуле 11.

Пример JobTrack

Возьмём Бориса из JobTrack. После discovery у него набрался список хотелок:

• ручное добавление вакансии;
• список вакансий;
• статус отклика;
• поле следующего шага;
• Telegram-бот;
• автоматический парсинг job-сайтов;
• генератор сопроводительных писем;
• аналитика откликов;
• теги и сложные фильтры;
• умные рекомендации вакансий.

Прогоняю через фильтр — остаётся только то, что проверяет главную боль.

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

Остальное — бантики. Для первой проверки гипотезы они не нужны.

Как использовать ИИ

ИИ тут работает жёстким редактором scope, но только если кормишь его данными с прошлого этапа.

Плохой вариант — кинуть в пустой чат:

Помоги выбрать MVP для сервиса поиска работы.

Агент начнёт гадать и выдаст усреднённую пустышку. Он не знает ни какую боль ты уже проверил, ни какие альтернативы нашёл, ни какие ограничения выписал, ни что люди реально сказали на discovery.

Правильный вариант — дать ему учебный черновик docs/discovery.md из модулей 1–2 и попросить резать scope на его основе.

Например:

На прошлом этапе я собрал discovery-документ.

Вот выдержка:
<вставь гипотезу, главную боль, факты, текущие альтернативы,
ограничения и уточнённую гипотезу из docs/discovery.md>

Теперь мне нужно определить MVP первого проекта.

Сделай это как жёсткий редактор scope:
1. выпиши главный сценарий, который нужно проверить;
2. назови самый рискованный результат;
3. предложи минимальный MVP на основе discovery;
4. разрежь список хотелок на MVP и не сейчас;
5. для каждой оставленной части объясни, какую боль из discovery она закрывает;
6. отдельно покажи, какие функции выглядят полезными, но не нужны для первой проверки.

Не добавляй новые идеи, которых нет в discovery.
Не выбирай стек и не пиши код.
Будь строгим: MVP должен быть маленьким.

Если хочешь добавить список хотелок, добавляй его после discovery:

Список хотелок:
- ручное добавление вакансии;
- список вакансий;
- статус;
- следующий шаг;
- Telegram-бот;
- парсинг job-сайтов;
- генератор писем;
- аналитика;
- теги;
- рекомендации.

На выходе получишь что-то вроде:

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

Только не глотай ответ ИИ целиком. Он помогает резать. Но продуктовый компромисс принимаешь ты.

Быстрая проверка по правилам ИИ

Для выбора MVP не нужно тащить весь список из 20 правил. Достаточно проверить 6:

Правило	Проверка
1. Идея не продукт	Идея оформлена как проверяемая гипотеза
3. Один продукт — одна главная боль	MVP проверяет одну главную боль из discovery
7. MVP — минимум, который даёт ценность	Оставлены только части, без которых сценарий не проходит
8. MVP — тест гипотезы	Первая версия задаёт вопрос рынку или себе
10. MVP нужно упаковать перед выводом	Результат можно открыть и проверить без личного экскурсовода
20. Ответственность всё равно твоя	Финальное решение о scope принимает человек, не агент

Что меняется после этапа

До этого этапа у тебя есть список хотелок. После — границы MVP:

• что входит;
• что не входит;
• почему каждая оставшаяся функция проверяет гипотезу;
• по какому сигналу будет понятно, что MVP помогает.

Хороший MVP выглядит подозрительно маленьким. Если первая версия кажется тебе полной — почти наверняка scope распух, режь ещё.

Возьми гипотезу и факты из первых двух модулей. Теперь на их основе определи MVP первого проекта.

Цель практики — не оставить абстрактные 3–5 функций. Цель — собрать минимальную версию, которая проверяет основной сценарий и самый рискованный результат из discovery.

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

Для JobTrack основной сценарий: сохранить вакансию, увидеть её в списке, обновить статус и следующий шаг.

Если твой продукт должен на выходе генерировать сложный документ в конкретном формате, первый MVP должен проверить, что этот файл реально получается. Не начинай с кабинета, ролей, красивого pipeline и аналитики, если главный файл ещё не генерируется.

SPP preflight

После установки SPP из модуля 1 начни рабочую сессию по scope через SPP-скилл mvp-scoping:

Используй /spp.

Мы на модуле 3. На прошлых этапах уже есть учебный docs/discovery.md: гипотеза, сегмент, факты, цитаты, ограничения и текущие альтернативы.

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

Для этого шага в SPP есть отдельный скилл mvp-scoping. Если агент его не видит, это проблема окружения: остановись, проверь установку SPP и не принимай подмену ручным workflow.

Что записать в учебный черновик docs/discovery.md

Это финальная часть учебного черновика перед созданием workspace. В модуле 4 ты перенесёшь гипотезу, discovery и границы MVP в настоящий jobtrack/docs/discovery.md.

Добавь раздел Границы MVP:

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

Шаг 1. Собери входные данные из предыдущего документа

Не начинай с чистого листа. Выпиши из учебного черновика docs/discovery.md:

• гипотезу;
• главную боль;
• 3–5 фактов или цитат из discovery;
• текущие альтернативы пользователя;
• ограничения и риски;
• уточнённую гипотезу.

Для JobTrack это может выглядеть так:

Гипотеза: JobTrack помогает активному соискателю не терять вакансии, статусы и следующие шаги.
Главная боль: вакансии, статусы и следующие шаги расползаются по вкладкам, таблицам и сообщениям.
Факты: пользователь ведёт таблицу нерегулярно; вечером восстанавливает, куда уже писал; часть вакансий остаётся во вкладках.
Альтернативы: Google Sheets, закладки, Telegram, заметки.
Ограничения: парсинг job-сайтов рискован для первого MVP.

Шаг 2. Выпиши полный список хотелок

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

Для JobTrack:

• ручное добавление вакансии;
• список вакансий;
• статус отклика;
• поле следующего шага;
• Telegram-бот;
• автоматический парсинг job-сайтов;
• генератор сопроводительных писем;
• аналитика откликов;
• теги и сложные фильтры;
• умные рекомендации вакансий.

Для своего проекта выпиши всё, что хочется сделать. Потом режь.

Уточнение: сложные фильтры здесь означают полноценный поиск, теги, сохранённые представления, много критериев и аналитику. Простой filter by source или sort by updatedAt может появиться позже отдельным маленьким slice, если спецификация и план явно это разрешат. Но это не часть первого сценария добавления вакансии.

Шаг 3. Попроси ИИ разрезать scope на основе discovery

Скопируй prompt и подставь свои данные:

Используй /spp.

На прошлом этапе я собрал discovery-документ.

Вот выдержка:
<гипотеза>
<главная боль>
<факты и цитаты>
<текущие альтернативы>
<ограничения>
<уточнённая гипотеза>

Список хотелок:
<полный список функций и идей>

Теперь мне нужно определить MVP первого проекта.

Сделай это как жёсткий редактор scope:
1. выпиши главный сценарий, который нужно проверить;
2. назови самый рискованный результат;
3. предложи минимальный MVP на основе discovery;
4. разрежь список хотелок на MVP и не сейчас;
5. для каждой оставленной части объясни, какую боль из discovery она закрывает;
6. отдельно покажи, какие функции выглядят полезными, но не нужны для первой проверки.

Не добавляй новые идеи, которых нет в discovery.
Не выбирай стек и не пиши код.
Будь строгим: MVP должен быть маленьким.

Если агент предлагает авторизацию, импорт, аналитику, бота и красивый dashboard в первом MVP, попроси переписать ответ. Он снова раздул scope.

Шаг 4. Прими решение человеком

ИИ предлагает резку, но решение принимаешь ты. Это не место, где можно спрятаться за агента: scope потом всё равно прилетит в твой проект.

Заполни короткую таблицу:

Часть продукта	Боль или риск из discovery	Решение
Ручное добавление вакансии	пользователь теряет вакансии между вкладками и таблицей	MVP
Список вакансий	нужно единое место вместо вкладок и сообщений	MVP
Статус отклика	непонятно, где процесс уже начат, а где нет	MVP
Следующий шаг	пользователь забывает follow-up	MVP
Telegram-бот	ускорит сохранение, но не нужен для первой проверки	не сейчас
Парсинг job-сайтов	полезен, но юридически и технически рискован	не сейчас

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

Шаг 5. Перепиши большую задачу в MVP-задачу

Плохо:

Сделай JobTrack: авторизацию, импорт вакансий, Telegram-бота, список, статусы, аналитику, генератор писем, экспорт, красивый интерфейс и деплой.

Лучше:

Первый MVP JobTrack: пользователь вручную добавляет вакансию, видит её в списке, меняет статус и записывает следующий шаг. Без авторизации, бота, аналитики, генератора писем и парсинга.

Для своего проекта запиши:

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

Шаг 6. Проверь MVP по 6 правилам

Полный список из 20 правил есть в дополнительном материале. В этом модуле проверь только те, которые помогают выбрать MVP.

Правило	Проверка	Решение
1. Идея не продукт	идея оформлена как проверяемая гипотеза
3. Один продукт — одна главная боль	MVP проверяет одну главную боль из discovery
4. MVP — минимум, который даёт ценность	оставлены только части, без которых сценарий не проходит
6. MVP — тест гипотезы	первая версия проверяет основной сценарий, а не полноту продукта
10. MVP нужно упаковать перед выводом	результат можно будет показать, открыть и проверить без личного экскурсовода
20. Ответственность всё равно твоя	финальное решение о scope принято человеком

Шаблон

## Границы MVP

Главная боль из discovery:
<одно конкретное предложение>

Основной сценарий:
<что пользователь делает от начала до результата>

Самый рискованный результат:
<что должно получиться, иначе продукт теряет смысл>

MVP первого проекта:
<короткое описание минимальной версии>

### В MVP входит

- <часть 1> - <какую боль или риск из discovery закрывает>
- <часть 2> - <какую боль или риск из discovery закрывает>
- <часть 3> - <какую боль или риск из discovery закрывает>

### Не сейчас

- <идея> - <почему не нужна для первой проверки>
- <идея> - <почему не нужна для первой проверки>

### Большая задача, которую нельзя отдавать агенту

<как звучит раздутый prompt>

### Маленькая MVP-задача

<как звучит первый проверяемый scope>

Сигнал успеха MVP:
<по какому поведению или результату понятно, что MVP помогает>

Следующий шаг декомпозиции:
<какую маленькую часть проектировать дальше>