A che tipo di gruppo partecipi solitamente agli hackathon? Inizialmente, abbiamo affermato che il team ideale è composto da cinque persone: un manager, due programmatori, un designer e un marketer. Ma l'esperienza dei nostri finalisti ha dimostrato che puoi vincere un hackathon con un piccolo team di tre persone. Delle 26 squadre che hanno vinto la finale, 3 hanno gareggiato e vinto con i moschettieri. Come hanno fatto: continua a leggere.
Abbiamo parlato con i capitani di tutte e tre le squadre e abbiamo capito che la loro strategia ha molto in comune. Gli eroi di questo post sono i team PLEXeT (Stavropol, nomina del Ministero delle Telecomunicazioni e delle Comunicazioni di massa), “Composite Key” (Tula, nomina del Ministero dell'Informazione e delle Comunicazioni della Repubblica del Tatarstan) e Jingu Digital (Ekaterinburg, nomina del Ministero dell'Industria e del Commercio). Per chi fosse interessato, sotto il cat è nascosta una breve descrizione dei comandi.
Descrizioni dei comandiPLEXeT
Il team è composto da tre persone: uno sviluppatore (competenze web, C++, sicurezza informatica), un designer e un manager. Non ci conoscevamo prima dell’hackathon regionale. La squadra è stata assemblata dal capitano sulla base dei risultati dei test online.
Chiave composita
Il team è composto da tre colleghi sviluppatori: fullstack con dieci anni di esperienza in IT, backend e dispositivi mobili e backend con particolare attenzione ai database.
Jingu digitale
Il team è composto da due programmatori: backend e AR/Unity, oltre a un designer che era anche responsabile della gestione del team. Ha vinto la nomina del Ministero dell'Industria e del Commercio
Scegli un compito vicino alle tue competenze
Ricordi che c'era una rima del genere "club di teatro, club di fotografia e voglio anche cantare"? Penso che molte persone abbiano familiarità con questa sensazione: quando tutto intorno a te è interessante, vuoi mostrarti in un modo nuovo nella tua direzione e provare un nuovo settore/area di sviluppo. La scelta qui dipende solo dagli obiettivi della tua squadra e dalla volontà di correre dei rischi: puoi accettare il tuo errore se all'improvviso nel bel mezzo dell'hackathon ti rendi conto che non è realistico risolvere questo problema? Gli esperimenti nella categoria "Non sono bravo nello sviluppo mobile, ma che diavolo è?" non sono per tutti. Sei un tipo dilettante?
Artem Koshko (), comando “Chiave composita”: “Inizialmente avevamo pianificato di provare qualcosa di nuovo. A livello regionale, abbiamo provato diversi pacchetti nuget, a cui non siamo mai riusciti, e Yandex.Cloud. Alla fine, abbiamo distribuito CockroachDB in Kubernetes e abbiamo provato a eseguire le migrazioni utilizzando EF Core. Alcune cose sono andate bene, altre meno. Quindi abbiamo imparato cose nuove, ci siamo messi alla prova e ci siamo assicurati dell’affidabilità degli approcci collaudati”..
Come scegliere un'attività se i tuoi occhi vagano:
- Pensa a quali competenze sono necessarie per risolvere questo caso e se tutti i membri del team le possiedono
- Se ti mancano le competenze, puoi compensarle (trovare un'altra soluzione, imparare rapidamente qualcosa di nuovo)
- Conduci una breve ricerca sul mercato per il quale realizzerai un prodotto
- Calcola la concorrenza: a quale percorso/azienda/attività andrà la maggior parte delle persone?
- Rispondi alla domanda: cosa ti spingerà di più?
Oleg Bakhtadze-Karnaukhov (), comando PLEXeT: “Abbiamo deciso di fare una sosta di dieci ore all'aeroporto: proprio al momento dell'atterraggio, nella nostra posta è arrivato un elenco di tracce e una breve descrizione dei compiti. Ho immediatamente identificato quattro compiti che erano interessanti per me come programmatore e per i quali il piano d'azione dopo l'inizio era chiaro: cosa deve essere fatto e come lo faremo. Quindi ho valutato i compiti di ciascun membro del team e valutato il livello di competizione. Di conseguenza, abbiamo scelto tra i compiti di Gazprom e del Ministero delle telecomunicazioni e delle comunicazioni di massa. Il padre del nostro designer lavora nel settore del petrolio e del gas; lo abbiamo chiamato e gli abbiamo posto domande sul settore. Alla fine, ci siamo resi conto che sì, è interessante, ma non saremo in grado di offrire nulla di fondamentalmente nuovo e sicuramente non saremo in grado di eguagliare le competenze, perché ci sono troppe specificità del settore che devono essere prese in considerazione account. Alla fine abbiamo preso un rischio e siamo andati sulla prima pista”.
Diana Ganieva (), il team Jingu Digital: “Nella fase regionale avevamo un compito legato all'agricoltura, e nella fase finale – AR/VR nell'industria. Sono stati scelti da tutta la squadra in modo che ogni persona potesse realizzare le proprie capacità. Poi abbiamo eliminato ciò che non trovavamo così interessante”.
Fai i tuoi compiti
E non stiamo parlando della preparazione del codice adesso: generalmente è inutile farlo. Riguarda la comunicazione all'interno della squadra. Se non avete ancora giocato insieme, non avete imparato a capirvi e a mettervi d'accordo, riunitevi un paio di volte in anticipo e simulate un hackathon, o almeno chiamatevi per parlare dei punti principali, pensate attraverso un piano d'azione e discutere i reciproci punti di forza e di debolezza. Puoi anche trovare qualche caso e provare a risolverlo, almeno schematicamente, al livello di "come andare dal punto A al punto B".
Durante questo paragrafo corriamo il rischio di cogliere degli svantaggi nel karma e nei commenti, dicendo, com'è possibile, non capisci niente, ma che dire dell'eccitazione, della spinta, della sensazione che ora un prototipo nascerà dal primordiale? brodo (ciao, lezioni di biologia).
Si ma.
L'improvvisazione e la spinta sono buone solo quando diventano solo una leggera deviazione dalla strategia, altrimenti i rischi sono troppo grandi per dedicare tempo a ripulire il caos e correggere gli errori, invece di lavorare, mangiare o dormire.
Oleg Bakhtadze-Karnaukhov, squadra PLEXeT: “Non conoscevo nessuno dei membri del mio team prima della competizione; li ho selezionati e invitati in base alle loro competenze e valutazioni in fase di test online. Quando abbiamo vinto l'hackathon regionale e ci siamo resi conto che dovevamo ancora andare insieme a Kazan e finire il progetto dell'hackathon a Stavropol, abbiamo deciso che ci saremmo riuniti e ci saremmo allenati. Prima della finale ci siamo incontrati due volte: abbiamo trovato un problema casuale e lo abbiamo risolto. Qualcosa come un campionato di casi. E già in questa fase abbiamo riscontrato un problema nella comunicazione e nella distribuzione dei compiti: mentre Polina (designer) e Lev (manager) pensavano allo stile aziendale, alle caratteristiche del prodotto, alla ricerca di dati di mercato, io avevo molto tempo libero. Quindi ci siamo resi conto che dovevamo affrontare una nomina più difficile (non mi vanto, semplicemente ci siamo imbattuti per lo più in compiti legati al web, ma per me sono solo uno o due) e che avevo bisogno di essere più coinvolto nei processi di lavoro . Di conseguenza, alle finali, durante la ricerca preliminare, ero impegnato nella modellazione matematica e nello sviluppo di algoritmi”.
Artem Koshko, team di Composite Key : “Ci siamo preparati più mentalmente, non si è parlato di preparare un codice. Avevamo già assegnato in anticipo i ruoli nel team: noi tre siamo tutti programmatori (abbiamo uno stack completo e due backend, in più so qualcosa di sviluppo mobile), ma era chiaro che qualcuno avrebbe dovuto assumersi il compito ruoli di progettista e manager. È così che, a mia insaputa, sono diventato un team leader, mi sono messo alla prova come analista aziendale, relatore e creatore di presentazioni. Penso che se non ne avessimo parlato in anticipo non saremmo riusciti a gestire correttamente il tempo e non saremmo arrivati alla difesa finale”.
Diana Ganieva, Jingu Digital: “Non ci siamo preparati per l’hackathon perché crediamo che i progetti di hacking debbano essere realizzati da zero: è giusto. In anticipo, nella fase di selezione dei brani, avevamo un'idea generale di ciò che volevamo fare".
Non puoi lavorare solo con gli sviluppatori
Diana Ganieva, team Jingu Digital: “Abbiamo tre specialisti in diversi settori nel nostro team. Secondo me questa è la composizione ideale per un hackathon. Ognuno è impegnato con i propri affari e non vi è alcuna sovrapposizione o divisione dei compiti. Una persona in più sarebbe superflua”.
Le statistiche hanno dimostrato che la composizione media dei nostri team va da 4 a 5 persone, incluso (nella migliore delle ipotesi) un designer. È generalmente accettato che sia necessario rafforzare il team con sviluppatori di diverse fasce, per poter sia aggiungere al database che sorprendere con una "macchina" se succede qualcosa. Nella migliore delle ipotesi, portano comunque con sé un designer (non offenderti, ti adoriamo!), La presentazione e le interfacce alla fine non si disegneranno da sole. Il ruolo di manager viene trascurato ancora più spesso: di solito questa funzione è assunta dal capitano della squadra, uno sviluppatore part-time.
E questo è fondamentalmente sbagliato.
Artem Koshko, team di Composite Key: “Ad un certo punto, ci siamo rammaricati di non aver assunto uno specialista specializzato nella squadra. Anche se in qualche modo siamo riusciti a far fronte alla progettazione, è stato difficile farlo con il business plan e altri aspetti strategici. Un esempio lampante è quando è stato necessario calcolare il pubblico target e il volume del mercato, TAM, SAM.”
Oleg Bakhtadze-Karnaukhov, squadra PLEXeT: “Il contributo dello sviluppatore al prodotto è ben lungi dall’80% del lavoro, come comunemente si crede. Non si può dire che sia stato più facile per i ragazzi: quasi la maggior parte dei compiti spettava a loro. Il mio codice senza interfacce, presentazioni, video, strategie è solo un insieme di simboli. Se nel team ci fossero stati più sviluppatori invece di loro, probabilmente ce l'avremmo fatta, ma tutto sarebbe sembrato meno professionale. Soprattutto la presentazione è generalmente la metà del successo, come mi sembra. Durante la difesa e poi nella vita reale in un paio di minuti, nessuno avrà il tempo di capire se il tuo prototipo funziona davvero. Se ti lasci trasportare dagli schemi, nessuno ti ascolterà. Se esageri con il testo, tutti capiranno che tu stesso non sai cosa è importante nel tuo prodotto, come presentarlo e chi ne ha bisogno”.
Gestione del tempo e relax
Ricordi come nei cartoni animati dell'infanzia come "Tom e Jerry" i personaggi mettevano i fiammiferi sotto le palpebre per impedirne la chiusura? I partecipanti all'hackathon inesperti (o eccessivamente entusiasti) sembrano più o meno gli stessi.
Durante un hackathon, è facile perdere il contatto con la realtà e il senso del tempo: l'atmosfera favorisce una programmazione sfrenata senza pause per riposare, dormire, scherzare nella sala giochi, comunicare con i partner o frequentare corsi di perfezionamento. Se consideri tutto questo come i Campionati del Mondo o le Olimpiadi, allora sì, forse è così che dovresti comportarti. Non proprio.
Artem Koshko, team di Composite Key: “Abbiamo fatto tanto chak-chak, tantissimo: al centro del nostro tavolo è stata costruita una torre che ci teneva alto il morale e ci dava i carboidrati al momento giusto. Ci siamo riposati e abbiamo lavorato quasi tutto il tempo insieme e non ci siamo riposati separatamente. Ma dormivano diversamente. Ad Andrey (sviluppatore fullstack) piace dormire durante il giorno, a me e Denis piace dormire la notte. Pertanto, ho lavorato di più con Denis durante il giorno e con Andrey di notte. E dormiva durante le pause. Non avevamo alcun sistema di lavoro o di definizione dei compiti, anzi tutto era spontaneo. Ma questo non ci ha disturbato, perché ci capiamo bene e ci completiamo a vicenda. Ci ha aiutato il fatto che siamo colleghi e comunichiamo strettamente. Sono l'ex stagista di Andrey e Denis è venuto in azienda come mio stagista.
E qui, a proposito, c'è la stessa montagna chak-chak.
Quasi tutti i partecipanti da noi intervistati hanno indicato nella gestione competente del tempo il criterio principale per il successo dell'hackathon. Cosa significa? Distribuisci le attività in modo da avere tempo per dormire e mangiare e le attività non vengono completate in modo regolare. tutto è crollato, ma a un ritmo confortevole per ciascun membro del team.
Oleg Bakhtadze-Karnaukhov, squadra PLEXeT"Il nostro obiettivo non era lavorare quante più ore possibile, ma rimanere produttivi il più a lungo possibile. Anche se dormivamo 3-4 ore al giorno, sembrava che ci riuscissimo. Potremmo andare nella sala giochi o frequentare gli stand dei nostri partner e dedicare il tempo normale al cibo. Il secondo giorno, abbiamo cercato di alleviare il più possibile Lev in modo che potesse dormire a sufficienza e avere il tempo di rimettersi in ordine prima dello spettacolo. Le prove dell'hackathon ci hanno aiutato, poiché avevamo già capito come distribuire i compiti e come sincronizzare la routine quotidiana: mangiavamo, dormivamo ed eravamo svegli allo stesso tempo. Di conseguenza, hanno funzionato come un unico meccanismo”.
Non sappiamo come questo team sia riuscito a portare Agomoto’s Eye all’hackathon, ma alla fine sono riusciti anche a girare un video sul progetto e a preparare una dispensa.
Alcuni suggerimenti per la gestione del tempo durante un hackathon:
- Passa dal grande al piccolo: suddividi le attività in piccoli blocchi.
- Un hackathon è una maratona. Qual è la cosa più importante in una maratona? Prova a correre allo stesso ritmo, altrimenti cadrai alla fine della distanza. Cerca di lavorare all'incirca alla stessa intensità e non spingerti fino all'esaurimento.
- Pensa in anticipo quali saranno i compiti di ciascun partecipante e quanto tempo gli occorrerà. Ti aiuterà a evitare sorprese quando manca mezz'ora alla scadenza e non hai un grosso lavoro pronto.
- Controlla le coordinate per regolare l'ambito delle attività. Pensi che stai andando bene e che ti sia rimasto del tempo? Fantastico: puoi spenderlo per dormire o finalizzare la tua presentazione.
- Non fissarti sui dettagli, lavora a grandi linee.
- È difficile prendersi una pausa dal lavoro, quindi dedica del tempo appositamente al sonno, al relax o al relax. È possibile impostare, ad esempio, degli allarmi.
- Prenditi del tempo per preparare e provare il tuo discorso. Questo è obbligatorio per tutti e sempre. Ne abbiamo parlato in uno dei precedenti .
E c'è anche questa opinione alternativa. Per quale opzione sei: tortura tramite codifica o guerra con la guerra e pranzo secondo un programma?
Diana Ganieva, team Jingu Digital: “Ogni persona nel nostro team è responsabile di una cosa, non c’era nessuno a sostituirci, quindi non potevamo lavorare a turni. Quando non c'erano più forze, abbiamo dormito per tre ore, a seconda della quantità di lavoro che rimaneva ancora al partecipante. Non c'era assolutamente tempo per uscire, non perdiamo tempo prezioso con questo. La produttività è stata supportata, anche se con un sonno breve e alcune prelibatezze con il tè, senza bevande energetiche o caffè.
Nascosti sotto il taglio ci sono diversi collegamenti utili se vuoi approfondire l'argomento della gestione del tempo. Tornerà utile nella vita di tutti i giorni - credi all'autore di questo post, che è sempre in ritardo :)
Per i conquistatori del tempo — Tecniche efficaci di gestione del tempo sono state raccolte nel blog Netology da un project manager di Kaspersky Lab:
— Un buon articolo per principianti su Cossa:
Cerca di distinguerti
Sopra abbiamo scritto del team che ha realizzato un volantino per proteggere il progetto. Erano gli unici nel loro percorso, e siamo certi che tra gli oltre 3500 partecipanti non ce n'erano altri come loro.
Naturalmente, questo non è stato il motivo principale della loro vittoria, ma ha sicuramente portato un ulteriore vantaggio, almeno la simpatia degli esperti. Puoi distinguerti in diversi modi: alcuni dei nostri vincitori iniziano ogni esibizione con una battuta su come hanno realizzato una bomba (squadra Sakharov, ciao!).
Non ci soffermeremo su questo in dettaglio, ma condivideremo semplicemente un caso del team PLEXeT: pensiamo che sia degno di diventare uno scherzo sul figlio di un'amica di madre.
Oleg Bakhtadze-Karnaukhov, squadra PLEXeT: “Ci siamo resi conto che eravamo in vantaggio e abbiamo deciso che sarebbe stato bello presentarsi in pre-difesa con un caso di trasferimento. Il progetto contiene molti dettagli tecnici, spiegazioni di algoritmi, che non sono affatto inclusi nella presentazione. Ma voglio mostrarlo. Gli esperti hanno supportato l’idea e hanno persino contribuito a ottimizzarla. Non hanno nemmeno guardato la prima versione, hanno detto che non avrebbero mai letto un dipinto del genere. Eravamo gli unici in difesa”.
Qualcosa è destinato ad andare storto, e va bene così.
Durante un hackathon, come nella vita di tutti i giorni, c'è sempre spazio per gli errori. Anche se sembra che abbiate pensato a tutto, chi di noi non è arrivato in ritardo a un aereo/esame/matrimonio semplicemente perché le auto hanno deciso di rimanere bloccate nel traffico, la scala mobile ha deciso di rompersi e il passaporto è stato dimenticato? a casa?
Oleg Bakhtadze-Karnaukhov, squadra PLEXeT: “Io e Polina abbiamo passato tutta la notte a fare una presentazione, ma alla fine si sono dimenticati di caricarla sul computer nella sala dove si è svolta la difesa. Proviamo ad aprirlo da un'unità flash e l'antivirus percepisce il file come un virus e lo elimina. Di conseguenza, siamo riusciti a far iniziare tutto solo un minuto prima della fine della nostra esibizione. Siamo riusciti a mostrare il video, ma eravamo ancora molto turbati. Una storia simile è accaduta a noi durante la pre-difesa. Il nostro prototipo non si è avviato, i computer di Polina e Lev si sono bloccati e per qualche motivo ho lasciato il mio nell'hangar dove si trovava la nostra pista. E anche se gli esperti hanno visto il nostro lavoro la mattina, sembravamo una squadra di eccentrici con volantini, belle parole, ma nessun prodotto. Considerando che molti partecipanti percepivano il mio lavoro sui modelli matematici come “è seduto, disegna qualcosa, senza guardare il computer”, la situazione non era molto buona.
Sembrerà banale, ma tutto ciò che puoi fare in questa situazione è espirare. E' già successo. No, non sei l'unico, tutti sbagliano. Anche se questo è un errore fatale, è un’esperienza. E pensa anche, la persona che ti sta valutando considererà questo caso un fakap?
Condividi nei commenti quale composizione ti senti più a tuo agio lavorando a un hackathon (sia persone che specialisti) e come costruisci processi in un team.
Fonte: habr.com