Факапы случаются у всех. На ошибках учатся и становятся мудрее. Но, как известно, лучше учиться на ошибках других – если о них вовремя узнать. В этой статье подробно расскажем, как мы подготовили и провели свой первый Хакатон, и почему многое пошло не по плану.
- Количество заявок ≠ количество участников
Первой неожиданностью для нас стала низкая конверсия в воронке участников. Мы проводили Хакатон в пандемию и были ограничены максимально допустимыми нормами вместимости помещения. Одновременно на площадке могли находиться не более 50 человек. Для жюри и команды забронировали 15 мест, для участников – 35.
Мы начали активную кампанию по сбору заявок. За 2 недели до начала Хакатона собрали 50 лидов. Предположили, что при конверсии в 60% к нам придут нужные 30-35 человек. Но конверсия оказалась в два раза ниже прогнозируемой. Почему так вышло?
Тут нужно сказать о механике нашего Хакатона. Он проходил офлайн и был рассчитан на студентов или начинающих разработчиков. В качестве кейса участникам нужно было разработать ресурс, который позволит удобно и быстро получать актуальные данные по пандемии. В день Хакатона, в субботу, все собирались офлайн, допиливали проекты и в конце дня презентовали их жюри.
Итак, за два дня до мероприятия мы анонсировали подробности задания и попросили подтвердить получение и присутствие офлайн в день мероприятия. И тут участники посыпались. Кто-то понял, что не рассчитал свои силы и не готов представить полноценный проект, кто-то просто ушёл на мьют.
Итог не радовал: первоначальное число заявок таяло на глазах, а вместе с ними и масштаб самого Хакатона. На финальный этап пришли всего 12 человек. Представляете наше разочарование?
Как нужно было поступить?
Нужно сразу учитывать, что конверсия лидов в участников будет низкой. В нашем случае она составила 24%. Именно поэтому мы получили лишь четверть участников на самой площадке.
Ещё советуем всем начинающим организаторам хакатонов закладывать на выполнение кейса от 4 до 7 дней – в зависимости от сложности задания. Желательно подгадать, чтобы два из них выпали на выходные. Мы столкнулись с тем, что за те два дня, которые мы дали ребятам на подготовку, они (90% из них были студентами) просто не успели как следует подготовиться. А приносить “сырые” кейсы не хотелось никому, и это тоже сильно сказалось на общем количестве участников.
Дайте разработчикам достаточно времени на подготовку, и они сами захотят прийти на презентационный этап, чтобы с кайфом защитить свой проект. Потому что он “допилен”.
2) Хайповая тема ≠ подходящая тема для Хакатона
Повторимся. Мы проводили свой Хакатон в период “постковида”– в октябре 2021-го. Тогда словосочетание “статистика заболеваемости коронавирусом” ещё уверенно держалось в топе запросов в Яндексе и Google. Тема, казалось бы, лежала на поверхности.
Наши дизайнеры придумали крутой визуал – отрисовали мифического Короназавра, по которому потенциальный Разраб должен “ударить карающим мечом кода”. В итоге наш Хакатон получил красивую упаковку, но из-за того, что тема была типовой для разработчиков, на выходе мы получили очень похожие проекты.
С другой стороны, актуальная тема дала нам хорошую прессу. Все СМИ, в которые мы отправили пресс-релизы с анонсом и результатами Хакатана, охотно опубликовали их.
Использование стандартных тем для Хакатона имеет свои плюсы и минусы. Плюсом станет простота выполнения кейса. Но все проекты будут похожи друг на друга – и это минус.
Как нужно было поступить?
Тема Хакатона была теоретической, мы не планировали выводить полученные решения в практику. Именно поэтому выбор пал на то, что тогда было актуально для всех. С одной стороны, тема оправдала наши ожидания, с другой – если вы хотите увидеть разнообразие проектов, лучше предложите участникам несколько тем или вариантов решения. Тогда у них появится возможность выбора, а у вас – минимум типовых проектов на выходе.
Мы могли бы остаться в рамках заявленной темы про Covid-19, но дать разработчикам такие варианты кейсов:
- разработка приложения по доставке необходимых товаров и медикаментов,
- разработка приложения для вызова Скорой помощи на дом в один клик,
- разработка приложения для туристов, которые попали на карантин в других странах (гайд с нужными советами и контактами).
Осветите тему со всех ракурсов. Разные целевые группы, причастные к одной теме, дадут вам разные проекты. В этом случае ценность и уникальность готовых продуктов возрастает в несколько раз. Это хорошо и для участников, и для организаторов.
3) Свобода в стеке ≠ хороший проект
Чтобы не ограничивать наших участников в творчестве, мы разрешили им использовать любые технологии. Проекты оценивались жюри по следующим пойнтам:
- полнота предоставляемых данных,
- удобство сервиса,
- оригинальность подачи информации,
- эстетичность ресурса.
Из-за отсутствия конкретики все участники начали стараться “кто во что горазд”. И, с точки зрения креативности, это было здорово. Но во время офлайн-тура, когда ребята допиливали проекты и сдавали их на проверку, мы поняли, как сильно усложнили себе жизнь.
В итоге одни проекты имели сильную backend-часть и хромали по юзабилити, другие – были очень красивыми, но слабенькими по производительности и функционалу.
Как нужно было поступить?
Отсутствие чётко обозначенного ТЗ для выполнения кейса привело к тому, что все участники оказались в неравном положении. Для кого-то проект Хакатона стал первым полноценным продуктом, для кого-то – привычной рутиной.
В таких условиях лучшим решением будет конкретика. Она нужна и для участников, и для жюри (если не хотите, чтобы ваши же коллеги чертыхались, проверяя проекты).
Введение ограничений по используемому стеку помогает уравновесить силы участников и нагляднее раскрывает потенциал каждого.
4) Жюри для однодневного Хакатона ≠ 5 человек
Оказалось, что проводить Хакатон одним днём, офлайн, с оценкой кода – было смело. Наше жюри из 5 человек едва смогло оценить качество проектов 12 участников. Если бы к нам пришли все ожидаемые 30-35 разработчиков – мы бы точно не успели провести оценку, защиту и награждение за один день.
На оценку одного проекта в среднем уходило 10 минут. Если умножить это на теоретические 40 кейсов, получим 6,5 часов работы жюри. Для однодневного Хакатона – это очень много.
Как нужно было поступить?
Детально продуманная механика проверки проектов – это обязательно условие для проведения Хакатона. Именно это мы проработали недостаточно. Советуем вам либо разделить жюри на две экспертные группы, либо прописать в условиях выполнения кейса обязательное требование – прислать готовые продукты за день до старта офлайн-тура.
В первом случае вы получите две рабочие команды, которые смогут быстрее и слаженнее проверить все проекты. Во втором – жюри сможет сделать первичную проверку кейсов, и на финальном этапе будет оценивать только уровень доработки всех участников.
Позаботьтесь о времени и нервах ваших экспертов. Чёткий план проверки проектов позволяет избежать факапных ситуаций, когда ваши ожидания не совсем совпали с реальностью. Как говорится, лучше перестраховаться.
5) В качестве постскриптума
Классический формат проведения хакатонов почти всегда состоит из двух дней. Мы сразу отказались от этой идеи и сейчас объясним, почему. Классика хороша для больших компаний, для которых Хакатон – это выгодный способ поиска решений какой-то конкретной проблемы (кейса) силами сторонних рук и умов. Чего стоят Хакатоны, например, Аэрофлота и других гигантов.
Для нас в Creative проведение Хакатона имело совсем другую цель. Мы ориентировались не на решение проблем компании, а на создание IT-комьюнити внутри своего города. Мы не стремились найти решение какой-то проблемы или сделать какой-то софт для себя, мы делали фановый проект для самих участников. После него у нас самих появилось понимание, каких ивентов не хватает нашим ребятам-разработчикам.
Сейчас мы готовим следующий Хакатон. На этот раз в онлайн-формате – чтобы расширить географию участников. Обязательно поделимся с вами результатами. Надеемся, наши факапы и советы помогут другим начинающим организаторам хакатонов сделать всё, как надо :)
Будем рады вашим историям по теме в комментариях!