Делимся лайфхаками от нашей команды U4 («Урбанистическая четверка»). В прошлом году мы победили в Urban Tech Challenge. Возможно, наши советы пригодятся участникам программы Urban.Tech Moscow от Агентства инноваций Москвы, которая проходит прямо сейчас.
Собрать команду
Наша команда появилась благодаря Telegram – незадолго до хакатона мы познакомились в чате для участников. Именно там frontend-разработчик встретил backend-разработчика и дизайнера, а потом к нам присоединилась бизнес-аналитик.
Тематические сообщества – это лучший способ найти единомышленников с разным набором скиллов. Посмотрите группы в Facebook, чаты в Telegram и паблики во “ВКонтакте”. Там не только ищут членов команды, но еще делятся лайфхаками и рассказывают о подводных камнях, с которыми могут столкнуться участники.
Обратитесь к коллегам, загляните в профессиональные сообщества, поищите специалистов на форумах – да, они до сих пор живы.
Минимальный набор: frontend- и backend-разработчики, дизайнер, бизнес-аналитик / маркетолог / продакт-менеджер. Важно не быть как мы и убедится, что во время хакатона железно никто не уезжает в командировку или в отпуск. Нас изначально было четверо – отсюда и название “Урбанистическая четверка”. Но в итоге в команде осталось только трое участников: в последний момент дизайнер сообщил, что не сможет присутствовать лично, а это было совсем не удобно. Пришлось выступать втроем.
Быть готовым ко всему
Изучите испытания с прошлых хакатонов и посмотрите, какие задачи решают на аналогичных соревнованиях – в России и в мире. Например, если вы работаете с технологиями умного города, поищите задания с европейских, американских и азиатских хакатонов из той же категории – заодно подсмотрите интересные решения и получите конкурентное преимущество.
Многие участники Urban.TechChallenge, в том числе и мы, пришли на хакатон уже подготовленные. Мы сразу приступили к целенаправленной работе и не тратили кучу времени на то, чтобы разобраться, с чего начать.
Перед нами стояла задача создать интеллектуальную систему поиска, сбора и классификации данных о московских предпринимателях и инноваторах, их продукции и услугах. Собирать данные мы решили с помощью парсинга сайтов краулерами [поисковыми роботами].
Мой совет – заранее выберите и протестируйте инструменты, которые хотите использовать. Иначе есть риск наткнуться на баги во время конкурса и зря потерять время. И еще один момент: никогда не берите на хакатон технологию, с которой вы плохо знакомы – возможны неприятные сюрпризы.
Жизнеспособность проекта лучше оценивать до начала хакатона – во время будет уже поздно. Так что проведите суровый reality check как можно раньше. И сконцентрируйтесь только на одной концепции, которую проработали заранее.
Посчитайте, сколько времени у вас уйдет на создание прототипа, и обязательно заложите время на форс-мажорные ситуации – поверьте, они точно возникнут.
Поймать волну
Узнайте заранее, какая компания или ведомство организует хакатон. Например, организаторы выступают за сокращение потребления и поддерживают активистку Грету Тунберг. А значит, им понравится акцент на экологической повестке, переработке и устойчивом развитии.
В жюри есть крупный банк, который экспериментирует с чат-ботами и биометрией? Добавьте похожий функционал в свой продукт – компания это оценит.
На хакатоне мы решили сконцентрироваться на одной задаче – разработке каталога инновационных предприятий от Департамента предпринимательства и инновационного развития города Москвы. Мы хорошо прочувствовали их цели и видение – как мне кажется, именно этим был обусловлен наш успех.
Учиться импровизировать
Даже если вам кажется, что вы учли все детали проекта, что-нибудь обязательно пойдет не так.
У нас на хакатоне сперва все шло гладко и по плану, но без осечек все-таки не обошлось. В начале мы использовали сервер neo4j, хотя frontend-разработчик никогда раньше с ним не работал. Мы провозились с этим вопросом, но вовремя остановились и перешли на MongoDB. На возню с neo4j мы потратили 5 часов, а на переход ушло всего 30 минут. Отсюда совет – не упорствуйте, fail fast. Иногда лучше быстро поменять стратегию, чем придерживаться неудачного плана.
На этом проблемы не закончились. За сутки до финального питча у нас уже было рабочее приложение, и весь оставшийся день мы планировали накручивать на него дополнительные фичи.
Но на стороне бэкенда возникла проблема с баном краулеров в поисковиках и со спамом агрегаторов юрлиц, который оказывался на первых местах поисковой выдачи при парсинге по каждой отдельной компании.
От успешного прохождения этого шага зависело решение остальных задач. Так что пришлось импровизировать. Краулеры работали вечером в последние часы, а параллельно версталась та часть фронта, для которой еще не было бэкенда. База данных при этом росла, а краулеры продолжали работу.
Это нам, кстати, помогло. В день питчей оказалось, что многие так и не смогли обойти баны краулеров в поисковиках и ни у кого, кроме нас, не было рабочего прототипа.
В итоге мы победили в треке. Но прежде мы долго общались с жюри, они тщательно проверяли код. Судя по отзывам, так происходило не во всех треках. Поэтому будьте готовы к дополнительным вопросам и проверкам, даже если вы успешно справились с задачей.
Вообще, по моему опыту, команду может спасти навык работы в условиях полной неопределенности. В стартаперской среде одно время часто использовали аббревиатуру VUCA: volatility (нестабильность), uncertainty (неопределенность), complexity (сложность) и ambiguity (неоднозначность). Это как раз применимо к хакатонам.