Scope, non-goals и release slice для MVP

1. MVP нужен scope freeze

После разговора о пользователе и метрике очень хочется сразу открыть редактор и начать «быстро собирать». Именно в этот момент проект обычно и начинает пухнуть. Сначала вы добавляете «ещё одну полезную кнопку», потом «небольшой экран настроек», потом «раз уж мы здесь, давайте прикрутим аналитику». MVP такое любит: он вообще мастер прикидываться безобидным, пока не съест весь срок.

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

Для нашего Support Agent это звучит очень приземлённо: не «универсальная AI-платформа для поддержки», а первая рабочая версия. Небольшой фрагмент из рабочей спецификации может выглядеть так:

## Заморозка области

Текущий релиз показывает один сценарий:
входящий ticket → классификация → draft ответа → проверка оператором.

Все новые большие функции после фиксации этого сценария
не входят в текущий релиз и переносятся в Later.

Заметьте важную вещь: здесь нет драмы и нет «мы навсегда отказались» — только дисциплина. Идея не выбрасывается, она перестаёт мешать текущему релизу. Даже если ваш проект не чистый MVP, умение вовремя заморозить scope спасает почти любую первую версию.

2. Отделяем must-have от «тоже важно»

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

Удобно смотреть на фичи через такую таблицу:

Главный вопрос один: уберём эту штуку — сценарий ломается или просто становится чуть менее красивым?

Например, для учебного демо Support Agent логин почти никогда не бывает must-have. Звучит немного кощунственно: разработчик внутри нас сразу хочет крикнуть «но у любого приложения же должен быть вход!». У первого релиза — нет. На локальных данных перед ментором логин не создаёт ценности оператору, только ощущение «теперь выглядит как настоящее приложение». Правдоподобность и ценность — не одно и то же.

Хорошая черновая категоризация для нашего примера может выглядеть так:

## Карта фич

Must-have: inbox, классификация, draft ответа, ручное подтверждение, audit trail.
Should-have: история последних тикетов клиента.
Nice-to-have: фильтр по типам тикетов, цветные метки.
Later: мультиязычность, шаблоны ответов, dashboard по SLA.
Out of scope: CRM, телефония, auto-refund, обучение модели на продакшен-данных.

Здесь особенно важна разница между Later и Out of scope. Later: «возможно, часть того же продукта, но не сейчас». Out of scope: «начнём это — поменяется не размер, а природа проекта». Для новичка это различие очень полезно — без него всё кажется одинаково «дополнительной фичей».

3. Release slice: один законченный путь

Теперь — самое важное понятие этой лекции: release slice, тот самый минимальный рабочий кусок продукта, который можно пройти от начала до конца. Не по слоям и папкам, не «сначала весь backend, потом весь frontend», а по пользовательскому сценарию.

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

Release slice собирается вертикально. Это означает: мы берём один путь пользователя от входа до результата и проводим через него все нужные слои сразу. Для Support Agent такой срез выглядит так:

flowchart TD
    A[Входящий ticket] --> B[Классификация]
    B --> C[Черновик ответа]
    C --> D[Проверка оператором]
    D --> E[Отправка]
    E --> F[Запись в audit trail]

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

## Релизный срез

Input: текст ticket'а и customer id.
Main action: классификация + draft ответа.
Output: оператор видит класс тикета и черновик ответа.
Fallback: при низкой уверенности ticket помечается как needs-human.
Demo data: 10 sample tickets трёх типов.

Обратите внимание на строку с fallback — это важная деталь. Release slice — не только happy path, но и минимально честное поведение там, где система не справляется. Для AI-продукта это особенно важно: не уверена модель — первая версия не должна героически делать вид, что всё поняла. Иногда лучший продуктовый ход — аккуратно отступить и передать задачу человеку.

Есть ещё один полезный sanity-check: если фичу нельзя показать на подготовленных данных за 3–5 минут, она почти наверняка не должна попадать в must-have текущего релиза. Сурово, но оздоравливает: отпадает половина идей, что отлично смотрятся в голове и ужасно — в дедлайне.

4. Non-goals: что вы сознательно не делаете

Когда разработчик пишет scope, он обычно с энтузиазмом перечисляет, что делает. А когда нужно написать, чего он не делает, энтузиазм резко испаряется, будто это список поражений. На самом деле non-goals — один из самых полезных разделов всей спецификации: не самокритика, а защита продукта. Какие разумно звучащие вещи мы сознательно не включаем, чтобы первая версия осталась завершённой? Для Support Agent хороший раздел non-goals может выглядеть так:

## Не-цели

В текущий релиз не входят:
multi-language support,
voice / phone support,
интеграция с CRM,
автоматическая обработка refund,
A/B testing ответов,
автообучение на новых диалогах.

Не красивая бумажка — список работает сразу в трёх местах.

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

Во-вторых, non-goals защищают от окружающих. Если кто-то смотрит на проект и спрашивает «а почему нет интеграции с CRM?» — у вас не оправдание, а архитектурное решение: для первого релиза мы строим inbox + classification + human review, а не платформу техподдержки всего мира.

В-третьих, non-goals очень полезны при работе с Claude Code. AI любит быть полезным с размахом: попросите «сделай MVP поддержки лучше» — он вполне может начать расширять продукт в стороны, которые вам вообще не нужны сейчас. А вот чётко прописанные non-goals сильно снижают риск такого helpful overreach.

Есть тонкая, но важная разница между идеями, которые уходят в Later, и теми, что попадают в Non-goals. Later — скорее дорожка на следующую версию того же продукта. Non-goals — акцент на том, что именно сейчас они мешают релизу. Иногда одно и то же может быть и тем, и другим — это нормально, не превращайте разделы в чистую математику.

5. Forbidden zone: ИИ помогает, но не решает

Есть особый тип границы, который полезно выделять отдельно. Это не просто «функции, которых нет», а зона, где ИИ принципиально не должен иметь последнее слово, даже если технически вы могли бы это автоматизировать. Для Support Agent такой блок особенно важен: продукт работает рядом с деньгами, жалобами и клиентскими решениями. И здесь уже мало сказать «мы не делаем auto-refund» — лучше прямо записать, что остаётся за человеком всегда:

## Запретная зона

Refund > $100 — только ручное одобрение.
Жалобы с юридическим риском — только эскалация человеку.
Отмена уже отправленного заказа — только manual action.
AI может подсказать, но не принимает финальное решение.

Прятать это внутри обычных non-goals не стоит: речь ведь не о размере релиза, а о границе ответственности. Продукт может показать кейс, подсветить его, подготовить черновик — но не исполнять автономно.

Это очень хорошая привычка для любых AI-сценариев. Если система соприкасается с деньгами, правами, медициной, безопасностью, доступами или с чем-то, что сложно откатить, — полезно явно ответить: где заканчивается помощь ИИ и начинается обязательное решение человека?

В нашем Support Agent forbidden zone ещё и отлично помогает на демо: показывать guardrail — не слабость продукта, а зрелость. Тикет с возвратом на 250 долларов честно блокируется и требует ручного подтверждения — это убедительнее «смелой автоматизации», которую никто в здравом уме не пустил бы в прод.

6. Сборка в текущую спецификацию

Когда scope, release slice, non-goals и forbidden zone определены, тот же spec-документ вдруг становится очень компактным и очень полезным — туман в нём исчезает. Он перестаёт быть сборником мечтаний и становится рабочим документом, по которому принимают решения каждый день. Для нашего примера центральный фрагмент выглядит так:

## Область изменений
Входит: inbox, три класса тикетов, draft ответа для typical-case,
ручное подтверждение оператором, audit trail, блокировка refund > $100.

## Не-цели
Не входят: мультиязычность, CRM, voice support, auto-refund, A/B testing.

## Основной поток пользователя
Оператор открывает ticket → видит класс и draft →
подтверждает или правит ответ → отправляет →
система сохраняет запись в audit trail.

Для чистого MVP это может быть MVP_SPEC.md; в остальных capstone — тот же блок внутри SPEC.md. Этот же документ можно продолжить ещё одной короткой вставкой:

## Demo-срез
Используем 10 sample tickets:
typical, needs-human, refund-high-value.

## Запретная зона
Refund > $100 и юридически рискованные жалобы
не обрабатываются автоматически.

В такой записи есть всё, что нужно для повседневного контроля проекта. Когда появляется новая идея, вы не обсуждаете её абстрактно, а сравниваете с документом: без неё core flow не существует — обсуждаем; делает демо приятнее, но не обязательнее — вниз по приоритету; лезет в forbidden zone — не пускаем под видом «улучшения».

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