Accenture Digital Hackathon Novembre 2015

Com’è stato il primo Accenture Digital Hackathon?

Il primo Hackathon organizzato da Accenture, svoltosi dalle ore 9:00 del 28 Novembre 2015 fino alle ore 13:00 del 29 Novembre 2015, è stato davvero qualcosa di eccezionale, e non solo perché ci ha visto vincitori, ma anche per altri numerosi fattori: location, organizzazione, mentor, atmosfera, gadget, premi, giudici e cibo. Insomma le parole dello slogan di accenture “High performance. Delivered” si sono concretizzate in fatti.

Perché avete partecipato all’Hackathon?

Abbiamo partecipato per tre motivi principali:

1. Per vincere. Sapevamo che partecipare e vincere questo hackathon sarebbe stato un modo non indifferente per metterci in mostra nel mondo del lavoro; i premi sono stati secondari rispetto alla vittoria.
2. Per metterci in gioco. Ogni membro del team ha avuto la possibilità di poter applicare le proprie conoscenze ma, ancora più importante, ha avuto feedback sui propri punti di debolezza; certamente è meglio sbagliare in un ambiente controllato che in un futuro ambito lavorativo: per esempio, durante la gara ho creato una survey online per validare la nostra idea commettendo alcuni errori nella creazione della stessa, e perdendo così informazioni importanti.
3. Per conoscere persone motivate. Non è facile trovare persone della propria età che vogliano effettivamente fare un passo in più per costruirsi un futuro. Eravamo certi che avremmo trovato questa categoria di ragazzi, poiché non è da tutti rinunciare ad un intero weekend con amici e fidanzati, dopo una “dura” settimana universitaria.

Quali sono state le tematiche dell’hackathon?

Le tematiche dell’Hackathon sono state: “Smart Mobility” e “Greenification“. Quando sono uscite le tematiche siamo rimasti un po’ sorpresi perché ce ne aspettavamo altre, legate agli ambiti Retail, Health, Banking, Telco e Comunications. Ovviamente è stata una piacevole sorpresa.

Chi sono i membri del team per l’hackathon?

Partendo dalla sinistra nell’immagine sopra, il team era costituito da:

♠ Riccardo Bianchi: frontend developer. Studente iscritto al 3° anno della LT di “Informatica” all’ Università degli Studi di Milano.

♠ Matteo Marzorati: designer. Studente iscritto al 3° della LT in “Design della Comunicazione” al Politecnico di Milano.

♠ Markus Ambrose: Marketing Specialist. Studente iscritto al 2° anno della LM in “Marketing e Mercati Globali” alla Università degli Studi di Milano Bicocca.

♠ Fabio Lipreri: backend developer. Studente iscritto al 3° anno della LT di “Informatica” all’ Università degli Studi di Milano.

♠ Federico Colmegna: backend developer. Studente iscritto al 3° anno della LT di “Informatica” all’ Università degli Studi di Milano.

Era la prima volta che il nostro team, così costituito, partecipava ad un Hackathon. Prima della competizione non ci conoscevamo tutti: per esempio, Matteo ha incontrato di persona tutta la squadra solamente il mercoledì antecedente all’evento. E per quanto mi riguarda, avevo visto Federico solamente una volta, durante il compleanno di Riccardo.

Come è nata l’idea?

L’idea è nata qualche giorno prima dell’Hackathon, precisamente un mercoledì sera al BhangraBar in zona Arco della Pace, a Milano: ci siamo ritrovati per fare un brainstorming, così da poter trovare un paio di idee, una per ogni tematica, e non presentarci completamente impreparati. I nostri progetti erano limitati dal fatto di non sapere se avremmo avuto delle restrizioni tecnologiche o meno.

Quale tecnologie sono state utilizzate per il backend e perché?

Le scelte tecnologiche per il backend sono state nodejs e mongodb, il tutto su una macchina virtuale AWS. Il server serve delle API, in modo tale da svincolare il backend dagli eventuali front­end (per l’hackathon avevamo solo un’applicativo android ma in una situazione più realistica si potrebbero avere applicazioni mobile per diversi device, una applicazione web etc.), poiché nel caso in cui si abbia la necessità di dover migliorare un determinato servizio (renderlo più performante, o aggiungere funzionalità), le app continueranno a fare la richiesta alle stesse API, riducendo le modifiche da eseguire su di esse.

Qual è stato la sfida più difficile per il back-end e perché?

♠ Fabio: “La problematica maggiore è stata configurare il login con Facebook che per svariati motivi ci ha portato via 7 ore, inoltre sia mongodb che nodejs erano tecnologie da noi poco conosciute. Abbiamo voluto utilizzarle come sfida in un’ottica di learn by doing.  Questo ci ha fatto sprecare molto tempo in quanto abbiamo dovuto cercare sul web risposte a questioni, che, con un po’ più di esperienza, avremmo risolto facilmente”.

♠ Federico: “Il database senza ombra di dubbio. Dal mio punto di vista mongodb non è stata una scelta azzeccata in quanto non avevamo esperienza. Abbiamo rischiato di non presentare niente alla giuria”.

Quale tecnologie sono state utilizzate per il frontend e perché?

♠ Riccardo: “Per il frontend è stato deciso di sviluppare un’ app nativa per android per due motivi; il primo è molto semplice: nessuno sapeva programmare in iOS; Il secondo si deve al fatto che la piattaforma fornisse mezzi implementativi per alcune idee costituitive del progetto”.

Qual é stato la sfida più difficile per il frontend e perché?

♠ Riccardo: “Le maggiori difficoltà sono state due: la prima è stata quella di consumare le APIs fornite dal backend senza tuttavia implementare un sistema che richiedesse troppa progettazione, è stato quindi molto difficoltoso trovare un compromesso fra velocità di sviluppo ed affidabilità del codice senza testing di progettazione; la seconda difficoltà è stata quella di mantenere un gemellaggio delle strutture dati fra il backend ed il client, con linguaggi tipizzati statisticamente (Kotlin) e dinamicamente (Javascript)”.

Quali sono state le schermate più difficili da progettare in 24 ore?

♠ Matteo: “La maggior difficoltà nel progettare le schermate l’ho trovata nello sketchare la home. Una semplice icona e un logo non potevano bastare a trasmettere quell’idea di divertimento e di ironia che volevamo infondere negli utenti. Trattandosi principalmente di un gioco di scommesse, con schedine dal molto testo, ho optato per la creazione di una home dal forte impatto visivo e senza testo – sempre in linea con i nostri valori – che in qualche modo potesse aiutare l’utente, frustrato dal disagio, a sorridere e a sentirsi accolto in una stazione idilliaca e colorata dove il ritardo viene sentito come un momento di gioco.“

Come avete bilanciato le meccaniche di gioco? In che modo l’utente potrà visualizzare e lanciare una scommessa?

♠ Matteo: “Sicuramente una delle sfide più grandi è stata proprio questa: bilanciare un gioco in modo tale da renderlo sempre avvincente non è cosa semplice e nel mercato molti buoni videogame hanno fallito proprio in questo tentativo. Tenendo a mente i valori dell’applicazione e mantenendo coerenti con le nostre linee guida, abbiamo pensato a delle schermate facilmente fruibili, non intasate da troppo testo, bensì divise tra loro per scelta di tratta e direzione, in seguito orari, scelta dell’importo da scommettere – fisso in caso si scommetta contro il banco, senza un tetto nel caso si scommetta con un amico – e infine, come ultima finestra, la scelta del ritardo e il conseguente invio della sfida”.

Quali sono stati gli errori che avete commesso durante l’hackthon?

♠ Riccardo: “Ho perso un po’ di tempo su piccoli dettagli che alla fine non si sono rivelati fondamentali. Nel gruppo, un ‘errore’, che ha però contribuito a portarci alla vittoria, è stato la scelta di utilizzare tecnologie nuove per metterci in gioco: è stato un po’ un azzardo in quanto abbiamo rischiato di non consegnare una mvp funzionante. Il routerino mai arrivato ha reso più faticoso il tutto :)”.

♠ Fabio: “La nostra applicazione funzionava ma non aveva tutto implementato, la prossima volta adotterei un approccio diverso: sceglierei due o tre funzionalità fondamentali dell’app (che ci rendano diversi dagli altri team, e che riteniamo punti di forza della nostra idea etc.) e mi concentrerei su quelle, perché è inutile focalizzare la nostra attenzione su elementi già presenti in tutte le app esistenti (lista degli amici di fb, sezione profilo utente etc.)”.

♠ Federico: “Per quanto riguarda il team per me c’è stata poca organizzazione nelle task. Ognuno aveva i suoi compiti ma non avevamo fatto stime di tempo né impostato obiettivi minimi. Per quanto mi riguarda non avevo dimestichezza con l’ambiente di sviluppo per il backend quindi ho dovuto prepararmi prima per potermi interfacciare con nodejs.”

♠ Matteo: “Ciò che più mi rimprovero è stata la progettazione delle schermate ad alto livello direttamente su Illustrator, con pochissimi sketch a mano di supporto: il tempo era tiranno e mi sono fatto prendere, in certi tratti, dalla foga di concludere il tutto il prima possibile per poter avviare una comunicazione stretta con Riccardo. Nel progettare le illustrazioni della home ho perso del tempo che avrebbe giovato in altri campi, poiché la scelta tra 2D isometrica o flat ha risucchiato le mie energie per almeno due ore”.

♠ Markus: “Come team dovevamo dedicare sicuramente almeno un’ora in più alla fase progettazione delle varie task, in modo da poter sviluppare un gantt o una timeline del progetto. Grazie ad esso avremmo potuto pivottare più agilmente. Personalmente ho sbagliato a sviluppare la struttura e qualche domanda  della survey. Ho perso tre ore in una sentiment analysis su Trenord senza riuscire poi a mettere il dato nelle slide”.

Svilupperete l’applicazione o rimarrà soltanto un’idea?

Abbiamo deciso di sviluppare l’applicazione, e questo anche perché ci sono arrivate molte richieste; non sappiamo se questa scelta ci condurrà ad un lieto fine, ma siamo sicuri che sarà un modo molto efficace per mettere sul campo quello che abbiamo appreso sui banchi dell’università nonchè per imparare cose nuove.