Demo and deploy readiness

1. Демо — это сценарий, а не стендап с ноутбуком

Когда разработчик впервые готовит защиту проекта, у него часто возникает опасная мысль: «Да что там показывать, просто открою приложение и потыкаю». Звучит бодро ровно до секунды, когда браузер открылся не в той вкладке, сид не загружен, сервер просит порт, а вы говорите ревьюеру: «сейчас, секундочку, это быстро». Обычно не быстро.

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

Для этого удобно держать в голове совсем короткую структуру показа:

Проблема → входные данные → действие → результат → ценность

Если взять, например, Landing Optimizer, плохое демо выглядит так: ходите по вкладкам, извиняетесь за некрасивый экспорт — ревьюер вежливо смотрит и внутри тонет. Хорошее выглядит иначе: одна landing page, нажимаете анализ, получаете список гипотез с приоритетами и объясняете, чем это полезно маркетологу. Один сценарий, одна ценность, одна дуга.

Здесь очень помогает неприятная, но полезная мысль: демо не обязано показать весь проект — оно обязано показать лучший и самый надёжный срез. Пять фич в capstone, а стабильно работает одна — показывайте её; остальные живут в README, screenshots, ограничениях и планах. Это не слабость, а инженерная честность, которая ценится выше хрупкой бравады.

2. Для показа нужен не прод, а предсказуемый demo slice

Разводить demo-ready и production-ready заново уже не нужно: stop/go для этого лежит в DEMO_QUALITY_GATE.md. Здесь важен практический вывод: для показа нужен не самый «взрослый» сетап, а самый предсказуемый demo slice.

Ваша цель не доказать, что вы умеете выкатывать проект, а доставить core flow без рулетки. Поэтому дальше полезно смотреть не на престиж, а на предсказуемость: локальный запуск, удалённый стенд и fallback — три способа показать один сценарий.

3. Deploy не всегда обязателен

После слов «подготовить демо» почти автоматически появляется другой внутренний голос: «надо срочно выкатить в облако, иначе не солидно». Это понятная реакция. Деплой выглядит взросло, у него есть URL, на него приятно смотреть издалека — но для учебного capstone он чаще источник риска, а не усиление. Здесь полезно сравнить три режима показа.

Для большинства capstone-проектов локальное воспроизводимое демо — лучший базовый выбор. Особенно если у вас уже есть понятный docker compose up, demo data лежат в репозитории, а README даёт короткий quickstart. Ревьюеру важен не модный домен, а то, что вы за минуты поднимаете проект и не зависите от падения среды. Минимальный локальный сценарий часто элегантнее облака:

docker compose up -d
# Поднимаем локальное окружение

python -m app demo --sample data/sample.csv
# Запускаем демонстрационный сценарий

Если же ваш deploy уже готов и скучно стабилен — это прекрасно: например, Landing Optimizer живёт на Vercel, открывается по одному URL, sample page зашита в интерфейс, без ручного прогрева. Но ключевое слово здесь — уже: не превращайте последнюю неделю sprint’а в «срочно выкатываем хоть куда-нибудь».

Под deploy readiness в рамках этой лекции мы понимаем не production-эксплуатацию, а вещь гораздо более скромную: если вы всё-таки показываете удалённый стенд, он должен быть предсказуемым. Стабильный адрес, понятный вход, заготовленные demo data и рядом fallback на случай, если облако захочет устроить театральную паузу. Иначе красивый URL превращается в красивую точку отказа.

4. Фолбэк — это часть демо, а не план провала

Самая спокойная защита — не та, где ничего не ломается, а та, где даже поломка уже предусмотрена. Именно поэтому fallback — не запасной стул в коридоре, а нормальная часть demo-сценария. Вы не придумываете его в момент падения live окружения: он уже лежит в DEMO.md, протестирован и даже чуть-чуть скучен. А скучный fallback — очень хорошая новость. Логику fallback удобно держать в виде короткой цепочки:

flowchart TD
    A[Live demo] -->|если всё хорошо| B[Показываем основной сценарий]
    A -->|если стенд не отвечает| C[Локальный запуск]
    C -->|если локальный запуск тоже капризничает| D[Записанное видео]
    D -->|если нужен быстрый обзор| E[Screenshots + walkthrough]

Сама идея простая. Первичный путь — лучший живой сценарий; ломается — переходите к вторичному, не перезапуская вслепую. Последний рубеж, screenshots walkthrough, показывает ценность без риска сбоя, даже когда жизнь решила пошутить. Очень полезно прописать это прямо в demo script:

## Если live demo не сработал

1. Перейти на локальный запуск по quickstart.
2. Если локальный сценарий недоступен — открыть `docs/demo.mp4`.
3. Если видео неуместно — показать screenshots из `docs/screens/`.

Заметьте, тут нет никакой магии — только заранее принятые решения. Именно это и снимает нервозность: вы больше не надеетесь, что «оно же обычно работает». Надежда, как вы уже наверняка заметили по курсу, — плохая замена тестам, gate’ам и demo strategy.

Для Personal CFO fallback особенно полезен, потому что сценарий там нередко зависит от загрузки CSV. Импорт в браузере закапризничал — нужен второй путь: готовый отчёт, CLI-вариант или скриншоты на sample data. Важно не нажать ту же кнопку, а сохранить ценность и результат.

5. Один проект — разные форматы показа

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

Если у вас проект ближе к API, не нужно насильно натягивать на него сложный UI. Намного сильнее может выглядеть короткий запрос к локальному серверу с понятным ответом:

curl -X POST http://localhost:8000/api/analyze \
  -H "Content-Type: application/json" \
  -d @data/sample-request.json
# В ответе приходит список гипотез с приоритетами

Если ваш проект — это CLI или отчёт, как бывает у части automation- и data-oriented capstone’ов, формат тоже может быть очень чистым:

python -m cfo summary --month 2026-04
# Отчёт сохранён в reports/2026-04.md

И это абсолютно нормальное демо. Более того, иногда такое демо лучше веб-интерфейса: короче, детерминированнее, честнее.

Для migration slice или legacy modernization основная ценность вообще может быть не в «красивом UI», а в доказательстве, что вы сохранили поведение и получили зелёную валидацию. Тогда хорошее демо — это не танцы вокруг интерфейса, а связка «до/после», validation report, smoke check и walkthrough по diff или отчёту. Не гламурно, зато инженерно убедительно.

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

6. Пишем понятный DEMO.md

Теперь перейдём к документу, который собирает всё это в одну управляемую штуку. В этой лекции я использую короткое имя DEMO.md; если у вас в репозитории принят вариант DEMO_README.md, суть та же — это ваш demo script, а не отдельная маркетинговая страница. Здесь роли разделяются просто: README.md — quickstart и ограничения, DEMO_QUALITY_GATE.md — внутренний stop/go перед репетицией, DEMO.md — сам маршрут показа, demo data, expected result и fallback.

Самый полезный каркас для DEMO.md:

# Сценарий demo

## Setup
...

## Команда для запуска
...

## Demo-данные
...

## Шаги сценария
...

## Ожидаемый результат
...

## Если live demo сломается
...

## Что объяснять
...

Каждый раздел здесь выполняет очень конкретную работу. В Command to run должна стоять реальная команда, а не абстракция «запустить приложение». В Demo data sample inputs лежат в репозитории или доступны по понятному пути, а не хранятся в папке Downloads под названием новый файл (17).csv.

Для Landing Optimizer блок сценария может быть примерно таким:

## Шаги сценария

1. Открыть страницу локального стенда.
2. Вставить demo URL лендинга.
3. Нажать Analyze.
4. Получить список гипотез с приоритетами.

А для Personal CFO — другим:

## Шаги сценария

1. Загрузить `data/sample-transactions.csv`.
2. Запустить категоризацию.
3. Показать месячную сводку.
4. Открыть блок recurring subscriptions.

Раздел Expected result особенно полезен тем, что заранее фиксирует, что считается успешным прохождением сценария, и убирает искушение на лету менять трактовку под то, что получилось. А раздел What to explain держит вас от чтения кода вслух: почему выбран именно этот slice, что он решает, что сознательно оставлено за рамками. Иными словами, DEMO.md — это документ, который делает выступление короче, а проект — понятнее.

7. Репетиция как тест воспроизводимости

Самый честный тест готовности проходит не у вас в голове и не когда вы сами в сотый раз открываете свой проект, а когда другой человек берёт ваш DEMO.md и пытается воспроизвести сценарий. В этот момент очень быстро выясняется всё интересное: что команда была «и так понятна», а на деле нет, что sample data лежат не там, а README предполагает ритуал, известный только автору. В общем, начинается очень полезная правда.

Поэтому репетиция демо — не актёрская практика, а почти инженерный smoke check. Лучше всего работает простой ритуал: попросите коллегу, одногруппника или ментора пройти по вашему сценарию и ничего не подсказывайте первые несколько минут. Дошёл уверенно до результата — воспроизводимость хорошая. Вставляете каждые тридцать секунд «а, тут ещё нужно вот это», «ой, забыл записать» — документ ещё не готов.

В этом месте особенно хорошо начинают работать уже знакомые вам артефакты. README.md отвечает за вход и запуск. DEMO_QUALITY_GATE.md подсказывает, можно ли вообще идти в репетицию. EVIDENCE_LOG.md помогает объяснить, что вы проверяли по спринту. DEMO.md задаёт маршрут показа. А честные ограничения в README снимают ненужное напряжение: ревьюер не ждёт того, чего вы сами не обещали. Всё складывается в спокойную систему, а не в набор героических «лишь бы красиво показать».

И вот это состояние и есть настоящая demo readiness. Не когда вы идеально выучили текст и быстро кликаете по кнопкам, а когда проект можно понять, запустить и оценить без магии автора. В такой момент демонстрация перестаёт быть выступлением на удачу и становится инженерным доказательством: результат воспроизводим, ценность видна, а падение live окружения не превращает защиту в импровизированный сериал.