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

1. MVP потрібен scope freeze

Після розмови про користувача й метрику дуже хочеться одразу відкрити редактор і почати «швидко збирати». Саме в цей момент проєкт зазвичай і починає роздуватися. Спочатку ви додаєте «ще одну корисну кнопку», потім «невеликий екран налаштувань», потім «раз ми вже тут, давайте прикрутимо аналітику». MVP таке любить: він узагалі майстер удавати безневинним, поки не зʼїсть увесь термін.

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

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

## Замороження області

Поточний реліз показує один сценарій:
вхідний тікет → класифікація → чернетка відповіді → перевірка оператором.

Усі нові великі функції після фіксації цього сценарію
не входять до поточного релізу й переносяться до Later.

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

2. Відділяємо must-have від «теж важливо»

На словах майже всі розуміють, що треба відокремлювати головне від другорядного. На практиці ж у «обовʼязково» чомусь миттєво потрапляє все підряд: логін, темна тема, експорт, історія дій, «раз уже є історія, давайте аналітику по тижнях». Тут рятує не інтуїція, а проста інженерна класифікація.

Зручно дивитися на фічі через таку таблицю:

Головне запитання одне: прибираємо цю штуку — сценарій ламається чи просто стає трохи менш красивим?

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

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

## Карта фіч

Must-have: inbox, класифікація, чернетка відповіді, ручне підтвердження, 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[Вхідний тікет] --> B[Класифікація]
    B --> C[Чернетка відповіді]
    C --> D[Перевірка оператором]
    D --> E[Надсилання]
    E --> F[Запис у audit trail]

Ось це і є перша версія, яку можна показати без ніякової фрази «тут поки не все підключено, але ви уявіть». Користувацький шлях завершений. Так, він вузький, так, він не покриває весь світ — зате він цілісний. У специфікації це зручно записувати коротко й дуже конкретно:

## Релізний зріз

Вхід: текст тікета та customer id.
Основна дія: класифікація + чернетка відповіді.
Вихід: оператор бачить клас тікета й чернетку відповіді.
Резервний сценарій: за низької впевненості тікет позначається як needs-human.
Демонстраційні дані: 10 тестових тікетів трьох типів.

Зверніть увагу на рядок із 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.
ШІ може підказати, але не ухвалює фінального рішення.

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

Це дуже добра звичка для будь-яких AI-сценаріїв. Якщо система контактує з грошима, правами, медициною, безпекою, доступами або з чимось, що складно відкотити, — корисно явно відповісти: де закінчується допомога ШІ та починається обовʼязкове рішення людини?

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

6. Збірка в поточну специфікацію

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

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

## Нецілі
Не входять: багатомовність, CRM, voice support, auto-refund, A/B testing.

## Основний потік користувача
Оператор відкриває тікет → бачить клас і чернетку →
підтверджує або править відповідь → надсилає →
система зберігає запис в 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 майже завжди є легкий ефект «щось він занадто компактний», і зазвичай саме в цей момент він і стає реалістичним. Перша версія не зобовʼязана вражати кількістю екранів. Її завдання — чесно довести одну корисну річ до стану, в якому її можна показати, зрозуміти й перевірити.