В Rozważałem kilka powodów, dla których warto brać udział w hackatonach. Motywacja do nauczenia się wielu nowych rzeczy i zdobycia cennych nagród przyciąga wielu, jednak często z powodu błędów organizatorów lub firm sponsorujących wydarzenie kończy się niepowodzeniem, a uczestnicy wychodzą niezadowoleni. Aby takie nieprzyjemne zdarzenia zdarzały się rzadziej, napisałam ten post. Druga część trylogii poświęcona jest błędom organizatorów.
Post jest zorganizowany w następujący sposób: na początku opowiadam o zdarzeniu, wyjaśniam, co poszło nie tak i do czego doprowadziło (lub może doprowadzić w dłuższej perspektywie). Następnie oceniam, co się dzieje i co sam bym zrobił, gdybym był organizatorem. Ponieważ brałem udział we wszystkich wydarzeniach, mogę się tylko domyślać, jaka była prawdziwa motywacja organizatorów. W rezultacie moja ocena może być jednostronna. Nie wykluczam, że niektóre punkty, które wydają mi się błędne, w rzeczywistości miały taki zamiar.
W pewnym momencie czytelnik może pomyśleć, że autor po walce zdecydował się machać pięściami. Mogę jednak zapewnić, że tak nie jest. W niektórych z wymienionych hackatonów udało mi się zdobyć nagrodę, co jednak nie zmienia faktu, że wydarzenie było słabo zorganizowane.
Z szacunku dla organizatorów i uczestników, w poście nie będzie żadnych odniesień do konkretnych firm. Uważny czytelnik może się jednak domyślić (lub Google), o kim mowa.
Hackaton nr 1. Ścisłe frameworki
Sześć miesięcy temu pewna duża firma telekomunikacyjna zorganizowała hackaton poświęcony analizie danych. O pulę nagród walczyło 20 drużyn. Podczas wydarzenia udostępniono do analizy zbiór danych, który zawierał informacje o połączeniach z serwisem firmy, aktywności na portalach społecznościowych oraz zakodowane informacje o użytkownikach (płeć, wiek itp.). Najciekawsza część zbioru danych — wiadomości użytkowników i odpowiedzi operatora (dane tekstowe) — była dość zaszumiona i wymagała oczyszczenia do dalszej pracy.
Organizatorzy postawili sobie zadanie - zrobić coś ciekawego z dostarczonymi danymi, zabraniając korzystania z dodatkowych otwartych zbiorów danych z sieci lub samodzielnego analizowania danych. Zabronione było także zgłaszanie pomysłów niezwiązanych ze zbiorem danych. Niestety podane dane były dość „ubogie”: trudno było uzyskać od nich jakieś ciekawe produkty, a z komunikacji z mentorami okazało się, że wiele z zaproponowanych pomysłów jest już wdrożonych (lub będzie realizowanych w najbliższej przyszłości) w firmie.
W rezultacie przeważająca liczba zespołów (15 z 20) stworzyła chatboty. Podczas występów decyzja jednego zespołu niewiele różniła się od poprzedniej. Nie mogąc tego znieść, jeden z jurorów zapytał wchodzący na scenę kolejny zespół: „Co, chłopaki, wy też macie chatbota?” W efekcie spośród trzech nagród pierwsze i drugie miejsce przypadło zespołom, które nie tworzyły chatbotów.
Dla porównania weźmy hackaton zorganizowany przez międzynarodową firmę doradczą dla firmy Zvezdochka dwa lata temu. Ponieważ wielu uczestnikom hackatonu nieznana była specyfika działalności firmy Zvezdochka, organizatorzy już na początku wydarzenia opowiedzieli o miernikach stosowanych w firmie. Następnie udostępniono sześć zbiorów danych różnego typu: tekst, tabele, geolokalizacja – wszyscy uczestnicy mieli pole manewru. Organizatorzy nie zabraniali wykorzystywania dodatkowych zbiorów danych, a nawet wspierali takie inicjatywy. W finale konkursu o nagrodę główną rywalizowało dziesięć zespołów stosujących różne rozwiązania, przy czym wszystkie zespoły korzystały z danych dostarczonych przez firmę (mimo braku ograniczeń), co wskazywało na duży potencjał uzyskania wysokiej jakości produktów.
Moralność
Nie ma potrzeby ograniczania twórczego przepływu uczestników. Jako organizator musisz zapewnić materiały i zaufać ich wizji i profesjonalizmowi. Jeśli jesteś uczestnikiem hackatonu, wszelkie ograniczenia lub zakazy powinny Cię zaniepokoić, zazwyczaj jest to oznaką złej organizacji (przykładem z życia jest ciągła chęć wstawienia gdzieś płotu). Jeśli napotkasz ograniczenia, przygotuj się na to, że będziesz musiał stworzyć projekt w puli z dużą konkurencją. W takim przypadku jesteś zobowiązany podjąć ryzyko: zrobić coś zasadniczo nowego lub zaoferować nietypową „zabójczą funkcję”, aby wyróżnić się z potoku monotonnych projektów.
Hackaton nr 2. Zadania niemożliwe
Ciekawie zapowiadał się hackaton w Amadorze. Sponsorująca firma, duży producent telefonów, przygotowania rozpoczęła na 4 miesiące przed datą wydarzenia. PR wydarzenia prowadzony był w mediach społecznościowych, potencjalni uczestnicy musieli przejść test techniczny i opisać swoje dotychczasowe projekty, aby zostać wybrani do tego wydarzenia. Pula nagród była przyjemnie duża. Kilka dni przed hackatonem mentorzy przeprowadzili sesję techniczną, aby uczestnicy mieli czas na zrozumienie specyfiki branży.
Na samą imprezę organizatorzy udostępnili zbiór logów sprzętowych o pojemności 8 GB, zadaniem była binarna klasyfikacja awarii. Rozmawiali o kryteriach oceny projektów – jakości klasyfikacji, kreatywności w tworzeniu funkcji, umiejętności pracy w zespole itp. To po prostu pech - na 8 GB „funkcji” w pociągu było tylko 20 przykładów, a w teście 5. Gwóźdź do trumny hackatonu przyniosły dane: otrzymane w środę logi sprzętu zawierały błąd w działaniu sprzętu, natomiast te utworzone w czwartek już go nie zawierały (notabene wiedziały o tym tylko dwa zespoły, a obaj pochodzili z Rosji, ojczyzny doświadczonych eksploratorów danych). Choć nawet znajomość prawdziwych etykiet testu nie pomogła w ustaleniu odpowiedzi – zadanie było nie do rozwiązania. Organizatorom nie udało się uzyskać pożądanego rezultatu, uczestnicy spędzili dużo czasu na rozwiązywaniu źle zaprojektowanego problemu. Hackaton okazał się porażką.
Moralność
Przeprowadzaj techniczne przeglądy zadań i sprawdzaj je pod kątem adekwatności. Lepiej przepłacić za wstępne badanie (w takim przypadku każdy analityk danych od razu zwróciłby uwagę, że nie da się rozwiązać tego problemu), niż później żałować.
W tym przypadku oprócz straconego czasu i pieniędzy firma straciła wiarygodność w oczach potencjalnych kandydatów i ewentualnie napisała o wynikach. Nawiasem mówiąc, o udanych wynikach powinni pisać nie tylko uczestnicy, ale także firma, maksymalizując hackaton z PR-owego punktu widzenia. Niestety nie wszystkie firmy to robią, ograniczając się jedynie do wpisu z ogłoszeniem i kilku zdjęć z wydarzenia na Twitterze.
Hackaton nr 3. Zdecyduj sie
Ostatnio nasz zespół wziął udział w hackatonie w Amsterdamie. Ponieważ z wykształcenia jestem inżynierem elektrykiem (w zakresie odnawialnych źródeł energii), temat był dla nas w sam raz - energia. Hackaton odbył się online: otrzymaliśmy opis zadania i miesiąc na jego realizację. Organizatorom zależało na zobaczeniu gotowego projektu, który pomógłby zwiększyć efektywność energetyczną amsterdamskich domów.
Zrobiliśmy projekt w którym przewidywano zużycie prądu (wcześniej brałam udział w konkursie na ten temat gdzie otrzymałam rozwiązanie zbliżone do soty, o czym możecie przeczytać ) i wytwarzanie przez panele słoneczne. Na podstawie tych przewidywań optymalizowana jest wydajność baterii (pomysł ten częściowo zaczerpnąłem z mojej pracy magisterskiej). Nasz projekt wpisywał się zarówno w zalecenia organizatorów (jak nam się wtedy wydawało), jak i w politykę administracji Amsterdamu w zakresie odnawialnych źródeł energii na kilka kolejnych lat.
Podczas oceny projektów powiedziano nam, podobnie jak wielu zespołom, że nie tego oczekiwał klient, dodając, że jeśli chcemy walczyć o nagrodę, musimy przerobić projekt. Nic nie przerabialiśmy, godząc się na porażkę. Spośród czterdziestu uczestniczących drużyn nie znaleźliśmy się nawet w pierwszej siódemce, choć wybór organizatorów, wydaje mi się, był dość dziwny. Do finału dopuścili na przykład zespół, który stworzył aplikację do obliczania prędkości wiatru i promieniowania słonecznego (SI) z wykorzystaniem danych z czujników smartfonów: mikrofonu do pomiaru wiatru, czujnika światła do SI. Zabójczą cechą była klasyfikacja hotdogów/nie hotdogów na trzy klasy: słońce, wiatr, woda i wyświetlenie odpowiedniego artykułu w Wikipedii ().
Zostawmy na chwilę moralną stronę zagadnienia: szantażowanie uczestników możliwością zwycięstwa jest po prostu nieetyczne. Ponieważ jedną z motywacji udziału w hackatonach (szczególnie doświadczonych programistów) jest realizacja swoich pomysłów, wielu silnych uczestników po usłyszeniu takich opinii może po prostu opuścić wydarzenie (co przydarzyło się nie tylko naszemu zespołowi, ale także wielu innym osobom, które przestały aktualizacja projektu strony po wysłuchaniu mentora). Załóżmy jednak, że zgodziliśmy się z życzeniami organizatorów i przerobiliśmy nasz projekt tak, aby odpowiadał ich wymaganiom. Co może się wydarzyć dalej?
Ponieważ organizatorzy mają własne rozumienie „idealnego projektu”, wszystkie życzenia (i odpowiednio zmiany) doprowadzą nas do tego ideału. Zawodnicy zmarnują czas i coraz trudniej będzie im odmówić dalszego udziału (bo już włożyli swoje siły i wydaje się, że są już o krok od zwycięstwa). Jednak w rzeczywistości konkurencja o nagrody będzie coraz większa, a uczestnicy w nadziei na zdobycie nagrody będą musieli coraz częściej przerabiać projekt na podstawie zmian wprowadzonych przez organizatorów. W rezultacie chłopaki, którzy nie odebrali nagród, patrząc wstecz, zrozumieją, że brali udział w freelancingu bez pieniędzy: robili edity dla klienta, ale nie otrzymali za to nic w zamian (poza odpowiednim doświadczeniem, np. kurs).
Moralność
Często na pomoc w realizacji projektu przychodzą życzenia i opinie organizatorów. Jednocześnie jednak uczestnicy nie powinni polegać na radach mentorów jak kulawy na lasce. Jeśli usłyszysz od organizatorów opinie na temat Twojego projektu w duchu „zabierz to, nie zamawialiśmy tego”, Twój udział w hackatonie można uznać za zakończony.
Jeśli organizujesz hackaton z jasną wizją projektu, ale nie masz umiejętności i możliwości samodzielnego jego wdrożenia, to lepiej sformalizować swoją wizję w postaci specyfikacji technicznych dla freelancera. W przeciwnym razie będziesz musiał zapłacić podwójnie – za hackaton i za usługi freelancera.
Źródło: www.habr.com