Costruire un Hackathon migliore: quattro principi fondamentali di LiveOps Hack Day
Keith McFarlane, capo architetto Keith McFarlane, capo architetto

Di recente abbiamo tenuto il nostro undicesimo evento LiveOps Hack Day ed è stato qualcosa di speciale; una serie di idee davvero interessanti hanno preso vita in sole 24 ore grazie agli sforzi di alcuni team e individui molto appassionati e dedicati. Alcuni degli hack mostrati al momento della demo sono stati:

  • Pivot to Video: il team coinvolto in questo ha trovato un modo per spostare una conversazione di chat dell'agente dal vivo nel mondo del video utilizzando tokbox.
  • Visualizzazione multicanale: il nostro team di segnalazione ha presentato un nuovo modo di guardare ai flussi di lavoro sovrapposti gestiti da un agente mentre si occupa di più elementi di lavoro contemporaneamente.
  • Agent Telephony in-Browser: l'ingegnere ha mostrato l'integrazione della nostra applicazione del pannello telefonico dell'agente con TwilioClient basato su JavaScript, che abilita le chiamate vocali utilizzando solo un PC.
  • Scriptable Callflow: alcuni dei nostri ingegneri della piattaforma hanno trovato un modo semplice per controllare le funzioni di telefonia granulare tramite l'API REST.
Questo è solo un sottoinsieme dei progetti completati questa volta; questi e altri potrebbero diventare prodotti in un futuro non troppo lontano.

Abbiamo lavorato per migliorare Hack Day nel corso degli anni da quando abbiamo tenuto il primo evento e, sebbene abbiamo apportato molte modifiche incrementali, abbiamo anche identificato una serie di principi fondamentali che possono creare o distruggere l'evento a seconda di quanto vengono seguiti da vicino.

1) I grandi hack vengono dal cuore, non dal backlog

Troppo spesso ho visto ingegneri o product manager provare a usare Hack Day come scusa per accelerare i loro elementi di backlog preferiti. Sebbene ciò ottenga certamente qualcosa di utile, vanifica il vero scopo dell'evento: l'innovazione. Gli sviluppatori dovrebbero usare questo tempo per perseguire i loro sogni software più sfrenati e provare nuove tecnologie. Lo stesso vale per i product manager; dovrebbero collaborare con gli sviluppatori per integrarsi con altri servizi Web in modi inaspettati o per tentare di definire e implementare un'idea che sembrerebbe rischiosa in circostanze normali. Dovrebbe essere un'opportunità per l'esplorazione, non come al solito in un ordine leggermente diverso.

Per gli sviluppatori, scegliere un elemento arretrato come progetto di un giorno di hack significa essenzialmente scherzare sulle priorità del team di gestione del prodotto. Pensa a tutti i pensieri e le discussioni che sono stati necessari per ottenere l'ordine delle storie giusto per la tua mischia, quindi immagina di ignorare tutto quel lavoro e di selezionare le storie a caso. Chiaramente il primo è preferibile al secondo.

Hack Day significa permettere che grandi idee emergano da luoghi inaspettati. Senza enfasi sulla ricerca di nuove idee piuttosto che su quelle esistenti, perde la maggior parte del suo valore.

2) Focus, focus, focus; scope creep uccide gli hack morti

Anche se qualsiasi nuova idea dovrebbe essere un gioco equo per il giorno dell'hacking, ho notato che i maggiori successi derivano da sforzi piccoli e mirati che mirano a completare una funzionalità minore ma preziosa o a dimostrare un concetto di grandi dimensioni attraverso un esempio ben definito che è portata limitata. Spesso, progetti come questo possono raggiungere il successo in anticipo e quindi aggiungere funzionalità quando il tempo lo consente. Inoltre, poiché le condizioni di vittoria sono ben definite, il team può abbandonare l'hack se si rivela troppo complesso e spostare la propria attenzione su un'altra idea.

Tutti gli sviluppatori hanno "grandi concetti" che fluttuano nelle loro teste; sfortunatamente, questi possono essere i più difficili da costruire, anche in forma limitata, come parte di Hack Day. Se vuoi perseguire con successo uno di questi grandi schemi sotto forma di hack, attira più persone nella discussione e trova un piccolo pezzo del puzzle che sta bene da solo, ma riesce comunque a ottenere il tuo punto di vista.

3) A volte ci vuole un villaggio per creare un hack

Alcuni hack sono così chiaramente definiti e di portata limitata che un singolo sviluppatore può realizzarli in tempo; tuttavia, per quanto sia complessa la maggior parte dei servizi Web, è molto più comune che qualsiasi hack veramente interessante richieda gli sforzi di diversi esperti in materia su una serie di piattaforme diverse.

Nel loro cuore, gli hackathon sono eventi sociali e riguardano tanto la squadra e il morale quanto l'innovazione. Se stai organizzando un evento Hack Day, fornisci un forum per la formazione del team prima dell'evento stesso; abbiamo tenuto una riunione di "reclutamento" pre-Hack-Day per diversi anni presso LiveOps, producendo combinazioni di team che potrebbero non verificarsi all'interno del normale flusso di lavoro del progetto e favorendo maggiori interazioni tra i team a lungo termine.

4) La distribuzione è la migliore ricompensa

Sì, è importante offrire una sorta di premio tangibile per il "miglior trucco", anche se tutti coloro che desiderano un iPad probabilmente ne hanno già uno. Tuttavia, non tutti gli sviluppatori hanno un'idea di prodotto da utilizzare come funzionalità in produzione; molti ingegneri possono lavorare per consentire le visioni dei product manager per anni senza che le proprie nozioni innovative vedano la luce del giorno. Se gli hack si mostrano promettenti come prodotti, o se sono immediatamente utilizzabili, dovrebbero essere avviati rapidamente alla produzione sia per il bene dell'azienda che come ricompensa per gli ingegneri coinvolti.

Ogni azienda di software (non solo le startup web) dovrebbe organizzare hackathon regolari per generare innovazione, aumentare la motivazione e migliorare le linee di comunicazione tra i team. Come per qualsiasi attività aziendale, tuttavia, esistono modi più efficaci e meno efficaci per svolgerla. Tieni traccia di ciò che funziona e non funziona, apporta miglioramenti nel tempo e ascolta il feedback dei partecipanti. Sebbene i principi di cui sopra abbiano funzionato molto bene per noi di LiveOps, molto probabilmente svilupperai una serie di linee guida che funzionano meglio per la tua organizzazione nel tempo.