В предыдущей части трилогии я рассмотрел несколько причин для участия в хакатонах. Мотивация узнать много нового и выиграть ценные призы привлекает многих, но часто из-за ошибок организаторов или компаний-спонсоров мероприятие заканчивается неудачно и участники уходят недовольными. Чтобы такие неприятные случаи происходили реже, я написал этот пост. Вторая часть трилогии посвящена ошибкам организаторов.
Пост организован следующим образом: в начале я рассказываю про мероприятие, объясняю что пошло не так и к чему это привело (или может привести в долгосрочной перспективе). Затем я даю свою оценку происходящему, и как бы я поступил на месте организаторов. Поскольку на всех мероприятиях я выступал в качестве участника, я могу только предполагать истинную мотивацию организаторов. Вследствие этого, моя оценка может получится однобокой. Я не исключаю, что некоторые моменты, которые мне видятся ошибочными, на самом деле были так и задуманы.
В определенный момент, читателю может показаться, что автор решил махать кулаками после драки. Но я могу заверить вас, что это не так. В некоторых из перечисленных хакатонах мне удалось занять призовое место, что, однако, не мешает говорить о том, что мероприятие было плохо организованно.
Из-за уважение к организаторам и участникам, в посте не будет указаний на конкретные компании. Внимательный читатель, однако, может догадаться (или нагуглить) о ком идет речь.
Хакатон № 1. Строгие рамки
Полгода назад одна крупная телеком компания организовала хакатон по анализу данных. За призовой фонд боролось 20 команд. На мероприятии был предоставлен датасет для анализа, в котором содержались информация об обращениях в службу поддержки компании, активности в социальных сетях и закодированная информация о пользователях (пол, возраст итд). Самая интересная часть датасета — сообщения пользователя и ответ оператора (текстовые данные) — была довольно “шумная”, для дальнейшей работы ее необходимо было почистить.
Организаторами было поставлено задание — сделать что-нибудь интересное с предоставленными данными, причем запрещалось использовать дополнительные открытые датасеты из сети или парсить данные самому. Запрещалось также предлагать идеи не связанные с датасетом. К сожалению, предоставленные данные были достаточно “бедными”: из них было трудно получить какие-либо интересные продукты, а из общения с менторами стало понятно, что многие из предложенных идей уже и так реализуются (или будут реализовываться в ближайшем будущем) в компании.
В результате подавляющее число команд (15 из 20) сделали чат-ботов. Во время выступлений решение одной команды было мало отличаемо от предыдущей. Не вытерпев, один из членов жюри спросил у очередной выходящей на сцену команды: “Что, ребята, у вас тоже чат-бот?”. В итоге из трех призовых мест, первое и второе места досталось командам, которые не стали делать чат-ботов.
Для сравнения возьмем хакатон, организованный международной консалтинговой компанией, для фирмы “Звездочка” два года назад. Так как специфика деятельности компании “Звездочка” была не знакома многим участникам хакатона, в начале мероприятия организаторы рассказали о метриках, которые применяются в компании. После этого были предоставили шесть датасетов различной направленности: текста, таблицы, геопозиции — для всех участников был простор для маневра. Организаторы не запрещали использовать дополнительные датасеты и даже поддерживали такие начинания. В финале соревнования десять команд с разными решениями боролись за главный приз, причем все команды использовали данные, представленные компанией (несмотря на отсутствие запретов), что свидетельствовало о хорошем потенциале для получения качественных продуктов.
Мораль
Не стоит ограничивать творческий поток участников. Как организатор вы должны предоставить материалы и довериться их взгляду и профессионализму. Если вы являетесь участником хакатона, любые ограничения или запреты должны вас настораживатью Обычно это свидетельство плохой организации (пример из реальной жизни — постоянное желание воткнуть куда-нибудь забор). Если же вы все же столкнулись с ограничениями, то будте готовы к тому, что вам придется создавать проект в пуле с большой конкуренцией. В таком случае вы обязаны рисковать: делать что-то принципиально новое или предлагать необычную “киллер фичу”, чтобы выделится из потока однообразных проектов.
Хакатон №2. Невыполнимые задания
Хакатон в Амадоре обещал быть интересным. Компания-спонсор — крупный производитель телефонов, начала подготовку за 4 месяца до даты проведения. В социальных сетях проводился пиар мероприятия, потенциальным участникам необходимо было пройти технический тест и написать про свои прошлые проекты, чтобы быть отобранным на данное событие. Призовой фонд был приятно большим. За несколько дней до хакатона, менторы провели техническую сессию для того чтобы у участников было время проникнуться спецификой отрасли.
На самом мероприятии организаторы предоставили датасет логов оборудования объемом 8 Гб, задача — бинарная классификация поломок. Рассказали про критерии оценки проектов — качество классификации, креативность создания фич, умение работать в команде итд. Вот только незадача — на 8 Гб “фичей”, было всего 20 примеров в трейне и 5 в тесте. Финальный гвоздь в крышку гроба хакатона забил лик в данных: логи оборудования полученные в среду содержали ошибку в работе оборудования, а созданные в четверг — не содержали (об этом, к слову, знали только две команды, и обе были из России — родины опытных датамайнеров). Хотя даже знание истинных лейблов теста не помогло подогнать ответ — задача была нерешаемой. Организаторы не получили желаемого результата, участники потратили уйму времени решая плохо составленную задачу. Хакатон был провален.
Мораль
Проводите технические экспертизы заданий и проверяйте свои задания на адекватность. Лучше переплатить за предварительную экспертизу (в данном случае любой датасаентист сразу бы указал на невозможно решения этой задачи), чем потом жалеть.
В данном случае, помимо потраченного времени и денег, компания потеряла кредит доверия от потенциальных кандидатов и возможно написать о результатах. К слову, об удачных результатах должны писать не только участники, но и компания, максимально реализуя хакатон с точки зрения PR. К сожалению, не все компании делают это, ограничиваясь только постом-анонсом и парой фотографий с мероприятия в твиттере.
Хакатон №3. Take it or leave it
Совсем недавно наша команда поучаствовала в хакатоне в Амстердаме. Поскольку по образованию я — инженер-электроэнергетик (в области возобновляемых источников энергии), то тематика была как раз для нас — энергетика. Хакатон проводился в онлайн формате: нам дали описание задания и месяц на выполнение. Организаторы хотели увидеть готовый проект, который поможет увеличить энергоэффективность домов Амстердама.
Мы сделали проект, в котором предсказывается потребление электроэнергии (до этого я участвовал в конкурсе на данную тематику где получил около-sota решение, о котором можно почитать тут) и генерация солнечной панелью. На основании этих предсказаний оптимизируется работа аккумуляторной батареи (эта идея была частично взята из моего магистерского диплома). Наш проект хорошо согласовывался как с заданием от организаторов (как нам тогда казалось), так и с политикой администрации Амстердама в области ВИЭ на несколько лет вперед.
Во время оценки проектов, нам, как и многим командам, сказали что это не то, что ожидал заказчик, добавив при этом, что мы должны переделать проект, если мы хотим побороться за призовое место. Мы не стали ничего переделывать, смирившись с поражением. Из сорока команд-участников мы не прошли даже в топ-7, хотя выбор организаторов, как мне кажется, был довольно странным. Например, они пропустили в финал команду, которая сделала приложение по расчету скорости ветра и солнечного излучения (СИ) по данным датчиков смартфона: микрофон для ветра, датчик освещенности — для СИ. Киллер фичей была классификация hotdog/not hotdog на три класса: Солнце, ветер, вода и показ соответствующей статьи в Википедии (демо).
Оставим на минуту моральную сторону вопроса: шантажировать участников возможностью победы просто неэтично. Так как однной из мотиваций участия в хакатонах (особенно опытных разработчиков) является реализация своих задумок, многие сильные участники могут просто покинуть мероприятие, услышав такую обратную связь (что произошло не только с нашей командой, но и с рядом других, которые перестали обновлять страницу своего проекта после прослушки ментора). Все же допустим, мы согласились с пожеланием организаторов и переделали свой проект под их требования. Что может произойти далее?
Поскольку у организаторов есть свое понимание “идеального проекта”, все пожелания (и соответственно изменения) будут подводить нас к этому идеалу. Конкурсанты будут тратить свое время и им будет все труднее и труднее отказаться от дальнейшего участия (так как уже вложены силы, и кажется что до победы совсем чу-чуть). Но в действительности, конкуренция за призовые места будет возрастать, и участникам все чаще придется переделывать проект по правкам от организаторов в надежде получить приз. В итоге, ребята которые не заняли призовые места, оглянувшись назад поймут, что поучаствовали в фрилансе без денег: вносили правки заказчика, но при этом не получили за этого ничего в замен (кроме соответсвующего опыта конечно же).
Мораль
Часто пожелания и обратная связь от организаторов приходят на помощь проекту. При этом, однако, участники не должны опираться на советы менторов как хромой на трость. Если вы слышите от организаторов фидбэк по вашему проекту в духе “уберите, мы это не заказывали” — ваше участие в хакатоне на этом можно считать завершенным.
Если вы организовываете хакатон с четким видением проекта, но без навыков или возможности реализовать его самостоятельно, то лучше оформите свое виденье в виде технического задания для фрилансера. В противном случае вам придется заплатить дважды — за хакатон и за услуги фрилансера.
Автор: Денис Воротынцев
