In ho esaminato alcune ragioni per partecipare agli hackathon. La motivazione di apprendere molte cose nuove e di vincere premi preziosi attira molti, ma spesso a causa di errori degli organizzatori o delle aziende sponsor, l'evento finisce male e i partecipanti se ne vanno insoddisfatti. Per ridurre questi casi spiacevoli, ho scritto questo post. La seconda parte della trilogia è dedicata agli errori degli organizzatori.
Il post è organizzato come segue: all'inizio parlo dell'evento, spiego cosa è andato storto e quali sono state le conseguenze (o potrebbero esserlo a lungo termine). Poi fornisco la mia valutazione di quanto accaduto e come mi comporterei al posto degli organizzatori. Poiché ho preso parte a tutti gli eventi, posso solo ipotizzare la vera motivazione degli organizzatori. Di conseguenza, la mia valutazione potrebbe risultare unilaterale. Non escludo che alcuni aspetti che mi sembrano errati, in realtà siano stati pianificati in quel modo.
A un certo punto, il lettore potrebbe pensare che l'autore abbia deciso di muovere le mani dopo la rissa. Ma posso assicurarvi che non è così. In alcuni degli hackathon elencati, sono riuscito a ottenere un premio, il che, tuttavia, non impedisce di dire che l'evento è stato mal organizzato.
Per rispetto verso gli organizzatori e i partecipanti, nel post non ci saranno riferimenti a specifiche aziende. Tuttavia, un lettore attento potrebbe indovinare (o cercare su Google) di chi si parla.
Hackathon n. 1. Limiti rigorosi
Circa sei mesi fa, una grande azienda di telecomunicazioni ha organizzato un hackathon per l'analisi dei dati. Venti squadre hanno gareggiato per il montepremi. Durante l'evento è stato fornito un dataset per l'analisi, contenente informazioni sulle richieste al servizio clienti dell'azienda, sull'attività sui social media e su dati codificati sugli utenti (genere, età, ecc.). La parte più interessante del dataset — i messaggi degli utenti e le risposte degli operatori (dati testuali) — era piuttosto “rumorosa”, e per un uso successivo doveva essere pulita.
Gli organizzatori hanno dato l'incarico di fare qualcosa di interessante con i dati forniti, vietando di utilizzare altri dataset disponibili online o di estrarre i dati in proprio. Era anche vietato proporre idee non correlate al dataset. Sfortunatamente, i dati forniti erano piuttosto "scarsi": era difficile ottenere prodotti interessanti e, dalle conversazioni con i mentori, è emerso che molte delle idee proposte erano già in fase di realizzazione (o saranno realizzate nel prossimo futuro) dall'azienda.
Di conseguenza, la stragrande maggioranza delle squadre (15 su 20) ha realizzato chatbot. Durante le presentazioni, la soluzione di una squadra era poco distinguibile da quella precedente. Non potendo trattenersi, uno dei membri della giuria ha chiesto alla squadra che stava salendo sul palco: "Quale, ragazzi, anche voi avete un chatbot?" Alla fine, dei tre posti premiati, il primo e il secondo sono andati a squadre che non hanno realizzato chatbot.
A titolo di confronto, prendiamo l'hackathon organizzato due anni fa da una società di consulenza internazionale per l'azienda "Stellina". Poiché la natura dell'attività dell'azienda "Stellina" era sconosciuta a molti partecipanti all'hackathon, all'inizio dell'evento gli organizzatori hanno spiegato le metriche utilizzate dall'azienda. Successivamente sono stati forniti sei dataset di diversa natura: testi, tabelle, geoposizioni — per tutti i partecipanti c'era spazio di manovra. Gli organizzatori non hanno vietato l'uso di ulteriori dataset e hanno anche sostenuto tali iniziative. Alla fine della competizione, dieci squadre con soluzioni diverse hanno gareggiato per il premio principale, e tutte le squadre hanno utilizzato i dati forniti dall'azienda (nonostante l'assenza di divieti), il che testimoniava un buon potenziale per ottenere prodotti di qualità.
Morale
Non dovresti limitare il flusso creativo dei partecipanti. In qualità di organizzatore, devi fornire i materiali e fidarti della loro visione e professionalità. Se sei un partecipante al hackathon, qualsiasi limitazione o divieto dovrebbe metterti in guardia. Di solito è un segnale di cattiva organizzazione (un esempio dalla vita reale è il costante desiderio di piantare una barriera da qualche parte). Se ti trovi comunque di fronte a delle restrizioni, sii pronto al fatto che dovrai creare un progetto in un ambiente con alta concorrenza. In tal caso, hai l'obbligo di rischiare: fare qualcosa di profondamente nuovo o proporre una
Hackathon n. 2. Compiti impossibili
L'hackathon ad Amador ha promesso di essere interessante. L'azienda sponsor, un grande produttore di telefoni, ha iniziato i preparativi 4 mesi prima della data dell'evento. Nei social media è stata condotta una campagna promozionale per l'evento; i potenziali partecipanti dovevano superare un test tecnico e scrivere dei loro progetti passati per essere selezionati per questo evento. Il montepremi era piacevolmente alto. Pochi giorni prima dell'hackathon, i mentor hanno tenuto una sessione tecnica affinché i partecipanti avessero tempo di immergersi nella specificità del settore.
Durante l'evento, gli organizzatori hanno fornito un dataset di log dell'attrezzatura di 8 GB, con il compito di fare una classificazione binaria dei guasti. Hanno spiegato i criteri di valutazione dei progetti: qualità della classificazione, creatività nella creazione delle funzionalità, capacità di lavorare in team, ecc. Solo che c'è stato un problema: su 8 GB di "funzionalità", c'erano solo 20 esempi nel training e 5 nel test. L'ultimo chiodo nella bara dell'hackathon è stato messo dalle lacune nei dati: i log dell'attrezzatura ottenuti mercoledì contenevano errori di funzionamento, mentre quelli generati giovedì non li contenevano (su questo, va detto, sapevano solo due team, entrambi dalla Russia — la patria dei dataminer esperti). Anche se conoscere le etichette vere del test non ha aiutato a migliorare la risposta — il compito era irrisolvibile. Gli organizzatori non hanno ottenuto il risultato desiderato e i partecipanti hanno speso molto tempo cercando di risolvere un compito mal formulato. L'hackathon è stato un fallimento.
Morale
Eseguite perizie tecniche degli incarichi e verificate l'adeguatezza dei vostri compiti. È meglio pagare di più per una perizia preliminare (in questo caso, qualsiasi data scientist avrebbe subito indicato l'impossibilità di risolvere questo compito) piuttosto che pentirsi dopo.
In questo caso, oltre al tempo e ai soldi spesi, l'azienda ha perso la fiducia dei potenziali candidati e potrebbe scrivere sui risultati. A proposito, devono scrivere dei risultati positivi non solo i partecipanti, ma anche l'azienda, massimizzando il hackathon dal punto di vista PR. Purtroppo, non tutte le aziende lo fanno, limitandosi solo a un post di annuncio e a qualche foto dell'evento su Twitter.
Hackathon n. 3. O lo prendi o lo lasci.
Recentemente, il nostro team ha partecipato a un hackathon ad Amsterdam. Avendo io una laurea in ingegneria elettrica (nel campo delle energie rinnovabili), il tema era perfetto per noi: l'energia. L'hackathon si è svolto online: ci è stata data una descrizione del compito e un mese per completarlo. Gli organizzatori volevano vedere un progetto finito che aiutasse ad aumentare l'efficienza energetica delle case di Amsterdam.
Abbiamo realizzato un progetto che prevede il consumo di energia elettrica (prima ho partecipato a un concorso su questo tema, ricevendo circa una soluzione di tipo sota, di cui si può leggere ) e la generazione con pannelli solari. Sulla base di queste previsioni, viene ottimizzato il funzionamento della batteria (questa idea è stata parzialmente ripresa dal mio lavoro di laurea magistrale). Il nostro progetto era ben allineato sia con il compito degli organizzatori (come ci sembrava allora) sia con la politica dell'amministrazione di Amsterdam in materia di fonti rinnovabili per diversi anni a venire.
Durante la valutazione dei progetti, ci hanno, come a molti altri team, detto che non era quello che il cliente si aspettava, aggiungendo che dovevamo rifare il progetto se volevamo lottare per un posto sul podio. Non abbiamo apportato modifiche, rassegnandoci alla sconfitta. Delle quaranta squadre partecipanti, non siamo nemmeno riusciti a entrare nella top 7, anche se la scelta degli organizzatori, a mio avviso, è stata piuttosto strana. Ad esempio, hanno fatto passare in finale un team che ha creato un'applicazione per calcolare la velocità del vento e l'irraggiamento solare (IS) basandosi sui dati dei sensori dello smartphone: microfono per il vento, sensore di luminosità — per IS. La killer feature era la classificazione hotdog/not hotdog in tre categorie: Sole, vento, acqua e la visualizzazione del corrispondente articolo su Wikipedia.).
Lasciamo da parte per un momento l'aspetto morale della questione: ricattare i partecipanti con la possibilità di vittoria è semplicemente non etico. Poiché una delle motivazioni per partecipare ai hackathon (soprattutto per gli sviluppatori esperti) è realizzare le proprie idee, molti partecipanti motivati potrebbero semplicemente abbandonare l'evento, sentendo tale feedback (ciò è accaduto non solo con il nostro team, ma anche con altri che hanno smesso di aggiornare la pagina del loro progetto dopo l'ascolto del mentore). Diciamo però che abbiamo accettato le richieste degli organizzatori e abbiamo rifatto il nostro progetto secondo le loro esigenze. Cosa potrebbe succedere dopo?
Poiché gli organizzatori hanno una loro idea di "progetto ideale", tutte le richieste (e le relative modifiche) ci porteranno verso quel ideale. I concorrenti spenderanno il loro tempo e sarà sempre più difficile per loro rinunciare a partecipare ulteriormente (dato che hanno già investito energie e sembra che la vittoria sia a portata di mano). Ma in realtà, la competizione per i posti premiati aumenterà, e i partecipanti dovranno sempre più frequentemente rifare il progetto seguendo le modifiche degli organizzatori nella speranza di ottenere un premio. Di conseguenza, i ragazzi che non hanno ottenuto un posto sul podio, guardandosi indietro, capiranno di aver partecipato a un'attività freelance senza guadagnare nulla: hanno apportato modifiche su richiesta del cliente, ma non hanno ricevuto nulla in cambio (a parte l'esperienza, ovviamente).
Morale
Spesso, le richieste e il feedback da parte degli organizzatori aiutano il progetto. Tuttavia, i partecipanti non dovrebbero fare affidamento sui consigli dei mentori come un zoppo su una stampella. Se ricevete feedback dagli organizzatori riguardo al vostro progetto del tipo "rimuovete, non lo abbiamo ordinato" — la vostra partecipazione all'hackathon può considerarsi conclusa.
Se state organizzando un hackathon con una chiara visione del progetto, ma senza le competenze o la possibilità di realizzarlo autonomamente, è meglio formalizzare la vostra visione sotto forma di un documento tecnico per un freelance. Altrimenti, dovrete pagare due volte — per l'hackathon e per i servizi del freelance.
Fonte: habr.com
