I jeg har overvejet flere grunde til at deltage i hackathoner. Motivation for at lære meget nyt og vinde værdifulde præmier tiltrækker mange, men ofte slutter arrangementet dårligt på grund af fejl fra arrangørerne eller sponsorvirksomhederne, hvilket efterlader deltagerne utilfredse. For at sådanne ubehagelige tilfælde sker sjældnere, har jeg skrevet dette indlæg. Den anden del af trilogien handler om fejl fra arrangørerne.
Indlægget er organiseret på følgende måde: først fortæller jeg om arrangementet, forklarer hvad der gik galt og hvad det førte til (eller kan føre til på lang sigt). Derefter giver jeg min vurdering af situationen, og hvordan jeg ville handle, hvis jeg var arrangør. Da jeg kun har deltaget i alle arrangementer, kan jeg kun antage den ægte motivation bag arrangørerne. Derfor kan min vurdering ende med at være ensidig. Jeg udelukker ikke, at nogle punkter, som jeg ser som fejlagtige, faktisk var planlagt sådan.
På et bestemt tidspunkt kan læseren få indtryk af, at forfatteren har besluttet at vifte med næverne efter et slagsmål. Men jeg kan forsikre dig om, at det ikke er tilfældet. I nogle af de nævnte hackathoner lykkedes det mig at opnå en præmieplads, hvilket dog ikke forhindrer mig i at sige, at arrangementet var dårligt organiseret.
Af respekt for arrangørerne og deltagerne vil der ikke blive nævnt specifikke virksomheder i indlægget. Den opmærksomme læser kan dog gætte (eller Google) hvilke virksomheder der tales om.
Hackathon nr. 1. Strenge rammer
For seks måneder siden organiserede en stor telekomvirksomhed et hackathon om dataanalyse. 20 hold kæmpede om præmiefonden. På arrangementet blev der stillet et datasæt til rådighed til analyse, som indeholdt oplysninger om henvendelser til virksomhedens kundeservice, aktivitet på sociale medier og kodede oplysninger om brugerne (køn, alder osv.). Den mest interessante del af datasættet — beskeder fra brugerne og svar fra operatoren (tekstdata) — var ret "støjfyldt"; den skulle renses for at kunne bruges videre.
Arrangørerne fik til opgave at lave noget interessant med de givne data, og det var forbudt at bruge ekstra åbne datasæt fra nettet eller selv at scrape data. Det var også forbudt at foreslå idéer, der ikke var relateret til datasættet. Desværre var de givne data ret "fattige": det var svært at få interessante produkter ud af dem, og fra samtalerne med mentorerne blev det klart, at mange af de foreslåede idéer allerede faktisk bliver implementeret (eller vil blive implementeret i den nærmeste fremtid) i virksomheden.
Som et resultat lavede det overvældende flertal af hold (15 ud af 20) chatbots. Under præsentationerne var løsningen fra ét hold knap forskellige fra den forrige. Uden at kunne holde sig tilbage spurgte et af dommerne det næste hold, der kom op på scenen: "Hvad, drenge, har I også en chatbot?" I sidste ende gik første og anden plads til hold, der ikke lavede chatbots.
Til sammenligning kan vi tage hackathonet, der blev organiseret af et internationalt konsulentfirma for virksomheden "Zvezdochka" for to år siden. Da mange deltagere ikke var bekendt med virksomhedens specifikke aktiviteter, informerede arrangørerne i starten af arrangementet om de målinger, der bruges i virksomheden. Derefter blev der præsenteret seks datasæt af forskellig art: tekst, tabeller, geolocation - for alle deltagere var der frihed til at navigere. Arrangørerne forbød ikke brugen af yderligere datasæt og støttede faktisk sådanne initiativer. I finalen kæmpede ti hold med forskellige løsninger om hovedprisen, og alle hold brugte de data, der blev præsenteret af virksomheden (på trods af manglen på forbud), hvilket vidner om et godt potentiale for at opnå kvalitetsprodukter.
Moral
Det er vigtigt ikke at begrænse deltagernes kreative strøm. Som arrangør skal du give materialer og stole på deres perspektiv og professionalisme. Hvis du deltager i hackathonen, skal enhver form for begrænsninger eller forbud vække din mistanke. Det er typisk et tegn på dårlig organisation (et eksempel fra det virkelige liv er det konstante ønske om at sætte hegn op et eller andet sted). Men hvis du alligevel støder på begrænsninger, skal du være forberedt på, at du skal skabe et projekt i et miljø med hård konkurrence. I så fald er du nødt til at tage risici: gøre noget fundamentalt nyt eller foreslå en usædvanlig
Hackathon nr. 2. Urealiserbare opgaver
Hackathonen i Amador lovede at blive interessant. Sponsoren, en stor telefonproducent, begyndte forberedelserne fire måneder før arrangementet. Der blev lavet PR for eventen på sociale medier, og potentielle deltagere skulle gennemføre en teknisk test og skrive om deres tidligere projekter for at blive udvalgt til dette event. Præmiepuljen var behageligt stor. Et par dage før hackathonen afholdt mentorerne en teknisk session, så deltagerne havde tid til at sætte sig ind i branchens specifikationer.
Ved selve arrangementet gav arrangørerne et datasæt med logfiler på 8 GB, og opgaven var binær klassificering af fejl. De fortalte om kriterierne for vurdering af projekterne — kvaliteten af klassificeringen, kreativiteten i at skabe funktioner, evnen til at arbejde i team, osv. Men der var et problem — ud af 8 GB “funktioner” var der kun 20 eksempler i træningssættet og 5 i testset. Den endelige spiker i kisten til hackathonen blev slået af fejlinformation: logfilerne, som blev indsamlet om onsdagen, indeholdt fejl i udstyrets funktion, mens dem der blev indsamlet om torsdagen ikke gjorde. (Bare for at nævne det, vidste kun to hold dette, og begge var fra Rusland — hjemland for erfarne dataminere). Selvom viden om de sande etiketter til testen ikke hjalp med at finde svaret — opgaven var uløselig. Arrangørerne fik ikke det ønskede resultat, og deltagerne brugte en masse tid på at løse en dårligt sammensat opgave. Hackathonen var en fiasko.
Moral
Udfør tekniske ekspertvurderinger af opgaver og kontroller, om dine opgaver er rimelige. Det er bedre at betale for en forudgående vurdering (i dette tilfælde ville enhver dataspecialist straks have påpeget, at det er umuligt at løse denne opgave), end at fortryde senere.
I dette tilfælde har virksomheden, udover den tid og de penge, der er brugt, mistet tillid fra potentielle kandidater og måske ikke kan rapportere om resultaterne. For øvrigt skal ikke kun deltagerne skrive om succesfulde resultater, men også virksomheden, for maksimalt at realisere hackathonet set fra et PR-perspektiv. Desværre gør ikke alle virksomheder dette, og begrænser sig kun til et anoncepost og et par billeder fra arrangementet på Twitter.
Hackathon nr. 3. Tag det eller lad det være.
For nylig deltog vores team i et hackathon i Amsterdam. Da jeg er uddannet ingeniør i elektroenergi (inden for vedvarende energikilder), var emnet lige i vores boldgade — energi. Hackathonet blev afholdt online: vi fik en opgavebeskrivelse og en måned til at udføre den. Arrangørerne ønskede at se et færdigt projekt, der kan øge energieffektiviteten i Amsterdam.
Vi lavede et projekt, hvor elforbruget forudsiges (tidligere deltog jeg i en konkurrence om dette emne, hvor jeg fik en omtrentlig løsning, som man kan læse om ) og solpanelgenerering. Baseret på disse forudsigelser optimeres driften af batteriet (denne idé blev delvist taget fra mit kandidatprojekt). Vores projekt harmonerede godt med opgaven fra arrangørerne (som vi troede dengang) og med politikken fra Amsterdams administration vedrørende VE i flere år frem.
Under evaluering af projekter blev vi, ligesom mange andre hold, fortalt, at det ikke var, hvad kunden havde forventet, og de tilføjede, at vi skulle omarbejde projektet, hvis vi ville kæmpe om præmierne. Vi valgte ikke at ændre noget og accepterede vores nederlag. Af de fyrre deltagerhold kom vi ikke engang i top 7, selvom valget af arrangørerne, efter min mening, var ret underligt. For eksempel udvalgte de et hold, der havde lavet en app til beregning af vindhastighed og solindstråling (SI) baseret på smartphone-sensorer: mikrofon til vind og lysføler til SI. Killer-featuret var klassifikationen hotdog/not hotdog i tre kategorier: Sol, vind, vand, og visning af den relevante artikel i Wikipedia.).
Lad os på et tidspunkt lægge den moralske side af spørgsmålet til side: at true deltagere med muligheden for at vinde er bare ikke etisk. Da en af motivationerne for at deltage i hackathons (især for erfarne udviklere) er implementeringen af deres ideer, kan mange stærke deltagere simpelthen forlade arrangementet, når de hører sådan feedback (hvilket ikke kun skete med vores hold, men også med flere andre, som stoppe med at opdatere deres projektside efter at have lyttet til mentoren). Men lad os antage, at vi gik med arrangørernes ønsker og omarbejdede vores projekt til deres krav. Hvad kan der så ske videre?
Da arrangørerne har deres egen opfattelse af det 'ideelle projekt', vil alle ønsker (og dermed ændringer) føre os mod denne ideal. Deltagerne vil bruge deres tid, og det vil blive sværere og sværere for dem at trække sig fra yderligere deltagelse (da de allerede har investeret kræfter og synes, at de næsten er ved at vinde). Men i virkeligheden vil konkurrencen om præmierne stige, og deltagerne vil oftere skulle omarbejde projektet efter arrangørernes feedback i håbet om at modtage en pris. Til sidst vil de, der ikke har vundet præmier, se tilbage og indse, at de har deltaget i et freelance-projekt uden betaling: de har lavet ændringer efter kundens ønsker, men har ikke fået noget som helst i bytte (bortset fra den erfaring, selvfølgelig).
Moral
Ofte kommer ønsker og feedback fra arrangørerne projektet til gode. Deltagerne bør dog ikke stole på mentorer som en handicappet på en krykke. Hvis du hører feedback fra arrangørerne om dit projekt i stil med "fjern det, vi har ikke bestilt det" - kan du betragte dit deltagelse i hackathonet som afsluttet.
Hvis du organiserer et hackathon med en klar vision for projektet, men uden evnerne eller mulighederne for at implementere det selv, så er det bedst at formulere din vision som en teknisk specifikation til en freelancer. Ellers risikerer du at betale to gange - for hackathonet og for freelancerens tjenester.
Kilde: habr.com
