Точка роста, а не просто соревнование: что хакатон даёт аналитику вне рабочей рутины

Привет, Хабр! Я — Луиза Шаипова, ведущий продуктовый аналитик РТЛабс. За 4 года работы в компании мне удалось поучаствовать в трёх хакатонах, и сегодня я расскажу, зачем это нужно аналитику и как может прокачать его скиллы.

С чего всё началось

«У меня и так хватает своих задач на работе, зачем мне ещё и чужие решать?» — примерно такие сомнения у меня были перед участием в первом хакатоне. На тот момент я была старшим аналитиком и имела, казалось бы, достаточно практики на рабочих задачах. Зачем добавлять к этому ещё и те, за которые не платят?

Но интерес и азарт взяли верх. Итог — участие сразу в трёх хакатонах: «Лидеры цифровой трансформации» (дважды) и Московский туристический хакатон. Там я выполняла роли аналитика, дизайнера и немного продакта, защищала проекты перед заказчиками-экспертами.

Задачи, которые мне пришлось решать, и результаты:

— мониторинг критичных заявок в сфере ЖКХ («Лидеры цифровой трансформации») —
3 место

— интерактивная карта для подбора локаций под спортивную инфраструктуру в Москве («Лидеры цифровой трансформации») — 2 место

— сервис подбора похожих изображений для RUSSPASS (Московский туристический хакатон) — 1 место

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

Хакатон — это обычная работа, сжатая в 48 часов

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

Чем хакатон отличается от обычной работы

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

— сжатые сроки — на хакатоне от вас хотят всё и сразу (хотя и на работе иногда тоже, чего уж скрывать);

— быстрые итерации — прототипирование, разработка и обратная связь от заказчиков происходят в разы быстрее привычного темпа;

— тревожное ощущение конкуренции, которое заставляет придумывать всё более сильные идеи для продукта;

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

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

Взгляд аналитика на процесс хакатона: польза на каждом этапе

Команда. Обычно моя команда состояла из бэкенд-разработчика, фронтенд-разработчика, меня в совмещённой роли аналитика и дизайнера и иногда ML-специалиста. Совмещение роли аналитика с ролью дизайнера сильно экономит время: не нужно ставить ТЗ дизайнеру, потому что дизайнер — это ты сам. А ещё роль дизайнера помогла мне детально понять, что разработчикам нужно видеть в макетах и как организовать последние так, чтобы с ними было проще работать.

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

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

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

Сбор требований. После анализа ТЗ нужно быстро составить требования к продукту — функциональные и нефункциональные, в идеале распределив их по важности, потому что реализовать всё за время хакатона получается не всегда. Для приоритизации хорошо подходит метод MoSCoW, который заключается в разделении списка задач на четыре категории по степени важности:

• Must have (должны иметь) — обязательные функции, без которых продукт не сможет работать;

• Should have (стоит иметь) — важные, но не критичные для запуска функции;

• Could have (могли бы иметь) — полезные дополнения, если останется время;

• Won’t have (не будем иметь) — не критично и не нужно.

В MVP должны входить Must have , закрывающие главную боль заказчика, а дополнительные фичи можно оставить на конец или просто озвучить как планы развития. И да, не стесняйтесь поглядывать за соперниками: плохой вор крадёт у одного, хороший — у множества.

Что это дало мне: дисциплину приоритизации — умение честно отделять главное от того, что просто «было бы неплохо».

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

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

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

Что это дало мне: привычку проверять гипотезы на живых людях как можно раньше, а не ждать «финального» варианта.

Презентация результата.

Здесь важны три составляющие.

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

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

3. Планы развития: за сжатые сроки хакатона не всегда получается реализовать всё задуманное, но важно озвучить, как продукт мог бы развиваться дальше, — это показывает экспертам, что вы заинтересованы в его будущем, что тоже влияет на итоговую оценку.

Что это дало мне: умение выстраивать презентацию вокруг критериев, по которым её будут оценивать, и говорить на языке пользователя.

Как хакатон прокачивает навыки аналитика на разных уровнях

Лайфхаки для аналитика на хакатоне

Вот что я бы посоветовала себе на первом хакатоне:

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

• Концентрируйтесь на корневых функциях, которые решают главную боль пользователя. Не беритесь за реализацию дополнительных фичей, если ещё не полностью оттестировали работу главных.

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

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

• Оставьте время на репетицию финального питча. Говорите на языке пользы для пользователя, а не на языке набора технологий.

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

Что можно взять из опыта участия в хакатонах в повседневную работу

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

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

• При работе с большим списком фич пробуйте MoSCoW вместо «сделаем всё, что успеем» — это экономит время на этапе планирования.

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

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

Стоит ли специалисту тратить время на хакатоны?

Мой ответ — да, и не потому что это красиво выглядит в резюме. Хакатон — это тренажёр, который за 48 часов прогоняет вас через весь цикл продуктовой работы в самой сжатой и честной форме: без бюрократии, но и без права на медленное раскачивание. То, чему вы научитесь на хакатоне, — от анализа сырого ТЗ до презентации решения перед экспертами — сможете применять каждый день в своей работе, даже не замечая этого. Особенно это полезно, если вы только начинаете свою карьеру: такой концентрированный опыт помогает быстрее нарастить те навыки, на которые в обычной работе ушли бы годы.

Если у вас есть интерес и небольшой резерв нервных клеток — пробуйте.

Пишите свои вопросы и комментарии, с радостью отвечу на них!