В Ik heb verschillende redenen bekeken om deel te nemen aan hackathons. De motivatie om veel nieuwe dingen te leren en waardevolle prijzen te winnen trekt velen aan, maar vaak eindigt het evenement, als gevolg van fouten van de organisatoren of sponsorende bedrijven, zonder succes en vertrekken de deelnemers ontevreden. Om ervoor te zorgen dat zulke vervelende incidenten minder vaak gebeuren, heb ik dit bericht geschreven. Het tweede deel van de trilogie is gewijd aan de fouten van de organisatoren.
De post is als volgt opgebouwd: aan het begin praat ik over de gebeurtenis, leg uit wat er mis is gegaan en waar het toe heeft geleid (of op de lange termijn kan leiden). Vervolgens geef ik mijn inschatting van wat er gebeurt en wat ik zou doen als ik de organisatoren was. Omdat ik aan alle evenementen heb deelgenomen, kan ik alleen maar uitgaan van de ware motivatie van de organisatoren. Mijn oordeel kan daardoor eenzijdig zijn. Ik sluit niet uit dat sommige punten die mij onjuist lijken, in werkelijkheid zo bedoeld waren.
Op een gegeven moment zou de lezer kunnen denken dat de auteur na een gevecht besloot met zijn vuisten te zwaaien. Maar ik kan u verzekeren dat dit niet het geval is. Bij sommige van de genoemde hackathons heb ik een prijs weten te pakken, wat ons er echter niet van weerhoudt te zeggen dat het evenement slecht georganiseerd was.
Uit respect voor de organisatoren en deelnemers zullen er in de post geen verwijzingen naar specifieke bedrijven staan. Een oplettende lezer kan echter wel raden (of googlen) over wie we het hebben.
Hackathon nr. 1. Strenge kaders
Een half jaar geleden organiseerde een groot telecombedrijf een hackathon over data-analyse. Er streden 20 teams om het prijzengeld. Tijdens het evenement werd een dataset ter analyse ter beschikking gesteld, die informatie bevatte over oproepen naar de ondersteuningsdienst van het bedrijf, activiteit op sociale netwerken en gecodeerde informatie over gebruikers (geslacht, leeftijd, enz.). Het meest interessante deel van de dataset – gebruikersberichten en operatorreacties (tekstgegevens) – was behoorlijk luidruchtig en moest worden opgeschoond voor verder werk.
De organisatoren stelden een taak op: iets interessants doen met de aangeleverde gegevens, en het was verboden om aanvullende open datasets van het netwerk te gebruiken of de gegevens zelf te parseren. Het was ook verboden om ideeën voor te stellen die geen verband hielden met de dataset. Helaas waren de verstrekte gegevens behoorlijk “slecht”: het was moeilijk om er interessante producten van te verkrijgen, en uit de communicatie met mentoren werd duidelijk dat veel van de voorgestelde ideeën al worden geïmplementeerd (of in de nabije toekomst zullen worden geïmplementeerd). in het bedrijf.
Als gevolg hiervan maakte het overweldigende aantal teams (15 van de 20) chatbots. Tijdens de optredens verschilde de beslissing van het ene team weinig van de vorige. Een van de juryleden kon het niet verdragen en vroeg aan het volgende team dat het podium betrad: “Wat jongens, hebben jullie ook een chatbot?” Als gevolg hiervan gingen van de drie prijzen de eerste en tweede plaats naar de teams die geen chatbots maakten.
Laten we ter vergelijking een hackathon nemen die twee jaar geleden door een internationaal adviesbureau voor het bedrijf Zvezdochka werd georganiseerd. Omdat de specifieke kenmerken van de activiteiten van het Zvezdochka-bedrijf voor veel hackathondeelnemers onbekend waren, spraken de organisatoren aan het begin van het evenement over de statistieken die in het bedrijf worden gebruikt. Hierna werden zes datasets van verschillende typen verstrekt: tekst, tabellen, geolocatie - er was manoeuvreerruimte voor alle deelnemers. De organisatoren verboden het gebruik van aanvullende datasets niet en steunden zelfs dergelijke initiatieven. In de finale van de competitie streden tien teams met verschillende oplossingen om de hoofdprijs, waarbij alle teams gebruik maakten van door het bedrijf verstrekte gegevens (ondanks het ontbreken van beperkingen), die duidden op goede mogelijkheden voor het verkrijgen van kwaliteitsproducten.
moraliteit
Het is niet nodig om de creatieve stroom van deelnemers te beperken. Als organisator moet je materialen aanleveren en vertrouwen op hun visie en professionaliteit. Als u deelneemt aan een hackathon, moet u zich zorgen maken over eventuele beperkingen of verboden. Meestal is dit een bewijs van slechte organisatie (een voorbeeld uit het echte leven is de constante wens om ergens een hek te plaatsen). Als je toch beperkingen tegenkomt, wees er dan op voorbereid dat je een project zult moeten opzetten in een pool met veel concurrentie. In dit geval bent u verplicht risico's te nemen: doe iets fundamenteel nieuws of bied een ongewone 'killer feature' aan om u te onderscheiden van de stroom van monotone projecten.
Hackathon nr. 2. Onmogelijke taken
De hackathon in Amador beloofde interessant te worden. Het sponsorbedrijf, een grote telefoonfabrikant, begon vier maanden vóór de datum van het evenement met de voorbereidingen. PR voor het evenement werd uitgevoerd op sociale netwerken; potentiële deelnemers moesten slagen voor een technische test en schrijven over hun eerdere projecten om voor dit evenement te worden geselecteerd. Het prijzengeld was aangenaam groot. Een paar dagen vóór de hackathon hielden de mentoren een technische sessie zodat de deelnemers de tijd hadden om de specifieke kenmerken van de branche te begrijpen.
Op het evenement zelf leverden de organisatoren een dataset met apparatuurlogboeken met een volume van 8 GB, de taak was een binaire classificatie van storingen. Ze spraken over de criteria voor het evalueren van projecten: kwaliteit van classificatie, creativiteit bij het creëren van functies, vermogen om in een team te werken, enz. Het is gewoon pech - voor 8 GB aan "functies" waren er slechts 20 voorbeelden in de trein en 5 in de test. De laatste nagel aan de kist van de hackathon kwam van de gegevens: de apparatuurlogboeken die woensdag werden ontvangen, bevatten een fout in de werking van de apparatuur, maar die van donderdag niet (trouwens, slechts twee teams wisten hiervan, en beiden kwamen uit Rusland, het thuisland van ervaren dataminers). Hoewel zelfs kennis van de echte labels van de test niet hielp om het antwoord te bepalen, was de taak onoplosbaar. De organisatoren behaalden niet het gewenste resultaat; de deelnemers besteedden veel tijd aan het oplossen van een slecht ontworpen probleem. De hackathon was een mislukking.
moraliteit
Voer technische beoordelingen van opdrachten uit en controleer uw opdrachten op geschiktheid. Het is beter om te veel te betalen voor een voorlopig onderzoek (in dit geval zou elke datawetenschapper er meteen op wijzen dat het onmogelijk is om dit probleem op te lossen) dan er later spijt van te krijgen.
In dit geval verloor het bedrijf niet alleen tijd en geld, maar verloor het ook de geloofwaardigheid bij potentiële kandidaten en schreef het mogelijk over de resultaten. Trouwens, niet alleen de deelnemers, maar ook het bedrijf moeten schrijven over succesvolle resultaten, waarbij de hackathon vanuit PR-oogpunt wordt gemaximaliseerd. Helaas doen niet alle bedrijven dit en beperken ze zich tot slechts een aankondigingspost en een paar foto's van het evenement op Twitter.
Hackathon nr. 3. Graag of niet
Recentelijk heeft ons team deelgenomen aan een hackathon in Amsterdam. Omdat ik een elektrotechnisch ingenieur ben van opleiding (op het gebied van hernieuwbare energiebronnen), was het onderwerp precies goed voor ons: energie. De hackathon vond online plaats: we kregen een beschrijving van de taak en een maand de tijd om deze te voltooien. De organisatoren wilden een voltooid project zien dat de energie-efficiëntie van Amsterdamse huizen zou helpen verhogen.
We hebben een project gemaakt waarin het elektriciteitsverbruik werd voorspeld (daarvoor heb ik deelgenomen aan een wedstrijd over dit onderwerp waarbij ik een bijna-sota-oplossing ontving, waarover je kunt lezen ) en opwekking door zonnepaneel. Op basis van deze voorspellingen worden de prestaties van de batterij geoptimaliseerd (dit idee is gedeeltelijk overgenomen uit mijn masterproef). Ons project sloot goed aan bij zowel de instructies van de organisatoren (zoals het ons toen leek) als bij het beleid van het Amsterdamse bestuur op het gebied van hernieuwbare energiebronnen voor de komende jaren.
Tijdens de evaluatie van projecten kregen we, net als veel teams, te horen dat dit niet was wat de klant verwachtte, en voegde eraan toe dat we het project opnieuw moesten doen als we wilden strijden om de prijs. We hebben niets opnieuw gedaan en de nederlaag geaccepteerd. Van de veertig deelnemende teams haalden we niet eens de top 7, al was de keuze van de organisatoren, zo lijkt mij, nogal vreemd. Zo lieten ze het team door naar de finale dat een aanvraag deed voor het berekenen van windsnelheid en zonnestraling (SI) met behulp van data van smartphonesensoren: een microfoon voor de wind, een lichtsensor voor de SI. Het killer-kenmerk was de hotdog/niet-hotdog-classificatie in drie klassen: zon, wind, water en weergave van het overeenkomstige artikel op Wikipedia ().
Laten we de morele kant van de kwestie even laten staan: deelnemers chanteren met de mogelijkheid van een overwinning is simpelweg onethisch. Omdat een van de motivaties voor deelname aan hackathons (vooral ervaren ontwikkelaars) het realiseren van hun ideeën is, kunnen veel sterke deelnemers het evenement eenvoudigweg verlaten nadat ze dergelijke feedback hebben gehoord (wat niet alleen met ons team gebeurde, maar ook met een aantal anderen die stopten het bijwerken van hun paginaproject na het luisteren naar de mentor). Maar laten we zeggen dat we het eens zijn met de wensen van de organisatoren en ons project opnieuw hebben gemaakt om aan hun eisen te voldoen. Wat zou er vervolgens kunnen gebeuren?
Omdat de organisatoren hun eigen begrip hebben van het ‘ideale project’, zullen alle wensen (en dienovereenkomstig veranderingen) ons naar dit ideaal leiden. De concurrenten zullen hun tijd verspillen en het zal voor hen steeds moeilijker worden om verdere deelname te weigeren (aangezien ze hun inspanningen al hebben geïnvesteerd, en het lijkt erop dat ze nog maar een klein stukje verwijderd zijn van de overwinning). Maar in werkelijkheid zal de concurrentie om prijzen toenemen en zullen deelnemers het project steeds vaker opnieuw moeten uitvoeren op basis van bewerkingen van de organisatoren, in de hoop een prijs te winnen. Als gevolg hiervan zullen de jongens die geen prijzen in ontvangst hebben genomen, als ze terugkijken, begrijpen dat ze zonder geld aan freelancen hebben deelgenomen: ze hebben bewerkingen voor de klant gemaakt, maar hebben er niets voor teruggekregen (behalve de relevante ervaring van cursus).
moraliteit
Vaak komen wensen en feedback van de organisatoren het project ten goede. Tegelijkertijd mogen de deelnemers echter niet als een lamme man op een stok vertrouwen op het advies van mentoren. Als je feedback hoort van de organisatoren op jouw project in de geest van “neem het mee, dit hebben we niet besteld”, kan je deelname aan de hackathon als voltooid worden beschouwd.
Organiseer je een hackathon met een duidelijke visie op het project, maar zonder de vaardigheden of het vermogen om deze zelf uit te voeren, dan kun je je visie beter formaliseren in de vorm van technische specificaties voor een freelancer. Anders moet je twee keer betalen – voor de hackathon en voor de diensten van de freelancer.
Bron: www.habr.com