21 татуировка хакера или как побеждать на хакатонах!

За последние годы я принял участие в более десятка различных хакатонов, за это время я выработал несколько принципов, которые помогут Вам побеждать в хакатонах. Каждый принцип — как татуировка, впечатанная в кожу и проверенная временем.

1. Правильный выбор хакатона.
Выбирайте хакатоны с большим призовым фондом.
Больше фонд хакатона — больше приз — приятнее победа.

Выбирайте хакатон в котором есть несколько треков и есть несколько призовых мест в каждом треке — так вероятность победы увеличивается в разы. Даже занять 3-е призовое место уже круто!
Например, хакатон Цифровой прорыв, с призовым фондом 55 млн. ₽.

2. Правильный выбор задачи.

- Ваша команда должна владеть технологическим стеком необходимым в треке, тут либо команда подбирается под задачу, либо задача подбирается под команду.

- Вашей команде должна нравится эта задача, для того чтобы мотивации хватило на 2-3 дня разработки.

Но бывают и фэйлы, например в хакатоне Moscow City Hack мы заранее выбрали задачу «Планирование досуговых мероприятий Моя Москва» и запланировали с командой сделать сайт. И только на церемонии открытия до нас дошло, что речь идёт о мобильном приложении «Моя Москва».

В результате мы решили продолжить участие и сделать мобильную версию сайта Афиша мероприятий. В упорной борьбе мы заняли 2-е место, так как сделали немного не тот продукт, кстати я даже написал об этом статью

3. Идея и стратегия.
Основная идея продукта должна быть продумана заранее.
Будет круто, если вы заранее распределите основные задачи крупными мазками внутри команды, а также приоритеты. Конечно, после первого чекпоинта Ваши планы могут поменяться, но в этом и прелесть итерационного подхода — как можно быстрее набить как можно больше шишек, чтобы встать на правильный путь, пока остальные команды раскачиваются.

4. Инструменты разработки.
Бывало, я до 2-х часов ночи разворачивал среду разработки во время хакатона. Или качал нужное ПО а площадке хакатона с медленным интернетом. Лучше это сделать заранее, и договорится командой об инструментах разработки и контроля версий.

5. В команде не должно быть лишних людей.
На мой взгляд оптимальный размер команды 3-5 человек. Конечно чем в команде больше рук — тем больше можно успеть реализовать, и на одном из хаков в моей команде было 8 человек, и мы заняли 1-е место.

Но скорее это исключение, так как эффективный костяк всё-равно состоял из 4-х человек.

6. Команда должна быть сыгранной.

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

Также и здесь, даже если вы не выиграли командой в первый раз, но вы чувствуете что у участников есть потенциал, поучаствуйте той же командой в другом хакатоне, вы увидите как вырастет продуктивность команды.
Например в хакатоне audithon.ru, мы заняли 1-е место командой из 2-х человек, с моим другом Алексеем, с которым дружим уже лет 10.

7. Приз в команде всегда делится поровну.

В моей практике был случай, когда после победы на хакатоне, в команде из 3-х человек мы поделили приз не поровну.
Один из участников принес меньше профита команде, и я решил поделить приз в долях 40%-40%-20%. В результате мы поссорились и я потерял друга, это того не стоило. Лучше всегда делить приз поровну, и грамотней подбирать участников в команду.

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

8. В команде должен быть лидер.

Лидер должен следить за дедлайнами, чекпоинтами, приоритетами, общаться с организаторами и экспертами и управлять командой.

Важно чтобы лидер слушал участников команды, так как лидер эгоист может потопить команду.

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

9. Споры в команде.

Иногда в команде случаются споры по поводу архитектуры проекта или приоритетов. Если в команде 3 человека — спор быстро решается голосованием. Если мы спорим вдвоём с Алексеем, то стараемся выслушать друг друга — осознать и принять решение, иногда я говорю — Леха, доверься моему опыту — давай сделаем так и мы победим.

10. Чекпоинты

Ходите на все чекпоинты и выжимайте максимум обратной связи от экспертов. Задавайте открытые вопросы, записывайте их ответы.

По сути это Customer Development — так как именно эксперты обычно являются заказчиками задачи и жюри.

11. Нетворкинг

Однажды ключевой эксперт на хакатоне, так вступился за нашу команду, что жюри взяли дополнительный день для определения победителя.На следующий день нам объявили что мы заняли 1-е место, а меня пригласили на хорошую вакансию.

12. Работайте спринтами.
Например можно сделать канбан-доску в trello.

Сперва накидываем все идеи в бэклог, затем проставляем приоритеты, и выбираем ответственных с учетом компетенций и интереса.

Это удобно, особенно в больших командах.

Я бы посоветовал длину спринта от 5 часов до 1 дня.

13. Взаимодействуйте в команде.

Часто происходят случаи, когда отдельно пилят фронтенд и бекенд, а потом не успевают подружить их, или не могут так как не договорились об архитектуре.

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

14. MVP-минимальный жизнеспособный продукт

Сделайте MVP продукта в первые 2/3 времени, а затем улучшайте продукт новыми фитчами. На многих хакатонах я видел как команды сливались из-за того что взяли сразу слишком большой объем. В итоге поняли что не успевают, опустили руки и слились с хакатона.

Если бы сперва сделали MVP — то мотивации доделывать было бы больше, и сразу бы решились технические вопросы интеграции/архитектуры.

15. Цельный продукт
Например, на нескольких хакатонах мы делали сайт, подбирали хороший домен, подключали https и упаковывали дизайн. Готовый продукт всегда выигрывает по сравнению с демо-версией на локальном компьютере.

16. Красивый дизайн

У любого продукта должен быть крутой дизайн. Даже самое крутое решение, будет смотреться хуже по сравнению с упакованными решениями.
Люди не видят код — а видят главный экран сайта или приложения. Если нет дизайнера используйте: bootstrap, шаблоны, tilda, figma, красивые прототипы с github.

17. Демо-видео

Выложите видео демо продукта на youtube и отправьте ссылку экспертам. Эксперты могут не заметить важной фитчи, а на видео вы можете сами правильно расставить акценты.

18. Кейсы и истории на презентации.

Стройте свою презентацию или демо как проблема — решение конкретного кейса. Реалистичные истории применения всегда лучше абстрактного описания функционала.

19. Меньше слайдов — больше продукта.

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

20. Рассказать презентацию команде.

Презентацию заранее нужно прогнать несколько раз и показать команде. Команда всегда подскажет как улучшить, и подправит продукт под нужный сценарий. На одном из online-хакатонов команда записала выступление на видео, но при показе в zoom микрофон компьютера глушил звук динамика и экспертам ничего не было слышно. Такие технические моменты можно заранее учесть при показе презентации команде.

21. Ответы на вопросы на презентации.

Большинство вопросов экспертов можно предугадать и подготовить слайды/материалы. Так вы будете чувствовать себя уверенней на презентации, и грамотно ответите на каверзные вопрос.