В Ho considerato diversi motivi per partecipare agli hackathon. La motivazione ad imparare tante cose nuove e vincere premi preziosi attira molti, ma spesso a causa degli errori degli organizzatori o delle aziende sponsor, l'evento finisce senza successo e i partecipanti se ne vanno insoddisfatti. Affinché casi così spiacevoli si verifichino meno spesso, ho scritto questo post. La seconda parte della trilogia è dedicata agli errori degli organizzatori.
Il post è organizzato così: all'inizio parlo dell'evento, spiego cosa è andato storto e cosa ha portato (o potrebbe portare a lungo termine). Poi do il mio giudizio su quanto sta accadendo e su cosa farei io al posto degli organizzatori. Poiché ho partecipato a tutti gli eventi come partecipante, posso solo supporre la vera motivazione degli organizzatori. Di conseguenza, la mia valutazione potrebbe rivelarsi unilaterale. Non escludo che alcuni punti che ritengo errati fossero in realtà destinati ad esserlo.
Ad un certo punto, al lettore può sembrare che l'autore abbia deciso di agitare i pugni dopo il combattimento. Ma posso assicurarti che non è così. In alcuni degli hackathon elencati sono riuscito a vincere un premio, il che però non ci impedisce di dire che l'evento è stato mal organizzato.
Per rispetto degli organizzatori e dei partecipanti, nel post non saranno presenti riferimenti ad aziende specifiche. Un lettore attento, tuttavia, può indovinare (o cercare su Google) di chi si sta discutendo.
Hackathon numero 1. Quadro rigoroso
Sei mesi fa, una grande azienda di telecomunicazioni ha organizzato un hackathon sull’analisi dei dati. 20 squadre hanno lottato per il montepremi. Durante l'evento è stato fornito per l'analisi un set di dati che conteneva informazioni sulle chiamate al servizio di supporto dell'azienda, sull'attività sui social network e informazioni codificate sugli utenti (sesso, età, ecc.). La parte più interessante del set di dati - i messaggi dell'utente e la risposta dell'operatore (dati di testo) - era piuttosto "rumorosa", doveva essere pulita per ulteriori lavori.
Gli organizzatori si sono posti il compito di fare qualcosa di interessante con i dati forniti ed era vietato utilizzare ulteriori set di dati aperti dalla rete o analizzare i dati da soli. Era inoltre vietato offrire idee non legate al dataset. Sfortunatamente, i dati forniti erano piuttosto "poveri": è stato difficile ottenere da loro prodotti interessanti e dalla comunicazione con i mentori è emerso chiaro che molte delle idee proposte sono già in fase di attuazione (o lo saranno nel prossimo futuro). nell'azienda.
Di conseguenza, la stragrande maggioranza dei team (15 su 20) ha realizzato chatbot. Durante le esibizioni, la decisione di una squadra è stata leggermente diversa da quella precedente. Incapace di sopportarlo, uno dei membri della giuria ha chiesto alla squadra successiva che entrava sul palco: "Ragazzi, avete anche voi un chatbot?". Di conseguenza, su tre premi, il primo e il secondo posto sono andati alle squadre che non hanno iniziato a creare chatbot.
Per fare un confronto, prendiamo un hackathon organizzato da una società di consulenza internazionale per Zvezdochka due anni fa. Poiché le specificità delle attività di Zvezdochka non erano familiari a molti partecipanti all'hackathon, all'inizio dell'evento gli organizzatori hanno parlato dei parametri utilizzati in azienda. Successivamente sono stati forniti sei set di dati di varie direzioni: testo, tabelle, geolocalizzazione: c'era spazio di manovra per tutti i partecipanti. Gli organizzatori non hanno vietato l'uso di set di dati aggiuntivi e hanno addirittura sostenuto tali iniziative. Nella finale del concorso, 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), che indicavano un buon potenziale per ottenere prodotti di qualità.
Moralità
Non limitare il flusso creativo dei partecipanti. In qualità di organizzatore, devi fornire materiali e fidarti della loro visione e professionalità. Se partecipi a un hackathon, qualsiasi restrizione o divieto dovrebbe avvisarti, di solito questo è la prova di una cattiva organizzazione (un esempio nella vita reale è il desiderio costante di piantare una recinzione da qualche parte). Se incontri ancora delle restrizioni, preparati al fatto che dovrai creare un progetto in un pool con molta concorrenza. In questo caso, devi correre dei rischi: fare qualcosa di fondamentalmente nuovo o offrire un'insolita "caratteristica killer" per distinguerti dal flusso di progetti monotoni.
Hackathon n.2. Compiti impossibili
L'hackathon di Amadora si preannunciava interessante. L'azienda sponsor, un importante produttore di telefoni, ha iniziato i preparativi 4 mesi prima della data dell'evento. Le PR dell'evento si sono svolte sui social network, i potenziali partecipanti hanno dovuto superare un test tecnico e scrivere dei loro progetti passati per essere selezionati per questo evento. Il montepremi era piacevolmente ampio. Pochi giorni prima dell'hackathon, i mentori hanno tenuto una sessione tecnica in modo che i partecipanti abbiano avuto il tempo di percepire le specificità del settore.
Durante l'evento stesso, gli organizzatori hanno fornito un set di dati di 8 GB di registri delle apparecchiature, il compito era una classificazione binaria dei guasti. Hanno parlato dei criteri per valutare i progetti: qualità della classificazione, creatività nella creazione di funzionalità, capacità di lavorare in gruppo, ecc. È solo sfortuna: per 8 GB di "funzionalità" c'erano solo 20 esempi nel treno e 5 nel test. L'ultimo chiodo nella bara dell'hackathon è stato piantato da una fuga di dati: i registri dell'attrezzatura ricevuti mercoledì contenevano un errore nel funzionamento dell'attrezzatura, mentre quelli creati giovedì no (a proposito, solo due squadre sapevano a questo proposito, ed entrambi provenivano dalla Russia, patria di dataminer esperti). Sebbene anche conoscere le vere etichette del test non abbia aiutato a correggere la risposta, il compito era irrisolvibile. Gli organizzatori non hanno ottenuto il risultato desiderato, i partecipanti hanno trascorso molto tempo a risolvere un problema mal formulato. L'hackathon è fallito.
Moralità
Condurre revisioni tecniche degli incarichi e verificarne l'adeguatezza. È meglio pagare più del dovuto per un esame preliminare (in questo caso, qualsiasi scienziato dei dati sottolineerebbe immediatamente che è impossibile risolvere questo problema) piuttosto che pentirsene in seguito.
In questo caso, oltre allo spreco di tempo e denaro, l'azienda ha perso credibilità nei confronti dei potenziali candidati ed eventualmente ha scritto dei risultati. A proposito, non solo i partecipanti dovrebbero scrivere dei risultati positivi, ma anche l'azienda, implementando l'hackathon il più possibile in termini di PR. Purtroppo non tutte le aziende lo fanno, limitandosi solo a un post-annuncio e ad un paio di foto dell'evento su Twitter.
Hackathon n.3. Prendere o lasciare
Più recentemente, il nostro team ha preso parte a un hackathon ad Amsterdam. Dato che sono un ingegnere elettrico di formazione (nel campo delle fonti energetiche rinnovabili), l'argomento era solo per noi: l'energia. L'hackathon si è svolto online: ci è stata fornita 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 elettricità (prima ho partecipato a un concorso su questo argomento in cui ho ricevuto una soluzione quasi sota, di cui puoi leggere ) e generazione tramite pannello solare. Sulla base di queste previsioni, le prestazioni della batteria vengono ottimizzate (questa idea è stata in parte presa dalla mia tesi magistrale). Il nostro progetto era in buon accordo sia con il compito degli organizzatori (come ci sembrava allora), sia con la politica dell'amministrazione di Amsterdam nel campo delle energie rinnovabili per molti anni a venire.
Durante la valutazione dei progetti, a noi, come a molti team, è stato detto che questo non era quello che il cliente si aspettava, aggiungendo che dovevamo rifare il progetto se volevamo competere per il premio. Non abbiamo cambiato nulla, rassegnati alla sconfitta. Delle quaranta squadre partecipanti, non siamo nemmeno arrivate tra le prime 7, anche se la scelta degli organizzatori, mi sembra, è stata piuttosto strana. Ad esempio, non è riuscito a raggiungere il team finale, che ha realizzato un'applicazione per calcolare la velocità del vento e la radiazione solare (SI) utilizzando i sensori dello smartphone: un microfono per il vento, un sensore di luce per SI. La caratteristica killer era la classificazione di hotdog/non hotdog in tre classi: sole, vento, acqua e la visualizzazione del corrispondente articolo di Wikipedia ().
Lasciamo per un attimo da parte il lato morale della questione: ricattare i partecipanti con la possibilità di vincere è semplicemente immorale. Poiché una delle motivazioni per partecipare agli hackathon (soprattutto sviluppatori esperti) è implementare le proprie idee, molti partecipanti forti possono semplicemente abbandonare l'evento dopo aver ascoltato tale feedback (cosa che è avvenuta non solo con il nostro team, ma anche con un numero di altri che hanno smesso aggiornando la loro pagina). progetto dopo aver ascoltato il mentore). Diciamo comunque che abbiamo concordato con i desideri degli organizzatori e ridisegnato il nostro progetto per soddisfare le loro esigenze. Cosa potrebbe succedere dopo?
Poiché gli organizzatori hanno la propria comprensione del "progetto ideale", tutti i desideri (e, di conseguenza, i cambiamenti) ci porteranno a questo ideale. I concorrenti perderanno tempo e sarà sempre più difficile per loro rifiutare un'ulteriore partecipazione (visto che le forze sono già state investite, e sembra che manchi ben poco alla vittoria). Ma in realtà la competizione a premi aumenterà, e i partecipanti dovranno sempre più rielaborare il progetto con correzioni da parte degli organizzatori nella speranza di vincere un premio. Di conseguenza, i ragazzi che non hanno preso premi, guardando indietro, si renderanno conto di aver partecipato al freelance senza soldi: hanno apportato modifiche al cliente, ma allo stesso tempo non hanno ricevuto nulla in cambio (tranne il corrispondente esperienza, ovviamente).
Moralità
Spesso i desideri e i feedback degli organizzatori vengono in aiuto del progetto. Nel fare ciò, tuttavia, i partecipanti non dovrebbero affidarsi ai consigli dei mentori come uno zoppo su un bastone. Se senti feedback dagli organizzatori sul tuo progetto nello spirito di "rimuovilo, non l'abbiamo ordinato", la tua partecipazione all'hackathon può essere considerata completata.
Se stai organizzando un hackathon con una visione chiara del progetto, ma senza le competenze o la capacità di implementarlo da solo, allora è meglio formattare la tua visione sotto forma di termini di riferimento di un libero professionista. Altrimenti dovrai pagare due volte: per l'hackathon e per i servizi di un libero professionista.
Fonte: habr.com