Non sono affatto un grande esperto di data visualization ma rimango sempre colpito dall’efficacia dello strumento nel fornire informazioni di valore al solo sguardo. In particolare mi affascinano quelle rappresentazioni che mostrano l’evoluzione di un set di dati nel tempo.
Vedere muoversi le informazioni sullo schermo gli conferisce una dinamicità ed una comprensione che una forma tabellare non è in grado di restituire.
A questo punto era arrivato il momento di mettere le mani ad un pochino di codice e vedere se fossi stato in grado di tirare fuori qualcosa di utile dalla enorme mole di dati che abbiamo accumulato in Sketchin negli ultimi dieci anni.
La prima cosa che mi ha colpito è la mole delle informazioni, dirette ed indirette, che abbiamo a disposizione. Al di là dei dati puramente economici e finanziare c’è una enormità di informazioni che sono disponibili nei nostri sistemi e di cui raramente abbiamo fatto uso.
I dati che sono presenti nella nostra applicazione di time tracking, i dati che abbiamo su Salesforce, l’enorme mole di dati che abbiamo in Google ed i relativi metadati che sono molto succosi. Google Drive può essere una fonte di informazioni pazzesca se pensiamo ai metadati che sono disponibili ed alle API che permettono di manipolarli. Posso sapere quante persone hanno collaborato ad un documento, quanto tempo ci hanno speso sopra. Posso sapere con che ritmo la cartella di un progetto in essere cresce nel tempo. Sono in grado di valutare il flusso di messaggi di posta elettronica e tante altre cose che si dovrebbe cercare di capitalizzare per farne un uso strategico all’interno dello studio.
Come primo esperimento mi sono concentrato sui dati che provengono dalla nostra applicazione di time tracking, Harvest. All’interno della nostra tassonomia esistono due grandi insiemi di dati. Il tempo che noi consideriamo essere “billable”, ovvero il tempo speso su progetti che sono remunerati, ed il tempo che chiamiamo “unbillable” che contiene tutte quelle attività che non sono riconducili ad un progetto remunerato.
Quando parlo di Sketchin mi capita di riferirmi ad essa come ad un organismo vivente. Da questa considerazione mi è venuta l’idea. Perché non considerare Sketchin come un organismo dotato di un cuore che pulsa e rappresentare la salute dell’organismo con il battito cardiaco. Più regolare e costante è il battito cardiaco, maggiore è il buono stato di salute dell’organismo. Così come nel mondo reale un battito cardiaco accelerato o la presenza di aritmie sono un sintomo di qualcosa che non funziona alla perfezione.
Da questo punto di vista avevo due opzioni a disposizione. Usare come dati in ingresso i dati “billable” o, in alternativa, quelli “unbillable”. Ho deciso di utilizzare i primi perché in fondo il tempo a disposizione è finito e quindi i dati “unbillable” non sono altro che il complemento ai dati “billable”.
A questo punto ho lanciato il mio IDE e mi sono messo a scrivere un pochino di codice per verificare se questa mia idea era fattibile. E’ ovvio che l’idea è fattibile, il tema era se io fossi in grado di realizzarla.
Ho deciso di dividere l’applicazione in due grandi parti.
La prima parte si occupa di prelevare di dati da Harvest e di depositarli, opportunamente maneggiati, in un database SQLite 3. Non ho scelto database più impegnativi di questo perché avevo stimato di non avre bisogno di feature particolari e perché la mole di dati stava sotto qualche centinaia di migliaia di dati. In fondo avevo deciso di concentrarmi solo sui dati del 2022. In questo modo non ho dovuto installare nulla di particolare sul mio personal computer e, tutto sommato, avrei comunque avuto a disposizione un database che è abbastanza robusto per le mie necessità.
La seconda parte di occupa di leggere i dati dal database e di rappresentarli su una pagina di un browser sotto forma di elettrocardiogramma. Per ogni giorno si calcolano le ore “billable” registrate sul sistema, si normalizza il dato rispetto ad un battito cardiaco massimo e minimo e, giorno dopo giorno, si aggiorna la pagina web e la relativa rappresentazione grafica.
Rappresentare un elettrocardiogramma su una pagina web non è proprio una cosa banale ma, fortunatamente, Google aiuta. In pochi minuti ho trovato il lavoro di David Omar Flores Chávez che ha realizzato proprio quello che stavo cercando: Machine that goes Ping!.
Il codice era a disposizione, scaricabile e modificabile.
Ho scritto tutto in Python in una mezza giornata di una domenica uggiosa.
L’applicazione che legge i dati dal database SQLite invia le informazioni elaborate alla pagina web, opportunamente modificata, tramite websockets perché modifichi in tempo reale il battito cardiaco rappresentato nel singolo istante.
Devo dire che osservare il modificarsi del ritmo del battito cardiaco nel tempo è stato molto significativo ed utile. Si sono evidenziati dei picchi che si presentano quando ci avviciniamo alla fine del mese, o del quarto. Ci sono momenti di calma, come ad esempio la partenza di Gennaio che è stata molto soft.
E’ stata una esperienza interessante che oltre ad avermi dato la possibilità di analizzare dei dati in una forma non consueta mi ha permesso di imparare un paio di cose su tecnologie che non avevo mai maneggiato molto.