В Jeg har sett på flere grunner til å delta i hackathons. Motivasjonen for å lære mye nytt og vinne verdifulle premier tiltrekker seg mange, men ofte, på grunn av feil fra arrangørene eller sponsorselskapene, avsluttes arrangementet uten hell og deltakerne går misfornøyde. For å få slike ubehagelige hendelser til å skje sjeldnere, skrev jeg dette innlegget. Den andre delen av trilogien er dedikert til arrangørenes feil.
Innlegget er organisert slik: i begynnelsen snakker jeg om hendelsen, forklarer hva som gikk galt og hva det førte til (eller kan føre til på sikt). Så gir jeg min vurdering av hva som skjer, og hva jeg ville gjort hvis jeg var arrangørene. Siden jeg deltok på alle arrangementene, kan jeg bare anta den sanne motivasjonen til arrangørene. Som et resultat kan min vurdering være ensidig. Jeg utelukker ikke at noen punkter som virker feilaktige for meg faktisk var ment på den måten.
På et visst tidspunkt kan leseren tenke at forfatteren bestemte seg for å vifte med knyttnevene etter en kamp. Men jeg kan forsikre deg om at dette ikke er tilfelle. I noen av de listede hackathonene klarte jeg å ta en premie, noe som imidlertid ikke hindrer oss i å si at arrangementet var dårlig organisert.
Av respekt for arrangører og deltakere vil det ikke være referanser til spesifikke selskaper i innlegget. En oppmerksom leser kan imidlertid gjette (eller Google) hvem vi snakker om.
Hackathon nr. 1. Strenge rammer
For seks måneder siden arrangerte et stort telekomselskap et hackathon om dataanalyse. 20 lag konkurrerte om premiefondet. På arrangementet ble det levert et datasett for analyse, som inneholdt informasjon om oppringninger til selskapets støttetjeneste, aktivitet på sosiale nettverk og kodet informasjon om brukere (kjønn, alder osv.). Den mest interessante delen av datasettet – brukermeldinger og operatørsvar (tekstdata) – var ganske støyende og måtte renses for videre arbeid.
Arrangørene satte en oppgave - å gjøre noe interessant med de oppgitte dataene, og det var forbudt å bruke flere åpne datasett fra nettverket eller analysere dataene selv. Det var også forbudt å foreslå ideer som ikke var relatert til datasettet. Dessverre var dataene som ble levert ganske "dårlige": det var vanskelig å få noen interessante produkter fra dem, og fra kommunikasjon med mentorer ble det klart at mange av de foreslåtte ideene allerede blir implementert (eller vil bli implementert i nær fremtid) i selskapet.
Som et resultat laget det overveldende antall lag (15 av 20) chatbots. Under forestillingene var avgjørelsen til ett lag litt annerledes enn det forrige. Ute av stand til å bære det, spurte et av jurymedlemmene det neste laget som tok scenen: «Hva, gutter, har dere også en chatbot?» Som et resultat, av tre premier, gikk første- og andreplassen til lagene som ikke laget chatbots.
Til sammenligning, la oss ta et hackathon organisert av et internasjonalt konsulentselskap for Zvezdochka-selskapet for to år siden. Siden detaljene i Zvezdochka-selskapets aktiviteter var ukjente for mange hackathon-deltakere, snakket arrangørene i begynnelsen av arrangementet om beregningene som brukes i selskapet. Etter dette ble det levert seks datasett av ulike typer: tekst, tabeller, geolokalisering – det var handlingsrom for alle deltakerne. Arrangørene forbød ikke bruk av tilleggsdatasett og støttet til og med slike initiativ. I finalen i konkurransen konkurrerte ti lag med ulike løsninger om hovedpremien, der alle lag brukte data levert av selskapet (til tross for manglende restriksjoner), noe som indikerte godt potensial for å få kvalitetsprodukter.
moral
Det er ikke nødvendig å begrense den kreative flyten av deltakere. Som arrangør må du levere materialer og stole på deres visjon og profesjonalitet. Hvis du er en deltaker i et hackathon, bør eventuelle restriksjoner eller forbud skremme deg. Vanligvis er dette bevis på dårlig organisering (et eksempel fra det virkelige liv er det konstante ønsket om å stikke et gjerde et sted). Hvis du møter begrensninger, så vær forberedt på at du må lage et prosjekt i et basseng med mye konkurranse. I dette tilfellet er du forpliktet til å ta risiko: gjør noe fundamentalt nytt eller tilby en uvanlig "killer-funksjon" for å skille deg ut fra strømmen av monotone prosjekter.
Hackathon nr. 2. Umulige oppgaver
Hackathonet i Amador lovet å bli interessant. Sponsorselskapet, en stor telefonprodusent, begynte forberedelsene 4 måneder før datoen for arrangementet. PR for arrangementet ble utført på sosiale nettverk; potensielle deltakere måtte bestå en teknisk test og skrive om sine tidligere prosjekter for å bli valgt til dette arrangementet. Premiefondet var behagelig stort. Noen dager før hackathonet holdt mentorene en teknisk sesjon slik at deltakerne fikk tid til å forstå bransjens spesifikasjoner.
På selve arrangementet ga arrangørene et datasett med utstyrslogger med et volum på 8 GB, oppgaven var en binær klassifisering av sammenbrudd. De snakket om kriteriene for å evaluere prosjekter - kvalitet på klassifisering, kreativitet i å lage funksjoner, evne til å jobbe i et team, etc. Det er bare uflaks - for 8 GB med "funksjoner" var det bare 20 eksempler i toget og 5 i testen. Den siste spikeren i hackathonets kiste kom fra dataene: utstyrsloggene mottatt onsdag inneholdt en feil i driften av utstyret, men de som ble opprettet på torsdag gjorde det ikke (forresten, bare to lag visste om dette, og begge var fra Russland, hjemlandet til erfarne datagruvearbeidere). Selv om selv kunnskap om testens sanne merkelapper ikke hjalp til å bestemme svaret - var oppgaven uløselig. Arrangørene fikk ikke ønsket resultat, deltakerne brukte mye tid på å løse et dårlig utformet problem. Hackathonet var en fiasko.
moral
Gjennomfør tekniske gjennomganger av oppdrag og sjekk oppgavene dine for tilstrekkelighet. Det er bedre å betale for mye for en foreløpig undersøkelse (i dette tilfellet vil enhver dataforsker umiddelbart påpeke at det er umulig å løse dette problemet) enn å angre på det senere.
I dette tilfellet, i tillegg til bortkastet tid og penger, mistet selskapet troverdighet overfor potensielle kandidater og skrev muligens om resultatene. Forresten, ikke bare deltakerne, men også selskapet bør skrive om vellykkede resultater, maksimere hackathon fra et PR-synspunkt. Dessverre er det ikke alle selskaper som gjør dette, og begrenser seg til kun et kunngjøringsinnlegg og et par bilder fra arrangementet på Twitter.
Hackathon nr. 3. Ta den eller la den stå
Senest deltok teamet vårt i et hackathon i Amsterdam. Siden jeg er utdannet elektroingeniør (innen fornybare energikilder), passet temaet helt for oss – energi. Hackathonet ble holdt på nett: vi fikk en beskrivelse av oppgaven og en måned til å fullføre den. Arrangørene ønsket å se et ferdig prosjekt som ville bidra til å øke energieffektiviteten til Amsterdam-hus.
Vi laget et prosjekt der strømforbruk ble spådd (før det deltok jeg i en konkurranse om dette temaet hvor jeg fikk en nesten-sota-løsning som du kan lese om ) og generering av solcellepanel. Basert på disse spådommene er batteriytelsen optimalisert (denne ideen er delvis hentet fra masteroppgaven min). Prosjektet vårt var i god overensstemmelse både med instruksjonene fra arrangørene (slik det så ut for oss da), og med politikken til Amsterdam-administrasjonen på området fornybare energikilder i flere år fremover.
Under evalueringen av prosjekter fikk vi, i likhet med mange team, beskjed om at dette ikke var det kunden forventet, og la til at vi måtte gjøre om prosjektet hvis vi ville konkurrere om prisen. Vi gjorde ikke om noe, og aksepterte nederlag. Av de førti deltakende lagene kom vi ikke en gang til topp 7, selv om valget til arrangørene, synes jeg, var ganske merkelig. For eksempel slapp de laget gjennom til finalen som laget en applikasjon for å beregne vindhastighet og solstråling (SI) ved hjelp av data fra smarttelefonsensorer: en mikrofon for vinden, en lyssensor for SI. Morderfunksjonen var pølse/ikke pølse-klassifiseringen i tre klasser: Sol, vind, vann og visning av den tilsvarende artikkelen på Wikipedia ().
La oss forlate den moralske siden av saken et øyeblikk: utpressing av deltakere med mulighet for seier er rett og slett uetisk. Siden en av motivasjonene for å delta i hackathons (spesielt erfarne utviklere) er å realisere ideene sine, kan mange sterke deltakere ganske enkelt forlate arrangementet etter å ha hørt slike tilbakemeldinger (som ikke bare skjedde med teamet vårt, men også med en rekke andre som sluttet oppdaterer sideprosjektet sitt etter å ha lyttet til mentoren). La oss likevel si at vi var enige i arrangørenes ønsker og omskapte prosjektet vårt for å passe deres behov. Hva kan skje videre?
Siden arrangørene har sin egen forståelse av det "ideelle prosjektet", vil alle ønsker (og følgelig endringer) lede oss mot dette idealet. Konkurrentene vil kaste bort tiden sin, og det vil bli vanskeligere og vanskeligere for dem å nekte videre deltakelse (siden de allerede har investert innsatsen, og det ser ut til at de bare er et stykke unna seier). Men i realiteten vil konkurransen om premier øke, og deltakerne vil i økende grad måtte gjøre om prosjektet basert på redigeringer fra arrangørene i håp om å vinne en premie. Som et resultat vil gutta som ikke tok premier, når de ser tilbake, forstå at de deltok i freelancing uten penger: de gjorde endringer for kunden, men fikk ikke noe tilbake for dette (bortsett fra den relevante opplevelsen, av kurs).
moral
Ofte kommer ønsker og tilbakemeldinger fra arrangørene prosjektet til hjelp. Samtidig bør deltakerne imidlertid ikke stole på råd fra mentorer som en halt mann på en stokk. Hvis du hører tilbakemeldinger fra arrangørene på prosjektet ditt i ånden "ta det bort, vi har ikke bestilt dette", kan din deltakelse i hackathonet anses som fullført.
Hvis du organiserer et hackathon med en klar visjon for prosjektet, men uten ferdigheter eller evne til å implementere det selv, så er det bedre å formalisere visjonen din i form av tekniske spesifikasjoner for en frilanser. Ellers må du betale to ganger - for hackathon og for frilanserens tjenester.
Kilde: www.habr.com