I Jag har övervÀgt flera anledningar till varför man deltar i hackathons. Motivation att lÀra sig mycket nytt och att vinna vÀrdefulla priser lockar mÄnga, men ofta pÄ grund av misstag frÄn arrangörerna eller sponsorföretagen slutar evenemanget olyckligt och deltagarna lÀmnar missnöjda. För att sÄdana obehagliga situationer ska ske mer sÀllan har jag skrivit detta inlÀgg. Den andra delen av trilogin handlar om arrangörernas misstag.
InlÀgget Àr organiserat pÄ följande sÀtt: först berÀttar jag om evenemanget, förklarar vad som gick fel och vad detta ledde till (eller kan leda till pÄ lÄng sikt). Sedan ger jag min bedömning av situationen och hur jag skulle agera i arrangörernas stÀlle. Eftersom jag har deltagit i alla evenemang kan jag bara anta arrangörernas sanna motivation. DÀrför kan min bedömning bli ensidig. Jag utesluter inte att vissa saker som jag ser som felaktiga faktiskt var avsedda att vara just sÄ.
Vid en viss tidpunkt kan lÀsaren tycka att författaren har beslutat att vifta med nÀven efter slagsmÄlet. Men jag kan försÀkra er att sÄ inte Àr fallet. I nÄgra av de nÀmnda hackathons lyckades jag nÄ en prisplacering, vilket dock inte hindrar mig frÄn att sÀga att evenemanget var dÄligt organiserat.
Av respekt för arrangörerna och deltagarna kommer inlÀgget inte att innehÄlla hÀnvisningar till specifika företag. En uppmÀrksam lÀsare kan dock lista ut (eller googla) vem som avses.
Hackathon nr 1. Strikta ramar
För sex mÄnader sedan organiserade ett stort telekombolag en hackathon för dataanalys. 20 team tÀvlade om prispotten. Under evenemanget tillhandahölls en dataset för analys, som innehöll information om Àrenden till företagets kundtjÀnst, aktivitet pÄ sociala medier och kodad information om anvÀndarna (kön, Älder osv). Den mest intressanta delen av datasetet - anvÀndarens meddelanden och operatörens svar (textdata) - var ganska "bullrig", och för vidare arbete behövde den stÀdas.
Arrangörerna hade satt ett uppdrag - att göra nÄgot intressant med de tillhandahÄllna datan, och det var förbjudet att anvÀnda ytterligare öppna datasÀtt frÄn nÀtet eller att sjÀlvparsa data. Det var ocksÄ förbjudet att föreslÄ idéer som inte var kopplade till datasÀttet. TyvÀrr var den tillhandahÄllna datan ganska "fattig": det var svÄrt att fÄ fram nÄgra intressanta produkter, och frÄn samtal med mentorer blev det klart att mÄnga av de föreslagna idéerna redan antingen var genomförda (eller skulle genomföras i en snar framtid) inom företaget.
Som ett resultat gjorde den avgörande majoriteten av teamen (15 av 20) chattbotar. Under presentationerna var lösningen frĂ„n ett team knappt skild frĂ„n den tidigare. En av jurymedlemmarna, otĂ„lig, frĂ„gade det nĂ€sta teamet som gick upp pĂ„ scenen: âVad, killar, har ni ocksĂ„ en chattbot?â. I slutĂ€ndan gick första och andra plats till team som inte gjorde chattbotar.
För jĂ€mförelse kan vi ta en hackathon som arrangerades av ett internationellt konsultföretag för företaget âZvezdĐŸŃĐșĐ°â för tvĂ„ Ă„r sedan. Eftersom verksamheten hos företaget âZvezdĐŸŃĐșĐ°â var okĂ€nd för mĂ„nga av hackathonens deltagare, berĂ€ttade arrangörerna i början av evenemanget om de mĂ€tverktyg som anvĂ€nds inom företaget. Efter detta tillhandahölls sex datasĂ€tt av olika slag: text, tabeller, geografisk position - för alla deltagare fanns det gott om utrymme för manövrar. Arrangörerna förbjöd inte anvĂ€ndningen av ytterligare datasĂ€tt och stödde faktiskt sĂ„dana initiativ. I finalen tĂ€vlade tio team med olika lösningar om huvudpriset, och alla team anvĂ€nde data frĂ„n företaget (trots avsaknad av förbud), vilket vittnade om en god potential för att skapa kvalitativa produkter.
Moral
Det Ă€r inte bra att begrĂ€nsa deltagarnas kreativa flöde. Som arrangör bör du förse dem med material och lita pĂ„ deras perspektiv och professionalism. Om du Ă€r deltagare i hackathonet, bör eventuella begrĂ€nsningar eller förbud fĂ„ dig att kĂ€nna dig oroande. Det Ă€r oftast ett tecken pĂ„ dĂ„lig organisation (ett verkligt exempel â den konstanta hungern att sĂ€tta upp nĂ„gon slags avspĂ€rrning). Om du Ă€ndĂ„ stöter pĂ„ begrĂ€nsningar, var beredd pĂ„ att du mĂ„ste skapa ett projekt i en pool med hĂ„rd konkurrens. I sĂ„ fall Ă€r du skyldig att ta risker: göra nĂ„got grundlĂ€ggande nytt eller föreslĂ„ en ovanlig "killer feature" för att sticka ut frĂ„n strömmen av likartade projekt.
Hackathon Nr 2. OuppnÄeliga uppgifter
Hackathonet i Amador lovade att bli intressant. Sponsorföretaget, en stor telefonproducent, började förbereda sig fyra mÄnader före evenemanget. PÄ sociala medier genomfördes PR för evenemanget, potentiella deltagare behövde genomgÄ ett tekniskt test och skriva om sina tidigare projekt för att bli utvalda till denna hÀndelse. Prispotten var dessutom rejÀlt stor. NÄgra dagar före hackathonet höll mentorerna en teknisk session sÄ att deltagarna hade tid att sÀtta sig in i branschens specifika krav.
Vid sjĂ€lva evenemanget tillhandahöll arrangörerna en datamĂ€ngd med loggar som verkade ha en storlek pĂ„ 8 GB, uppgiften var att utföra binĂ€r klassificering av fel. De berĂ€ttade om bedömningskriterierna för projekten â klassificeringskvalitet, kreativitet i funktionsskapande, förmĂ„ga att arbeta i team, etc. Problemet var bara att pĂ„ 8 GB "features" fanns det bara 20 exempel i trĂ€ningsdata och 5 i testet. Den sista spiken i kistan för hackathonet var datafelet: loggarna som erhĂ„llits pĂ„ onsdagen hade ett fel i utrustningen, medan de skapade pĂ„ torsdagen inte hade det (detta var, för att nĂ€mna, nĂ„got som bara tvĂ„ team visste â bĂ„da frĂ„n Ryssland, hem till erfarna datavinnare). Ăven om man kĂ€nde till de verkliga etiketterna i testet, hjĂ€lpte det inte att justera svaret â uppgiften var olösbar. Arrangörerna fick inte det resultat de önskade, och deltagarna spenderade en massa tid pĂ„ att lösa en dĂ„ligt formulerad uppgift. Hackathonet misslyckades.
Moral
Genomför tekniska expertutvÀrderingar av uppgifter och kontrollera dina uppgifter för rimlighet. Det Àr bÀttre att betala extra för en förhandsgranskning (i det hÀr fallet skulle varje dataspecialist omedelbart peka pÄ att denna uppgift Àr omöjlig), Àn att Ängra sig senare.
I det hÀr fallet förlorade företaget, förutom tid och pengar, sitt förtroende hos potentiella kandidater och kanske kunde skriva om resultaten. För övrigt bör lyckade resultat skrivas om inte bara av deltagarna, utan ocksÄ av företaget, vilket maximerar hackathonets PR-vÀrde. TyvÀrr gör inte alla företag detta, utan begrÀnsar sig till ett annonspost och ett par bilder frÄn evenemanget pÄ Twitter.
Hackathon nr 3. Ta det eller lÀmna det.
Nyligen deltog vĂ„rt team i ett hackathon i Amsterdam. Eftersom jag Ă€r utbildad ingenjör inom elkraft ( inom förnybara energikĂ€llor) var Ă€mnet precis rĂ€tt för oss â energi. Hackathonet genomfördes online: vi fick en uppgiftsbeskrivning och en mĂ„nad för att genomföra den. Arrangörerna ville se ett fĂ€rdigt projekt som skulle hjĂ€lpa till att öka energieffektiviteten i Amsterdams hus.
Vi skapade ett projekt som förutser elförbrukningen (tidigare deltog jag i en tÀvling pÄ detta tema dÀr jag fick en nÀstan-optimal lösning, som man kan lÀsa om) ) och generation av solenergi. Baserat pÄ dessa förutsÀgelser optimeras arbetet för batteriet (denna idé togs delvis frÄn min masteruppsats). VÄrt projekt stÀmde vÀl överens med uppgiften frÄn arrangörerna (som vi dÄ trodde) och med Amsterdam stads politik för förnybar energi under flera Är framöver.
Under projektutvÀrderingen fick vi, precis som mÄnga andra team, veta att det inte var vad bestÀllaren förvÀntade sig, och att vi mÄste revidera projektet om vi ville tÀvla om priserna. Vi valde att inte Àndra nÄgot och accepterade nederlaget. Av fyrtio deltagande team kom vi inte ens med bland de sju bÀsta, Àven om jag tycker att arrangörernas val var ganska mÀrkligt. Till exempel gick de vidare med ett team som hade skapat en app för att berÀkna vindhastighet och solstrÄlning (SI) baserat pÄ smartphone-sensorers data: mikrofon för vinden, ljussensor för SI. En killerfunktion var klassificeringen hotdog/not hotdog i tre klasser: Sol, vind, vatten och en lÀnk till den relevanta artikeln pÄ Wikipedia.).
LÄt oss för en stund lÀmna den moraliska aspekten av frÄgan: att utpressa deltagare med möjligheten till seger Àr helt enkelt oetiskt. Eftersom en av motivationerna för att delta i hackathons (speciellt för erfarna utvecklare) Àr att förverkliga sina idéer, kan mÄnga starka deltagare helt enkelt överge evenemanget nÀr de hör sÄdan feedback (vilket inte bara hÀnde med vÄrt team, utan Àven med flera andra som slutade uppdatera sin projektsida efter mentorsamtalet). Men lÄt oss anta att vi gick med pÄ arrangörernas önskemÄl och reviderade vÄrt projekt efter deras krav. Vad kan hÀnda hÀrnÀst?
Eftersom arrangörerna har sin egen uppfattning om det "ideala projektet", kommer alla önskemÄl (och dÀrmed Àndringar) att leda oss mot detta ideal. Deltagarna kommer att spendera sin tid, och det kommer bli allt svÄrare för dem att avstÄ frÄn fortsatt deltagande (eftersom de redan har investerat tid och kraft, och det kÀnns som om vinsten Àr nÀra). Men i verkligheten kommer konkurrensen om priserna att öka, och deltagarna kommer allt oftare att behöva revidera sina projekt med arrangörernas Àndringar i hopp om att fÄ ett pris. I slutÀndan kommer de som inte vunnit priser, nÀr de ser tillbaka, att förstÄ att de deltog i frilansarbete utan betalning: de gjorde Àndringar pÄ bestÀllarens begÀran, men fick i gengÀld ingenting (förutom sjÀlvklart relevant erfarenhet).
Moral
Ofta kommer önskemĂ„l och feedback frĂ„n arrangörerna till nytta för projektet. Deltagarna ska dock inte lita pĂ„ mentorerna som en krycka. Om du hör feedback frĂ„n arrangörerna om ditt projekt som âta bort det, vi har inte bestĂ€llt detâ â kan du betrakta ditt deltagande i hackathonet som avslutat.
Om du arrangerar ett hackathon med en tydlig vision för projektet men utan kunskaper eller möjligheter att genomföra det sjÀlv, Àr det bÀttre att formulera din vision som ett tekniskt underlag för en frilansare. Annars kommer du att fÄ betala tvÄ gÄnger - för hackathonet och för frilansarens tjÀnster.
KĂ€lla: habr.com
