V Размотрим неколико разлога за учешће у хакатонима. Мотивација да сазнамо много новог и освојимо вредне награде привлачи многе, али често због грешака организатора или спонзора догађаји завршавају неуспешно и учесници одлазе незадовољни. Како би такви непријатни случајеви били ређи, написао сам овај пост. Друга част трилогије посвећена је грешкама организатора.
Пост је организован овако: на почетку говорим о догађају, објашњавам шта је пошло наопако и до чега је то довело (или може довести у дугом року). Затим дајем своју процену ситуације и како бих ја поступио да сам на месту организатора. Пошто сам на свим догађајима учествовао као учесник, могу само да нагађам истинску мотивацију организатора. У том смислу, моја процена може бити једнострана. Не искључујем да су неки аспекти који ми изгледају грешно, у ствари, били тако замишљени.
У неком тренутку, читаоцу може изгледати као да је аутор одлучио да махне шаком после туке. Али могу вас уверити да то није случај. У неким од наведених хакатона успео сам да освојим награду, што, ипак, не спречава да говорим о томе да је догађај био лоше организован.
Из поштовања према организаторима и учесницима, у посту неће бити назнака на конкретне компаније. Внимљиви читалац, међутим, може да нагађа (или пронађе на интернету) о коме се ради.
Хакатон бр. 1. Строге рамке
Пре шест месеци, једна велика телекомуникациона компанија организовала је хакатон за анализу података. За нагодни фонд борило се 20 тимова. На догађају је био доступан сет података за анализу, који је садржао информације о позивима у службу подршке компаније, активности на друштвеним мрежама и кодиране информације о корисницима (пол, старост итд). Најзанимљивији део скупа података — поруке корисника и одговори оператора (текстуални подаци) — били су релативно „шумни“, те је требало очистити за даље обраде.
Organizatorji so postavili nalogo, da naredijo kaj zanimivega s ponujenimi podatki, pri čemer je bilo prepovedano uporabljati dodatne odprte podatkovne nize iz spleta ali samostojno pridobivati podatke. Prav tako ni bilo dovoljeno predlagati idej, ki niso povezane z podatkovnim nizom. Na žalost so bili ponujeni podatki precej "revni": iz njih je bilo težko pridobiti kakršne koli zanimive izdelke, iz komunikacije z mentorji pa je postalo jasno, da se mnoge predlagane ideje že izvajajo (ali se bodo v bližnji prihodnosti) v podjetju.
Zaradi tega je prevladovalo število ekip (15 od 20), ki so naredile klepetalne robote. Med predstavitvami je bila rešitev ene ekipe malo neprepoznavna od prejšnje. Brez natančnosti je eden od članov žirije vprašal ekipo, ki je stopila na oder: "Kaj, fantje, imate tudi vi klepetalnega robota?" Na koncu sta prva in druga mesta pripadla ekipama, ki nista izdelali klepetalnih robotov.
Za primerjavo vzemimo hackathon, ki ga je organizirala mednarodna svetovalna družba, za podjetje "Zvezdica" pred dvema letoma. Ker specifičnost delovanja podjetja "Zvezdica" ni bila znana mnogim udeležencem hackathona, so organizatorji na začetku dogodka predstavili metrike, ki se uporabljajo v podjetju. Po tem so bili predstavljeni trije različni podatkovni nizi: besedila, tabele, geolokacijska mesta — za vse udeležence je bil prostor za manevriranje. Organizatorji niso prepovedovali uporabe dodatnih podatkovnih nizov in so celo podpirali take pobude. Na finalu tekmovanja je deset ekip z različnimi rešitvami tekmovalo za glavno nagrado, pri čemer so vse ekipe uporabljale podatke, predstavljene s strani podjetja (kljub odsotnosti prepovedi), kar je dokazovalo dober potencial za pridobivanje kakovostnih izdelkov.
Morala
Ni uresničevanje ustvarjalnosti udeležencev. Kot organizator morate zagotoviti materiale ter zaupati njihovemu pogledu in profesionalizmu. Če ste udeleženec hackathona, vas morejo zaskrbeti kakršne koli omejitve ali prepovedi. Običajno to pomeni slabo organizacijo (primer iz resničnega življenja — stalna želja po postavljanju ograd). Če pa se kljub temu srečate z omejitvami, bodite pripravljeni na to, da boste morali ustvariti projekt v zelo konkurenčnem okolju. V tem primeru ste dolžni tvegati: narediti nekaj načeloma novega ali ponuditi nenavadno “killer feature”, da se ločite od morja enoličnih projektov.
Hackathon #2. Neizvedljive naloge
Hackathon v Amadorju je obetal biti zanimiv. Sponzorska podjetje — velika proizvodnja telefonov, je začela s pripravami 4 mesece pred datumom dogodka. V družbenih omrežjih je potekala promocija dogodka, potencialni udeleženci so morali opraviti tehnični test in predstaviti pretekle projekte, da bi bili izbrani za to dogodivo. Nagradni sklad je bil prijetno velik. Nekaj dni pred hackathonom, so mentorji izvedli tehnično sejo, da bi imeli udeleženci čas, da se prepustijo specifikam panoge.
Na samem dogodku so organizatorji zagotovili niz podatkov s 8 GB dnevnikov opreme, naloga pa je bila binarna klasifikacija okvar. Povedali so o merilih ocenjevanja projektov — kakovost klasifikacije, ustvarjalnost pri ustvarjanju funkcij, sposobnost dela v ekipi itd. Vendar je bila težava — med 8 GB “funkcijami” je bilo le 20 primerov v trening naboru in 5 v testu. Končni žebelj v krsto hackathona je zabila napaka v podatkih: dnevniki opreme, pridobljeni v sredo, so vsebovali napako pri delovanju opreme, medtem ko so tisti, ustvarjeni v četrtek — niso imeli napake (o tem so, mimogrede, vedeli le dve ekipi, in obe sta bili iz Rusije — rojstna država izkušenih podatkovnih rudarjev). Čeprav je celo poznavanje pravih oznak testa ni pomagalo prilagoditi odgovora — naloga je bila nerešljiva. Organizatorji niso dosegli želenega rezultata, udeleženci so porabili ogromno časa, reševalni slabo sestavljeno nalogo. Hackathon je propadel.
Morala
Izvršite tehničke ekspertize zadataka i proverite svoje zadatke na adekvatnost. Bolje je platiti više za preliminarnu ekspertizu (u ovom slučaju bi svaki data naučnik odmah ukazao na nemogućnost rešenja ovog zadatka) nego kasnije da žalite.
U ovom slučaju, pored potrošenog vremena i novca, kompanija je izgubila kredibilitet od potencijalnih kandidata i moguće je napisati o rezultatima. Usput, o uspešnim rezultatima treba da pišu ne samo učesnici, već i kompanija, maksimalno iskoristivši hackathon sa stanovišta PR-a. Nažalost, ne rade sve kompanije to, ograničavajući se samo na post-annonce i nekoliko fotografija sa događaja na Tviteru.
Hackathon br. 3. Uzmite ili ostavite.
Nedavno je naš tim učestvovao na hackathonu u Amsterdamu. Obzirom da sam po obrazovanju inženjer elektroenergetike (u oblasti obnovljivih izvora energije), tema je bila savršena za nas - energetika. Hackathon se održavao online: dobili smo opis zadatka i mesec dana za izvršenje. Organizatori su želeli da vide gotov projekat koji će pomoći u povećanju energetske efikasnosti kuća u Amsterdamu.
Napravili smo projekat u kojem se predviđa potrošnja električne energije (pre toga sam učestvovao na takmičenju na ovu temu gde sam dobio oko-sota rešenje, o kojem možete pročitati ) i generacija solarne energije. Na osnovu ovih predviđanja optimizuje se rad akumulatorske baterije (ova ideja je delimično preuzeta iz mog master rada). Naš projekat je dobro odgovarao kako zadatku od organizatora (kako nam se tada činilo), tako i politici uprave Amsterdama u oblasti OIE na nekoliko godina unapred.
Med oceno projektov so nam, tako kot mnogim ekipam, povedali, da to ni bilo tisto, kar je naročnik pričakoval, pri čemer so dodali, da moramo projekt predelati, če se želimo potegovati za nagrade. Nismo predelali ničesar in smo se sprijaznili s porazom. Od štiridesetih sodelujočih ekip nismo prišli niti v top-7, čeprav se mi zdi, da je bil izbor organizatorjev precej nenavaden. Na primer, spustili so ekipo v finale, ki je naredila aplikacijo za izračun hitrosti vetra in sončnega sevanja (SI) na podlagi podatkov senzorjev pametnega telefona: mikrofonom za veter, senzorjem svetlobe za SI. Ključna funkcija je bila klasifikacija hotdog/not hotdog v tri razrede: Sonce, veter, voda in prikaz ustreznega članka na Wikipediji.).
Pustimo ob strani moralno plat vprašanja: šantžirati udeležence z možnostjo zmage je preprosto neetično. Ker je ena od motivacij za udeležbo na hackathonih (še posebej pri izkušenih razvijalcih) uresničitev njihovih zamisli, lahko mnogi močni udeleženci preprosto zapustijo dogodek, ko slišijo tovrstno povratno informacijo (kar se je zgodilo ne samo naši ekipi, ampak tudi številnim drugim, ki so prenehale posodabljati stran svojega projekta po poslušanju mentorja). Kljub temu predpostavimo, da smo se strinjali z željami organizatorjev in predelali svoj projekt po njihovih zahtevah. Kaj se lahko zgodi naprej?
Ker organizatorji imajo svoje razumevanje 'idealan projekt', nas bodo vse želje (in ustrezne spremembe) vodile k temu idealu. Tekmovalci bodo izgubljali čas in vse težje se bodo odrekli nadaljnji udeležbi (saj so že vložili trud in se zdi, da je do zmage le malo). V resnici pa bo konkurenca za nagrade naraščala in udeleženci bodo morali vedno pogosteje predelati projekt po popravkih organizatorjev v upanju na nagrado. Na koncu bodo fantje, ki niso zasedli nagradnih mest, pogledali nazaj in ugotovili, da so sodelovali v brezplačnem delu brez denarja: vnašali so popravke naročnika, toda za to niso prejeli ničesar v zameno (razen seveda ustrezne izkušnje).
Morala
Pogosto želje in povratne informacije organizatorjev pomagajo projektu. Vendar pa se udeleženci ne bi smeli zanašati na nasvete mentorjev, kot da bi se opirali na berglo. Če slišite od organizatorjev povratno informacijo o vašem projektu v smislu 'odstranite, tega nismo naročili' — vaše sodelovanje na hackathonu se lahko šteje za zaključeno.
Če organizirate hackathon s jasno vizijo projekta, a brez znanja ali možnosti, da ga izvedete sami, je bolje, da svojo vizijo oblikujete v tehnično specifikacijo za freelancerja. V nasprotnem primeru boste morali plačati dvakrat — za hackathon in za storitve freelancerja.
Izvor: habr.com
