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