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

Подготовка

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

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

Хакатон

Само мероприятие проходило два дня, и, в целом, было неплохо организовано. По факту мне не с чем сравнивать, но из того, что я знаю и чего ожидал, могу оценить мероприятие примерно на 6/10.

Тайминг мероприятия был очень хорош, также участников неплохо кормили в столовой ВУЗа, в котором расположилась площадка хакатона.

Сам зал был оформлен приемлемо, каждой команде выделили парты с собственным сетевым фильтром, интернет был слабый, но выдерживал такое количество подключений. Стулья были самые простые, высидеть на таком стуле 36 часов было, мягко говоря, непросто. Из основных минусов - участникам мало того, что не дали никаких напитков (обычно принято раздавать энергетики, но за нелюбовью к таковым я ожидал хотя бы колу), так еще и не разрешали ничего пить и есть в зале, аргументируя какими-то невнятными тезисами про отсутствие оборудования для… для еды и питья в зале, видимо.

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

Задача и ее решение

Предварительно были даны примерные тематики вопросов по каждому направлению, наша команда выбрала направление “образование”. По факту от некоторых тем отказались, а некоторые заменили. В итоге в нашей рубрике осталась только одна тема, в то время как у остальных направлений было по две. Не знаю, хорошо это, или нет, но, по крайней мере, нам не пришлось выбирать. Собственно, сами задачи (проблемы) были сформированы уже на мероприятии, поэтому загоняться заранее особого смысла и не было (хотя некоторые, наверняка, не согласятся). Мы обсудили проблему, побрейнштормили часок и выбрали основные фичи продукта, который будем представлять, и приступили к реализации.

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

Подготовка

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

Окружение

Стоит заранее продумать, где приложение будет исполняться, как коммуницировать с другими частями (клиентские приложения, администраторская панель, внешние сервисы и т.п.). Также, если вы находитесь на территории РФ, стоит учесть, что некоторые сервисы могут иметь переменчивую доступность.

Деплой

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

Заготовка приложения

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

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

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

Проверка инфраструктуры

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

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

Продукт

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

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

Приоритезация задач

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

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

Выбор функционала

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

Организация командной работы

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

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

Моей большой ошибкой было то, что я не стал сразу делать описание API сервера в Swagger, а начал делать это стихийно. В итоге документацию все равно пришлось делать, для чего основой послужил readme файл. В какой-то момент я понял, что информацию о структуре всех данных, передаваемых между сервером и клиентом, не получится просто так рассказать или написать без указания специфики. Начни я сразу со Swagger файла, я бы, во-первых, предоставил бы разработчику клиентской части максимально явную документацию по взаимодействию а API, а во-вторых, я мог бы сгенерировать на основе него описанные типы и обработчики запросов (и перегенерировать их по мере изменения API в одну команду) и тем самым сэкономить себе много времени на рутинную работу.

Помимо этого, полезным оказалось держать включенный сервер и в реальном времени перезапускать его по мере обновления кода. Это позволило клиенту сразу “пристреляться” к интерфейсу и сэкономить время на интеграцию.

Разработка

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

Итерация по приоритетам

Разработку нужно вести в соответствии с выработанными приоритетами функционала - и никак иначе.

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

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

Окружение

Узким местом может оказаться окружение вашего приложения. Например, я отказался от деплоя на Heroku, потому что не успевал правильно настроить Postgres и ее миграции, а также не было возможности легко подключиться к БД извне через графический тул, чтобы редактировать данные в базе наживую. В итоге я развернул базу и приложение на своем ноутбуке и прокинул порт во внешний мир. Для этого я использовал сервис localtunnel, который мне очень понравился тем, что не требует никаких манипуляций, кроме установки самого приложения через npm. Как вариант, можно использовать условно-бесплатный ngroc с более широким функционалом или другой подобный сервис, на ваш вкус.

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

Выбор инструментария

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

Например, я принял ошибочное решение использовать Postgres для хранения данных, которое стоило мне много времени и проблем в дальнейшем. На этом примере могу сказать, что NoSQL база подошла бы намного лучше за счет отсутствия необходимости менять схему (и вообще иметь схему) и простоты хранения любых структур данных. Мощные возможности SQL по поиску и построению выборок мне так и не пригодились, однако я потратил много времени на добавление автоматических миграций в приложение, написание DDL инструкций и прочую настройку.

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

Презентация

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

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

Однако нужно понимать несколько основных вещей.

Презентация - и есть ваш продукт

Выступление перед жюри - и есть результат всей вашей деятельности. Не важно, насколько круто ваше детище, если вы не можете его грамотно показать.

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

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

Покажите все хорошее. Умолчите о плохом - это никому не важно, а если кому и важно - задаст вопрос. Сделайте яркую презентацию со скринами, красивыми картинками и минимумом текста. Серьезно, текст никому не нужен, это же не лекция.

Начинать подготовку презентации нужно рано. Как и заканчивать

Презентация требует много времени. И, в отличие от самого продукта, с ней нельзя облажаться. Вы можете не успеть доделать фичу, но успеете рассказать о том, как она будет работать, в презентации. По большому счету, вы можете покрыть 300% или даже 1000% от вашего текущего функционала в презентации, указав на перспективу - и это нормально. Но если ваша презентация сыра или в ней есть явные косяки - это не прокатит.

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

Готовиться к выступлению нужно заранее. Спонтанно выступить тяжело

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

Не выходите рассказывать всей командой. Я еще не видел ни одного успешного и целостного питча, рассказанного несколькими спикерами по кусочкам. Да и воспринимать нескольких человек сложнее, чем одного, особенно если у вас есть жалкие 5-10 минут. Лучше пускай расскажет человек, у которого это лучше всего получается, а на специфические вопросы сможет ответить уже тот, чью тему это затрагивает.

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

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

Итоги

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