Наратив захисту без хаосу

1. Захисту потрібен сценарій, а не імпровізація

На захисті майже ніколи не провалюються через те, що сказали недостатньо розумну фразу. Зазвичай провалюються через відсутність маршруту. Автор починає з того, що проєкт на FastAPI або Spring Boot, показує випадковий екран, згадує про користувача, а перевірку й обмеження додає як післямову. Для рецензента це виглядає так: проєкт є, контролю над ним немає.

Захист потрібен не для того, щоб переповісти весь репозиторій, рецензент відкриє його сам. Ваше завдання — провести людину коротким і логічним шляхом: проблема → рішення → докази → межі. Це той самий trust mechanism, механізм довіри. Submission package показує, що проєкт існує і відтворюється. Defense narrative — що ви розумієте, що зробили і чому.

Хороший захист дуже схожий на екскурсію квартирою перед продажем. Ви не починаєте з розповіді про марку шурупів у шафі — спершу де кухня, навіщо перепланування, чому тут зручно жити. Так само і тут: спочатку сенс, потім маршрут, потім технічні рішення, а окремі деталі — наприкінці.

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

2. Від 4 опор до 10 кроків захисту

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

Ось як чотири опори розкладаються на повну 10-крокову структуру.

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

Щоб структура не розпливалася, зручно тримати під рукою односторінкову заготовку — не текст для читання вголос, а опорну карту.

# DEFENSE_NOTES.md

1. Problem:
2. User / JTBD:
3. Scope / non-goals:
4. Core scenario:
5. Solution:
6. Architecture decisions:
7. Claude Code workflow:
8. Verification:
9. Limitations:
10. Trade-offs / Next steps:

Зверніть увагу на порядок — він не випадковий. Рецензенту легше довіряти тому, що він бачить у правильній послідовності. Спочатку навіщо проєкт потрібен, потім що в нього ввійшло, далі як він улаштований і як ви його робили, і лише після цього — наскільки надійний результат і де межі. Переставте місцями — захист пролунає як випадковий набір технічних фактів.

3. Кроки 1–4: проблема, користувач, scope, сценарій

Перші чотири кроки — це момент, коли ви домовляєтеся з рецензентом про саме завдання. Поки немає ясності, для кого проєкт і що входить до scope, будь-які розмови про стек і тести звучать як розповідь про молоток до пояснення, навіщо ви взагалі будували будинок.

Щоб не розпливатися в абстракції, візьмімо один наскрізний приклад. Capstone: CSV-валідатор вивантажень повернень для команди підтримки Commerce OS. Перевіряє файл, показує помилки, допомагає зрозуміти, чи можна завантажувати вивантаження далі.

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

На другому кроці ви називаєте користувача і його JTBD. Якщо ви цей крок пропускаєте, рецензент потім сам починає гадати: це для адміністратора? аналітика? розробника?

На третьому кроці ви фіксуєте scope і non-goals, межі проєкту. Це один із найбільш недооцінених моментів, і саме тут видно зрілість. Слабкий автор соромиться цього і намагається звучати «ширше». Сильний чесно показує, де проєкт закінчується — рецензент майже завжди любить друге.

Четвертий крок — core scenario, основний сценарій. Це один шлях, який ви показуєте на демо від початку до кінця. Не «а тут теж цікаво», а одна ясна доріжка.

Для цих чотирьох кроків корисно мати коротку заготовку приблизно в такому вигляді:

1. Problem:
Команда підтримки вручну перевіряє CSV-вивантаження повернень і витрачає на це багато часу.

2. User / JTBD:
Інженер підтримки хоче швидко зрозуміти, чи годиться файл для завантаження, не переглядаючи його вручну.

3. Scope / non-goals:
Підтримуються лише CSV до 50 МБ. XLSX, авторизація й хмарне розгортання не входять до поточного scope.

4. Core scenario:
Завантаження файлу → валідація → звіт з помилками → експорт результату.

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

4. Кроки 5–7: рішення, архітектура, процес із Claude

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

На пʼятому кроці ви формулюєте solution простими словами: «Невеликий вебінструмент, який приймає CSV-файл, валідовує структуру й видає звіт про помилки». Цього достатньо — не перераховуйте модулі, пакети та бібліотеки, важливий сенс, а не список імпортів.

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

Сьомий крок — process with Claude Code. Тут не можна обмежитися фразою «AI допомагав писати код» — вона нічого не пояснює. Сильне формулювання показує розподіл відповідальності: що робив Claude, а що ви.

Нижче добре видно, як відрізняються слабкі й сильні формулювання.

Гарний короткий блок для кроку 7 може виглядати так:

## Claude Code workflow

- Почав із `SPEC.md` і критеріїв приймання
- Спочатку попросив plan-first розбір завдання
- Реалізував рішення маленькими diff-ами
- Після кожного кроку вручну читав зміни
- Запускав tests і smoke-перевірку
- Ключові рішення фіксував у `EVIDENCE.md`

Особливо важливо не перетворити цей крок на спробу здаватися «більш AI-native, ніж життя». Використовували один CLAUDE.md, кілька запитів і ручний review — так і кажіть. Доречність сильніша за кількість. Пʼять незрозумілих хуків і агентів проєкт не врятують — один чесно застосований процес його посилить.

5. Кроки 8–10: перевірка, обмеження, компроміси

Останні три кроки роблять захист дорослим. До них ви показували, що проєкт є і в нього є структура. Тут ви показуєте, чому йому можна вірити. Саме на цих кроках рецензент розуміє: перед ним людина, яка перевіряла результат, чи та, що сподівається, що demo не зламається в найближчі дві хвилини.

Восьмий крок — verification, перевірка. Найслабше формулювання на захисті звучить так: «Я протестував проєкт». Сильне формулювання завжди конкретне: скільки тестів, які команди, чи був smoke-сценарій, ручний прогін, перевірка з чистого клону.

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

Десятий крок — trade-offs / next steps, компроміси й наступний розумний крок. Компроміс — це не виправдання, а чесна відповідь, чому проєкт зроблено саме так. І наступний крок логічно випливає з компромісу.

Усе це лягає в короткий фрагмент:

## Перевірка
- `pytest -q` → 12 тестів зелені
- smoke: завантаження 3 тестових CSV проходить за demo-сценарієм
- reproducibility: fresh clone + запуск за `README.md`

## Обмеження
- лише CSV, без XLSX
- файли до 50 МБ
- немає авторизації
- немає повторного надсилання після помилки

## Компроміси / наступні кроки
- відмовився від БД заради простого локального запуску
- не робив хмарне розгортання, щоб не роздувати scope
- наступний крок: XLSX + історія перевірок + CI

Якщо ваш capstone не MVP, а, скажімо, migration slice або team workflow design, сам принцип не змінюється — змінюється лише verification. Для migration це feature parity, smoke checks, rollback plan і compatibility evidence. Для team workflow design — відтворювана структура plugin, policy, guardrails і перевірка сценарію впровадження. Логіка одна: спочатку докази, потім обмеження, далі свідомий наступний крок.

6. Одна розповідь, три масштаби: short / mid / full

Структура захисту в усіх однакова, різна лише глибина зуму. Це як одна й та сама карта міста: комусь потрібен маршрут від станції до офісу, комусь — схема кварталу, комусь — інженерний план комунікацій. Junior, Middle і Senior розповідають не різні історії — по-різному наближають одну.

Ось зручний спосіб дивитися на це в трьох форматах.

Якщо вам потрібен дуже короткий pitch, він має звучати як стисла версія тих самих десяти кроків, а не як зовсім інша розповідь. Наприклад, для CSV-валідатора він може виглядати так:

Я зробив demo-ready інструмент для команди підтримки, який перевіряє CSV-вивантаження повернень і швидко показує помилки. 
Основний сценарій — завантаження файлу, валідація й звіт. 
Claude Code я використовував для plan-first роботи, чорновиків і перевірки edge cases, а фінальні рішення, diff review і smoke-check робив сам. 
Наразі проєкт підтримує лише CSV без авторизації, і це свідомі межі поточного scope.

Це вже пристойний короткий варіант. Середній формат додає глибину, повний — архітектуру, traceability і більш дорослу розмову про компроміси. Але це все та сама історія, наближена сильніше.

Тут корисно памʼятати важливу річ: різні capstone-формати трохи зміщують акценти, але не ламають структуру. Modernization або migration — підсвітіть кроки 6, 8 і 10: архітектура, перевірка паритету, rollback, ризики. Team workflow design — policy, CLAUDE.md, plugin structure і межі впровадження. Але перші чотири кроки — проблема, користувач, межі, основний сценарій — не зникають: без них рецензент не розуміє, що саме ви захищаєте.

7. Репетиція захисту до впевненого подання

Репетиція потрібна не тому, що mentor любить дисципліну. Вона потрібна тому, що під стресом мозок швидко перетворює навіть розумну людину на колекціонера випадкових вкладок. Narrative спочатку збирають на папері, потім проговорюють уголос, і лише потім поєднують із живим demo та файлами. І так, перша репетиція майже завжди звучить незграбно — це нормальна плата за те, щоб на реальному захисті не звучати незграбно.

Практично зручніше йти в три кола. Спочатку зберіть one-pager: сторінку нотаток із десятьма кроками та однією-двома фразами на кожен. Не весь README, а коротку карту. Потім пройдіть її вголос без demo і без перемикання вікон — почуєте, де фрази довгі, де зависаєте, де раптом пояснюєте бібліотеку замість проблеми користувача. Третє коло: вмикаєте реальний demo-path і відкриваєте лише потрібні вкладки.

Зазвичай достатньо чотирьох опорних вікон. Перше — сам проєкт або його demo. Друге — README.md або SPEC.md для формального формулювання завдання. Третє — EVIDENCE.md або короткий блок із tests/checks. Четверте — PR diff, architecture note або інший артефакт, якщо ваш capstone його вимагає. Якщо вікон більше і ви самі в них плутаєтесь, це майже завжди означає, що narrative ще не зібраний.

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

# Односторінковий захист-нота

1. Яку проблему вирішую?
2. Для кого це рішення?
3. Що ввійшло, а що не ввійшло до scope?
4. Який один сценарій я показую на demo?
5. Що саме побудував?
6. Які 2–3 архітектурні рішення були ключовими?
7. Де допоміг Claude, а де рішення було моїм?
8. Чим я перевірив результат?
9. Які обмеження має поточна версія?
10. Які компроміси прийняв і що логічно робити далі?

Під час репетиції обовʼязково проговорюйте вголос фразу про розподіл відповідальності: що робив Claude і що робили ви. Це одне з тих запитань, які майже завжди виявляються навантажувальними. Чуєте розмите «Claude допомагав по всьому проєкту» — приземліть: «Claude запропонував план, допоміг із чорновиком тестів і підсвітив edge cases, а я вручну читав diff, запускав перевірки та ухвалював рішення щодо scope».

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

Коли ви спокійно проходите всі десять кроків, не втрачаючи порядок, показуєте один ясний demo-сценарій і без метушні пояснюєте роль Claude Code — захист перестає бути лотереєю. Він звучить як розмова інженера, який справді володіє своїм результатом.