Я обожаю хакатоны. Они - как демоверсия стартапов - надо сварганить 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. Надежность невероятно важна. Не пренебрегайте ей - от неё может зависеть судьба вашего проекта.

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