Я обожаю хакатоны. Они - как демоверсия стартапов - надо сварганить MVP, провести аналитику, создать продукт. Вот только побеждать в этих самых хакатонах у меня не всегда получается. Я со своей командой участвовал в хакатоне ЛЦТ-2022. Думали будет просто - мы были опытны, слаженны, побеждали ранее. Но в итоге, как это часто бывает, что-то пошло не так. Заняли мы, само собой, самое обидное место из существующих: 4-е из 97 Мы решили провести анализ ошибок, результатом которого и стала данная статья. Как слили? Почему? Зачем? Давайте разбираться. Давайте знакомиться с главными героями нашего боевого отряда. По регламенту, участвовать в одной команде может от 2 до 5 человек. Изначально нас было 4-ро, роли у нас были следующие: Backend разработчик Аналитик/PM Fullstack разработчик Frontend разработчик (Я) Нам не хватало только дизайнера, поэтому мы решили как и всегда - попытаться найти его на просторах телеграм чатов с поисками сокомандников. Для того чтобы полноценно начинать участвовать, нам также нужно было выбрать трек (задачу). Невероятно забавно, но уже на данном этапе у нас появились первые проблемы. Треков было 10, каждый со своими странностями. Треки были следующими: Увидели темы? Вам они тоже показались какими-то странными? Ну и мы сидим и думаем - а что брать то? Выбор пал на 2, 6 и 9. В итоге взяли 6-ю тему "Сервис для расчёта рыночной стоимости жилой недвижимости города Москвы" как самую понятную. Как оказалось - это было не самое умное решение - мы выбрали самый конкурентный трек хакатона. Зашибись. На 6 треке было наибольшее кол-во команд - 97, Карл! Для понимания, на одном из других треков (не помню точно на каком) было ~14 команд. Как споткнулись: Выбрали самый популярный и сложный трек Какие выводы сделали: Следует тщательней анализировать выбор задач на хакатоне. Порой выбрать самую "понятную" - не лучшее решение, т.к ее логично будет выбирать большинство. Если мы спроецируем эту ошибку на коммерческие проекты и стартапы, она будет звучать как “делайте анализ рынка заранее, прежде чем начинать разрабатывать продукт”. Наш состав команды почти не менялся между хакатонами - единственное что приходилось делать всегда, это искать UI/UX дизайнера - каждый раз мы это делали с нуля. В этот раз ситуация была еще хуже - начали активно искать дизайнера лишь за 2 дня до начала, затем поняли, что он нам не понравился, и начали искать другого. Нашли нового, когда прошла неделя от хакатона. Т.е, мы потратили 50% отведенного времени. Как споткнулись: Не имели проверенного дизайнера в команде. Начали искать дизайнера слишком поздно. Потратили слишком много времени, прежде чем понять что нам не подходит человек. Какие выводы сделали: Лучший сценарий - иметь полностью готовую, наработанную и укомплектованную команду без поиска в условиях ограниченного времени У нас был странный предрассудок, что без дизайна мы не сможем начать работу, это и стало причиной, почему в первую неделю мы не сделали почти ничего. При этом, наш аналитик сделал очень подробный  и внятный план за 2 дня - мы могли начать по крайней мере заранее пилить бекенд, а на фронтенде делать не красивый, но функциональный код который бы решал задачу. Надо было сразу писать бизнес логику, пока создавался интерфейс, а на фронтовой части просто использовать серые квадраты - главное чтобы они были рабочими. Как споткнулись: Выбросили в никуда 50% времени Могли начать писать код спустя 2-3 дня, а не спустя неделю Какие выводы сделали: Используйте все время которое дано на задачу с первой минуты. Отдыхать будете потом. По максимуму используй все возможности которые у тебя есть. Так. И вот началась наша разработка. Спустя половину потраченного времени, мда уж. Какой стек был у нас: бэкенд - python + FastAPI, база - PostgreSQL, фронтенд - React (с связкой с Next). Все из нас были бекендерами, я в том числе. На работе я нечасто взаимодействую с React, хоть и приходится это иногда делать. У нас фактически была команда из 4-х серверных разработчиков, но при этом фронтенд кто-то, да должен делать. В итоге нам, не сильно разбирающимся в фронтенд разработке, надо было писать фронтенд код. Компетенции во фронте у нас объективно слабые. Во всех хакатонах у нас всегда была одна и та же проблема - мы нормально верстали, писали хороший бек, но когда дело доходило до связи с этим самым бэком - мы испытывали космический уровень боли. Очень часто мы не успевали от слова совсем. У нас был опыт на React, но недостаточный для продуктовой разработки. Как споткнулись: У нас не было достаточных компетенций во фронтенде. Очень долго настраивали и пытались первично соединить бек с фронтом Нужно не просто верстать компоненты, а потом соединять их с беком. Необходимо делать сразу рабочие компоненты которые к этому беку обращаются. Какие выводы сделали: Много кто из нас значительно прокачался в React. Что-то не знать и пытаться внедрить новое на хакатоне может быть очень полезным опытом. Но если цель именно победа и получение приза - команда должна иметь всю необходимую квалификацию для этого изначально. Осталось 40 часов до дедлайна. Так как код писался очень быстро, то и его качество оставляло желать лучшего. Одна из причин его плохого качества - не следование принципу единого языка (Ubiquitous language). Так как мы работали параллельно и нечасто координировали свою работу, у нас было по 2-3 разных названия для одной и той же Entity в разных частях проекта. Помимо этого, все знание по проекту было сосредоточено у аналитика. Никто не понимал user flow кроме него - нам было лень в этом разбираться, и мы поплатились за это абсолютным непониманием того что происходит и что нам делать. Не сказать что я эксперт в DDD, но книжку Эванса (синюю) и Вернона (красную) по Domain Driven Design я прочёл. И почему-то, у меня всегда было стойкое ощущение о том, что DDD - это дорого, сложно, занимает много времени и не всегда полезно (наверное потому что сам Вернон приводил матрицу DDD в которой описывал его применимость в проекте). А на самом деле, если декомпозировать DDD на самые полезные его части - то их следует использовать абсолютно всегда. Теперь я убежден, что как минимум ubiquitous language нужно внедрять в любой проект, а каждый разработчик должен уделить время на понимание предметной области, и того что он вообще разрабатывает, особенно на начальных стадиях производства продукта. Как споткнулись: Зависели от нашего аналитика. Bus factor был равен единице - если бы наш аналитик вдруг внезапно заболел - мы бы не смогли сделать абсолютно ничего с этим. Не вникали в предметную область на наших созвонах и QA сессиях, относились к этому халатно Не имели никакого глоссария, в разных частях проекта были разные названия для одних и тех же сущностей. Какие выводы сделали: Единый язык необходим даже когда вы делаете MVP. Отсутствие словаря сильно отвлекало и мешало добавлять фичи, он должен быть всегда - особенно если разработка идёт быстро и параллельно. Хорошее понимание предметной области должно быть у каждого члена команды, особенно на ранних этапах разработки. В нашем случае, хорошее понимание было лишь у нашего аналитика, и это нас сильно ограничивало. Осталось 12 часов до дедлайна. Снова одна и та же проблема из раза в раз - мы сделали слишком большой акцент на вторичных фичах, при этом основа была все еще не готова. Я не знаю почему, но мы постоянно об это спотыкаемся, я - в особенности. Мы не делали проект итеративно, мы не делали минимальный жизнеспособный продукт - вместо этого мы потратили очень много времени на дизайн, красивые паддинги, красивые отображения прогресса, нерелевантные и необязательные фичи, при этом забивая на критически важные части приложения. Как споткнулись: Не разрабатывали проект итеративно Делали красиво, но не жизнеспособно Не использовали принципы продуктовой разработки Какие выводы сделали: Сначала нужно концентрироваться на главном - чтобы приложение работало, не важно как плохо оно выглядит. Не важно насколько красиво будет выглядеть ваш дизайн, если приложение не будет работать. Составляйте Backlog с критическими задачами, от реализации которых зависит успех проекта. Делайте наиболее важные задачи в первую очередь. Вечер последнего дня, 5-6 часов до деделайна. Мы объективно не успеваем. Большинство из нас в какой-то невероятной печали. Мы очень сильно устали, в последние 2 дня страдали от депривации сна и работы по 15 часов. Код лапша, жизнь отстой, всё достало, тлен. Тут всё очевидно - нам не сильно это помогало, напротив, только мешало. Самым забавным является то, что мы прошли в финал (топ-10 команд трека). Да, мы это сделали, но при этом мы буквально на финишной прямой могли забить и уйти спать. Как споткнулись: Были в унынии, и думали вообще уйти с проекта Какие выводы сделали: Если уж начал что-то делать, делай это до конца. Возможно от уныния в таких ситуациях не избавиться, но как минимум доделать дело - это твоё обязательство. Уныние не всегда оправдано. В нашем случае все еще абсурднее - мы объективно сделали неплохое решение для финала, но при этом мы так не считали Наш тимлид все время был "на подъеме" - единственный кто нас поддерживал и поднимал наше настроение. Постоянно писал что все отлично, это легчайший хакатон, займём первое место - надо лишь немного поработать. Он провёл идеальную аналитику, проработал план продукта и проекта, продумал в деталях весь user flow, а также скоординировал между собой работу всех членов команды. Без него все было бы сильно сложнее, мы бы не смогли дойти до финала, сдавшись в самый ответственный момент. Какие выводы сделали: Кто бы что не говорил, но хороший Тимлид/PM реально решает и приносит колоссальную пользу в продуктовой разработке. Аналитику проведет, задачи декомпозирует, скоординирует разные части команды, vision всем свой даст, спасёт от уныния. Мы часто раздражаемся от "эффективных менеджеров", но по-настоящему эффективные менеджеры реально существуют. Таких людей немного, но они есть, и порой они могут быть причиной успеха или неудачи всего проекта. Итак, проходит неделя. И каким-то чудом мы попали в топ 10, а значит мы официально участвуем в финале, на котором решение нужно питчить прямо на сцене. Отдам должное организации мероприятия - она была на высоте. Здание было крутое, нас кормили завтраком, обедом и ужином, а вечером даже разливали шампанское и вино! Раздавали бесплатные протеиновые батончики, можно было поиграть в PS4 или отдохнуть в массажных креслах. А, ну и мерч само собой за то что мы попали в финал выдали. Настало время защиты решений. Мы сидели, и скрупулёзно смотрели за нашими соперниками. Конкурентны объективно имели крутые, проработанные решения, и это было офигенно. После защиты, как нам показалось, что топ-3 точно наш. Но, как оказалось, это не так. Думали SLA - не для MVP? Думали высокая доступность и надежность - прерогатива highload приложений с кучей пользователей? А вот нифига. Надежность - основная причина по которой мы проиграли. И заняли, внимание 4-место. Не дотянули совсем чуть-чуть до призового (обидно конечно). После финала, когда жюри давало свой фидбек, основной жалобой на нас была нестабильность работы сервиса. Кто-то из проверяющих загружал неправильный формат файла в приложение - мы кидали ошибку без внятного объяснения причин отказа, и проверяющий не понимал, что это он что-то делает не так. Если бы мы показывали ошибку вроде "формат файла не верный, проверьте, пожалуйста еще раз", то возможно все обернулось бы иначе. В другие попытки проверить решение, у проверяющих оно также не работало - насколько мы поняли проблема в этот раз была на нашей стороне. Как споткнулись: Не придали значение надежности - думали что для MVP это не важно. Не имели адекватной обработки ошибок на клиентской части - это могло спасти нас хотя бы частично. Какие выводы сделали: Надежность - важнейший параметр проекта, от него может зависеть его успех, даже если всё остальное было сделано на высоте. Уделяйте достаточное время обработке ошибок с учетом UX. Давайте подведём итоги, и выделим самые полезные инсайты из нашего опыта: В хакатонах не всегда стоит брать самый понятный на первый взгляд трек. Правильно набирайте команду - берите людей, которым доверяете, с которыми работали ранее, и навыки которых достаточны для реализации проектов. Либо, учитесь: хакатон отличная возможность взять незнакомый стек и научиться чему-то новому! Используйте все доступное время - не тратьте его на бесполезное уныние и реализуйте ваш проект до победного конца. Domain Driven Design очень важен даже на начальных этапах разработки - каждый разработчик должен погружаться в предметную область проекта. Делайте MVP. Выполняйте в первую очередь задачи, приближающие вас к работоспособному продукту Хороший PM реально решает. Ищите хорошего менеджера и тимлида - он может принести колоссальную пользу вам и команде. Надежность невероятно важна. Не пренебрегайте ей - от неё может зависеть судьба вашего проекта. Спасибо за уделенное время. Надеюсь эта статья поможет вам не допускать ошибок, допущенных нами.  Какой-то рандомный dude