В Jeg har overvejet flere grunde til at deltage i hackathons. Motivationen til at lære en masse nyt og vinde værdifulde præmier tiltrækker mange, men ofte på grund af arrangørers eller sponsorvirksomheders fejl, slutter arrangementet uden held, og deltagerne går utilfredse ud. For at sådanne ubehagelige tilfælde opstår sjældnere, skrev jeg dette indlæg. Anden del af trilogien er afsat til arrangørernes fejltagelser.
Indlægget er organiseret på følgende måde: I starten taler jeg om begivenheden, forklarer, hvad der gik galt, og hvad det førte til (eller kunne føre til på længere sigt). Så giver jeg min vurdering af, hvad der sker, og hvad jeg ville gøre i arrangørernes sted. Da jeg deltog i alle arrangementer som deltager, kan jeg kun gå ud fra arrangørernes sande motivation. Som følge heraf kan min vurdering vise sig at være ensidig. Jeg udelukker ikke, at nogle punkter, som jeg ser som fejlagtige, faktisk var beregnet til at være det.
På et tidspunkt kan det se ud for læseren, at forfatteren har besluttet sig for at slå næverne efter kampen. Men det kan jeg forsikre dig om, at det ikke er. I nogle af de listede hackathons lykkedes det mig at tage en præmie, hvilket dog ikke forhindrer os i at sige, at arrangementet var dårligt organiseret.
På grund af respekt for arrangører og deltagere vil der ikke være referencer til specifikke virksomheder i opslaget. En opmærksom læser kan dog gætte (eller google), hvem der diskuteres.
Hackathon nummer 1. Strenge rammer
For seks måneder siden arrangerede et stort teleselskab et dataanalyse-hackathon. 20 hold kæmpede om præmiefonden. Ved arrangementet blev der udleveret et datasæt til analyse, som indeholdt information om opkald til virksomhedens supporttjeneste, aktivitet på sociale netværk og indkodet information om brugere (køn, alder mv.). Den mest interessante del af datasættet - brugerens beskeder og operatørens svar (tekstdata) - var ret "støjende", det skulle ryddes op til videre arbejde.
Arrangørerne stillede opgaven - at gøre noget interessant med de leverede data, og det var forbudt at bruge yderligere åbne datasæt fra netværket eller selv parse dataene. Det var også forbudt at tilbyde ideer, der ikke var relateret til datasættet. Desværre var de leverede data ret "dårlige": det var svært at få nogle interessante produkter fra dem, og fra kommunikation med mentorer blev det klart, at mange af de foreslåede ideer allerede er ved at blive implementeret (eller vil blive implementeret i den nærmeste fremtid) i virksomheden.
Som et resultat lavede langt de fleste teams (15 ud af 20) chatbots. Under forestillingerne var beslutningen fra et hold lidt anderledes end det forrige. Ude af stand til at holde det ud, spurgte et af jurymedlemmerne det næste hold, der kom ind på scenen: "Hvad, gutter, har I også en chatbot?". Som følge heraf gik første- og andenpladsen ud af tre præmier til de hold, der ikke begyndte at lave chatbots.
Til sammenligning, lad os tage et hackathon arrangeret af et internationalt konsulentfirma for Zvezdochka for to år siden. Da detaljerne i Zvezdochkas aktiviteter ikke var velkendte for mange hackathon-deltagere, talte arrangørerne i begyndelsen af begivenheden om de målinger, der bruges i virksomheden. Derefter blev der leveret seks datasæt af forskellige retninger: tekst, tabeller, geolokationer - der var råderum for alle deltagere. Arrangørerne forbød ikke brugen af yderligere datasæt og støttede endda sådanne initiativer. I finalen i konkurrencen dystede ti hold med forskellige løsninger om hovedpræmien, hvor alle hold brugte data fra virksomheden (på trods af fraværet af forbud), hvilket indikerede et godt potentiale for at opnå kvalitetsprodukter.
moral
Begræns ikke deltagernes kreative flow. Som arrangør skal du levere materialer og stole på deres vision og professionalisme. Hvis du er en hackathon-deltager, bør eventuelle restriktioner eller forbud advare dig. Normalt er dette et bevis på dårlig organisation (et virkeligt eksempel er det konstante ønske om at stikke et hegn et sted). Hvis du alligevel løber ind i restriktioner, så vær forberedt på, at du bliver nødt til at lave et projekt i en pulje med stor konkurrence. I dette tilfælde skal du tage risici: gøre noget grundlæggende nyt eller tilbyde en usædvanlig "dræberfunktion" for at skille dig ud fra strømmen af monotone projekter.
Hackathon #2. Umulige opgaver
Hackathonet i Amadora lovede at blive interessant. Det sponsorerende firma, en stor telefonproducent, begyndte forberedelserne 4 måneder før datoen for begivenheden. PR af begivenheden blev udført i sociale netværk, potentielle deltagere skulle bestå en teknisk test og skrive om deres tidligere projekter for at blive udvalgt til denne begivenhed. Præmiefonden var behagelig stor. Et par dage før hackathonet holdt mentorerne en teknisk session, så deltagerne havde tid til at mærke branchens detaljer.
Ved selve arrangementet leverede arrangørerne et 8 GB datasæt af udstyrslogfiler, opgaven var en binær klassificering af nedbrud. De talte om kriterierne for at evaluere projekter - kvaliteten af klassificeringen, kreativiteten ved at skabe funktioner, evnen til at arbejde i et team osv. Det er bare uheld - for 8 GB "features" var der kun 20 eksempler i toget og 5 i testen. Det sidste søm i hackathonets kiste blev drevet af en læk i data: Udstyrsloggene, der blev modtaget i onsdags, indeholdt en fejl i betjeningen af udstyret, og dem, der blev oprettet i torsdags, gjorde det ikke (forresten, kun to hold vidste om dette, og begge var fra Rusland, erfarne dataminers hjemland). Selv om selv at kende testens sande etiketter ikke hjalp med at justere svaret - var opgaven uløselig. Arrangørerne fik ikke det ønskede resultat, deltagerne brugte meget tid på at løse et dårligt formuleret problem. Hackathonet mislykkedes.
moral
Foretag tekniske gennemgange af opgaver og tjek dine opgaver for tilstrækkelighed. Det er bedre at betale for meget for en foreløbig undersøgelse (i dette tilfælde vil enhver dataforsker straks påpege, at det er umuligt at løse dette problem) end at fortryde senere.
I dette tilfælde, ud over spildtid og penge, mistede virksomheden troværdighed fra potentielle kandidater og muligvis skrive om resultaterne. Forresten skal ikke kun deltagere skrive om succesfulde resultater, men også virksomheden, implementere hackathon så meget som muligt med hensyn til PR. Desværre er det ikke alle virksomheder, der gør dette, og begrænser sig til kun en post-annoncering og et par billeder fra begivenheden på Twitter.
Hackathon #3. tag den eller lad den være
Senest deltog vores hold i et hackathon i Amsterdam. Da jeg er el-ingeniør af uddannelse (inden for vedvarende energikilder), var emnet kun for os - energi. Hackathonet blev afholdt online: vi fik en opgavebeskrivelse og en måned til at udføre. Arrangørerne ønskede at se et færdigt projekt, der ville være med til at øge energieffektiviteten i Amsterdams huse.
Vi lavede et projekt, der forudsiger elforbrug (inden da deltog jeg i en konkurrence om dette emne, hvor jeg modtog en near-sota løsning, som du kan læse om ) og generering af et solpanel. Baseret på disse forudsigelser optimeres batteriydelsen (denne idé er delvist hentet fra min kandidatafhandling). Vores projekt var i god overensstemmelse både med opgaven fra arrangørerne (som det så ud for os dengang), og med Amsterdam-administrationens politik på området for vedvarende energi i flere år fremover.
Under evalueringen af projekter fik vi ligesom mange teams at vide, at det ikke var, hvad kunden forventede, samtidig med at vi var nødt til at lave projektet om, hvis vi ville konkurrere om prisen. Vi ændrede ikke noget, resignerede for at besejre. Af de 7 deltagende hold nåede vi ikke engang til top XNUMX, selvom valget af arrangører, synes jeg, var ret mærkeligt. For eksempel gik de glip af det endelige hold, som lavede en applikation til beregning af vindhastighed og solstråling (SI) ved hjælp af smartphone-sensorer: en mikrofon til vinden, en lyssensor til SI. Den dræberfunktion var klassificeringen af hotdog / ikke hotdog i tre klasser: Sol, vind, vand og visning af den tilsvarende Wikipedia-artikel ().
Lad os forlade den moralske side af sagen et øjeblik: At afpresse deltagere med muligheden for at vinde er simpelthen uetisk. Da en af motivationerne for at deltage i hackathons (især erfarne udviklere) er at implementere deres ideer, kan mange stærke deltagere simpelthen forlade begivenheden efter at have hørt sådan feedback (hvilket skete ikke kun med vores team, men også med en række andre, der stoppede opdatere deres side). projekt efter at have lyttet til mentoren). Lad os alligevel sige, at vi var enige i arrangørernes ønsker og redesignede vores projekt for at opfylde deres krav. Hvad kan der ske næste gang?
Da arrangørerne har deres egen forståelse af det "ideelle projekt", vil alle ønsker (og følgelig ændringer) føre os til dette ideal. Deltagerne vil spilde deres tid, og det bliver mere og mere vanskeligt for dem at nægte yderligere deltagelse (da der allerede er investeret kræfter, og det ser ud til, at der er meget lidt før sejren). Men i virkeligheden vil konkurrencen om præmier øges, og deltagerne skal i stigende grad bearbejde projektet med rettelser fra arrangørerne i håbet om at vinde en præmie. Som et resultat vil de fyre, der ikke tog præmier, når de ser tilbage, indse, at de deltog i freelancing uden penge: de foretog ændringer til kunden, men modtog samtidig ikke noget til gengæld for dette (bortset fra de tilsvarende erfaring, selvfølgelig).
moral
Ofte kommer ønsker og feedback fra arrangørerne til hjælp for projektet. Ved at gøre det bør deltagerne dog ikke stole på råd fra mentorer som en halt mand på en stok. Hvis du hører feedback fra arrangørerne om dit projekt i ånden "fjern det, vi har ikke bestilt det" - kan din deltagelse i hackathon betragtes som afsluttet.
Hvis du arrangerer et hackathon med en klar vision om projektet, men uden evner eller evner til selv at implementere det, så er det bedre at formatere din vision i form af en freelancers kommissorium. Ellers skal du betale to gange - for hackathonet og for en freelancers tjenester.
Kilde: www.habr.com