CONSULENTI DI BUSINESS, ANALISTI-PROGRAMMATORI E PROXY-EXPERT: I VOLTI DI UN RUOLO CHE CAMBIA
In un era, quella agile, in cui spopolano le figure dei “pragmatic-” programmers e degli architetti “evolutivi” (evolution architects), anche la figura dell’analista è soggetta al cambiamento. Negli anni ’70-’90 essere analisti significava ricoprire un ruolo ben definito all’interno di un altrettanto chiaro ciclo di vita del software (il modello Waterfall). Nella “cascata” di fasi attorno alle quali un progetto software veniva elaborato, l’analista si ritrovava a scrivere un documento dei requisiti usando il linguaggio naturale, schemi a blocchi con notazioni proprietarie, e nei casi più fortunati, dei diagrammi in standard DFD (Data-Flow Diagram). La maggior parte delle volte questi documenti erano lunghi, ambigui, incompleti, rapidamente obsoleti. In quegli anni, inoltre, l’analista software viveva spesso un conflitto interno: catturare le funzionalità essenziali del problema oppure le sue entità chiave. I paradigmi in eterna competizione erano quello Strutturato e quello dell’Analisi dei Dati.
Pur partendo da obiettivi generali simili, le due scuole di pensiero rimanevano costantemente in contrapposizione e, spesso, anche in chiara competizione. In molti progetti industriali di grandi dimensioni dove venivano assoldati team separati (uno per la progettazione di flussi di dati tra processi, l’altro per la definizione della base di dati), la frattura emergeva su svariati piani: nella diversa visione del sistema, nelle politiche di gestione del progetto e persino nella comprensione stessa del dominio. Il risultato dell’atteggiamento competitivo tra l’approccio strutturato e quello orientato ai dati fu ben sintetizzato da Peter Coad e Edward Yourdon nell’introduzione al loro libro Object Oriented Analysis, un testo seminale sull’analisi orientata agli oggetti e le radici del Metodo OO:
“Sotto la pressione di scadenze, costi e poteri politici, i modelli prodotti dalle due scuole di pensiero finivano per diventare progetti preliminari ricchi di contraddizioni. Poiché entrambi i team ritenevano di possedere ciascuno la visione corretta del dominio, tali contraddizioni rimanevano irrisolte.”
Poi sono arrivati gli oggetti e tutto è stato unificato. Dati e funzioni. Almeno in teoria. Sono passati altri vent’anni. Il modello a cascata non è più popolare :-), soppiantato dall’approccio agile (nelle sue varie incarnazioni). Ma la figura dell’analista come è cambiata?
Senza avere l’ambizione di redigere una tassonomia completa, esistono diversi volti di quell’antica figura chiamata analista. In molte realtà che forniscono ai propri clienti non solo del software ma anche dei servizi, l’analista è prima di tutto un consulente. È cioè colui che interagisce con uno o più rappresentanti del cliente (a volte il cliente stesso), recepisce un bisogno, aiuta talvolta ad esplicitare tale bisogno, e infine produce un documento che formalizza la descrizione del bisogno affinché sia poi codificata all’interno di un programma software.
Un’altra variante, antica quasi tanto quanto la figura del programmatore, è l’analista-programmatore. La genesi dell’analista-programmatore è legata troppo spesso allo stato di anzianità dell’individuo e all’organizzazione gerarchica di molte aziende. Salire di livello, in tali realtà, significa ad esempio passare da programmatori a programmatori senior e, infine, ad analisti-programmatori. Questa figura si interfaccia sia con il team di sviluppo, sia all’esterno, redige specifiche, elabora piani di sviluppo, a volte coordina anche piccoli gruppi di lavoro. In altre parole, (a dispetto del titolo) smette rapidamente di scrivere codice.
La terza “incarnazione” dell’analista oggi è il proxy-expert. A prescindere dal tipo di interazione che tale figura ha con l’esterno, il proxy-expert ha approfondito svariati aspetti di uno specifico dominio applicativo al punto da essere considerato altrettanto autorevole della controparte cliente che lavora su quel dominio in modo nativo. Il proxy-expert diventa spesso un sostituto del cliente, simulandone i bisogni e la conoscenza di dominio. È il consulente di dominio interno dei programmatori.
Questi tre esempi sono solo alcuni dei ruoli in cui emerge oggi la figura dell’analista. I titoli in fondo sono solo indicativi. Ciò che dovrebbe contraddistinguere un analista moderno sono le sue abilità. Prendiamo allora l’analista-programmatore. Essere analisti oggi cosa significa? Se è vero che la guerra delle notazioni è finita, l’analista moderno, inserito in un contesto OO, dovrebbe adottare un linguaggio a oggetti per comunicare parte dell’analisi. Ad esempio dovrebbe poter sostenere una conversazione sui requisiti articolata su (semplici) diagrammi di classe e/o di sequenza, a beneficio di architetti e programmatori. Dovrebbe conoscere la tecnologia degli oggetti, capire gli strumenti per rappresentare e governare la complessità di un dominio applicativo attraverso l’ereditarietà, la composizione, i soggetti (a.k.a. packages). Può non essere così cruciale che sappia programmare bene con i più moderni linguaggi di programmazione o capirne il codice in ogni aspetto, ma dovrebbe rendersi conto se una porzione del codice è articolata in modo da creare fratture con il modello mentale del problema che ha elaborato (i concetti chiave e le loro mutue relazioni sono presenti nel codice? Sono fedele implementazione del modello concettuale dell’analisi? Se vi è un forte scostamento, l’analista ne è conscio? lo ha validato?). Le conoscenze di questo analista moderno dovrebbero comprendere la teoria dei “problem frames” di Michael Jackson, il principio di scala, l’analisi dei soggetti, la prospettiva concettuale dei diagrammi UML, forse le CRC card e gli use case essenziali, le context map e la metafora del linguaggio ubiquo del Domain-Driven Design, per poi abbracciarfe tecniche che stanno emergendo nel mondo agile come Event Storming e User Story Mapping. Un’altra caratteristica dell’analista è possedere le soft-skills che gli permettono di comunicare efficacemente con il team tecnico, con l’upper management e con i clienti. Per questo un (vero) analista-programmatore non è semplicemente un programmatore anziano, bensì un professionista che ha allargato la propria visione di cosa significhi costruire software. E nel farlo ha acquisito nuovi strumenti.
Evolvere significa però anche imparare a gestire nuovi rischi, nuovi pericoli: ad esempio l’analista che ha una forte conoscenza di come è stato scritto, progettato e pensato un sistema software deve guardarsi dalla possibilità che tale conoscenza lo influenzi nella visione delle cose. Avendo magari contribuito a creare una parte del software oggi in uso all’interno dell’azienda per cui lavora, l’analista-programmatore rischia di essere influenzato dalla conoscenza di specifiche implementazioni, confondendo il problema con la soluzione. Fare le domande “giuste”, non dare mai per scontato di aver capito, cercare continue conferme, aiutare i clienti ad esplicitare il vero problema, la loro conoscenza tacita. Questa è una delle più grosse sfide dell’analista-programmatore moderno. Conoscere una tecnologia, in fin dei conti, non significa porsi necessariamente al livello implementativo. Quando però le analisi sono tradotte in documenti in cui un requisito viene descritto non in termini del problema da risolvere, ma in quelli di una tabella da aggiungere, di una specifica interrogazione su una base di dati, o ancora sull’uso di una funzione di libreria da richiamare… il demone della conoscenza “legacy” emerge inesorabile. E forse questo è il confine in cui l’analista-programmatore smette di essere analista.
Quanto i tre ruoli appena descritti rispettano le vostre esperienze e la realtà della vostra azienda? Oppure quella dei vostri clienti? Che caratteristiche dovrebbe avere secondo voi un analista moderno? E quali sono le sfide che deve perseguire, la sua formazione, il suo contributo nel lavoro in team? Parliamone.