Defense narrative без хаоса

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

На защите почти никогда не проваливаются из-за того, что сказали недостаточно умную фразу. Обычно проваливаются из-за отсутствия маршрута. Автор начинает с того, что проект на FastAPI или Spring Boot, показывает случайный экран, вспоминает про пользователя, а проверку и ограничения добавляет как послесловие. Для reviewer это выглядит так: проект есть, контроля над ним нет.

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

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

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

2. От 4 опор к 10 шагам защиты

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

Вот как четыре опоры раскладываются на полную 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:

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

3. Шаги 1–4: проблема, пользователь, scope, сценарий

Первые четыре шага — это момент, когда вы договариваетесь с reviewer о самой задаче. Пока нет ясности, для кого проект и что входит в scope, любые разговоры про стек и тесты звучат как рассказ про молоток до объяснения, зачем вы вообще строили дом.

Чтобы не расплываться в абстракции, возьмём один сквозной пример. Capstone: CSV-валидатор выгрузок возвратов для команды поддержки Commerce OS. Проверяет файл, показывает ошибки, помогает понять, можно ли загружать выгрузку дальше.

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

На втором шаге вы называете пользователя и его JTBD. Если вы этот шаг пропускаете, reviewer потом сам начинает гадать: это для администратора? аналитика? разработчика?

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

Четвёртый шаг — core scenario, основной сценарий. Это один путь, который вы показываете на демо от начала до конца. Не «а тут тоже интересно», а одна ясная дорожка.

Для этих четырёх шагов полезно иметь короткую заготовку примерно в таком виде:

1. Problem:
Команда поддержки вручную проверяет CSV-выгрузки возвратов и тратит на это много времени.

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

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

4. Core scenario:
Загрузка файла → валидация → отчёт с ошибками → экспорт результата.

На этом этапе не стоит скатываться в технические подробности, и это нормально — их время ещё придёт. Сначала reviewer должен понять, что проект делает полезного и в каких границах вы его сознательно удержали.

4. Шаги 5–7: решение, архитектура, процесс с Claude

Когда проблема и основной сценарий уже ясны, reviewer естественно спрашивает: «А что именно вы построили и как принимали решения?» Вот здесь многие по привычке открывают дерево файлов и листают проект, как экскурсию по складу. Лучше сделать наоборот: сначала кратко решение, затем архитектурные выборы и только потом — процесс с 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: проверка, ограничения, компромиссы

Последние три шага делают защиту взрослой. До них вы показывали, что проект есть и у него есть структура. Здесь вы показываете, почему ему можно верить. Именно на этих шагах reviewer понимает: перед ним человек, который проверял результат, или тот, кто надеется, что demo не сломается ближайшие две минуты.

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

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

Десятый шаг — 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 и границы внедрения. Но первые четыре шага — проблема, пользователь, границы, основной сценарий — не исчезают: без них reviewer не понимает, что именно вы защищаете.

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 — защита перестаёт быть лотереей. Она звучит как разговор инженера, который действительно владеет своим результатом.