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