Value proposition для capstone-проекта

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

Когда вы говорите «хочу сделать AI-помощника для маркетинга», «хочу сделать платформу для поддержки» или «хочу сделать финансовый dashboard», звучит вроде бы серьёзно. Но это не идея проекта, а категория. Всё равно что сказать «Хочу открыть ресторан». Какой? Для кого? С чем? Почему туда придут? Без ответов у вас не ресторан, а красивое слово с потенциальными расходами.

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

Здесь важно снять лишнюю тревогу. Если вы уже выбрали capstone раньше, новый в панике придумывать не нужно. Задача не сломать идею, а сузить до рабочей формы: такой, которую быстро объясните ментору, reviewer'у, работодателю и себе через три дня, когда энтузиазм остынет.

Очень полезно на этом этапе задать себе неприятный, но честный вопрос. Уберите слова «AI», «платформа» и «система» — останется понятная ценность? Не остаётся — идея держится на упаковке. Claude Code тут не спасает: когда задача размыта, он не помогает, он додумывает. А когда додумывают и вы, и Claude одновременно, получается то, что программисты вежливо называют «творческий хаос», а дедлайны — уже по-другому.

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

Очень полезно научиться отличать широкую область от рабочего кейса внутри неё. В кейсе видно, кто пользуется результатом, зачем и что вы покажете на demo. Не «всё для всех», а один понятный кусок пользы.

Обратите внимание на закономерность. В «сырой» формулировке есть масштаб, но нет действия. В рабочем угле наоборот. Учебный проект должен внушать доверие ясностью, а не пугать масштабом.

Ещё один полезный тест: продолжите формулировку словом «чтобы…». «Чтобы улучшать бизнес-процессы» — вы на уровне категории. «Чтобы оператор поддержки не тратил полдня на однотипные ответы и не пропускал дорогие refund-кейсы» — на нужной глубине.

3. Четыре фильтра хорошей идеи

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

Эти четыре фильтра — базовые. Если идея прошла их, уже хорошо. Но в реальной работе есть ещё три очень приземлённых вопроса, которые стоит задать до старта. Во-первых, покажете ли проект за три минуты, не объясняя пять минут контекст? Во-вторых, есть ли данные или sample data, на которых это вообще можно продемонстрировать? В-третьих, не держится ли всё на внешнем сервисе, который завтра ответит «429 Too Many Requests» и испортит защиту? Проект, целиком висящий на хрупком платном API, — не MVP, а лотерея с элементами DevOps-хоррора.

Если идея не проходит один из фильтров, её не обязательно выбрасывать — обычно нужно не заменить, а сузить. Это важный психологический момент. Вы не «провалили brainstorm», а сняли лишние слои. Часто после этого у проекта появляется форма.

4. Value proposition — не слоган, а инженерный абзац

Когда слышишь выражение value proposition, легко представить баннер вроде «революционная AI-платформа нового поколения». Курс просит вас мыслить намного прозаичнее. Это не украшение, а рабочий абзац на четыре вопроса: кому полезен проект, какую боль снимает, что делает в основном сценарии и почему это стоит показывать.

Хорошее value proposition одинаково работает и в начале текущей спецификации — MVP_SPEC.md для чистого MVP или существующего SPEC.md для остальных capstone, — и в разговоре с reviewer'ом, и в описании демо. Плохое звучит так, будто автор боится назвать пользователя — тогда придётся отвечать за смысл.

Удобный шаблон для старта:

Этот проект помогает <кому> сделать <что>,
когда у него есть <конкретная ситуация или боль>.
Основной результат: <измеримый эффект>.
На demo я показываю <один core scenario>.

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

AI Support Agent помогает оператору поддержки небольшого интернет-магазина
быстрее закрывать типовые tickets и не пропускать high-value refunds.
Основной результат: типовые обращения классифицируются автоматически,
для них появляется draft ответа, а 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 не врёт и не раздувает масштаб. Он говорит что-то вроде: «Собрал AI-assisted support inbox MVP с классификацией обращений, draft-ответами и human-in-the-loop guardrails для дорогих refund-кейсов». Уже из этой фразы понятно, что вы делали, какую проблему решали и где у проекта границы. А это гораздо сильнее, чем фраза «разработал инновационную AI-платформу поддержки».

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

Теперь соберём всё на одном примере — AI Support Agent for Online Store. Он удобен тем, что домен вам знаком по support-модулю Commerce OS: то есть это не чужая предметная область, а компактная версия того, что вы уже видели раньше.

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

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

В таком виде идея уже живая: пользователь, боль, ограничение, демо-сценарий. Более того, у неё есть явная forbidden zone — дорогой refund не должен улетать в автоматическую обработку. Когда у проекта есть не только «что он умеет», но и «чего он принципиально не делает сам», он выглядит взрослее и честнее.

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

## Value proposition
AI Support Agent помогает оператору поддержки быстрее закрывать
типовые обращения и не пропускать risky refund cases.

## Основное 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-проекта». Второй: «Разбей мою текущую идею как строгий reviewer и скажи, где она расплывчата». Для инженерной работы почти всегда полезнее второй: на стадии выбора идеи Claude должен не раздувать scope, а подсвечивать дыры в логике.

Хороший запрос на этом этапе:

Review this project idea as a strict reviewer.
Вернуть:
- who the user is,
- what pain is explicit,
- what outcome is measurable,
- what is too broad,
- what can be shown in a 3-minute demo.
Do not suggest more features.

Последняя строка тут едва ли не важнее всех. Если её не написать, Claude из лучших побуждений начнёт «помогать» и предложит ещё несколько прекрасных улучшений. А вам нужны не улучшения — нужна ясность. Здесь Claude полезнее как собеседник с холодной головой, чем как генератор энтузиазма.

Этот же подход работает и для capstone, который не является MVP. Feature в существующем коде, migration slice, DevOps automation — дайте Claude ту же задачу: выявить пользователя, боль, измеримый результат и показать, где слишком широко. Даже самый технический проект на защите придётся объяснять через ценность, а не через количество настроенных YAML-файлов.

В какой-то момент после такого review вы поймаете хороший эффект: проект перестанет звучать как мечта и начнёт звучать как обещание, которое реально выполнить. Слышно это просто: если одним абзацем объясните, кому полезен проект, какую боль закрывает и что покажете на demo, — идея готова жить дальше не в голове, а в спецификации.