Как перестать волноваться и полюбить хакатоны
Зачем студентам ходить на хакатоны? Получить опыт, поработать над реальной задачей, пополнить резюме, получить передозировку кофеина приз и что-то весомое в виде стажировки, например. Но как получить от хакатона максимум? Попробуем разобраться как выбрать хороший хакатон, получить от него то, что хочешь и не потратить время зря.
Примечание. Расскажем как выбрать полезный хакатон на примере нашего трека на 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
Пример слайда команды.
Демонстрацию хорошо дополняют видео — лучше один раз увидеть, как работает решение, чем сто раз услышать.
«Кроме презентации, в которой мы освещали проект в пределах задачи, которую решали, нас было видео работы сайта + плагина в OBS»
Шемякин Алексей. 1 курс магистратуры МГТУ им. Баумана, участник Hack&Change
Вот видео команды.
Как уже писали выше, решение должно работать, хоть с костылями. Иначе жюри не сможет его оценить.
«Были ребята, которые сделали очень крутой дизайн и фронт приложения, но ввиду того, что у них не было бэкенд-разработчиков, дальше макета их идея не ушла и, к сожалению, мы не смогли в полном объеме оценить их решение, так как оно было просто не функционирующим»
Михаил Яндимиров, наставник на Hack&Change, Java техлид на сайте alfabank.ru
Обратная ситуация работает таким же образом. Даже если решение максимально близко к бизнесу с великолепным кодом, но вы будете половину презентации рассказывать про команду, проведенные вами исследования, а вторую половину про код, и под конец вспомните про бизнес, то потеряете время и фокус жюри, а значит шанс победить.
«На хакатоне мы хотели научить ребят правильно расставлять приоритеты и смотреть на себя глазами аудитории. На хакатоне ваша аудитория — жюри.
Достаточно задать вопрос, что они хотят увидеть и услышать от вас, и как максимально быстро до них донести эту информацию. Ведь есть всего 5 минут, чтобы вызвать «вау» вашим решением, а значит надо раскрывать бизнес суть с цифрами по деньгам. Потом показать как вы это сделали, а значит нужна демонстрация рабочей версии.
Дальше станет интересен код. В конце можно рассказать о том, что посчитаете нужным, если останется время. И, кажется, не так страшно, если вы не расскажете про команду, чем не доберетесь до концепции бизнеса и демонстрации прототипа»
Светлана Вагнер, автор задач и судья хакатона
Когда эти правила соблюдаются, защита идёт как по маслу.
«Прекрасно понимая, что соль нашего решения в идее, мы выделили достаточно много времени для разработки презентации. Все последние часы перед моментом сдачи хакатона я ею занималась и передо мной стояла цель лаконично, сжато и, в то же время, ярко, рассказать о нашем решение. Вот всё это я и попробовала воплотить в презентации. Защищал проект наш разработчик и по его словам каверзных вопросов не было, просто жюри уточнили некоторые моменты»
Дёмина Анастасия, Волгоградский государственный университет, участница Hack&Change
Итог
Итак, у хорошего хакатона есть несколько критериев.
Задания не абстрактны, а приближены к реальным.
Есть список технологий, на которых это будет реализовано, плюс есть возможность поработать с реальными API, которые предоставляет компания-организатор.
Есть список рекомендуемых ролей в команде и/или чат, где можно собрать команду.
На хакатоне есть подобранные наставники, обычно это сеньоры и/или лиды по разным направлениям: фронт, бэк, аналитика.
И если хакатон сделан хорошо, то после него останутся приятные чувства.
«В целом появилось ощущение, что можно решать большие задачи в краткие сроки и это будет не кринж. Стал чаще смотреть на хакатоны, планка ЧСВ поднялась до уровня, чтобы не заниматься самобичеванием. Добавил в резюме, но со стажировкой это не особо помогает, по крайней мере на бэкенд. Хотя все равно очевидно, что это большой плюс. Хак енд Чендж, или Как я научился не волноваться и полюбил хакатонить»
Шемякин Алексей, 1 курс магистратуры МГТУ им. Баумана, участник Hack&Change
Но не всегда всё проходит хорошо. Организационные ошибки случаются, и вам, как участникам, всё же, стоит кое что перепроверять.
Заранее узнайте про ограничения — есть ли они и какие. Например, утомите организаторов вопросами про стек технологий, чтобы он не был для вас сюрпризом.
Заложенное количество времени на обратную связь после хакатона может быть оптимистичным, и чем четче будут сформулированы вопросы, тем качественнее будет обратная связь.
Если на хакатоне есть сессии с наставниками, старайтесь, чтобы к моменту встречи у вас были хотя бы идеи. Это поможет вам продвинуться в решении.
«Совет: продумывайте заранее вопросы для наставников. Чем более чётко они будут сформулированы, тем более точный ответ можно будет дать. Следите за временем, чтобы к моменту встречи с наставниками были уже какие-то наработки по проекту (были команды, у которых почти ничего ещё не было сделано к сессии общения с наставниками)»
Александр Ходыкин, наставник на Hack&Change, фронтенд-разработчик
И ещё несколько советов по прохождению.
Подготовьте продукт, который будет закрывать потребности пользователя от начала и до конца. Важно — соберите рабочее решение вашего продукта, пусть даже с костылями и продемонстрируйте его работу.
Определите, по возможности, на какие показатели и/или целевые кейсы будут ориентироваться судьи, и не делать нечто, что просто захотелось.
Участвуйте в хакатонах — ведь их для роста опыта и придумали.
