W Zastanowiłem się nad kilkoma powodami, dla których warto brać udział w hackathonach. Motywacja do poznania czegoś nowego i zdobycia cennych nagród przyciąga wielu, ale często z powodu błędów organizatorów lub firm sponsorujących wydarzenie, kończy się to niepowodzeniem i uczestnicy wychodzą niezadowoleni. Aby takie nieprzyjemne sytuacje zdarzały się rzadziej, napisałem ten post. Druga część trylogii jest poświęcona błędom organizatorów.
Post jest zorganizowany w następujący sposób: na początku opowiadam o wydarzeniu, wyjaśniam, co poszło nie tak i do czego to doprowadziło (lub może doprowadzić w dłuższej perspektywie). Następnie przedstawiam swoją ocenę sytuacji oraz to, jak postąpiłbym na miejscu organizatorów. Ponieważ na wszystkich wydarzeniach występowałem jako uczestnik, mogę jedynie przypuszczać prawdziwe motywacje organizatorów. W związku z tym, moja ocena może być jednostronna. Nie wykluczam, że niektóre aspekty, które wydają mi się błędne, w rzeczywistości były zamierzone.
W pewnym momencie czytelnik może pomyśleć, że autor postanowił machać pięściami po bójce. Ale mogę zapewnić, że tak nie jest. W niektórych z wymienionych hackathonów udało mi się zająć miejsce na podium, co jednak nie przeszkadza mi mówić o tym, że wydarzenie było źle zorganizowane.
Z szacunku do organizatorów i uczestników, w poście nie będą wskazywane konkretne firmy. Uważny czytelnik jednak może się domyślić (lub wygooglować), o kim mowa.
Hackathon nr 1. Surowe ramy
Pół roku temu jedna z dużych firm telekomunikacyjnych zorganizowała hackathon dotyczący analizy danych. O nagrody rywalizowało 20 zespołów. Na wydarzeniu udostępniono zestaw danych do analizy, który zawierał informacje o kontaktach z biurem obsługi klienta firmy, aktywności w mediach społecznościowych oraz zakodowane informacje o użytkownikach (płeć, wiek itp.). Najciekawsza część zestawu danych — wiadomości użytkownika i odpowiedzi operatora (dane tekstowe) — była dość „szumna”, dlatego do dalszej pracy należało ją oczyścić.
Zadanie dla organizatorów polegało na tym, aby stworzyć coś interesującego z dostarczonych danych, przy czym zabronione było korzystanie z dodatkowych otwartych zbiorów danych z sieci lub samodzielne pozyskiwanie danych. Zabroniono również proponowania pomysłów niezwiązanych z zestawem danych. Niestety, dostarczone dane były dość „ubogie”: trudno było uzyskać z nich jakiekolwiek ciekawe produkty, a podczas rozmów z mentorami stało się jasne, że wiele z zaproponowanych pomysłów już się realizuje (lub będzie realizowanych w najbliższej przyszłości) w firmie.
W rezultacie przytłaczająca większość zespołów (15 z 20) stworzyła chatboty. Podczas wystąpień rozwiązanie jednego z zespołów było mało odróżnialne od poprzedniego. Nie wytrzymując, jeden z członków jury zapytał kolejny zespół wychodzący na scenę: „Co, chłopaki, wy też macie chatbota?”. W efekcie z trzech nagród pierwsze i drugie miejsce przyznano zespołom, które nie zdecydowały się na stworzenie chatbotów.
Dla porównania weźmy hackathon zorganizowany przez międzynarodową firmę konsultingową dla firmy „Zvezdochka” dwa lata temu. Ponieważ specyfika działalności firmy „Zvezdochka” była nieznana wielu uczestnikom hackathonu, na początku wydarzenia organizatorzy opowiedzieli o metrykach używanych w firmie. Potem udostępniono sześć zbiorów danych o różnej tematyce: teksty, tabele, dane geolokalizacyjne — wszyscy uczestnicy mieli szeroką przestrzeń do działania. Organizatorzy nie zabraniali korzystania z dodatkowych zbiorów danych i nawet wspierali takie inicjatywy. W finale rywalizowało dziesięć zespołów z różnymi rozwiązaniami o główną nagrodę, przy czym wszystkie zespoły wykorzystały dane zaprezentowane przez firmę (pomimo braku zakazów), co świadczyło o dużym potencjale do uzyskania wysokiej jakości produktów.
Morał
Nie ograniczaj twórczego potencjału uczestników. Jako organizator powinieneś dostarczyć materiały i zaufać ich spojrzeniu oraz profesjonalizmowi. Jeśli jesteś uczestnikiem hackathonu, wszelkie ograniczenia czy zakazy powinny cię niepokoić. Zazwyczaj są one oznaką złej organizacji (przykład z życia: ciągłe pragnienie wstawiania ogrodzenia, gdzie się da). Jeśli jednak napotkałeś na ograniczenia, bądź gotowy na to, że przyjdzie Ci stworzyć projekt w warunkach dużej konkurencji. W takiej sytuacji musisz podjąć ryzyko: stworzyć coś zasadniczo nowego lub zaproponować nietypową „killer feature”, aby wyróżnić się z monotonności projektów.
Hackathon nr 2. Niemożliwe zadania
Hackathon w Amadorze obiecywał być interesujący. Firma-sponsor, duży producent telefonów, rozpoczęła przygotowania na 4 miesiące przed datą wydarzenia. W mediach społecznościowych prowadzono kampanię promocyjną, potencjalni uczestnicy musieli przejść test techniczny i opisać swoje wcześniejsze projekty, aby zostać zakwalifikowanym do tego wydarzenia. Fundusz nagród był całkiem duży. Na kilka dni przed hackathonem mentorzy zorganizowali sesję techniczną, aby uczestnicy mieli czas zapoznać się ze specyfiką branży.
Podczas samego wydarzenia organizatorzy dostarczyli zestaw danych logów sprzętu o objętości 8 GB, a zadanie polegało na binarnej klasyfikacji awarii. Opowiedziano o kryteriach oceny projektów — jakość klasyfikacji, kreatywność w tworzeniu funkcji, umiejętność pracy w zespole itd. Ale problem w tym, że w 8 GB „funkcji” było zaledwie 20 przykładów w zbiorze treningowym i 5 w teście. Ostatecznym gwoździem do trumny hackathonu był błąd w danych: logi sprzętu uzyskane w środę miały błąd w pracy urządzenia, a stworzone w czwartek — nie miały (na ten temat wiedziały tylko dwie drużyny, obie z Rosji — ojczyzny doświadczonych data minerów). Chociaż nawet znajomość rzeczywistych etykiet testowych nie pomogła w dostosowaniu odpowiedzi — zadanie było nierozwiązywalne. Organizatorzy nie osiągnęli pożądanego wyniku, a uczestnicy stracili mnóstwo czasu na rozwiązywanie źle skonstruowanego zadania. Hackathon został nieudany.
Morał
Przeprowadzaj techniczne ekspertyzy zadań i sprawdzaj adekwatność swoich zadań. Lepiej przepłacić za wstępną ekspertyzę (w takim przypadku każdy data scientist natychmiast wskazałby na niemożliwość rozwiązania tego zadania), niż potem żałować.
W tym przypadku, oprócz straconego czasu i pieniędzy, firma straciła zaufanie potencjalnych kandydatów i mogła podzielić się wynikami. Swoją drogą, o udanych wynikach powinni pisać nie tylko uczestnicy, ale także firma, maksymalnie wykorzystując hackathon pod względem PR. Niestety, nie wszystkie firmy to robią, ograniczając się tylko do posta zapowiadającego i kilku zdjęć z wydarzenia na Twitterze.
Hackathon nr 3. Weź to lub zostaw.
Niedawno nasz zespół wziął udział w hackathonie w Amsterdamie. Ponieważ z wykształcenia jestem inżynierem energetykiem (w dziedzinie odnawialnych źródeł energii), temat był dla nas idealny — energetyka. Hackathon odbył się w formacie online: otrzymaliśmy opis zadania i miesiąc na jego wykonanie. Organizatorki chciały zobaczyć gotowy projekt, który pomoże zwiększyć efektywność energetyczną domów w Amsterdamie.
Stworzyliśmy projekt, w którym prognozowane jest zużycie energii elektrycznej (wcześniej brałem udział w konkursie na ten temat, gdzie zdobyłem rozwiązanie 'około-sota', o którym można poczytać ) i generację energii przez panele słoneczne. Na podstawie tych prognoz optymalizowana jest praca akumulatora (pomysł ten był częściowo zaczerpnięty z mojego dyplomu magisterskiego). Nasz projekt dobrze współbrzmiał zarówno z zadaniem od organizatorów (jak nam się wtedy wydawało), jak i z polityką administracji Amsterdamu w dziedzinie OZE na kilka lat do przodu.
Podczas oceny projektów nam, jak wielu zespołom, powiedziano, że to nie jest to, czego oczekiwał klient. Dodano, że musimy przerobić projekt, jeśli chcemy walczyć o nagrodę. Nie zdecydowaliśmy się na żadne poprawki, pogodziliśmy się z porażką. Z czterdziestu zespołów uczestniczących nie dostaliśmy się nawet do czołowej siódemki, chociaż wybór organizatorów wydaje mi się dość dziwny. Na przykład, wpuszczono do finału zespół, który stworzył aplikację do obliczania prędkości wiatru i promieniowania słonecznego (SI) na podstawie danych z czujników smartfona: mikrofon do pomiaru wiatru, czujnik natężenia światła - do SI. Killer feature polegała na klasyfikacji hotdog/not hotdog na trzy klasy: Słońce, wiatr, woda oraz wyświetlanie odpowiedniego artykułu w Wikipedii.).
Zostawmy na chwilę moralny aspekt sprawy: szantażowanie uczestników możliwością zwycięstwa jest po prostu nieetyczne. Ponieważ jedną z motywacji do udziału w hackathonach (szczególnie doświadczonych programistów) jest realizacja swoich pomysłów, wielu silnych uczestników może po prostu opuścić wydarzenie, słysząc taką informację zwrotną (co zdarzyło się nie tylko z naszym zespołem, ale także z kilkoma innymi, które przestały aktualizować stronę swojego projektu po sesji z mentorem). Załóżmy, że zgodziliśmy się z życzeniem organizatorów i przerobiliśmy nasz projekt według ich wymagań. Co może się wydarzyć dalej?
Ponieważ organizatorzy mają swoje wyobrażenie o "idealnym projekcie", wszystkie ich sugestie (i stosowne zmiany) będą prowadzić nas do tego ideału. Uczestnicy będą marnować swój czas, a rezygnacja z dalszego udziału będzie coraz trudniejsza (ponieważ już włożono wysiłek, a wydaje się, że do zwycięstwa już blisko). W rzeczywistości konkurencja o nagrody będzie wzrastać, a uczestnicy coraz częściej będą musieli przerabiać projekt według poprawek organizatorów w nadziei na zdobycie nagrody. W końcu młodzi ludzie, którzy nie zajęli miejsc na podium, z perspektywy czasu zrozumieją, że brali udział w freelansie bez pieniędzy: wprowadzali poprawki na życzenie klienta, ale nie otrzymali w zamian nic (poza odpowiednim doświadczeniem, oczywiście).
Morał
Często życzenia i opinie od organizatorów pomagają projektowi. Jednak uczestnicy nie powinni opierać się na radach mentorów jak kaleka na lasce. Jeśli słyszysz od organizatorów opinię na temat swojego projektu w duchu „usuńcie, nie zamawialiśmy tego” — można uznać, że Twoje uczestnictwo w hackatonie dobiegło końca.
Jeśli organizujesz hackaton z wyraźną wizją projektu, ale bez umiejętności lub możliwości zrealizowania go samodzielnie, lepiej przygotuj swoją wizję w formie specyfikacji technicznej dla freelancera. W przeciwnym razie będziesz musiał zapłacić dwa razy — za hackaton i za usługi freelancera.
Źródło: habr.com
