In Ik heb enkele redenen overwogen 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 vanwege fouten van de organisatoren of de sponsors teleurstellend en verlaten deelnemers ontevreden. Om dergelijke vervelende situaties te verminderen, heb ik deze post geschreven. Het tweede deel van de trilogie is gewijd aan de fouten van de organisatoren.
De post is als volgt gestructureerd: eerst vertel ik over het evenement, leg uit wat er misging en wat dit heeft veroorzaakt (of kan veroorzaken op de lange termijn). Vervolgens geef ik mijn beoordeling van de situatie en hoe ik het zou hebben aangepakt als ik de organisatoren was geweest. Aangezien ik op alle evenementen als deelnemer heb opgetreden, kan ik alleen maar gissen naar de werkelijke motivatie van de organisatoren. Daarom kan mijn beoordeling eenzijdig zijn. Ik sluit niet uit dat sommige punten die ik als foutief beschouw, eigenlijk zoals bedoeld waren.
Op een bepaald moment kan het de lezer lijken dat de auteur probeert te boks te vechten na de strijd. Maar ik kan u verzekeren dat dit niet het geval is. In enkele van de genoemde hackathons ben ik erin geslaagd om een prijs te winnen, wat echter niet voorkomt dat ik zeg dat het evenement slecht georganiseerd was.
Uit respect voor de organisatoren en deelnemers zal de post geen specifieke bedrijven noemen. Een oplettende lezer kan echter raden (of googelen) over wie het gaat.
Hackathon ā 1. Strikte kaders
Zes maanden geleden organiseerde een groot telecommunicatiebedrijf een hackathon voor data-analyse. 20 teams streden om de prijzenpot. Tijdens het evenement werd een dataset voor analyse verstrekt, die informatie bevatte over klantcontacten bij de klantenservice, activiteit op sociale media en gecodeerde informatie over gebruikers (geslacht, leeftijd enzovoorts). Het meest interessante deel van de dataset ā gebruikersberichten en de reacties van de operator (tekstgegevens) ā was behoorlijk 'rumoros', en voor verder werk moest het worden schoongemaakt.
De organisatoren gaven de opdracht om iets interessants te doen met de beschikbare gegevens, met de beperking dat er geen extra open datasets uit het internet mochten worden gebruikt of dat de gegevens zelf geparsed mochten worden. Ook mochten er geen ideeĆ«n worden voorgesteld die niet gerelateerd waren aan de dataset. Helaas waren de beschikbare gegevens vrij 'arm': het was moeilijk om interessante producten eruit te halen en uit gesprekken met de mentoren bleek dat veel van de voorgestelde ideeĆ«n al in ontwikkeling waren (of binnenkort in de onderneming zouden worden geĆÆmplementeerd).
Als gevolg hiervan maakten de meeste teams (15 van de 20) chatbots. Tijdens de presentaties was de oplossing van Ć©Ć©n team nauwelijks te onderscheiden van de vorige. Niet in staat om het te weerstaan, vroeg een van de juryleden aan het volgende team dat op het podium verscheen: āWat, hebben jullie ook een chatbot?ā. Uiteindelijk gingen de eerste en tweede prijs naar teams die geen chatbots hadden gemaakt.
Ter vergelijking nemen we de hackathon, georganiseerd door een internationaal adviesbureau, voor het bedrijf 'Zvezdochka' twee jaar geleden. Aangezien de specificiteit van de activiteiten van 'Zvezdochka' veel deelnemers onbekend was, gaven de organisatoren in het begin van het evenement uitleg over de metrics die het bedrijf gebruikte. Hierna werd er een zestal datasets van verschillende aard gepresenteerd: tekst, tabellen, geoposities ā er was voor alle deelnemers veel ruimte voor creativiteit. De organisatoren verboden niet om extra datasets te gebruiken en steunden dergelijke initiatieven zelfs. In de finale streden tien teams met verschillende oplossingen om de hoofdprijs, waarbij alle teams de gegevens van het bedrijf gebruikten (ondanks het ontbreken van verboden), wat getuigde van het goede potentieel voor het verkrijgen van kwalitatief hoogwaardige producten.
De moraal
Beperk de creativiteit van de deelnemers niet. Als organisator moet je materialen verstrekken en vertrouwen op hun visie en professionaliteit. Als je een deelnemer van de hackathon bent, moeten elke beperking of verbod je wantrouwen oproepen. Dit is meestal een teken van slechte organisatie (een echt leven voorbeeld ā de constante neiging om ergens een hek te plaatsen). Als je toch met beperkingen te maken krijgt, wees dan voorbereid op concurrentie bij het ontwikkelen van je project. In dat geval moet je risico's nemen: iets totaal nieuws doen of een ongebruikelijke "killer feature" aanbieden om je te onderscheiden van de stroom uniforme projecten.
Hackathon #2. Onmogelijk te voltooien opdrachten
De hackathon in Amador beloofde interessant te zijn. De sponsor ā een grote telefoonfabrikant ā begon vier maanden voor de datum met de voorbereidingen. Op sociale media werd er reclame gemaakt voor het evenement, potentiĆ«le deelnemers moesten een technische test doorstaan en schrijven over hun eerdere projecten om geselecteerd te worden voor deze gebeurtenis. De prijzen waren aantrekkelijk groot. Enkele dagen voor de hackathon hielden de mentoren een technische sessie zodat de deelnemers de kans kregen om zich de specifieke kenmerken van de sector eigen te maken.
Tijdens het evenement boden de organisatoren een dataset van 8 GB aan logbestanden, de opdracht was om binaire classificatie van defecten uit te voeren. Er werd uitleg gegeven over de beoordelingscriteria voor de projecten ā de classificatiekwaliteit, creativiteit in het creĆ«ren van features, teamwerk, enzovoorts. Het probleem was alleen dat er op 8 GB aan features slechts 20 voorbeelden in de training en 5 in de test waren. De laatste doodsteek voor de hackathon kwam van een datalek: de logs van de apparatuur die op woensdag waren verkregen, bevatten een fout in de werking van de apparatuur, terwijl die van donderdag dat niet deden (dat wisten, terloops, alleen twee teams, en beide waren uit Rusland ā het thuisland van ervaren datamineurs). Hoewel zelfs het weten van de ware labels van de test niet hielp om het antwoord aan te passen ā de taak was onoplosbaar. De organisatoren kregen niet het gewenste resultaat en de deelnemers besteedden veel tijd aan het oplossen van een slecht geformuleerde opdracht. De hackathon was een mislukking.
De moraal
Voer technische beoordelingen van opdrachten uit en controleer de haalbaarheid van je taken. Het is beter om extra te betalen voor een voorlopige beoordeling (in dit geval zou elke data scientist onmiddellijk wijzen op de onoplosbaarheid van deze taak) dan later spijt te hebben.
In dit geval heeft het bedrijf naast de verspilde tijd en geld ook het vertrouwen van potentiƫle kandidaten verloren, en mogelijk kunnen ze niets over de resultaten schrijven. Het is trouwens niet alleen de taak van deelnemers om over succesvolle resultaten te schrijven, maar ook van het bedrijf, om het hackathon tot het maximale te benutten vanuit PR-oogpunt. Helaas doen niet alle bedrijven dit, beperken ze zich tot een aankondigingspost en een paar foto's van het evenement op Twitter.
Hackathon ā3. Neem het of laat het.
Recentelijk nam ons team deel aan een hackathon in Amsterdam. Aangezien ik als opleiding elektro-energie ingenieur ben (in het gebied van hernieuwbare energiebronnen), was het thema precies geschikt voor ons - energie. De hackathon werd online gehouden: we kregen een beschrijving van de opdracht en een maand om het uit te voeren. De organisatoren wilden een eindproject zien dat zou helpen de energie-efficiƫntie van huizen in Amsterdam te verhogen.
We hebben een project gemaakt waarin het elektriciteitsverbruik wordt voorspeld (eerder heb ik deelgenomen aan een wedstrijd over dit onderwerp waarvoor ik een bijna-sota oplossing heb ontvangen, waarvan je kunt lezen ) en de energieopbrengst van zonnepanelen. Afhankelijk van deze voorspellingen wordt het werk van de batterij geoptimaliseerd (dit idee was gedeeltelijk overgenomen uit mijn masterproef). Ons project was goed afgestemd op zowel de opdracht van de organisatoren (zoals we toen dachten) als op het beleid van de Amsterdamse overheid op het gebied van hernieuwbare energie voor de komende jaren.
Tijdens de projectbeoordelingen werd ons, net als veel andere teams, verteld dat het niet was wat de klant verwachtte, en dat we het project moesten herzien als we wilden strijden voor een prijs. We gingen niets opnieuw doen en accepteerden onze nederlaag. Van de veertig deelnemende teams haalden we zelfs niet de top 7, hoewel de keuze van de organisatoren, naar mijn mening, vreemd was. Ze lieten bijvoorbeeld een team door naar de finale, dat een app had gemaakt voor de berekening van windsnelheid en zonne-energie (Z.E.) op basis van smartphone-sensoren: een microfoon voor de wind en een lichtsensor voor Z.E. De killer functie was de classificatie hotdog/not hotdog in drie klassen: Zon, Wind, Water, met daarbij de bijbehorende Wikipedia-pagina.).
Laten we de morele kant van de zaak even terzijde schuiven: het chanteren van deelnemers met de mogelijkheid om te winnen is gewoon onethisch. Een van de motivaties om aan hackathons deel te nemen (vooral voor ervaren developers) is het realiseren van hun ideeƫn, en veel sterke deelnemers kunnen gewoon het evenement verlaten als ze zo'n feedback horen (wat niet alleen met ons team gebeurde, maar ook met verschillende anderen die stopten met het bijwerken van hun projectpagina na de feedback van de mentor). Stel dat we akkoord gingen met de wensen van de organisatoren en ons project hervormen aan hun eisen. Wat kan er dan gebeuren?
Omdat de organisatoren hun eigen idee van een 'perfect project' hebben, zullen alle wensen (en dus wijzigingen) ons naar dit ideaal toenemen. De deelnemers zullen hun tijd verdoen en het zal steeds moeilijker voor hen worden om verdere deelname af te wijzen (aangezien ze al hun energie hebben geĆÆnvesteerd, en het lijkt alsof ze haast bij de overwinning zijn). Maar in werkelijkheid zal de concurrentie om de prijzen toenemen, en zullen deelnemers steeds vaker hun project moeten herzien op verzoek van de organisatoren in de hoop op een prijs. Uiteindelijk zullen degenen die geen prijs hebben gewonnen, achteromkijkend beseffen dat ze hebben deelgenomen aan freelancen zonder betaling: ze hebben de aanpassingen van de opdrachtgever aangebracht, maar ontvingen hiervoor niets in ruil (behalve natuurlijk de bijbehorende ervaring).
De moraal
Vaak komen verzoeken en feedback van de organisatoren het project ten goede. Deelnemers moeten echter niet afhankelijk zijn van de adviezen van mentoren, zoals een krukkende op een stok. Als u van de organisatoren feedback over uw project hoort in de trant van "haal dit weg, we hebben dit niet besteld" ā dan kunt u uw deelname aan de hackathon als beĆ«indigd beschouwen.
Als u een hackathon organiseert met een duidelijke visie op het project, maar zonder vaardigheden of de mogelijkheid om het zelf uit te voeren, is het beter om uw visie als een technische opdracht voor een freelancer op te stellen. Anders moet u twee keer betalen ā voor de hackathon en voor de diensten van de freelancer.
Bron: habr.com
