Ціннісна пропозиція для capstone-проєкту

1. Проєкт ламається ще в заголовку

Коли ви кажете «хочу зробити ШІ-помічника для маркетингу», «хочу зробити платформу для підтримки» або «хочу зробити фінансовий дашборд», звучить ніби серйозно. Але це не ідея проєкту, а категорія. Все одно що сказати «Хочу відкрити ресторан». Який? Для кого? З чим? Чому туди прийдуть? Без відповідей у вас не ресторан, а красиве слово з потенційними витратами.

Із проєктами в capstone — та сама історія. Широка формулювання створює ілюзію, ніби проєкт обрано. Обрано лише домен. А далі звичний сценарій: фіча «про всяк випадок», потім дашборд, авторизація, експорт, інтеграції, «ну раз уже AI, давайте ще рекомендацій». І MVP перетворюється на музей нездійснених обіцянок.

Тут важливо зняти зайву тривогу. Якщо ви вже обрали capstone раніше, новий у паніці вигадувати не потрібно. Завдання не зламати ідею, а звузити до робочої форми: такої, яку швидко поясните ментору, ревʼюеру, роботодавцю і собі через три дні, коли ентузіазм охолоне.

Дуже корисно на цьому етапі поставити собі неприємне, але чесне запитання. Приберіть слова «AI», «платформа» і «система» — залишиться зрозуміла цінність? Не залишається — ідея тримається на упаковці. Claude Code тут не рятує: коли завдання розмите, він не допомагає, він домислює. А коли домислюєте і ви, і Claude одночасно, виходить те, що програмісти чемно називають «творчий хаос», а дедлайни — вже інакше.

2. Ідея — не категорія, а конкретний кейс

Дуже корисно навчитися відрізняти широку область від робочого кейсу всередині неї. У кейсі видно, хто користується результатом, навіщо і що ви покажете на demo. Не «все для всіх», а один зрозумілий шматок користі.

Зверніть увагу на закономірність. У «сирій» формулюванні є масштаб, але немає дії. У робочому куті — навпаки. Навчальний проєкт має викликати довіру ясністю, а не лякати масштабом.

Ще один корисний тест: продовжте формулювання словом «щоб…». «Щоб покращувати бізнес-процеси» — ви на рівні категорії. «Щоб оператор підтримки не витрачав пів дня на однотипні відповіді й не пропускав дорогі refund-кейси» — на потрібній глибині.

3. Чотири фільтри хорошої ідеї

На цьому етапі корисно не гадати за натхненням, а проганяти ідею через кілька простих фільтрів. Вони не вбивають креативність, вони прибирають самообман. Хороша ідея для MVP проходить чотири перевірки підряд і не розвалюється на другій.

Ці чотири фільтри — базові. Якщо ідея пройшла їх, уже добре. Але в реальній роботі є ще три дуже приземлені запитання, які варто поставити до старту. По-перше, чи покажете ви проєкт за три хвилини, не пояснюючи п’ять хвилин контекст? По-друге, чи є дані або sample data, на яких це взагалі можна продемонструвати? По-третє, чи не тримається все на зовнішньому сервісі, який завтра відповість «429 Too Many Requests» і зіпсує захист? Проєкт, цілком повислий на крихкому платному API, — не MVP, а лотерея з елементами DevOps-хорору.

Якщо ідея не проходить один із фільтрів, її не обов’язково викидати — зазвичай потрібно не замінити, а звузити. Це важливий психологічний момент. Ви не «провалили brainstorm», а зняли зайві шари. Часто після цього в проєкту з’являється форма.

4. Ціннісна пропозиція — не слоган, а інженерний абзац

Коли чуєш вислів value proposition, легко уявити банер на кшталт «революційна AI-платформа нового покоління». Курс просить вас мислити значно прозаїчніше. Це не прикраса, а робочий абзац на чотири запитання: кому корисний проєкт, який біль знімає, що робить в основному сценарії та чому це варто показувати.

Хороша value proposition однаково працює і на початку поточної специфікації — MVP_SPEC.md для чистого MVP або наявного SPEC.md для інших capstone, — і в розмові з ревʼюером, і в описі демо. Погана звучить так, ніби автор боїться назвати користувача — тоді доведеться відповідати за зміст.

Зручний шаблон для старту:

Цей проєкт допомагає <кому> зробити <що>,
коли в нього є <конкретна ситуація або біль>.
Основний результат: <вимірюваний ефект>.
На demo я показую <один основний сценарій>.

А ось той самий шаблон уже як робочий абзац для нашого наскрізного прикладу:

AI Support Agent допомагає оператору підтримки невеликого інтернет-магазину
швидше закривати типові звернення й не пропускати high-value refunds.
Основний результат: типові звернення класифікуються автоматично,
для них зʼявляється чернетка відповіді, а refund вище порога потребує ручного підтвердження.
На demo показується обробка 10 sample tickets і видиме блокування risky case.

Зверніть увагу: тут немає жодного слова про стек, модель, embeddings, workflow engine і решту технічних прикрас. І це добре. Технічна сторона важлива, але value proposition живе раніше за неї. Інакше виходить класична помилка: технічно витончений проєкт, про який неможливо за 20 секунд пояснити, навіщо він існує.

Якщо ваш capstone взагалі не є MVP у чистому вигляді, логіка не змінюється. Value proposition просто звучить менш «продуктово». Наприклад, для migration slice можна чесно сказати: цей проєкт допомагає команді безпечно перевірити перехід проблемного модуля на нову версію фреймворку без поломки критичного розрахунку. Так, це не звучить як startup pitch. Зате це зрозуміла цінність для реальної команди.

5. Demo potential і portfolio value: рахуємо заздалегідь

Є дві перевірки, які на стадії ідеї часто здаються «занадто карʼєрними» або «занадто пізніми». Насправді це ранні інженерні фільтри. Перша перевірка звучить так: що саме я покажу за три хвилини? Друга — як це потім виглядатиме в одному bullet point у портфоліо або резюме? Якщо відповіді немає, ідея ще надто розпливчаста.

Дуже часто студенти думають про demo занадто пізно. Десь ближче до захисту вони раптом розуміють, що проєкт у них «загалом цікавий», але швидко показати його не можна. Потрібно довго пояснювати контекст, готувати оточення, запускати три сервіси, потім з’ясовується, що sample data бракує, а зовнішній API сьогодні не відповідає. Все це не проблема demo. Це проблема ідеї, яку не перевірили на демонстрованість заздалегідь.

Із портфоліо та сама історія. Якщо ви не можете сформулювати проєкт одним чесним рядком, він, найімовірніше, занадто роз’їхався. Хороший bullet не бреше й не роздуває масштаб. Він каже щось на кшталт: «Зібрав MVP для скриньки підтримки з ШІ: класифікація звернень, чернетки відповідей і human-in-the-loop guardrails для дорогих кейсів із поверненням коштів». Уже з цієї фрази зрозуміло, що ви робили, яку проблему розв’язували і де в проєкту межі. А це значно сильніше, ніж фраза «розробив інноваційну AI-платформу підтримки».

6. Розбираємо AI Support Agent як робочу ідею

Тепер зберемо все на одному прикладі — AI Support Agent for Online Store. Він зручний тим, що домен вам знайомий за support-модулем Commerce OS: тобто це не чужа предметна область, а компактна версія того, що ви вже бачили раніше.

Сира ідея звучить так: «Зробити ШІ-помічника для підтримки інтернет-магазину». Погана не темою — тема чудова. Погана тим, що всередину можна сховати що завгодно: CRM, чат, multilingual support, voice, sentiment analysis, automation, escalation, knowledge base. Це не одна ідея, а ціла продуктова лінійка.

Після уточнення робочий кут стає помітно вужчим — і сильнішим. Проєкт потрібен оператору підтримки невеликого інтернет-магазину: приблизно 60–100 звернень на день. Половина однотипна — де замовлення, коли доставка, як оформити повернення. Водночас refund-запити вище певної суми автоматично обробляти не можна. Цінність не «замінити підтримку AI», а розвантажити типові відповіді й зробити небезпечні кейси помітними.

У такому вигляді ідея вже жива: користувач, біль, обмеження, демо-сценарій. Ба більше, у неї є явна forbidden zone — дорогий refund не повинен полетіти в автоматичну обробку. Коли в проєкту є не лише «що він уміє», а й «чого він принципово не робить сам», він виглядає доросліше й чесніше.

Чорновий фрагмент для специфікації:

## Ціннісна пропозиція
AI Support Agent допомагає оператору підтримки швидше закривати
типові звернення й не пропускати ризикові refund-кейси.

## Основне demo
Ticket → classification → AI draft → operator approval.

## Сигнал успіху
На 10 sample tickets класифікація не нижче 80%,
refund > $100 не проходить без ручного підтвердження.

Для чистого MVP цей блок живе в MVP_SPEC.md. Для capstone іншого типу — той самий абзац в основному SPEC.md, а не привід заводити другого близнюка.

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

7. Claude Code тут — суворий редактор, не фантазер

Є велика різниця між двома запитами до Claude Code. Перший: «Придумай мені класну ідею AI-проєкту». Другий: «Розбий мою поточну ідею як суворий ревʼюер і скажи, де вона розпливчаста». Для інженерної роботи майже завжди корисніший другий: на стадії вибору ідеї Claude має не роздувати scope, а підсвічувати діри в логіці.

Хороший запит на цьому етапі:

Розглянь цю ідею проєкту як суворий ревʼюер.
Поверніть:
- хто є користувачем,
- який біль є явним,
- який результат можна виміряти,
- що є надто широким,
- що можна показати за 3-хвилинне демо.
Не пропонуйте більше функцій.

Останній рядок тут майже важливіший за всі інші. Якщо його не написати, Claude з найкращих намірів почне «допомагати» й запропонує ще кілька чудових поліпшень. А вам потрібні не поліпшення — вам потрібна ясність. Тут Claude корисніший як співрозмовник із холодною головою, ніж як генератор ентузіазму.

Цей самий підхід працює і для capstone, який не є MVP. Feature в існуючому коді, migration slice, DevOps automation — дайте Claude те саме завдання: виявити користувача, біль, вимірюваний результат і показати, де занадто широко. Навіть найтехнічніший проєкт на захисті доведеться пояснювати через цінність, а не через кількість налаштованих YAML-файлів.

У певний момент після такого review ви відчуєте хороший ефект: проєкт перестане звучати як мрія і почне звучати як обіцянка, яку реально виконати. Це чути просто: якщо одним абзацом поясните, кому корисний проєкт, який біль закриває і що покажете на demo, — ідея готова жити далі не в голові, а в специфікації.