В Jag har tittat på flera anledningar till att delta i hackathons. Motivationen att lära sig mycket nytt och vinna värdefulla priser lockar många, men ofta, på grund av misstag från arrangörer eller sponsrande företag, avslutas evenemanget utan framgång och deltagarna går missnöjda. För att få sådana obehagliga incidenter att hända mer sällan skrev jag det här inlägget. Den andra delen av trilogin är tillägnad arrangörernas misstag.
Inlägget är organiserat enligt följande: i början pratar jag om händelsen, förklarar vad som gick fel och vad det ledde till (eller kan leda till i längden). Sedan ger jag min bedömning av vad som händer, och vad jag skulle göra om jag var arrangörer. Eftersom jag deltog i alla evenemang kan jag bara anta arrangörernas verkliga motivation. Som ett resultat kan min bedömning vara ensidig. Jag utesluter inte att vissa punkter som förefaller mig felaktiga faktiskt var avsedda på det sättet.
Vid en viss tidpunkt kan läsaren tro att författaren bestämde sig för att vifta med nävarna efter ett slagsmål. Men jag kan försäkra er att så inte är fallet. I några av de listade hackathonen lyckades jag ta ett pris, vilket dock inte hindrar oss från att säga att evenemanget var dåligt organiserat.
Av respekt för arrangörer och deltagare kommer det inte finnas några referenser till specifika företag i inlägget. En uppmärksam läsare kan dock gissa (eller Googla) vem vi pratar om.
Hackathon nr 1. Strikta ramar
För sex månader sedan anordnade ett stort telekomföretag ett hackathon om dataanalys. 20 lag tävlade om prisfonden. Vid evenemanget tillhandahölls en datauppsättning för analys, som innehöll information om samtal till företagets supporttjänst, aktivitet på sociala nätverk och kodad information om användare (kön, ålder etc.). Den mest intressanta delen av datasetet – användarmeddelanden och operatörssvar (textdata) – var ganska bullriga och behövde rengöras för vidare arbete.
Arrangörerna satte en uppgift - att göra något intressant med den tillhandahållna data, och det var förbjudet att använda ytterligare öppna datauppsättningar från nätverket eller analysera data själv. Det var också förbjudet att föreslå idéer som inte var relaterade till datamängden. Tyvärr var informationen ganska "dålig": det var svårt att få några intressanta produkter från dem, och från kommunikation med mentorer blev det klart att många av de föreslagna idéerna redan implementeras (eller kommer att implementeras inom en snar framtid) i företaget.
Som ett resultat skapade det överväldigande antalet lag (15 av 20) chatbotar. Under föreställningarna var beslutet för ett lag lite annorlunda än det tidigare. Utan att stå ut med det frågade en av jurymedlemmarna nästa lag som gick på scenen: "Vad, killar, har ni också en chatbot?" Som ett resultat, av tre priser, gick första och andra platserna till de lag som inte skapade chatbots.
Som jämförelse, låt oss ta ett hackathon som anordnades av ett internationellt konsultföretag för Zvezdochka-företaget för två år sedan. Eftersom detaljerna i Zvezdochka-företagets aktiviteter var obekanta för många hackathondeltagare, pratade arrangörerna i början av evenemanget om de mätvärden som används i företaget. Därefter tillhandahölls sex datauppsättningar av olika typer: text, tabeller, geolokalisering - det fanns manöverutrymme för alla deltagare. Arrangörerna förbjöd inte användningen av ytterligare datauppsättningar och stödde till och med sådana initiativ. I finalen i tävlingen tävlade tio lag med olika lösningar om huvudpriset, där alla lag använde data från företaget (trots avsaknaden av restriktioner), vilket tydde på god potential för att få kvalitetsprodukter.
moral
Det finns ingen anledning att begränsa det kreativa flödet av deltagare. Som arrangör måste du tillhandahålla material och lita på deras vision och professionalism. Om du är en deltagare i ett hackathon bör alla restriktioner eller förbud skrämma dig. Vanligtvis är detta bevis på dålig organisation (ett exempel från det verkliga livet är den ständiga önskan att sticka ett staket någonstans). Om du stöter på begränsningar, var då beredd på att du kommer att behöva skapa ett projekt i en pool med mycket konkurrens. I det här fallet är du skyldig att ta risker: gör något i grunden nytt eller erbjuder en ovanlig "killer-funktion" för att sticka ut från strömmen av monotona projekt.
Hackathon nr 2. Omöjliga uppgifter
Hackathonet i Amador lovade att bli intressant. Det sponsrande företaget, en stor telefontillverkare, påbörjade förberedelserna 4 månader före evenemangets datum. PR för evenemanget genomfördes på sociala nätverk; potentiella deltagare var tvungna att klara ett tekniskt test och skriva om sina tidigare projekt för att bli utvalda till detta evenemang. Prisfonden var behagligt stor. Några dagar innan hackathonet höll mentorerna en teknisk session så att deltagarna fick tid att förstå branschens detaljer.
Vid själva evenemanget tillhandahöll arrangörerna en datauppsättning av utrustningsloggar med en volym på 8 GB, uppgiften var en binär klassificering av haverier. De pratade om kriterierna för att utvärdera projekt - kvalitet på klassificering, kreativitet i att skapa funktioner, förmåga att arbeta i ett team, etc. Det är bara otur - för 8 GB "funktioner" fanns det bara 20 exempel i tåget och 5 i testet. Den sista spiken i hackathonets kista kom från data: utrustningsloggarna som mottogs på onsdagen innehöll ett fel i driften av utrustningen, men de som skapades på torsdagen gjorde det inte (förresten, bara två lag visste om detta, och båda var från Ryssland, hemlandet för erfarna dataminers). Även om inte ens kunskap om testets sanna beteckningar hjälpte till att avgöra svaret - var uppgiften olöslig. Arrangörerna fick inte det önskade resultatet, deltagarna lade ner mycket tid på att lösa ett dåligt utformat problem. Hackathonet var ett misslyckande.
moral
Genomför tekniska granskningar av uppdrag och kontrollera att dina uppdrag är tillräckliga. Det är bättre att betala för mycket för en preliminär undersökning (i det här fallet skulle vilken datavetare som helst påpeka att det är omöjligt att lösa detta problem) än att ångra det senare.
I det här fallet tappade företaget, förutom bortkastad tid och pengar, trovärdighet hos potentiella kandidater och skrev möjligen om resultatet. Förresten, inte bara deltagarna, utan också företaget bör skriva om framgångsrika resultat, maximera hackathon ur PR-synpunkt. Tyvärr är det inte alla företag som gör detta, de begränsar sig till endast ett tillkännagivandeinlägg och ett par bilder från evenemanget på Twitter.
Hackathon nr 3. Ta det eller lämna det
Senast deltog vårt team i ett hackathon i Amsterdam. Eftersom jag är utbildad elingenjör (inom området förnybara energikällor) var ämnet helt rätt för oss – energi. Hackathonet hölls online: vi fick en beskrivning av uppgiften och en månad på oss att slutföra den. Arrangörerna ville se ett färdigt projekt som skulle bidra till att öka energieffektiviteten för hus i Amsterdam.
Vi gjorde ett projekt där elförbrukningen förutspåddes (innan dess deltog jag i en tävling på detta ämne där jag fick en near-sota lösning som du kan läsa om ) och generering av solpanel. Baserat på dessa förutsägelser optimeras batteriprestanda (denna idé är delvis hämtad från min masteruppsats). Vårt projekt stämde väl överens både med instruktionerna från arrangörerna (som det verkade för oss då), och med Amsterdamadministrationens policy på området för förnybara energikällor under flera år framöver.
Under utvärderingen av projekt fick vi, liksom många team, höra att detta inte var vad kunden förväntade sig, och tillade att vi var tvungna att göra om projektet om vi ville tävla om priset. Vi gjorde inte om någonting, accepterade nederlag. Av de fyrtio deltagande lagen kom vi inte ens till topp 7, även om valet av arrangörerna, tycker jag, var ganska konstigt. Till exempel släppte de laget igenom till finalen som gjorde en applikation för att beräkna vindhastighet och solstrålning (SI) med hjälp av data från smartphonesensorer: en mikrofon för vinden, en ljussensor för SI. Mördarfunktionen var klassificeringen av korv/ej varmkorv i tre klasser: Sol, vind, vatten och visning av motsvarande artikel på Wikipedia ().
Låt oss lämna den moraliska sidan av frågan för ett ögonblick: att utpressa deltagare med möjlighet till seger är helt enkelt oetiskt. Eftersom en av motiven för att delta i hackathons (särskilt erfarna utvecklare) är att förverkliga sina idéer, kan många starka deltagare helt enkelt lämna evenemanget efter att ha hört sådan feedback (vilket inte bara hände vårt team, utan också för ett antal andra som slutade uppdaterar sitt sidprojekt efter att ha lyssnat på mentorn). Låt oss ändå säga att vi gick med på arrangörernas önskemål och gjorde om vårt projekt för att passa deras krav. Vad kan hända härnäst?
Eftersom arrangörerna har sin egen förståelse för det "ideala projektet" kommer alla önskemål (och följaktligen förändringar) att leda oss mot detta ideal. De tävlande kommer att slösa bort sin tid och det kommer att bli svårare och svårare för dem att vägra ytterligare deltagande (eftersom de redan har investerat sina ansträngningar och det verkar som att de bara är en liten bit ifrån att vinna). Men i verkligheten kommer konkurrensen om priser att öka och deltagarna kommer i allt högre grad att behöva göra om projektet utifrån redigeringar från arrangörerna i hopp om att vinna ett pris. Som ett resultat kommer killarna som inte tog priser, när de ser tillbaka, att förstå att de deltog i frilansande utan pengar: de gjorde ändringar för kunden, men fick ingenting i utbyte för detta (förutom den relevanta upplevelsen, av kurs).
moral
Ofta kommer önskemål och feedback från arrangörerna till projektets hjälp. Samtidigt bör dock deltagarna inte lita på råd från mentorer som en halt man på en käpp. Om du hör feedback från arrangörerna om ditt projekt i andan av "ta bort det, vi beställde inte det här", kan ditt deltagande i hackathon anses avslutat.
Om du organiserar ett hackathon med en tydlig vision för projektet, men utan kompetens eller förmåga att genomföra det själv, är det bättre att formalisera din vision i form av tekniska specifikationer för en frilansare. Annars måste du betala två gånger – för hackathon och för frilansarens tjänster.
Källa: will.com