«Не следует все усилия направлять на технологичность решения»: как хорошо показать себя на хакатоне

Привет! Меня зовут Илья Сазонов, я руководитель backend-разработки в сервисе рассрочек Всегда.Да и технический эксперт конкурса «Цифровой прорыв», хакатона по финтеху. В этой статье хочу поделиться советами и лайфхаками для тех, кто готовится впервые попробовать себя на хакатоне – «Цифровом прорыве» или любом другом.

Немного обо мне. Большую часть своей карьеры занимаюсь backend-разработкой, также есть опыт в патентных исследованиях и геймдеве. На «Цифровом прорыве» я консультировал несколько команд – 4 из 5 вошли в первую 10-ку, а одна – в тройку победителей. До этого участвовал в нескольких хакатонах как программист.

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

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

Хакатон – штука изнурительная, и кто-то может банально не вынести перегрузки и не успеть закончить свою часть. Это критично, если у вас есть только один человек для разработки, например, фронта. Или бэка. С точки зрения жюри незаконченный продукт мало отличается от продукта, для которого есть только презентация.

Больше шансов на победу получает кросс-функциональная команда, в которой все – фулстек, или могут дублировать функции друг друга. Предварительно посмотрите, сколько человек допустимо иметь в команде – условия могут разниться.

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

Проведите репетиции. Запланируйте несколько встреч или Zoom-ов, чтобы вместе покодить или порешать кейсы из прошлых/похожих хакатонов.

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

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

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

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

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

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

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

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

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

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

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

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

После хакатона в первую очередь нужно выспаться. Потом собраться и обсудить, как он прошел. Что получилось хорошо, что не очень. И что поменять, чтобы следующий хакатон прошел лучше, чем прошлый. Вы ведь собираетесь участвовать в следующих хакатонах, правда?:)

Если вы выиграли – поздравляем! Если нет, то результаты не стоит списывать со счетов.

#хакатон #финтех #разработка