Постмортем: Как мы слили крупнейший хакатон в РФ и чему у нас можно научиться

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

Я со своей командой участвовал в хакатоне ЛЦТ-2022. Думали будет просто — мы были опытны, слаженны, побеждали ранее. Но в итоге, как это часто бывает, что-то пошло не так. Заняли мы, само собой, самое обидное место из существующих: 4-е из 97

Мы решили провести анализ ошибок, результатом которого и стала данная статья.

Как слили? Почему? Зачем? Давайте разбираться.

Заходят как-то бард, маг и воин в бар…

Давайте знакомиться с главными героями нашего боевого отряда. По регламенту, участвовать в одной команде может от 2 до 5 человек. Изначально нас было 4-ро, роли у нас были следующие:

• Backend разработчик

• Аналитик/PM

• Fullstack разработчик

• Frontend разработчик (Я)

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

Невероятно забавно, но уже на данном этапе у нас появились первые проблемы.

1. Оценивайте популярность трека и предсказывайте выборы других людей

Треков было 10, каждый со своими странностями. Треки были следующими:

Увидели темы? Вам они тоже показались какими-то странными?

Ну и мы сидим и думаем — а что брать то? Выбор пал на 2, 6 и 9. В итоге взяли 6-ю тему «Сервис для расчёта рыночной стоимости жилой недвижимости города Москвы» как самую понятную. Как оказалось — это было не самое умное решение — мы выбрали самый конкурентный трек хакатона. Зашибись.

На 6 треке было наибольшее кол-во команд — 97, Карл! Для понимания, на одном из других треков (не помню точно на каком) было ~14 команд.

Как споткнулись:

1. Выбрали самый популярный и сложный трек

Какие выводы сделали:

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

• Если мы спроецируем эту ошибку на коммерческие проекты и стартапы, она будет звучать как “делайте анализ рынка заранее, прежде чем начинать разрабатывать продукт”.

2. Берите в команду уже проверенных бойцов

Наш состав команды почти не менялся между хакатонами — единственное что приходилось делать всегда, это искать UI/UX дизайнера — каждый мы это делали с нуля.

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

Как споткнулись:

1. Не имели проверенного дизайнера в команде.

2. Начали искать дизайнера слишком поздно.

3. Потратили слишком много времени, прежде чем понять что нам не подходит человек.

Какие выводы сделали:

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

3. Используйте все доступное время

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

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

Как споткнулись:

1. Выбросили в никуда 50% времени

2. Могли начать писать код спустя 2-3 дня, а не спустя неделю

Какие выводы сделали:

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

• По максимуму используй все возможности которые у тебя есть.

4. Набирайте команду по скиллам

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

Какой стек был у нас: бэкенд — python + FastAPI, база — PostgreSQL, фронтенд — React (с связкой с Next).

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

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

Как споткнулись:

1. У нас не было достаточных компетенций во фронтенде.

2. Очень долго настраивали и пытались первично соединить бек с фронтом

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

Какие выводы сделали:

• Много кто из нас значительно прокачался в React. Что-то не знать и пытаться внедрить новое на хакатоне может быть очень полезным опытом. Но если цель именно победа и получение приза — команда должна иметь всю необходимую квалификацию для этого изначально.

5. DDD в каждый стартап

Осталось 40 часов до дедлайна. Так как код писался очень быстро, то и его качество оставляло желать лучшего. Одна из причин его плохого качества — не следование принципу единого языка (Ubiquitous language). Так как мы работали параллельно и нечасто координировали свою работу, у нас было по 2-3 разных названия для одной и той же Entity в разных частях проекта. Помимо этого, все знание по проекту было сосредоточено у аналитика. Никто не понимал user flow кроме него — нам было лень в этом разбираться, и мы поплатились за это абсолютным непониманием того что происходит и что нам делать.

Не сказать что я эксперт в DDD, но книжку Эванса (синюю) и Вернона (красную) по Domain Driven Design я прочёл. И почему-то, у меня всегда было стойкое ощущение о том, что DDD — это дорого, сложно, занимает много времени и не всегда полезно (наверное потому что сам Вернон приводил матрицу DDD в которой описывал его применимость в проекте).

А на самом деле, если декомпозировать DDD на самые полезные его части — то их следует использовать абсолютно всегда. Теперь я убежден, что как минимум ubiquitous language нужно внедрять в любой проект, а каждый разработчик должен уделить время на понимание предметной области, и того что он вообще разрабатывает, особенно на начальных стадиях производства продукта.

Как споткнулись:

1. Зависели от нашего аналитика. Bus factor был настолько большим, что если бы наш аналитик вдруг внезапно заболел — мы бы не смогли сделать абсолютно ничего с этим.

2. Не вникали в предметную область на наших созвонах и QA сессиях, относились к этому халатно

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

Какие выводы сделали:

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

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

6. Делай MVP. Делай MVP. Делай MVP.

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

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

Как споткнулись:

1. Не разрабатывали проект итеративно

2. Делали красиво, но не жизнеспособно

3. Не использовали принципы продуктовой разработки

Какие выводы сделали:

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

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

7. Не унывайте

Вечер последнего дня, 5-6 часов до деделайна. Мы объективно не успеваем.

Большинство из нас в какой-то невероятной печали. Мы очень сильно устали, в последние 2 дня страдали от депривации сна и работы по 15 часов. Код лапша, жизнь отстой, всё достало, тлен. Тут всё очевидно — нам не сильно это помогало, напротив, только мешало.

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

Как споткнулись:

1. Были в унынии, и думали вообще уйти с проекта

Какие выводы сделали:

• Если уж начал что-то делать, делай это до конца. Возможно от уныния в таких ситуациях не избавиться, но как минимум доделать дело — это твоё обязательство.

• Уныние не всегда оправдано. В нашем случае все еще абсурднее — мы объективно сделали неплохое решение для финала, но при этом мы так не считали

8. Хороший Тимлид/PM реально решает

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

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

Какие выводы сделали:

• Кто бы что не говорил, но хороший Тимлид/PM реально решает и приносит колоссальную пользу в продуктовой разработке. Аналитику проведет, задачи декомпозирует, скоординирует разные части команды, vision всем свой даст, спасёт от уныния. Мы часто раздражаемся от «эффективных менеджеров», но по-настоящему эффективные менеджеры реально существуют. Таких людей немного, но они есть, и порой они могут быть причиной успеха или неудачи всего проекта.

Финал

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

Отдам должное организации мероприятия — она была на высоте. Здание было крутое, нас кормили завтраком, обедом и ужином, а вечером даже разливали шампанское и вино!

Раздавали бесплатные протеиновые батончики, можно было поиграть в PS4 или отдохнуть в массажных креслах. А, ну и мерч само собой за то что мы попали в финал выдали.

Настало время защиты решений. Мы сидели, и скрупулёзно смотрели за нашими соперниками. Конкурентны объективно имели крутые, проработанные решения, и это было офигенно.

После защиты, как нам показалось, что топ-3 точно наш. Но, как оказалось, это не так.

9. Надежность, Доступность и UX — важные штуки

Думали SLA — не для MVP? Думали высокая доступность и надежность — прерогатива highload приложений с кучей пользователей? А вот нифига.

Надежность — основная причина по которой мы проиграли. И заняли, внимание 4-место. Не дотянули совсем чуть-чуть до призового (обидно конечно).

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

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

Как споткнулись:

1. Не придали значение надежности — думали что для MVP это не важно.

2. Не имели адекватной обработки ошибок на клиентской части — это могло спасти нас хотя бы частично.

Какие выводы сделали:

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

• Уделяйте достаточное время обработке ошибок с учетом UX.

Резюмируюя

Давайте подведём итоги, и выделим самые полезные инсайты из нашего опыта:

1. В хакатонах не всегда стоит брать самый понятный на первый взгляд трек.

2. Правильно набирайте команду — берите людей, которым доверяете, с которыми работали ранее, и навыки которых достаточны для реализации проектов. Либо, учитесь: хакатон отличная возможность взять незнакомый стек и научиться чему-то новому!

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

4. Domain Driven Design очень важен даже на начальных этапах разработки — каждый разработчик должен погружаться в предметную область проекта.

5. Делайте MVP. Выполняйте в первую очередь задачи, приближающие вас к работоспособному продукту

6. Хороший PM реально решает. Ищите хорошего менеджера и тимлида — он может принести колоссальную пользу вам и команде.

7. Надежность невероятно важна. Не пренебрегайте ей — от неё может зависеть судьба вашего проекта.

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