Резервное демо хакатона: что показать, если сервис не работает

Во время выступления запрос зависает. Докладчик нажимает кнопку снова, второй участник открывает журнал ошибок, время идёт. Если команда заранее решила, когда и на что переключаться, она может продолжить объяснение проекта. Без такого решения техническая проблема быстро становится проблемой всего выступления.

Резервное демо готовят для конкретного отказа: недоступная сеть, внешний API, сбой устройства или проблема с выводом изображения. Оно показывает уже достигнутый результат. Запись не превращает неработающую функцию в работающую и не отменяет требования события к живой демонстрации.

Узнайте, какой резерв допускают правила

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

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

Не рассчитывайте, что дополнительное время дадут автоматически. Постройте выступление так, чтобы после переключения уложиться в первоначальный лимит. Публичный спор с ведущим о времени редко помогает объяснить работу проекта.

Выберите резерв под уязвимую часть

Если продукт зависит от сети, полезна локальная видеозапись полного сценария. Если проблема в устройстве, заранее проверьте допустимый способ показать зафиксированный результат измерения. Если риск связан с авторизацией, подготовьте согласованный демонстрационный доступ и протестируйте его заранее.

Скриншоты помогают объяснить отдельные состояния, но не доказывают переход между ними. Кликабельный макет показывает взаимодействие, но не подтверждает работу обработки данных. Подписывайте формат точно: запись работающей сборки, макет интерфейса, пример результата.

В рекомендациях Devpost по видео акцент сделан на демонстрации проекта. Для резерва это особенно полезно: зрителю нужен видимый ход работы, а не ещё один ролик с обещаниями. Сценарий записи должен соответствовать тому, что команда собирается показать вживую.

Подготовьте небольшой комплект файлов

Соберите в одной папке:

Сохраните комплект на основном и резервном устройстве. Проверьте воспроизведение с отключённой сетью. Ссылка на облачный диск не является автономным резервом, даже если файл однажды открывался в браузере.

Уберите из кадров личные уведомления, токены и чужие данные. Проверьте размер текста на экране зрителя. Если звук записи нельзя вывести в зал, докладчик должен уметь комментировать её самостоятельно. Подробнее о подготовке ролика написано в статье о видео демо.

Договоритесь о моменте переключения

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

Человек у ноутбука открывает подготовленный файл сразу. Он не ищет его среди загрузок и не спрашивает, какая из пяти версий последняя. Докладчик продолжает с того же шага, объясняя входные данные, действие и результат.

Отдельно решите, кто может проверять неисправность во время выступления. Если команда из двух человек, иногда разумнее отложить диагностику и закончить показ. Исправление на сцене имеет смысл только тогда, когда причина понятна и действие укладывается в оставшееся время.

Проведите репетицию с намеренным отказом

Один раз пройдите выступление нормально, второй раз отключите уязвимую зависимость в безопасной тестовой среде. Засеките время от сбоя до продолжения рассказа. Проверьте, не потерялась ли мысль при смене формата и осталось ли место для вопросов.

После репетиции согласуйте последний рабочий набор файлов. Не перезаписывайте резерв непроверенной сборкой за несколько минут до выхода. Если запись отстаёт от проекта, прямо назовите различия и не приписывайте ей новые функции.

Когда выступление закончится, сохраните сведения о сбое для команды: где он произошёл, как повлиял на показ, что стоит изменить. Это пригодится на ретроспективе хакатона и при подготовке следующего демо.

Организаторам стоит заранее описать действия при сбое. Добавьте порядок резервного показа в шаблон регламента Stavleak и сообщите его командам до защиты.