Как перестать волноваться и полюбить хакатоны

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

e182bdc8d5d1dc7cdf0309202cc7b7e4.jpg

Примечание. Расскажем как выбрать полезный хакатон на примере нашего трека на Hack&Change. Из 4 компаний, представленных на хакатоне, трек выбрали 613 студентов ВШЭ, Баумана, МИРЭА, МИФИ и ИТМО из 1158 участников. Hack & Change — это хакатон для студентов, которые хотят начать карьеру в мобильной и веб-разработке. Мы участвовали там как генеральный партнёр и у нас был свой трек. 

Итак, как выбирать хакатоны? По профиту на выходе.

  • Хорошо, чтобы он матчился с реальной задачей, которую потом где-то внедрят.

  • Хорошо бы, чтобы он позволял реализовать какую-то идею, и прокачать себя в знаниях технологий (на практике) и в командности.

  • Хорошо бы не работать над придумыванием никому не нужного нейроалгоритма, а спроектировать MVP на данных из продакшена, чтобы они были максимально приближены к реальной жизни.

Теперь давайте про эти (и другие) пункты подробнее.

Реальные задачи

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

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

Нет смысла ожидать, что за 1–2 дня получится разработать чудо-сервис. У хакатона должна быть реалистичная цель с «приземлёнными» задачами. Разработать рекомендательный сервис для музыки/фильмов или приложение для сбора донатов — это задача, которая будет к месту в резюме. 

Поэтому на Hack&Change, где мы были генпартнерами трека, выкатили реалистичную задачу.

«Придумайте и разработайте инновационный способ интеграции в контент стриминговой платформы для донатов стримерам. Оно должно содержать базовую аналитику для стримера, быть доступным в РФ и отображать факт доната в контенте с сообщением»

Это, конечно, краткое описание, в полном виде на экране оно выглядело как-то так:  

За скриншот спасибо Шемякину Алексею

За скриншот спасибо Шемякину Алексею

Наши эксперты — Светлана Вагнер и Максим Чернухин — с суммарным опытом в IT в пару десятков лет, заранее провели анализ рынка за студентов. 

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

Максим Чернухин, автор задач и судья хакатона

На генерацию задач ушло несколько недель, в итоге из 57 вариантов выбрали те, что будут эффективны в бизнесе, а участникам помогут не тратить время на идеи.

«Например, один из вариантов задания было создание нового способа оплаты без Applе Pay и без установки приложений на телефон. Но это задание не стали использовать, потому что оно уже решается многими компаниями, а нам хотелось дать участникам возможность приобщиться к разработке чего-то нового. В Альфе мы стараемся идти от проблемы/идеи, и давать возможность команде воплощать свои решения»

Светлана Вагнер, автор задач и судья хакатона

И работа не ушла «в стол». По результатам опроса участников, большинство выбрало трек потому, что у нас было решение, которое соответствует реалиям рынка здесь и сейчас. 

«Для моей команды кейс был актуальным, и нас заинтересовал, так как мы все смотрим стримы, знаем много сервисов для донатов. Поэтому хотелось создать рабочий прототип продукта»

Булавина Юля, участница Hack&Change

Получается, если на хакатоне есть задание/задания с критериями:

  • техническое, с заделом для самостоятельности;

  • матчится с реальной задачей, которую потом где-то внедрят;

  • позволяет реализовать какую-то идею, и прокачать себя в знаниях технологий (на практике) и в командности…

…то, вероятно, хакатон будет полезным.

Работа с реальными API и готовыми решениями

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

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

Иван Кунцевич, наставник на Hack&Change, дизайнер сайта alfabank.ru

Но приступать к решению и сделать проект с нуля не надо. Ведь в больших компания так не работают. 

«Если надо сделать проект, команда интегрирует готовые модули, библиотеки и сервисы, которые реализовали другие команды, в свой проект, чтобы реализовать его быстрее»

Максим Чернухин, автор задач и судья хакатона

Это позволяет переиспользовать решения друг друга и значительно экономить время и силы. Хороший хакатон предполагает использование того же принципа.

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

Для ускорения процесса разработки бэкенда использовали фреймворк Spring. Для фронтенда думали использовать React, но его никто не знал. Поэтому фронтенд простаивал в муках. В конце концов решили сверстать обычные HTML-страницы. Выглядел как сайт начала нулевых, но он работал»

Шемякин Алексей, 1 курс магистратуры МГТУ им. Баумана, участник Hack&Change

Но на фреймворках и библиотеках ничего не заканчивается. 

«Ведь есть готовые решения от самой компании (организатора хакатона): можно подсмотреть способы разработки, описания ошибок, написания и чтения документации, можно получить какие-то технические и бизнес-инсайды в разработке проектов. Например, для Hack&Change мы предоставили API сервиса нетмонет. Его функциональность можно интегрировать в свой проект и не писать с нуля»

Максим Чернухин, автор задач и судья хакатона

Команда

Опытные разработчики чаще приходят слаженными командами. А студент первого курса, который пришел на свой первый хакатон, может просто не догадаться, что ему для задания нужен один участник, который будет работать над фронтом, а другой — над API. Поэтому на странице хорошего хакатона есть подсказки. Например, такая. 

Или такая.

Задания выкладываются заранее и именно под них и собираются команды. И, обычно, идеальная команда покрывает бэк, UI и фронт: один участник работает над фронтом, другой — над API и т.д. 

«У нас было 3 человека. По ролям это бэкенд, фронтенд, аналитик. Узкие задачи распределяли, отталкиваясь от ролей, а задачи общего плана решались совместно»

Шемякин Алексей, 1 курс магистратуры МГТУ им. Баумана, команда Скрепыши на Hack&Change

«Нас было трое. Егор отвечал за бэкенд, я отвечала за дизайн и фронтенд, а Андрей за бизнес аналитику и презентацию»

 Булавина Юля, участница Hack&Change

Важно собрать такую команду которая полностью может проработать ваш продукт, включая бэк, фронт, UI и бизнес, а потом это всё протестировать и поставить в прод. Такая классическая продуктовая команда «в миниатюре». 

«Нас было 3, прям минималка. Моя банда была больше по техсфере, а я по аналитике, так как специализировалась именно в этом, поэтому меня и позвали — не хватало человека, который бы потянул аналитику и презентацию результатов. Вышел какой-то успешный шарм, никто никого не отвлекает и занимается своими задачами. Меня лично заинтересовали задачи по бизнес-аналитике, так как хотела проверить свои способности в нестандартных ситуациях»

Смирнова Мария, 1 курс магистратуры НИУ ВШЭ, участник команды Скрепыши на Hack&Change

Если команда будет неполной, когда не хватает какой-то роли, то от этого пострадает качество: фронтенд красивый, а интеграций нет, или наоборот — интеграции были, но UI неудобный.

«Это классические случаи, когда фронт пилит бэк и наоборот, или когда никто в команде ранее не работал с определенными фреймворками»

Иван Кунцевич, наставник на Hack&Change, дизайнер сайта alfabank.ru

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

«Как начинающий UX/UI дизайнер я тогда впервые столкнулась с разработкой веб-сервиса. Было очень интересно работать над онбордингом и согласовывать свои решения с командой. До этого у меня по сайтам был только опыт курсов <...> Я занялась дизайном, стараясь при помощи него как можно более выпукло проявить концепцию, сделав предлагаемые нами решения удобными и практичными для пользователя. Разработчик при этом параллельно воплощал всё это в жизнь на, цитирую, «стандартном стеке для React».

Дёмина Анастасия, участница Hack&Change, выпускница Волгоградского государственного университета

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

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

Также обстоят дела и у 90% команд. Они состоят из фронтов и бэкендеров, а на аналитику (как продуктовую, так и системную) и дизайн оставляют лишь одного человека. А как тогда детально проработать MVP, придумать план и способы его продажи? Отсюда и следует необходимость правильно подобрать команду, чтобы проработать весь продукт и впечатлить судей и менторов!

Представьте, что вы, как наставник, помогаете ребятам на хакатоне, обсуждаете вместе идеи, направляете их, предлагаете варианты доработок той или иной части проекта. И на очереди крутейшая команда, знакомимся с ними, начинаем общаться по проекту, и, как оказывается, — они все бэкендеры. Интересуемся: «Вы планируете в таком составе участвовать?», на что получаем облегчающий ответ — «Нет, у нас ещё аналитик не подключилась в Зум». Пришлось пояснять, что всё же такого распределения недостаточно для успеха на хакатоне»

Никита Дукин, наставник на Hack&Change, фронтенд-разработчик в проекте Альфа Зарплата

А если команды нет, то на хороших хакатонах обычно есть возможность её собрать, например, в специальном чате.

«Поскольку пришла на хакатон изначально одна, команду удалось найти в чате в последний момент»

Дёмина Анастасия, участница Hack&Change, выпускница Волгоградского государственного университета

Наставники

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

«По моим вопросам наставники прям помогали, помогли сократить время на ненужный анализ»

Смирнова Мария, 1 курс магистратуры НИУ ВШЭ, участница команды Скрепыши на Hack&Change

«Наставники помогали. Особенно выручила консультация по технологиями фронта на первом чек-пойнте»

Кузнецов Денис, 4 курс бакалавриата НИТУ МИСиС, участник Hack&Change

Мы подбирали наставников долго и упорно. Искали людей по нескольким критериям: у них должно быть желание менторства, желание поделиться знаниями, умение делиться, и, главное, наличие того, чем делиться. Это важно, потому что это те люди, с которыми у команд будет ассоциироваться Альфа-Банк. Поэтому отбор был достаточно жесткий — примерно из 50 человек выбрали около десятка.

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

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

Иван Кунцевич, наставник на Hack&Change, дизайнер сайта alfabank.ru

«У меня с начала работы в Альфе были просто прекрасные наставники, которые были всегда рядом и были всегда готовы помочь. Поэтому удачный опыт с менторами передал мне желание помогать и другим ребятам, например на хакатоне или в Альфа Кампусе»

Никита Дукин, наставник на Hack&Change, фронтенд-разработчик в проекте Альфа Зарплата

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

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

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

Михаил Яндимиров, наставник, Java техлид на сайте alfabank.ru

«Процесс взаимодействия был построен так, что в личке у меня не было вообще ни одного сообщения от студентов. Тем не менее, вопросов всё же было много, как от команд, так и от менторов к командам. В основном, вопросы от студентов были связаны с ревью их системы и взаимодействия. Кто-то рисовал схемы взаимодействия между сервисами, кто-то показывал всё на дизайн-макетах. Всё это отлично подходит, ведь в таком случае наставники могут подсказать, что стоит учесть дополнительно, например, поменять протокол взаимодействия для упрощения задачи и снятия излишней нагрузки или обратить внимание на обработку состояний загрузки»

Никита Дукин, наставник на Hack&Change, фронтенд-разработчик в проекте Альфа Зарплата

Но даже если по каким-то причинам команда пропустила все чек-пойнты, наставники уделят время, когда всё уже закончено.

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

Дёмина Анастасия, Волгоградский государственный университет, участница Hack&Change

Демонстрация

Хорошая презентация — половина победы. 

От чего она зависит? От того, насколько близко решение к бизнесу и насколько просто сможете показать это решение.

«Мы предоставили рабочий прототип с личным кабинетом для стримера, мобильный интерфейс для донатов и виджет для OBS. Архитектуры, как таковой не было, фронт писала на React, бэкенд на Django. Так же использовали WebSocket. 

Решение подготовили в формате презентации и видеодемонстрации. Попросили нашего друга стримера вставить наш виджет и запустить стрим, после чего сняли на видео, как мы сканируем QR-код и проводим платёж. В завершение показали личный кабинет стримера»

Булавина Юля, участник одной из команд на Hack&Change

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

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

Смирнова Мария, 1 курс магистратуры НИУ ВШЭ, команда Скрепыши на Hack&Change

Пример слайда команды.

68973e7937058dcd3a5c97c81559d82c.png

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

«Кроме презентации, в которой мы освещали проект в пределах задачи, которую решали, нас было видео работы сайта + плагина в OBS»

Шемякин Алексей. 1 курс магистратуры МГТУ им. Баумана, участник Hack&Change

Вот видео команды.

Как уже писали выше, решение должно работать, хоть с костылями. Иначе жюри не сможет его оценить.

«Были ребята, которые сделали очень крутой дизайн и фронт приложения, но ввиду того, что у них не было бэкенд-разработчиков, дальше макета их идея не ушла и, к сожалению, мы не смогли в полном объеме оценить их решение, так как оно было просто не функционирующим»

Михаил Яндимиров, наставник на Hack&Change, Java техлид на сайте alfabank.ru

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

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

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

Дальше станет интересен код. В конце можно рассказать о том, что посчитаете нужным, если останется время. И, кажется, не так страшно, если вы не расскажете про команду, чем не доберетесь до концепции бизнеса и демонстрации прототипа»

Светлана Вагнер, автор задач и судья хакатона

Когда эти правила соблюдаются, защита идёт как по маслу.

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

Дёмина Анастасия, Волгоградский государственный университет, участница Hack&Change

Итог

Итак, у хорошего хакатона есть несколько критериев.

  • Задания не абстрактны, а приближены к реальным. 

  • Есть список технологий, на которых это будет реализовано, плюс есть возможность поработать с реальными API, которые предоставляет компания-организатор.

  • Есть список рекомендуемых ролей в команде и/или чат, где можно собрать команду.

  • На хакатоне есть подобранные наставники, обычно это сеньоры и/или лиды по разным направлениям: фронт, бэк, аналитика.

И если хакатон сделан хорошо, то после него останутся приятные чувства.

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

Шемякин Алексей, 1 курс магистратуры МГТУ им. Баумана, участник Hack&Change

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

  • Заранее узнайте про ограничения — есть ли они и какие. Например, утомите организаторов вопросами про стек технологий, чтобы он не был для вас сюрпризом.

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

  • Если на хакатоне есть сессии с наставниками, старайтесь, чтобы к моменту встречи у вас были хотя бы идеи. Это поможет вам продвинуться в решении.

«Совет: продумывайте заранее вопросы для наставников. Чем более чётко они будут сформулированы, тем более точный ответ можно будет дать. Следите за временем, чтобы к моменту встречи с наставниками были уже какие-то наработки по проекту (были команды, у которых почти ничего ещё не было сделано к сессии общения с наставниками)»

Александр Ходыкин, наставник на Hack&Change, фронтенд-разработчик

И ещё несколько советов по прохождению. 

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

  • Определите, по возможности, на какие показатели и/или целевые кейсы будут ориентироваться судьи, и не делать нечто, что просто захотелось.

Участвуйте в хакатонах — ведь их для роста опыта и придумали.

© Habrahabr.ru