Как выжить на хакатоне

Как человек, принимавший активное участие в чуть менее чем десятке хакатонов, а некоторые даже выигравший☺, в преддверии самого большого хакатона в Украине, я хочу поделиться с будущими участниками некоторыми мыслями и советами.
Заранее предупреждаю — эти мысли мои собственные, и советы отнюдь не претендуют на истину в последней инстанции. Да, эти советы помогли мне — но не гарантированно помогут именно вам; на вкус и на цвет все фломастеры разные, и то, что работает для одного проекта, может не сработать для другого. Тем не менее, надеюсь, что часть “фломастеров” вам пригодится.

Зачем вообще ехать на хакатон?

Во-первых, это фан. Вообще, это волшебное впечатление — увидеть, сколько всего можно сделать за сутки. А уж если хатакон продолжается 48 часов — то можно сделать работающее приложение, выложить в интернет/зарегистрировать в каталогах и даже получить первые продажи☺Когда у вас собирается команда, которая работает на результат и только на него, когда всё получается, несмотря на трудности — это очень-очень круто.

Во-вторых — это возможности. Возможность познакомиться с новыми, интересными людьми, с которыми в будущем вы можете сделать что-то крутое (именно на хакатоне я познакомился с теми, с кем в дальнейшем мы сделали PromoRepublic). Возможность попробовать что-то новое: вы всю жизнь писали код под Windows? приезжайте на хакатон и пробуйте писать под веб на javascript, или наоборот — на C# для очков виртуальной реальности. Провалиться не страшно, страшно не попробовать.

Как подбирать команду?

В хорошей команде должны быть, как минимум:

Владелец идеи. Человек “из бизнеса”, или по крайней мере разбирающийся в области бизнеса, связанной с идеей. Может не иметь понятия, как разрабатывается софт и как сделать нужную железку — главное, что он/она знает, что именно должно получиться в итоге. Скорее всего, маркетинговая часть (объём рынка, целевая аудитория, намётки бизнес-плана) тоже будет на владельце идеи.

PM/TeamLead/etc. Человек, разбирающийся в процессе разработки и проектирования. Знает, как разбить идею на требования, как проанализировать целевую аудиторию и получить набор “персон”, как проверить требования на полноту и непротиворечивость, как разбить их на задачи и разделить по команде (в идеале, конечно, всё это делает сама команда — но в рамках жёсткого временного лимита и несработанной команды нужен человек, берущий на себя ответственность и говорящий “делаем так”). Если умеет программировать и останется время — будет помогать команде.

Дизайнер. Умеет рисовать красивые картинки (бэкграунды для сайта, кнопочки, эффекты для видео/VR, вот это вот всё). Учтите, что у вас будет всего несколько минут на демонстрацию — и даже прекрасную идею во многом будут судить именно по обложке. Production-like демо почти всегда получают более высокую оценку.

UI/UX специалист (может совмещаться с другими ролями, часто — с дизайнером или PM). Проектирует удобные интерфейсы, прокладывает “тропинки” по функциям системы. Практически никогда не бывает на хакатонах — но если удалось отхватить, то это таки удача.

Программист. Лучше два или больше. Какие именно — зависит от специфики проекта (вполне вероятно, что часть “программистов” окажутся например “железячниками”). Ключевые люди для успеха проекта, т.к. именно они в итоге делают то, что другие будут показывать.

Что взять с собой?

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

3G Модем и/или телефон с функцией раздачи мобильного интернета. Если местный интернет вдруг “упадёт”, а вам срочно нужно что-то найти — незаменимая вещь.

Удлинитель. Возможно, розеток хватит на всех — а может и нет. В таком случае удлинитель/тройник не помешает.

Зарядные устройства для всей мобильной электроники. Не забудьте про запасные батарейки/аккумуляторы к мышкам, графическим планшетам и т.п. Хакатоны продолжаются круглосуточно, и ночью всё это может быть просто негде купить.

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

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

Как работать?

Создайте репозиторий проекта. Проще всего воспользоваться сервисами типа Bitbucket или GitHub. И почаще делайте commit и push. Код имеет свойство теряться, уставшие люди дел,ают ошибки — а так у вас будет, по крайней мере, возможность откатиться к прошлой версии.

Заведите таск трекер, чтобы иметь общий список задач для всех членов команды и отслеживать прогресс. Проще всего воспользоваться канбан-доской на Trello, но в принципе и простой google doc со списком задач может сработать.

Чётко определите свой MVP (minimum viable product) и идите к нему, не отвлекаясь на посторонние задачи. Помните: за время хакатона вы успеете в лучшем случае найти подход к решению единственной проблемы; писать швейцарский нож можно будет позже, когда (и если) он понадобится.

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

Осторожнее относитесь к pivot’ам. Конечно, цель гибкой разработки (а никакая другая на хакатонах не работает) — это fail fast, и если вы понимаете, что ваша идея “не летит” — меняйте её как можно быстрее. Но при этом не забывайте валидировать новые идеи — вы должны быть в состоянии закончить проект до конца хакатона, и идея должна хотя бы выглядеть разумно (на одном из хакатонов, например, жюри не поверило в идею, что люди будут приходить в бар выпить пива и выпускать няшных виртуальных питомцев-тамагочи “погулять” в общий телевизор).

Выкиньте всё, без чего можно обойтись. Отвлечение на посторонние задачи дорого вам обойдётся и сильно уменьшит ваши шансы на победу. Если же идея “выстрелит” — у вас будет время дописать на сайте раздел “About”.

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

И — удачи вам, и пусть победит сильнейший!