План на 48 часов хакатона: разработка, проверка и сдача
Пример рабочего плана на двухдневный хакатон: когда выбрать идею, объединить код, проверить прототип, записать демо и сдать заявку.
·4 мин чтения
План на 48 часов хакатона должен заканчиваться отправленной и проверенной заявкой. Если последнее действие в расписании называется «дописать код», вы ещё не выделили время на видео, доступы, загрузку файлов и исправление ошибок. Эти задачи входят в проект с самого начала.
Ниже приведён учебный план для команды, которая делает небольшой программный прототип. Интервалы показывают последовательность работы, а не обязательную норму. В них нужно разместить сон, еду, дорогу, мероприятия организатора и реальные часы доступности участников. Для аппаратных решений и заданий с длительными вычислениями распределение будет другим.
Первые три часа: договориться о результате
Прочитайте задачу, требования к сдаче и критерии жюри всей командой. Назовите пользователя, его проблему и один сценарий демонстрации. Запишите ограничения: обязательный сервис, разрешённые данные, формат файлов, время окончания разработки.
Сравните несколько идей по основному риску. Если команда не знает, как получить нужные данные, это требует проверки раньше выбора цветов. Назначьте короткий эксперимент и время решения: продолжаем выбранную идею или берём более доступный вариант.
Распределите ответственность за рабочие части, объединение, тестирование и сдачу. Создайте черновик описания проекта. Ссылки пока могут отсутствовать, но список полей покажет, что придётся подготовить к финалу. Назначьте человека, который следит за комплектностью материалов.
Часы с третьего по восьмой: собрать первый сквозной путь
Соедините ввод, обработку и результат на минимальном примере. Внешний вид может быть простым. На этом этапе требуется проверить, что части проекта разговаривают друг с другом и выбранный подход вообще осуществим.
Если используете временную заглушку, отметьте её в задачах и описании. Она помогает работать параллельно, но не доказывает готовность интеграции. Укажите, кто заменяет заглушку и что команда делает, если настоящий сервис недоступен.
Попросите второго участника запустить проект по инструкции. Все необходимые файлы должны находиться в общем репозитории, а секретные значения передаваться предусмотренным безопасным способом. Ошибка запуска сейчас стоит меньше, чем та же ошибка за несколько минут до защиты.
Часы с восьмого по двадцатый: закончить обязательные части
Работайте короткими законченными изменениями. После каждого объединения проверяйте главный сценарий. Договоритесь, кто меняет общие файлы и структуру данных, чтобы несколько человек не переделывали одни и те же границы одновременно.
Используйте консультацию ментора для конкретной неопределённости. Подготовьте вопрос, текущий результат и уже проверенные варианты. Обсуждение всей идеи заново может занять больше времени, чем исправление выбранного риска.
В этот промежуток включите отдых по реальному расписанию команды. Нельзя считать все 48 календарных часов рабочими. Перед передачей задачи оставляйте короткую запись: какая версия готова, что не работает и какое действие ожидается следующим. Тогда другой участник сможет продолжить без срочного созвона.
К середине события: проверить объём заново
Покажите прототип от начала до конца. Запускайте реальную сборку, а не отдельные экраны на разных ноутбуках. Составьте список оставшейся обязательной работы и сравните его с доступным временем.
Если основной путь ещё не проходит, остановите добавление функций. Уберите второстепенные фильтры, отдельные страницы и экспериментальные интеграции. Не сокращайте проверки доступа, сохранения данных или правдивость описания. Иногда честный узкий прототип полезнее более широкого проекта с неработающей серединой.
Учебный пример: до конца остаются сутки, а команда строит сервис поиска документов. Поиск работает, но личный кабинет и история запросов не готовы. Если они не обязательны по заданию, разумно оставить поиск, проверку источников и обработку пустого результата. Освободившееся время уйдёт на тестовые вопросы и демонстрацию.
Часы с двадцатого по тридцать шестой: проверить результат
Пройдите обычный сценарий, некорректный ввод и случай без результата. Убедитесь, что пользователь понимает состояние системы. Запишите дефекты с шагами воспроизведения и разделите их по последствиям: блокирует показ, искажает результат или мешает удобству.
Покажите решение человеку вне команды, если правила и доступность аудитории позволяют. Не подсказывайте каждое действие. Наблюдение поможет заметить непонятную кнопку или термин, который разработчики уже перестали видеть. Не называйте такую короткую проверку полноценным подтверждением спроса.
Начните репетировать рассказ на текущей версии. Это выявляет пробелы в логике: вы обещаете одно, а экран показывает другое. Зафиксируйте, что действительно построено за время события, какие компоненты готовые и какие ограничения останутся к сдаче.
Последние двенадцать часов: защитить готовность
Назначьте момент, после которого новые функции больше не принимаются. Его точное время зависит от проекта. Оставьте возможность исправлять блокирующие ошибки, но проверяйте каждое изменение повторным запуском сценария.
Запишите видео, подготовьте презентацию и завершите описание. В рекомендациях Devpost о демороликах отдельно выделено время на запись и загрузку. Для вашего проекта запас определяется размером файлов, скоростью соединения и требованиями организатора.
Сохраните рабочую версию, по которой сделаны материалы. Проверьте внешние ссылки без своего аккаунта, а закрытые ресурсы через согласованный доступ жюри. Назначенный участник отправляет заявку и сохраняет подтверждение. Второй человек проверяет, что отправлены именно финальные материалы.
Если план уже сорвался
Сначала назовите оставшийся результат, который можно честно показать. Затем составьте короткий список препятствий и выберите те, без устранения которых сдача невозможна. Не добавляйте ещё один сервис только потому, что текущая интеграция оказалась сложной.
О техническом сбое на стороне организатора сообщайте через официальный канал с временем и безопасными снимками ошибки. Продление срока может объявить только организатор. Пока такого объявления нет, действуйте по текущему дедлайну и используйте проверку сдачи проекта.
Сверьте свой план с официальными дедлайнами. Откройте выбранное событие в каталоге Stavleak и проверьте время сдачи и защиты.
