В Preučil sem več razlogov za sodelovanje v hackathonih. Motivacija, da se naučijo veliko novega in osvojijo vredne nagrade, pritegnejo marsikoga, pogosto pa se zaradi napak organizatorjev ali sponzorskih podjetij dogodek konča neuspešno in ga udeleženci zapustijo nezadovoljni. Da bi se takšni neprijetni dogodki redkeje dogajali, sem napisal to objavo. Drugi del trilogije je posvečen napakam organizatorjev.
Prispevek je organiziran takole: na začetku spregovorim o dogodku, razložim, kaj je šlo narobe in do česa je to pripeljalo (oz. dolgoročno lahko pripelje). Nato podam svojo oceno, kaj se dogaja in kaj bi naredil, če bi bil organizator. Ker sem sodeloval na vseh dogodkih, lahko le predvidevam pravo motivacijo organizatorjev. Zaradi tega je lahko moja ocena enostranska. Ne izključujem, da so bile nekatere točke, ki se mi zdijo napačne, dejansko mišljene tako.
Na neki točki se bo bralec lahko zazdel, da se je avtor odločil zamahniti s pestmi po prepiru. Vendar vam lahko zagotovim, da temu ni tako. Na nekaterih od naštetih hackathonov mi je uspelo osvojiti nagrado, kar pa ne preprečuje, da bi rekli, da je bil dogodek slabo organiziran.
Iz spoštovanja do organizatorjev in udeležencev v objavi ne bo omembe določenih podjetij. Pozoren bralec pa lahko ugiba (ali pogugla), o kom govorimo.
Hackathon št. 1. Strogi okviri
Pred šestimi meseci je eno veliko telekomunikacijsko podjetje organiziralo hackathon o analizi podatkov. Za nagradni sklad se je potegovalo 20 ekip. Na dogodku je bil v analizo ponujen nabor podatkov, ki je vseboval podatke o klicih v podporno službo podjetja, aktivnosti na družbenih omrežjih in kodirane podatke o uporabnikih (spol, starost ipd.). Najbolj zanimiv del nabora podatkov – uporabniška sporočila in odgovori operaterja (besedilni podatki) – je bil precej šumen in ga je bilo treba očistiti za nadaljnje delo.
Organizatorji so si zadali nalogo - narediti nekaj zanimivega s posredovanimi podatki, pri čemer je bilo prepovedano uporabljati dodatne odprte nize podatkov iz omrežja ali podatke razčleniti sami. Prav tako je bilo prepovedano predlagati ideje, ki niso povezane z naborom podatkov. Žal so bili posredovani podatki precej »slabi«: težko je bilo iz njih pridobiti kakšne zanimive izdelke, iz komunikacije z mentorji pa je postalo jasno, da je marsikatera od predlaganih idej že v izvedbi (ali pa se bo v bližnji prihodnosti) v podjetju.
Posledično je ogromno ekip (15 od 20) izdelalo chatbote. Med nastopi se je odločitev ene ekipe malo razlikovala od prejšnje. Eden od članov žirije ni mogel prenesti, zato je naslednjo ekipo, ki je stopila na oder, vprašal: "Kaj, fantje, imate tudi vi chatbota?" Posledično sta od treh nagrad prvo in drugo mesto pripadli ekipi, ki nista izdelali chatbotov.
Za primerjavo vzemimo hackathon, ki ga je pred dvema letoma organiziralo mednarodno svetovalno podjetje za podjetje Zvezdochka. Ker specifika dejavnosti podjetja Zvezdochka mnogim udeležencem hackathona ni bila znana, so organizatorji na začetku dogodka spregovorili o metrikah, ki se uporabljajo v podjetju. Nato je bilo zagotovljenih šest naborov podatkov različnih vrst: besedilo, tabele, geolokacija - manevrski prostor je bil za vse udeležence. Organizatorji niso prepovedali uporabe dodatnih naborov podatkov in so takšne pobude celo podprli. V finalu tekmovanja se je za glavno nagrado potegovalo deset ekip z različnimi rešitvami, pri čemer so vse ekipe (kljub pomanjkanju omejitev) uporabljale podatke, ki jih je posredovalo podjetje, kar je kazalo na dober potencial za pridobivanje kakovostnih izdelkov.
Moralno
Ni treba omejevati ustvarjalnega toka udeležencev. Kot organizator morate zagotoviti materiale in zaupati njihovi viziji in strokovnosti. Če ste udeleženec hackathona, bi vas morale vse omejitve ali prepovedi vznemiriti, ponavadi je to dokaz slabe organizacije (primer iz resničnega življenja je nenehna želja, da bi nekam zataknili ograjo). Če naletite na omejitve, bodite pripravljeni na dejstvo, da boste morali ustvariti projekt v skupini z veliko konkurenco. V tem primeru ste dolžni tvegati: narediti nekaj bistveno novega ali ponuditi nenavadno "ubijalsko funkcijo", da bi izstopali iz toka monotonih projektov.
Hackathon št. 2. Nemogoče naloge
Hackathon v Amadorju je obetal zanimivo. Sponzorsko podjetje, velik proizvajalec telefonov, je pričelo s pripravami 4 mesece pred datumom dogodka. PR dogodka je potekal na družbenih omrežjih, potencialni udeleženci so morali opraviti tehnični preizkus in pisati o svojih preteklih projektih, da so bili izbrani za ta dogodek. Nagradni sklad je bil prijetno velik. Nekaj dni pred hackathonom so mentorji izvedli tehnično sejo, da so udeleženci imeli čas razumeti specifike panoge.
Na samem dogodku so organizatorji posredovali nabor podatkov logov opreme v obsegu 8 GB, naloga je bila binarna klasifikacija okvar. Govorili so o kriterijih za ocenjevanje projektov – kakovost razvrščanja, kreativnost pri ustvarjanju elementov, sposobnost timskega dela itd. To je samo smola - za 8 GB "funkcij" je bilo v vlaku le 20 primerkov in 5 v testu. Zadnji žebelj v krsto hackathona so zabili podatki: v sredo prejeti dnevniki opreme so vsebovali napako v delovanju opreme, tisti v četrtek pa ne (mimogrede, za to sta vedeli le dve ekipi in oba sta bila iz Rusije, domovine izkušenih rudarjev podatkov). Čeprav tudi poznavanje resničnih oznak testa ni pomagalo določiti odgovora - naloga je bila nerešljiva. Organizatorji niso dosegli želenega rezultata, udeleženci so porabili veliko časa za reševanje slabo zasnovanega problema. Hackathon je bil neuspešen.
Moralno
Izvedite tehnične preglede nalog in preverite ustreznost svojih nalog. Bolje je preplačati predhodni pregled (v tem primeru bi vsak podatkovni znanstvenik takoj poudaril, da je tega problema nemogoče rešiti), kot pa kasneje obžalovati.
V tem primeru je podjetje poleg izgubljenega časa in denarja izgubilo kredibilnost pri potencialnih kandidatih in morebiti pisalo o rezultatih. Mimogrede, o uspešnih rezultatih bi morali pisati ne le udeleženci, ampak tudi podjetje, kar bi povečalo hackathon z vidika PR. Na žalost tega ne počnejo vsa podjetja, omejijo se le na napovedno objavo in nekaj fotografij z dogodka na Twitterju.
Hackathon št. 3. Vzemi ali pusti
Nedavno se je naša ekipa udeležila hackathona v Amsterdamu. Ker sem po izobrazbi inženir elektrotehnike (s področja obnovljivih virov energije), je bila tema ravno pravšnja za nas - energija. Hackathon je potekal preko spleta: dobili smo opis naloge in mesec dni za njeno izvedbo. Organizatorji so želeli videti dokončan projekt, ki bi pripomogel k povečanju energetske učinkovitosti amsterdamskih hiš.
Naredili smo projekt, v katerem je bila predvidena poraba električne energije (pred tem sem sodeloval na natečaju na to temo, kjer sem prejel rešitev skoraj sota, o kateri si lahko preberete ) in proizvodnjo s pomočjo sončne plošče. Na podlagi teh predvidevanj se optimizira zmogljivost baterije (ta ideja je delno povzeta iz moje magistrske naloge). Naš projekt se je dobro ujemal tako z navodili organizatorjev (kot se nam je takrat zdelo) kot s politiko amsterdamske administracije na področju obnovljivih virov energije za prihodnja leta.
Med ocenjevanjem projektov so nam, tako kot mnogim ekipam, povedali, da to ni tisto, kar naročnik pričakuje, in dodali, da moramo projekt predelati, če se želimo potegovati za nagrado. Ničesar nismo ponovili, sprejeli smo poraz. Od štiridesetih sodelujočih ekip se nismo uvrstili niti med 7 najboljših, čeprav je bila izbira organizatorjev, se mi zdi, precej čudna. V finale so denimo spustili ekipo, ki je naredila aplikacijo za izračun hitrosti vetra in sončnega obsevanja (SI) s pomočjo podatkov senzorjev pametnega telefona: mikrofon za veter, senzor svetlobe za SI. Ubijalska funkcija je bila razvrstitev hotdog/ne hotdog v tri razrede: sonce, veter, voda in prikaz ustreznega članka na Wikipediji ().
Pustimo za trenutek moralno plat vprašanja: izsiljevanje udeležencev z možnostjo zmage je preprosto neetično. Ker je ena izmed motivacij za udeležbo na hackathonih (predvsem izkušenih razvijalcev) uresničitev njihovih idej, lahko marsikateri močan udeleženec preprosto zapusti dogodek, ko sliši takšne povratne informacije (kar se ni zgodilo le naši ekipi, ampak tudi številnim drugim, ki so prenehali posodabljanje projekta njihove strani po poslušanju mentorja). Kljub temu smo se, recimo, strinjali z željami organizatorjev in naš projekt predelali po njihovih željah. Kaj bi se lahko zgodilo naslednje?
Ker imamo organizatorji svoje razumevanje »idealnega projekta«, nas bodo vse želje (in s tem spremembe) vodile k temu idealu. Tekmovalci bodo izgubljali čas in vse težje bodo zavračali nadaljnje sodelovanje (saj so že vložili svoj trud, pa se zdi, da jih le še malo loči od zmage). Toda v resnici se bo konkurenca za nagrade povečala in udeleženci bodo morali vse pogosteje obnavljati projekt na podlagi popravkov organizatorjev v upanju, da bodo osvojili nagrado. Posledično bodo fantje, ki niso prejeli nagrad, ko se ozrejo nazaj, razumeli, da so sodelovali pri freelancingu brez denarja: urejali so za stranko, vendar za to niso prejeli ničesar (razen ustreznih izkušenj, tečaj).
Moralno
Projektu pogosto priskočijo na pomoč želje in povratne informacije organizatorjev. Hkrati pa naj se udeleženci ne zanašajo na nasvete mentorjev kot hrom na palico. Če od organizatorjev slišite povratne informacije o vašem projektu v duhu "odnesite, tega nismo naročili", se lahko vaša udeležba na hackathonu šteje za zaključeno.
Če organizirate hackathon z jasno vizijo projekta, vendar nimate veščin ali sposobnosti, da bi ga sami izvedli, potem je bolje, da svojo vizijo formalizirate v obliki tehničnih specifikacij za svobodnjaka. V nasprotnem primeru boste morali plačati dvakrat - za hackathon in za storitve svobodnjaka.
Vir: www.habr.com