Questo articolo è comparso originariamente sul agile monocle, la mia newsletter in lingua inglese in cui parlo di agile non come un martello ma come una lente attraverso cui osservare il modo in cui lavoriamo.

---

Ogni volta che una nuova competenza inizia ad avere trazione ed essere sempre più richiesta ricadiamo automaticamente nella trappola della specializzazione: ci servono specialisti e ci ritroviamo a non sapere come integrare questi specialisti all’interno dei nostri team e progetti agili, e ci ritroviamo a dire cose come “la data science non è agile”.

Dato che in passato sono stato una persona che si occupava di dati, trovo molto interessante tutto quello che riguarda le opportunità e le difficolta di integrare la data science a livello organizzativo.

Questo articolo è un po’ più articolato del solito, perché questo è un tema su cui sto facendo ricerca e lavorando da un po’ di tempo, sono sicuramente interessato a lavorarci nel futuro, e quindi ho fatto un po’ di compiti.

I dati sono fuoco, non petrolio

Penso che quello che renda i dati e la data science leggermente diversi da altre competenze che in precedenza abbiamo dovuto integrare nei nostri prodotti e nei nostri progetti sia il fatto che viviamo in un’epoca in cui siamo testimoni della massima differenza tra la quantità di dati disponibili, sia privatamente che pubblicamente, e la quantità di persone che capiscono anche solo le basi della potenzialità dei dati.

Abbiamo quindi molti dati, una quantità in costante crescita di dati, e veramente poche persone davvero capaci di capirli — e no, per nessun motivo ha senso definire i dati come “nuovo petrolio”, una metafora più calzante è pensare ai dati come fuoco.

Come il fuoco, quindi, i dati possono essere usati bene o male, possono essere pericolosi oppure aiutarci, ma soprattutto, i dati devono essere capiti da molto più persone, quindi prima di passare a trucchi e consigli su come integrare la data science nei progetti e nei prodotti, credo sia il caso di pensare al tema della alfabetizzazione dei dati.

Prendendo spunto da questa interessante chiacchierata dalla Data Visualizazion Society riguardo l’alfabetizzazione dei dati, proverò a riassumere alcuni concetti chiave riguardo al significato della data literacy e come dovremmo agire al riguardo:

“91% on Americans feel like they lost control of their data, they don’t know what they can do to get it back […] for most people data are impenetrable and they are only for people with ‘rarified skills’, we [as data practitioners] have expected for people to come at our table, but it’s incumbent upon us [as data practitioners] to build communities around data literacy”

Mary Aviles
Freelance multi-sector human experience strategist and researcher

“With ‘data empathy’ you can understand the flow of data in the organization but most importantly you can understand the audience so you can understand that everyone doesn’t use data in the same way […] You don’t need to be a data scientist in order to be data literate […]”

Allen Hillery
Columbia University, Adjunct Faculty

“[…] people and context are important […] how data can be used in their day-to-day life? […] realize that every single situation or most situations and decisions that you make are based on data and if you can find a way to read and interpret that data for yourself you’ll probably find that you are making better decisions in the long run.”

Rama Raphalalani
Monitoring, Evaluation, Research & Learning Officer, Data Innovator

🛠 Adesso prova a fare questo: Da quella conversazione ho trovato questo template. Questo esercizio è accompagnato da questo ottimo articolo intitolato “The UX of Data” che spiega come e perché dovresti ridurre l’ambiguità e la confusione riguardo i dati nella tua organizzazion.

🛠 Oppure prova questo: potrebbe essere utile applicare un modello di maturità delle tue analytics per fare una pensata su quello che è il livello di comprensione dei dati nella tua azienda.

Sono dati, non spilli

Come dicevo nella introduzione, con nuovi bisogni servono nuove capacità, con nuove capacità ci rivolgiamo automaticamente agli esperti di un certo campo, creiamo nuovi titoli professionali, e tutto viene ridotto a “ci serve un data-qualcosa” oppure “abbiamo bisogno di un team di data-qualcosa”.

Questo è quello che chiamerei, basato al precedente tema di alfabetizzazione ai dati, una sorta di “esternalizzazione della alfabetizzazione”: a meno che si voglia fare un passo verso il miglioramento della comprensione dei dati nel nostro contesto, staremo sempre a girare in tondo al come integrare i dati nel nostro lavoro, nei nostri progetti e prodotti.

Ci sono sempre vie di uscita da questo circolo vizioso: prima di tutto smettiamola di considerare la persona data-qualcosa come fosse una specialista assoluta, rimossa da qualsiasi contesto. La persona data-qualcosa vive e respira dentro il contesto della tua industria, del tuo mercato, del tuo prodotto, del tuo team.

Questo è importante per due fattori

• A livello individuale, potremmo voler puntare su persone più generaliste. Questo è difficile da fare perché viviamo in un mondo che ancora valorizza più gli specialisti che i generalisti, ma “Working end-to-end provides increased context. While specialized roles can increase efficiency, it reduces context (for the data scientist) and leads to suboptimal solutions.”
• A livello di team, invece, sia esso un team interno in una grande aziende o una piccola agenzia, dovresti evitare di diventare “la fabbrichetta della data science”. Di nuovo, cadiamo vittme di vecchi modelli industriali per razionalizzare e ottimizzare il lavoro in termini di efficienza, a scapito della efficacia. “The goal of assembly lines is execution. […] But the goal of data science is not to execute. Rather, the goal is to learn and develop profound new business capabilities. […] With data science, you learn as you go, not before you go.”

Come si rompono questi silo della data science per le singole persone, per i team e intere aziende?

Allarga le tue competenze, non i tuoi titoli professionali

Abbiamo pensato a lungo che la specializzazione fosse qualcosa che solo le aziende più grandi potevano permettersi: aziende più grandi di solito hanno il lusso di poter assumere persone altamente specializzate e poi mettere branchi di manager a gestire l’inevitabile surplus comunicativo e di coordinamento.

Di conseguenza siamo portati a pensare che le aziende più piccole, non avendo quel lusso, sono intrinsecamente più fluide e generaliste nel modo in cui operano.

Questo non è sempre il caso, infatti possiamo avere:

• aziende o team piccoli che sono una replica esatta della “fabbrichetta della data science” menzionata poco sopra;
• granzi aziende che si stanno rendendo conto che non si possono permettere di gestire tutto il surplus comunicativo che deriva da un certo tipo di organizzazione.

Quindi se Netflix — non un’aziendina — si è accorta che non può mettere persone e team dentro dei silos, perché dovresti farlo tu?

“Below are three broadly defined personas to help illustrate some of the different backgrounds, motivations, and activities of individuals in the analytics role at Netflix. […] Ultimately, these skills are all on a continuum, some broad and some deep, and these are just a few examples of such expertise. So if you find yourself connecting with any part of these descriptions, the analytics role could be for you.”

Colgo lo spunto di “skills on a continuum”, competenze lungo uno spettro, da Netflix per introdurre il concetto di “flexing”:

“As a team goes about their work, the need to flex may arise to address disruptions, bottlenecks, and issues with flow through the system. Flexing in an agile context is when a team member (or members) temporarily contribute to a role or activity that is not their primary function.”

🛠 Adesso, prova questo: disegna il tuo processo di lavoro come nell’immagine qui sopra, metti in fila tutte le persone che contribuiscono, indica dove, come, quanto e con che livello di competenza. Vedrai dei “buchi”, vedrai opportunità, potrai iniziare a capire come puoi individuare e gestire colli di bottiglia, tempi di attesa, incomprensioni, dipendenze o semplici carenze di competenza. Per il massimo impatto e divertimento ti consiglio di fare questo esercizio non con un solo team ma coinvolgendone molti.

La data science è agile?

Sarò breve: in ultima istanza, i valori e i principi agili sono basati sull’empirismo, quindi se stai facendo data science stai intrinsicamente approcciando il tuo lavoro con metodo scientifico quindi non c’è davvero spazio per l’affermazione “la data science non è agile”.

Quello che si intende davvero quando si dice “la data science non è agile” è che non si riesce a incastrare il risultato di un team interno o un fornitore di data science (probabilmente sconnesso dal resto dell’organizzazione) al lavoro di un altro team Scrum (probabilmente disfunzionale).

Spero che queste riflessioni ti siano state utili e magari ti aiutino a fare qualche passo indietro rispetto ai “team che lavorano in sprint” e avere più visione di insieme: tornerò sull’argomento perché — come facilmente intuibile – c’è tanto da dire.