Что делать с проектом после хакатона: план продолжения
Как решить судьбу проекта после финала: сохранить материалы, договориться о вкладе, проверить спрос и назначить следующий результат.
·4 мин чтения
После хакатона проекту нужно отдельное решение о продолжении. Обсудите, кому ещё интересна задача, сколько времени доступно команде и какой следующий результат стоит проверить. Победа, приз или хорошая реакция зала сами по себе не определяют дальнейший план.
Допустимы разные исходы: небольшой пилот, учебная доработка, открытая публикация материалов или завершение работы. Выберите тот, который соответствует намерениям участников. Не записывайте человека в будущую команду только потому, что он участвовал в двухдневном событии.
Сначала сохраните состояние проекта
Соберите ссылку на репозиторий, сдаваемую версию, видео, презентацию и обратную связь. Запишите, какие функции работали на финале и какие зависимости могут исчезнуть. Выданные кредиты, временные аккаунты и доступ к данным часто требуют отдельного продления.
Зафиксируйте инструкцию запуска, пока детали ещё помнят несколько человек. Если сервис работал только с настройками на одном ноутбуке, перенесите допустимые настройки в описание окружения. Секреты храните отдельно и не добавляйте в общую публичную папку.
Определите владельцев репозитория, домена и облачных ресурсов. Доступ к исходникам должен сохраняться у тех, кто договорился продолжать работу. Если проект закрывается, завершите платные ресурсы и временные доступы по установленному порядку, сохранив нужные материалы.
Проведите разговор о намерениях
Спросите каждого участника, что он готов делать после возвращения к обычной работе или учёбе. Удобнее обсуждать конкретное обязательство на ближайший период, чем обещание «развивать стартап». Например, подготовить интервью, исправить запуск или разобрать данные.
Разделите интерес к идее и доступное время. Человек может поддерживать проект, но не иметь возможности регулярно писать код. Договоритесь, считается ли он активным участником, консультантом или автором уже выполненной части.
Обсудите авторство, использование названия и внешних материалов до публичных обещаний. Если предполагаются коммерческие договорённости или передача прав, их условия нужно оформить отдельно с подходящими специалистами. Хакатонная переписка не должна становиться единственной записью важных решений.
Разберите обратную связь без голосования по впечатлениям
Соберите замечания жюри, вопросы пользователей и собственные наблюдения в один список. Отделите непонимание презентации от проблем продукта. Если зритель не заметил готовую функцию, может потребоваться новый показ; если пользователь не может выполнить задачу, нужен разбор самого сценария.
Для каждого замечания запишите, на чём оно основано. Совет одного эксперта может быть полезной гипотезой, но не доказывает спрос. Похвала внешнему виду тоже не подтверждает, что человек станет пользоваться сервисом.
Выберите вопрос с наибольшей неопределённостью. Для приложения распределения обращений это может быть готовность координатора доверить системе предварительную сортировку. Тогда следующий шаг связан с реальным рабочим процессом, а не с добавлением ещё одной темы оформления.
Назначьте небольшой проверяемый результат
Полезный следующий этап имеет владельца, срок и условие решения. Например: показать прототип нескольким подходящим координаторам, записать места ручного исправления и после этого решить, стоит ли делать ограниченный пилот. Число бесед выберите по доступу и задаче, не выдавая его за статистическое исследование.
Сформулируйте заранее, что заставит изменить план. Если потенциальные пользователи не имеют доступа к нужным данным, улучшение алгоритма не решит проблему внедрения. Если существующий процесс устраивает их полностью, нужно пересмотреть ценность предложения.
Не называйте учебный прототип готовым продуктом. Для пилота могут понадобиться обработка ошибок, управление доступом, наблюдение за работой сервиса и отдельное согласование данных. Список зависит от проекта; выпишите его до обещания даты запуска.
Следующий эксперимент можно описать в шаблоне ТЗ для партнёра Stavleak: укажите владельца задачи, ожидаемый результат и способ проверки.
Уменьшите технический долг по риску
После короткого события легко захотеть переписать всё. Сначала определите, какие части мешают следующей проверке. Неработающий запуск, потеря данных и неясные права доступа имеют прямое влияние на пилот. Неидеальная структура небольшого модуля может подождать.
Сохраните рабочий сценарий и исправляйте по одному риску. Для изменений, которые могут нарушить поведение, подготовьте воспроизводимую проверку. Не проводите большой рефакторинг одновременно с переездом инфраструктуры и заменой модели, если команда не сможет понять источник новой ошибки.
Уберите секреты и временные обходы перед внешним доступом. Проверьте условия библиотек, данных и сервисов, которые использовали во время конкурса. Разрешение для демонстрации не следует автоматически переносить на дальнейший коммерческий запуск.
Что исследования говорят о продолжении
В работе Nolte, Chounta и Herbsleb What Happens to All These Hackathon Projects? краткосрочная активность после события и длительное развитие рассматриваются как разные явления. Авторы исследуют связи между характеристиками проектов и техническим продолжением, а не дают гарантию успеха конкретной команды.
Для практического решения это повод отдельно обсудить мотивацию, доступные навыки и дальнейшую работу. Количество коммитов в первую неделю ещё не отвечает на вопрос, нужен ли проект пользователям и может ли команда поддерживать его несколько месяцев.
Если вы решили остановиться
Оформите итоговую страницу: какую задачу исследовали, что собрали, что проверили и почему не продолжаете. Сохраните вклад каждого участника и разрешённые материалы. Такой результат можно использовать в портфолио, если честно указать состояние проекта.
Сообщите о решении тем, кто ожидал следующий шаг. Не оставляйте тестовых пользователей с неработающей ссылкой без объяснения. При необходимости закройте сбор данных и удалите то, что больше не требуется, в соответствии с согласованными условиями.
Завершённый эксперимент остаётся полезным, если по нему можно понять, что вы узнали. Для команды это понятная точка остановки, после которой участники свободно выбирают следующую задачу.
