Quale non è il ruolo del Data Scientist in azienda

Negli ultimi anni la figura del Data Scientist si è sempre più diffusa in azienda affermandosi come ruolo fondamentale. I Data Scientist sono presenti a tutti i livelli dello sviluppo del prodotto. Iniziando dalla direzione di sviluppo fino alla messa in produzione passando per l’analisi dei dati.

Parallelamente a questa grande, e giusta, diffusione del ruolo del Data Scientist nelle aziende si sono anche diffuse idee spesso esagerate e sicuramente erronee. Questo ha spesso reso il Data Scientist una figura mitica dotata di poteri taumaturgici e quasi magici per ogni azienda.

In questo articolo voglio sfatare alcuni di questi miti e spiegare esattamente cosa NON è e cosa invece è un Data Scientist, spiegando anche quale è il suo ruolo in un’azienda. Lo farò prendendo spunto dalla mia esperienza personale di Data Scientist a Booking.com

Iniziamo dalle incomprensioni più frequenti.

Il ruolo del Data Scientist NON è avere QUALSIASI risposta sui dati in azienda

Un errore molto comune è vedere nel Data Scientist la persona che si occupa di ogni cosa riguardante i dati in un’azienda, ed è capace di rispondere ad ogni possibile domanda non solo ricavata DAI dati ma anche SUI dati. Questo errore deriva dall’idea che sia sufficiente un Data Scientist per risolvere qualsiasi problema di dati di un’azienda.

Al contrario, è fondamentale prima di tutto mettere il Data Scientist nella condizione di lavorare e poter generare quegli insights dai dati che sono la sua vera specialità. Per questo c’è bisogno di un ambiente intorno che permetta di lavorare nel modo corretto.  Questo significa non solo avere a disposizione dati, ma soprattutto dati ben strutturati e il più possibile affidabili e puliti

È necessario che questo background e questi dati siano messi a disposizione del Data Scientist dall’inizio del suo lavoro per permettere di poter ricavare quei desiderati insights dai dati. Questo vuol anche dire che ogni azienda che pensi di utilizzare i propri dati per prendere decisioni migliori ed avere un miglior controllo sul suo sviluppo del prodotto deve prima considerare lo stato attuale dei suoi dati e muoversi il più presto possibile verso una situazione di raccolta e storage dei dati il più “intelligente” possibile. Questo può avere molti significati su diversi livelli. Dalla raccolta iniziale, alle decisioni di storing fino al livello più basso come possono essere la scelta dei data scheme. 

Esempi a Booking.com

A Booking.com ad esempio utilizziamo tool interni che aiutino nella discovery e documentazione delle tabelle esistenti. Questo permette ad ogni Data Scientist di usufruire di dati creati e curati da altri team. Abbiamo anche un team di data engineers che si occupa dello store ottimale dei dati così che possano essere utilizzati nel modo più rapido ed efficiente possibile. 

Questo lavoro preparatorio è solitamente svolto da software developer o per casi più specifici data engineers e data architect. In assenza di questo, è molto difficile attendersi soluzioni miracolose a parte dei Data Scientists. Questo ci porta al prossimo mito da sfatare.

Il Data Scientist non è un salvatore e non può fare magie

Se non c’è una buona infrastruttura di base per la raccolta di dati e quindi il Data Scientist si trova davanti a dati inesistenti o molto “sporchi”, non è possibile aspettarsi miracoli, e spesso semplicemente neanche risultati utilizzabili. Questo problema è generalmente riassunto con la massima “garbage in, garbage out”. Le tecniche di analisi e di statistica utilizzate infatti sono sensibili alla qualità dei dati e trovandosi di fronte ad una bassa qualità dei dati possiamo solo aspettarci una scarsa qualità di risultati. È importante quindi avere una visione realistica dei dati che si hanno a disposizione per aver una realistica aspettativa dei risultati che si possono ottenere. 

In pratica questo si traduce spesso nell’utilizzare prima figure più legate allo sviluppo tecnico del prodotto per generare dati: software developers e data engineers. Allo stesso tempo è importante che i dati e la loro struttura vengano considerati come priorità dall’inizio per avere un corretto logging e storage così da poter essere usati nel modo migliore possibile per generare insights.

Per aziende giovani o con un approccio non corretto ai dati questo non deve essere un motivo per scoraggiarsi o lasciare perdere la materia. Anzi, deve essere visto come un obiettivo ed una motivazione per cominciare a raccogliere dati correttamente e investire nelle giuste infrastrutture. È anche utile tenere presente che data science non è sinonimo di big data e non sono sempre necessarie enormi moli di dati per avere risultati incoraggianti (vedere al punto sotto)! Purché siano di buona qualità, chiaramente 🙂

Data Science NON è (solo) applicare i più recenti algoritmi di Machine Learning e Deep Learning

Argomenti come machine learning, deep learning, reti neurali e simili sono ormai diventati estremamente diffusi e quasi sinonimo di data science. Se è vero che molte di queste tecniche fanno parte stabilmente delle toolbox di un Data Scientist è altrettanto vero e ancora più importante precisare che sono solo una parte, e spesso non preponderante, del lavoro e delle tecniche utilizzate.

Queste tecniche infatti non solo sono spesso un’esagerazione per i problemi che il Data Scientist si trova usualmente ad affrontare ma spesso sono addirittura sbagliate per molti problemi. Ad esempio tecniche di deep learning, ovvero complessi modelli matematici basati su reti neurali con molti “strati”, si sono dimostrate molto valide per applicazioni legate all’analisi di testi ed immagini. In moltissimi altri casi tuttavia tecniche più semplici e robuste come modelli lineari o ad albero sono preferibili e più frequenti.

Ancora più frequente però è il caso in cui un Data Scientist può avere impatto nel prodotto utilizzando tecniche ancora più semplici, potenzialmente basate anche su semplici “euristiche”, cioè regole derivate dall’analisi dei dati. Questo approccio verso la tecnica più semplice ha anche il vantaggio produrre risultati semplici e facili da portare in produzione.

Esempi a Booking.com

Nella mia esperienza a Booking.com mi è spesso capitato che la prima soluzione messa in produzione per un problema nuovo fosse anche la più semplice.  Questo ha permesso ad esempio di avere subito risultati ed iterare velocemente sul prodotto, o, nel caso della cybersecurity, bloccare attacchi informatici in corso in modo rapido ed efficace. 

Ad esempio ho sviluppato algoritmi per la raccomandazione di hotel basati semplicemente sulla relazione tra hotel visti e prenotati. Ovvero, ad un utente che visualizza un determinato hotel vengono suggeriti gli hotel più prenotati da utenti che hanno visitato lo stesso hotel. 

Un altro esempio riguarda gli approcci per bloccare accessi fraudolenti al sito. Dopo aver fatto un’analisi vedendo il numero di accessi per ip o device per utenti buoni e cattivi si elabora una regola per bloccare tutti i tentativi di accesso sopra un certo numero di accessi per ip o device. Questo tipo di regole sono molto robuste e semplici da implementare, nonché da spiegare al management.

Avallare decisioni: i dati parlano e non vanno torturati per farli parlare

Una situazione frequente in cui possono trovarsi i Data Scientist ed in generale chi lavora coi dati è di essere usati come “giustificatori” per decisioni aziendali. Capita spesso infatti che al Data Scientist venga assegnato un compito tipo mostrare il valore di un certo prodotto o trovare dati a supporto di una certa decisione/cambiamento. Questo è l’esatto opposto del corretto utilizzo e scopo del Data Scientist. Lo scopo principale dei dati e del Data Scientist è infatti quello di analizzare i dati per GENERARE o PROPORRE nuove ipotesi e non per GIUSTIFICARE ipotesi esistenti.

Questo dipende da una serie di fattori, il primo fra tutti è che generalmente l’analisi di dati esistenti è fatta su dati non raccolti con lo scopo specifico di essere analizzati. Nello specifico non si possono trarre conclusioni causali da osservazioni oggettive, al massimo si possono osservare correlazioni che suggeriscono quindi ipotesi da testare. Questo concetto è spesso espresso in termini di “correlation does not imply causation”. L’altro motivo è che senza utilizzare metodologie solide e concetti chiari sostanzialmente si può trarre qualsiasi conclusione dai dati. Questo è soprattutto vero in un contesto di sovrabbondanza di dati e dimensioni lungo le quali sezionare di dati.

Esempi a Booking.com

A Booking.com ad esempio il Data Scientist si occupa di analizzare i dati preliminarmente per generare ipotesi da testare insieme ai Product Manager. Queste ipotesi vengono testate tramite A/B test e solo e soltanto quando proveranno di essere corrette tramite il test vengono approvate. L’A/B testing infatti è l’unico metodo valido per trarre conclusioni causali dai dati. Questo perché permette di testare un’ipotesi specifica decorrelandola da tutte le altre variabili.

Il Data Scientist non lavora solamente con i Big Data 

È molto comune associare la data science in generale con i cosiddetti big data ovvero le enormi moli di dati che al giorno d’oggi sono generate dalle aziende tecnologiche e non solo. Se è vero che spesse volte i Data Scientist si trovano nelle condizioni di lavorare con queste moli e quantità di dati è altrettanto vero che molto spesso queste dimensioni non sono necessarie per applicare le tecniche di data science. Talvolta, considerare enormi quantità di dati può addirittura essere negativo!

Lavorare con piccole quantità di dati ha moltissimi vantaggi! Da la possibilità di processare ed utilizzare i dati più velocemente, permettendo ad esempio di utilizzare tecniche statistiche più sofisticate e di visualizzare i dati in modo semplice! Permette infine di sincerarsi più accuratamente della qualità del dato, spesso quindi arrivando a conclusioni più solide e robuste. Inoltre, lavorare con piccole quantità di dati permette di non dover usare piattaforme di big data tipo Hadoop. Queste tecnologie rappresentano un grande overhead per un’azienda in termini di manutenzione, stack tecnologico e competenze tecniche.

La situazione in cui si hanno pochi dati a disposizione può essere comune anche in aziende solitamente ricche di dati. Il caso del lancio di un nuovo prodotto è un esempio frequente e tipico. Proprio in questi casi però i dati sono importantissimi, per valutare la bontà del prodotto, la direzione ed eventuali cambiamenti. Ad esempio può essere il caso del lancio di un prodotto in una country o una città. Questi lanci specifici vengono usati come campione per decidere gli sviluppi del prodotto. In questi casi è cruciale assicurarsi che i dati, ancora prima di essere generati, siano strutturati, puliti e completi. Questo permette di essere in grado di raccogliere segnali da subito dopo il lancio del prodotto. 

Cosa fa il Data Scientist in azienda

Terminiamo questo elenco di errori frequenti sul ruolo del Data Scientist in un’azienda con una descrizione di questa figura! Il Data Scientist si occupa di tradurre i dati in insight di business azionabili: permette l’evoluzione del prodotto, l’iterazione veloce, la generazione di ipotesi per esperimenti e l’analisi degli esperimenti stessi. Nelle sue competenze figurano conoscenze di matematica e statistica, di programmazione conoscenza specifica del business.

Conclusioni

In questo articolo abbiamo fatto una carrellata veloce degli errori più comuni legati al ruolo del Data Scientist in azienda. Questo va dal considerare i Data Scientist come factotum dei dati al vederli “semplicemente” esperiti degli ultimi trend. Nell’indagare queste comuni idee sbagliate abbiamo anche voluto dare un’idea di quale sia il vero ruolo dei Data Scientist e come contribuiscono allo sviluppo del prodotto.

Se ti é piaciuto l’articolo e vuoi saperne di più sulla data science, fammelo sapere con un commento. Nel prossimo articolo parleremo dell’interazione tra Data Scientist e Product Manager.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *