In passato mi è capitato molto frequentemente di lavorare in gruppi multidisciplinari con professionisti, ricercatori, tecnici, personale medico e sanitario, biologi, statistici, ingegneri. Ho sempre pensato che uno degli aspetti più interessanti di questi progetti fosse l’opportunità di imparare a riconoscere ulteriormente i propri limiti e a convivere con quelli degli altri.
Ma, concretamente, come è possibile lavorare in un gruppo multidisciplinare in un contesto come quello degli Analytics, un settore in cui la professionalità viene spesso misurata in base al livello di specializzazione e in cui perfino l’utente (purtroppo) è talvolta tentato di accettarne i risultati a “scatola chiusa”?
Tante teste
Nel mondo degli Analytics si confrontano sempre diverse anime: quella dell’esperto del business, o di dominio, di estrazione tecnica o commerciale (in progetti multidisciplinari può non essere affatto un tecnico, ma uno specialista di settore, come un medico); quella dello sviluppatore o del sistemista, di estrazione spesso informatica; quella dell’analista, generalmente specializzato in discipline “quantitative” (scientifiche, economiche, ecc.). Le differenze si traducono in diversi punti di vista e, spesso, nell’uso di tecnologie diverse, che devono essere necessariamente integrate perché un progetto abbia successo. A fronte di questa difficoltà la tentazione costante è quella di limitarsi a tradurre la propria professionalità in documentazione da affidare ai propri partner e di relegare, o accaparrarsi, la responsabilità di “sintetizzare” i risultati secondo il proprio esclusivo punto di vista. Nonostante una fase di sintesi sia ovviamente necessaria, i progetti di maggior successo e interesse a cui ricordi di aver partecipato sono stati quelli in cui le professionalità complementari sono state gestite, più che sintetizzate da uno solo o da pochi membri. Per poterlo fare, sono stati necessari gli strumenti giusti, un linguaggio comune ed immediato, un approccio basato su metodi agili e fiducia reciproca.
Da precisare che la visione proposta è una necessaria semplificazione della realtà. Qui un altro divertente e interessante punto di vista.
Modularità e approcci agili
Traducendo liberamente la frase di un libro interessante, Agile Data Science 2.0: Building Full-Stack Data Analytics Applications with Spark, “l’informazione ha un contesto, e se il contesto è interattivo, i contenuti sono imprevedibili”. Come dire: la buona riuscita di un progetto di Analytics dipende largamente dalla qualità dei dati (ovvero dall’informazione) a disposizione. Questo si spiega con il fatto che i progetti di Analytics sono in genere data-driven (letteralmente: guidati dai dati): l’outcome non è il software di per sé, quanto piuttosto l’informazione estratta dal software stesso, che cambia al variare dei dati. Per ciascun membro del gruppo è quindi essenziale essere in grado di adattarsi al mutamento, tanto repentino quanto frequente. Una soluzione efficace per affrontare il cambiamento è quella di creare (quando possibile) gruppi di lavoro relativamente piccoli, costituiti da persone con competenze estremamente varie, favorendo frequenti scambi di opinioni “fra pari” (o quasi). Gli scambi dovrebbero essere supportati da strumenti che consentano di accedere sistematicamente ai dati e a elaborazioni anche parziali. Questo approccio consente di lavorare in modo iterativo ed efficiente, ottimizzando il tempo necessario alla comunicazione, ma richiede a ciascun componente del gruppo di essere disposto a studiare ed ampliare costantemente la propria professionalità con competenze nuove.
Strumenti collaborativi
I progetti che coinvolgono lo sviluppo di sistemi di Machine Learning in genere richiedono validazioni frequenti, una rapida condivisione dei risultati e frequenti consultazioni fra tutte le anime del gruppo, o con il cliente. Dunque è cruciale la scelta e l’uso di strumenti di condivisione, che consentano di accedere a documenti, presentazioni, codice, e di visualizzare dati in modo collaborativo e, possibilmente, interattivo, secondo diversi livelli di complessità. La maggior parte dei sistemi di visualizzazione dati oggi supporta modalità di lavoro in cloud. A partire da canovacci iniziali, siano essi documenti, presentazioni, dashboard o codice e partendo dal rispetto di pochi requisiti essenziali, nel corso del progetto ciascuno potrà aggiungere il proprio contributo, in base al proprio ruolo e grado di coinvolgimento. Chiaramente, questo presuppone una comunicazione efficace tra membri del gruppo e una regia accurata.
Linguaggio comune
Non credo sia mai esagerata l’importanza che viene attribuita alla comunicazione fra professionisti, a maggior ragione se di diverso background culturale. L’uso di termini tecnici, pur riferendosi a concetti condivisi, spesso è talmente diverso da generare ritardi, importanti fraintendimenti e interminabili discussioni. A volte, si tratta di affrontare la sfida di tradurre concetti semplificandoli, ma senza banalizzarli al punto da risultare superficiali e inconcludenti. Anche l’essenzialità è una dote che credo vada coltivata. Non per niente molti corsi post-laurea, anche di tipo tecnico, oggi propongono percorsi di formazione nell’ambito delle soft-skills (presentazioni, comunicazione, ecc.). In effetti per un analista può essere una sfida tradurre i propri risultati in modo sintetico, affinché possano essere validati da un utente di dominio; per un informatico, non è sempre semplice valorizzare una soluzione tecnologica, pur definendone il perimetro, che nasce dal compromesso tra requisiti di progetto e budget. Una comunicazione povera mina l’efficacia dei risultati del progetto.
Strumenti di “sintesi” e osmosi delle competenze
In ambito IT, spesso una delle priorità è quella di “rilasciare” soluzioni algoritmiche, che hanno la caratteristica di essere modulari, spesso basate su sistemi di Machine Learning e destinate ad essere integrate in piattaforme più ampie. Dal punto di vista strettamente tecnico, uno degli strumenti più efficaci che consente l’integrazione di componenti analitici è quello delle API o dei microservizi che, a prescindere dalla soluzione applicativa o dal linguaggio utilizzato, consentono di interrogare modelli ed effettuare previsioni. I sistemi di virtualizzazione degli ambienti (come Docker), coniugati a strumenti di Continuous Integration (come Jenkins), consentono di sviluppare microservizi in maniera scalabile e modulare. Gli analisti possono concentrarsi sulla produzione di contenuti, lasciando ai profili più tecnici (orientati a professionalità tipo DevOps) il complesso compito di disegnarne i dettagli di integrazione e agli esperti di dominio la possibilità di consultare dati a prescindere (o quasi) dalla piattaforma utilizzata. Anziché produrre solo documentazione da affidare alle capacità realizzative dei colleghi, ciascun membro del gruppo diventa quindi direttamente responsabile di una componente del progetto stesso, che sviluppa ed integra insieme ai colleghi.
Per chi volesse approfondire, rimando a un divertente articolo nato da un seminario tenuto a Strata+Hadoop World, London, 2016.
Fiducia
Ultima nella lista, ma probabilmente prima per rilevanza, la fiducia si guadagna, ma talvolta si deve anche accordare, soprattutto alle prime esperienze di gruppo. Com’è naturale, un clima di fiducia consente l’instaurarsi di un ambiente umano fertile per favorire scambi di idee e di competenze e di concentrarsi su obiettivi comuni. Questo clima si rafforza favorendo occasioni di contatto tra persone e condividendo spazi e oggetti, ma anche promuovendo occasioni di confronto all’interno del gruppo stesso. Nella mia esperienza, il confronto che nasce da una serena condivisione, soprattutto in gruppi multidisciplinari, porta sempre ad una crescita delle proprie vedute e conoscenze che, penso, possa essere considerata una delle massime aspirazioni per chiunque dedichi cura e passione al proprio lavoro.
Michele Gabusi
