In Ho esaminato alcune ragioni per partecipare a hackathon. La motivazione di apprendere molte nuove informazioni e di vincere premi preziosi attira molte persone, ma spesso, a causa degli errori degli organizzatori o delle aziende sponsor, l'evento si conclude in modo deludente e i partecipanti se ne vanno insoddisfatti. Per ridurre la frequenza di questi incidenti sgradevoli, 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 possono essere nel lungo termine). Poi fornisco la mia valutazione di quanto accaduto e come avrei agito al posto degli organizzatori. Poiché ho partecipato a tutti gli eventi, posso solo supporre la vera motivazione degli organizzatori. Di conseguenza, la mia valutazione potrebbe risultare parziale. Non escludo che alcuni aspetti che vedo come errori possano in realtà essere stati concepiti in quel modo.
A un certo punto, il lettore potrebbe avere l'impressione che l'autore stia cercando scuse dopo la battaglia. Ma posso assicurarvi che non è così. In alcuni dei hackathon elencati sono riuscito a occupare un posto nelle prime posizioni, il che, tuttavia, non toglie il fatto che l'evento fosse mal organizzato.
Per rispetto verso gli organizzatori e i partecipanti, nel post non saranno indicati nomi di aziende specifiche. Il lettore attento, però, potrebbe indovinare (o cercare su Google) di chi si parla.
Hackathon n. 1. Regole severe
Sei mesi fa, una grande azienda di telecomunicazioni ha organizzato un hackathon per l'analisi dei dati. Vent20 squadre hanno lottato per il montepremi. Durante l'evento è stato fornito un dataset per l'analisi, contenente informazioni sulle chiamate al servizio clienti dell'azienda, sull'attività sui social media e dati codificati riguardanti gli utenti (sesso, 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 lavoro successivo doveva essere ripulita.
Gli organizzatori hanno assegnato un compito: creare qualcosa di interessante con i dati forniti, vietando l'uso di ulteriori dataset aperti o il parsing dei dati. Era anche proibito proporre idee non correlate al dataset. Purtroppo, i dati forniti erano piuttosto "scarni": era difficile ricavarne prodotti interessanti, e attraverso le conversazioni con i mentori è emerso che molte delle idee proposte erano già in fase di realizzazione (o lo sarebbero state a breve) all'interno dell'azienda.
Di conseguenza, la stragrande maggioranza dei team (15 su 20) ha creato chatbot. Durante le presentazioni, la soluzione di un team era poco distinta dalle precedenti. Non riuscendo a resistere, uno dei membri della giuria ha chiesto a un altro team che saliva sul palco: “Cosa, ragazzi, anche voi avete un chatbot?”. Alla fine, dei tre posti premiati, il primo e il secondo sono andati a team che non hanno scelto di realizzare chatbot.
Prendiamo come esempio un hackathon organizzato due anni fa da una società di consulenza internazionale per la ditta 'Stellina'. Poiché la specificità delle attività della società 'Stellina' non era familiare a molti partecipanti all'hackathon, all'inizio dell'evento gli organizzatori hanno illustrato le metriche utilizzate dall'azienda. Successivamente sono stati forniti sei dataset di diversa natura: testi, tabelle, geolocalizzazione — per tutti i partecipanti c'era ampio margine di manovra. Gli organizzatori non vietavano l'uso di dataset aggiuntivi e anzi sostenevano tali iniziative. Nella fase finale della competizione, dieci squadre con diverse soluzioni hanno gareggiato per il premio principale, e tutte le squadre hanno utilizzato i dati forniti dall'azienda (nonostante non ci fossero divieti), il che dimostra un buon potenziale per la creazione di prodotti di qualità.
Moralità
Non 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 a un hackathon, eventuali restrizioni o divieti dovrebbero sollevare dei dubbi. Di solito, questo è un segno di cattiva organizzazione (un esempio dalla vita reale è il desiderio costante di inserire una recinzione ovunque). Se ti trovi di fronte a delle limitazioni, sii pronto a sapere che dovrai lavorare su un progetto in un contesto ad alta competitività. In tal caso, devi rischiare: fare qualcosa di radicalmente nuovo o proporre una 'killer feature' insolita per distinguerti dalla marea di progetti simili.
Hackathon n. 2. Compiti impossibili
L'hackathon ad Amadora prometteva di essere interessante. L'azienda sponsor, un grande produttore di telefoni, ha iniziato i preparativi quattro mesi prima della data dell'evento. Sui social media è stata realizzata una campagna pubblicitaria, e ai potenziali partecipanti è stato richiesto di superare un test tecnico e di scrivere dei loro progetti passati per essere selezionati per l'evento. Il montepremi era decisamente significativo. Pochi giorni prima dell'hackathon, i mentor hanno tenuto una sessione tecnica per fornire ai partecipanti il tempo di approfondire le specificità del settore.
Durante l'evento, gli organizzatori hanno fornito un dataset di log delle attrezzature di 8 GB, con il compito di effettuare una classificazione binaria dei guasti. Hanno discusso i criteri di valutazione dei progetti: qualità della classificazione, creatività nella creazione delle feature, capacità di lavorare in team, ecc. Tuttavia, c'era un problema: su 8 GB di “feature”, c'erano solo 20 esempi nel training e 5 nel test. Il colpo finale al hackathon è stato dato dalla discrepanza nei dati: i log delle attrezzature ottenuti mercoledì presentavano un errore nel funzionamento dell'attrezzatura, mentre quelli creati giovedì non lo mostravano (a proposito, solo due team sapevano di questo e entrambi provenivano dalla Russia, patria di esperti data miner). Anche conoscere le etichette reali del test non ha aiutato a fornire una risposta — il compito era insolubile. Gli organizzatori non hanno ottenuto il risultato desiderato, i partecipanti hanno sprecato un sacco di tempo a cercare di risolvere un compito mal formulato. L'hackathon è stato un fallimento.
Moralità
Esegui esperti tecnici sulle assegnazioni e verifica che le tue assegnazioni siano adeguate. È meglio pagare di più per una valutazione preliminare (in questo caso, qualsiasi data scientist avrebbe subito indicato l'impossibilità di risolvere questo compito), piuttosto che pentirsi in seguito.
In this case, in addition to the time and money spent, the company lost the trust of potential candidates and possibly failed to report on the results. Furthermore, successful results should be shared not only by participants but also by the company, maximizing the hackathon's impact from a PR perspective. Unfortunately, not all companies do this, limiting themselves to just an announcement post and a few photos from the event on Twitter.
Hackathon #3. Take it or leave it
Recently, our team participated in a hackathon in Amsterdam. Since I have an educational background as a power engineer (in the field of renewable energy), the theme was just right for us — energy. The hackathon was held online: we were given a description of the task and a month to complete it. The organizers wanted to see a finished project that would help increase the energy efficiency of homes in Amsterdam.
We created a project that predicts electricity consumption (prior to this, I participated in a competition on this topic where I received an approximately state-of-the-art solution, which can be read about) ) e generazione da parte del pannello solare. In base a queste previsioni, viene ottimizzata l'operatività della batteria (questa idea è stata parzialmente estratta dalla mia tesi di laurea). Il nostro progetto si allineava bene sia con le richieste degli organizzatori (come ci sembrava allora) sia con la politica dell'amministrazione di Amsterdam riguardo alle energie rinnovabili per i prossimi anni.
Durante la valutazione dei progetti, a noi, come a molte squadre, è stato detto che non era ciò che si aspettava il committente, aggiungendo che avremmo dovuto rifare il progetto se volessimo competere per i premi. Non abbiamo cambiato nulla, accettando la sconfitta. Su quaranta squadre partecipanti, non siamo riusciti nemmeno a entrare nella top 7, anche se la scelta degli organizzatori, a mio avviso, è stata piuttosto strana. Ad esempio, hanno passato in finale una squadra che ha realizzato un'app per il calcolo della velocità del vento e dell'irraggiamento solare (IS) basata su dati provenienti dai sensori dello smartphone: microfono per il vento, sensore di luminosità per l'IS. La killer feature era la classificazione hotdog/not hotdog in tre classi: Sole, vento, acqua e la relativa voce su Wikipedia.).
Lasciamo da parte per un momento l'aspetto etico della questione: ricattare i partecipanti con la possibilità di vincere è semplicemente disonesto. Una delle motivazioni per partecipare ai hackathon (soprattutto per gli sviluppatori esperti) è realizzare le proprie idee; pertanto, molti partecipanti di talento potrebbero semplicemente abbandonare l'evento dopo una feedback del genere (e ciò è accaduto non solo alla nostra squadra, ma anche ad altre, che hanno smesso di aggiornare la pagina del loro progetto dopo la sessione con il mentore). Tuttavia, supponiamo che siamo d'accordo con 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 di conseguenza le modifiche) ci guideranno verso questo ideale. I concorrenti spenderanno il loro tempo e diventerà sempre più difficile per loro rinunciare a continuare a partecipare (dato che hanno già investito energie e sembra che la vittoria sia a portata di mano). Ma in realtà, la competizione per i premi aumenterà e i partecipanti dovranno spesso rimaneggiare i progetti secondo le richieste degli organizzatori nella speranza di ottenere un premio. Alla fine, coloro che non occuperanno i posti premiati si renderanno conto, guardando indietro, di aver partecipato a un freelance senza guadagnare: hanno apportato modifiche richieste dal cliente, ma non hanno ricevuto nulla in cambio (tranne ovviamente l'esperienza corrispondente).
Moralità
Spesso le richieste e il feedback degli organizzatori arrivano in aiuto al progetto. Tuttavia, i partecipanti non devono basarsi sui consigli dei mentori come un monco su una stampella. Se sentite dagli organizzatori feedback sul vostro progetto come "eliminate, non lo abbiamo richiesto" — potete considerare completata la vostra partecipazione all'hackathon.
Se stai organizzando un hackathon con una chiara visione del progetto, ma senza le competenze o le possibilità di realizzarlo autonomamente, è meglio trasformare la tua visione in un documento tecnico per un freelance. In caso contrario, ti troverai a pagare due volte: per l'hackathon e per i servizi del freelance.
Fonte: habr.com
