U Razmotrio sam nekoliko razloga za sudjelovanje na hackathonima. Motivacija da se nauči mnogo novog i osvoje vrijedne nagrade privlači mnoge, ali često zbog grešaka organizatora ili kompanija-sponzora događaj završi neuspjehom i sudionici odlaze nezadovoljni. Da bi se takvi neugodnosti događali rjeđe, napisao sam ovaj post. Drugi dio trilogije posvećen je greškama organizatora.
Post je organiziran na sljedeći način: na početku govorim o događaju, objašnjavam što nije bilo u redu i do čega je to dovelo (ili može dovesti na duže staze). Zatim dajem svoju ocjenu onoga što se događa i kako bih postupio na mjestu organizatora. Budući da sam na svim događanjima nastupao kao sudionik, mogu samo pretpostavljati pravu motivaciju organizatora. Kao rezultat toga, moja ocjena može biti jednostrana. Ne isključujem da su neki aspekti koji mi se čine pogrešnima zapravo bili zamišljeni na taj način.
U određenom trenutku, čitatelju se može činiti da autor odlučuje mahati šakama nakon tuče. No, mogu vas uvjeriti da to nije slučaj. Na nekim od navedenih hackathona uspio sam osvojiti nagradno mjesto, što ipak ne sprječava da govorim o tome da je događaj bio loše organiziran.
Zbog poštovanja prema organizatorima i sudionicima, u postu neće biti navoda na konkretne kompanije. Pažljiv čitatelj, međutim, može naslutiti (ili pronaći putem pretraživača) o kome se radi.
Hackathon br. 1. Strogi okviri
Prije šest mjeseci jedna velika telekom kompanija organizirala je hackathon za analizu podataka. Za nagradni fond borilo se 20 timova. Na događaju je bio dostavljen skup podataka za analizu, koji je sadržavao informacije o pozivima u korisničku podršku kompanije, aktivnostima na društvenim mrežama i kodirane informacije o korisnicima (spol, dob itd.). Najzanimljiviji dio skupa podataka — poruke korisnika i odgovori operatora (tekstualni podaci) — bili su prilično 'bučni', za daljnji rad potrebno ih je bilo očistiti.
Organizatori su postavili zadatak - napraviti nešto zanimljivo s dostupnim podacima, pri čemu je bilo zabranjeno koristiti dodatne otvorene skupove podataka s interneta ili samostalno prikupljati podatke. Također je bilo zabranjeno predlagati ideje koje nisu bile povezane s skupom podataka. Nažalost, dostupni podaci bili su prilično "siromašni": bilo ih je teško iskoristiti za bilo kakve zanimljive proizvode, a iz razgovora s mentorima postalo je jasno da mnoge od predloženih ideja već postoje (ili će se uskoro realizirati) u tvrtki.
Kao rezultat, dominantna većina timova (15 od 20) napravila je chat-botove. Tijekom prezentacija rješenje jednog tima jedva se razlikovalo od prethodnog. Jedan član žirija, ne izdržavši, upitao je jedan od timova koji su izlazili na pozornicu: "Što, momci, i vi imate chat-bota?" Na kraju su prva i druga nagrada otišle timovima koji nisu napravili chat-botove.
Za usporedbu, uzmimo hackathon koji je organizirala međunarodna konzultantska tvrtka za firmu "Zvezdica" prije dvije godine. Budući da specifičnost djelatnosti tvrtke "Zvezdica" nije bila poznata mnogim sudionicima hackathona, na početku događaja organizatori su objasnili metrike koje se koriste u tvrtki. Nakon toga su bili predstavljeni šest skupova podataka različitih specijalizacija: tekst, tablice, geolokacija - za sve sudionike bio je prostor za manevriranje. Organizatori nisu zabranili korištenje dodatnih skupova podataka i čak su podržavali takve inicijative. Na kraju natjecanja, deset timova s različitim rješenjima borilo se za glavnu nagradu, a svi timovi iskoristili su podatke koje je pružila tvrtka (unatoč nepostojanju zabrana), što je ukazivalo na veliki potencijal za dobivanje kvalitetnih proizvoda.
Moral
Ne biste trebali ograničavati kreativni tok sudionika. Kao organizator, trebate im pružiti materijale i vjerovati njihovoj perspektivi i profesionalizmu. Ako ste sudionik hackathona, bilo kakva ograničenja ili zabrane trebala bi vas zabrinuti. Obično to ukazuje na lošu organizaciju (primjer iz stvarnog života — konstantna želja da se nekuda postavi ograda). Ako se ipak suočite s ograničenjima, budite spremni na to da ćete morati stvoriti projekt u konkurentnom okruženju. U tom slučaju morate riskirati: napraviti nešto potpuno novo ili ponuditi neobičnu "killer feature" kako biste se istaknuli iz niza jednoličnih projekata.
Hackathon br. 2. Neizvedivi zadaci
Hackathon u Amadoru obećao je biti zanimljiv. Sponzor — veliki proizvođač pametnih telefona, počeo je pripreme 4 mjeseca prije datuma održavanja. Na društvenim mrežama provodila se promocija događaja, potencijalni sudionici morali su proći tehnički ispit i napisati o svojim prethodnim projektima kako bi bili odabrani za ovo događanje. Nagradni fond bio je ugodno veliki. Nekoliko dana prije hackathona, mentori su održali tehničku sesiju kako bi sudionici imali vremena upoznati se s specifičnostima industrije.
Na samom događaju organizatori su pružili skup podataka s logovima opreme u veličini od 8 GB, zadatak — binarna klasifikacija kvarova. Razgovaralo se o kriterijima ocjenjivanja projekata — kvaliteta klasifikacije, kreativnost u stvaranju značajki, sposobnost rada u timu itd. Ipak, problem je bio u tome — od 8 GB "značajki", bilo je samo 20 primjera u treningu i 5 u testu. Konačni udarac hackathonu zadala je greška u podacima: logovi opreme dobiveni u srijedu sadržavali su grešku u radu opreme, dok oni stvoreni u četvrtak nisu sadržavali (o tome su, usput, znale samo dvije ekipe, i oboje su bile iz Rusije — dom iskusnih data miner-a). Iako je čak i poznavanje pravih oznaka testa nije pomoglo u usklađivanju odgovora — zadatak je bio nerješiv. Organizatori nisu dobili željeni rezultat, sudionici su potrošili puno vremena rješavajući loše izrađeni zadatak. Hackathon je bio propao.
Moral
Provodite tehničke ekspertize zadataka i provjeravajte svoje zadatke na adekvatnost. Bolje je preplatiti za preliminarnu ekspertizu (u ovom slučaju bi bilo koji data scientist odmah ukazao na nemogućnost rješenja ovog zadatka) nego kasnije žaliti.
U ovom slučaju, osim potrošenog vremena i novca, kompanija je izgubila kredit povjerenja od potencijalnih kandidata i moguće je pisati o rezultatima. Usput, o uspješnim rezultatima bi trebali pisati ne samo učesnici, već i kompanija, maksimalno iskorištavajući hackathon s aspekta PR-a. Nažalost, ne rade sve kompanije to, ograničavajući se samo na objavu najave i nekoliko fotografija s događaja na Twitteru.
Hackathon br. 3. Uzimaj ili ostavi
Nedavno je naš tim sudjelovao u hackathonu u Amsterdamu. Budući da sam po obrazovanju inženjer elektroenergetike (u području obnovljivih izvora energije), tema je bila upravo za nas - energetika. Hackathon se održavao u online formatu: dali su nam opis zadatka i mjesec dana za izvršenje. Organizatori su željeli vidjeti gotov projekt koji će pomoći povećanju energetske učinkovitosti kuća u Amsterdamu.
Napravili smo projekt u kojem se predviđa potrošnja električne energije (prije toga sam sudjelovao u natjecanju na tu temu gdje sam dobio približno-sota rješenje, o kojem se može pročitati ) i generacija solarne ploče. Na temelju tih predviđanja optimizira se rad baterije (ova ideja je djelomično preuzeta iz mog magistarskog rada). Naš projekt je dobro odgovarao kako zadatku od organizatora (kako se tada nama činilo), tako i politici administracije Amsterdama u području OIE za nekoliko godina unaprijed.
Tijekom ocjenjivanja projekata, nama, kao i mnogim timovima, rečeno je da to nije ono što je naručitelj očekivao, dodajući pritom da moramo prepraviti projekt ako želimo konkurirati za nagradu. Nismo ništa prepravljali, prihvativši poraz. Od četrdeset timova sudionika, nismo prošli ni u top-7, iako se izbor organizatora, čini mi se, činilo prilično čudnim. Na primjer, iz finala su izostavili tim koji je napravio aplikaciju za izračun brzine vjetra i sunčevog zračenja (SI) na temelju podataka sa pametnog telefona: mikrofon za vjetar, senzor osvjetljenja — za SI. Killer feature bila je klasifikacija hotdog/not hotdog u tri klase: Sunce, vjetar, voda i prikaz odgovarajuće stranice na Wikipediji.).
Ostavimo na trenutak moralnu stranu pitanja: ucjenjivati sudionike mogućnošću pobjede jednostavno nije etično. Budući da je jedna od motivacija sudjelovanja na hackathonima (posebno iskusnih programera) realizacija vlastitih ideja, mnogi jaki sudionici mogli bi napustiti događaj nakon takve povratne informacije (što se nije dogodilo samo s našim timom, već i s nizom drugih koji su prestali ažurirati stranicu svog projekta nakon savjetovanja s mentorom). No, pretpostavimo da smo pristali na želje organizatora i prepravili svoj projekt prema njihovim zahtjevima. Što se može dogoditi dalje?
Budući da organizatori imaju svoje razumijevanje "idealnog projekta", sve želje (i u skladu s tim promjene) usmjeravat će nas prema tom idealu. Sudionici će trošiti svoje vrijeme i bit će im sve teže i teže odustati od daljnjeg sudjelovanja (jer su već uložili napor, i čini se da je do pobjede ostalo samo malo). No, u stvarnosti, konkurencija za nagrade će rasti, a sudionici će sve češće morati prepraviti projekt prema izmjenama organizatora u nadi da će dobiti nagradu. Na kraju, dečki koji nisu osvojili nagradu, osvrćući se unatrag, shvatit će da su sudjelovali u freelancerskom radu bez plaće: unosili su izmjene naručitelja, ali pritom nisu dobili ništa zauzvrat (osim tog iskustva naravno).
Moral
Često želje i povratne informacije od organizatora dolaze u pomoć projektu. Međutim, učesnici ne bi trebali oslanjati se na savete mentora kao što slabi zavise o štapu. Ako od organizatora čujete povratne informacije o vašem projektu u duhu "uklonite, mi to nismo tražili" — vaše učešće na hackathonu se može smatrati završеним.
Ako organizujete hackathon sa jasnom vizijom projekta, ali bez veština ili mogućnosti da ga realizujete sami, bolje je da svoje viđenje oblikujete u tehničku specifikaciju za freelancera. U suprotnom, moraćete platiti dvostruko — za hackathon i za usluge freelancera.
Izvor: habr.com
