Siamo vicini ad un punto di discontinuità: quello che abbiamo sempre creduto valido, e che abbiamo cercato di applicare, su come organizzare le nostre aziende sta svanendo.
Negli ultimi anni il tema dell’evoluzione delle modalità organizzative è passato da utopia, o nel migliore dei casi da speculazione accademica, a punto centrale di riflessione per il mondo del business. Si prefigura un passaggio da organizzazioni burocratiche e gerarchiche, fatte cioè di regole e manager, a nuovi stili basati sull’auto-organizzazione e sulla leadership contestuale.
È interessante notare come molti di questi approcci derivino da esperienze e riflessioni nate nel campo dello sviluppo software, e come siano proprio le società IT più moderne le pioniere nell’adottare approcci non convenzionali all’organizzazione aziendale (citiamo ad esempio i casi di Google o di Valve). Molti spunti sono infatti nati dall’applicazione delle metodologie Agile, pensate per migliorare la gestione di progetti di sviluppo software, a contesti più ampi, tanto che oggi si parla spesso di Agile Organizations.
È quindi proprio dall’informatica che sta arrivando questa rivoluzione organizzativa, e questo non deve stupire. Chi lavora in questo ambito è il primo ad essersi scontrato con i limiti delle organizzazioni e delle metodologie attuali, e per primo si è mosso per trovare possibili soluzioni attuando una profonda revisione organizzativa della divisione IT. Il paradosso è evidente: mentre le tecnologie dell’informazione si evolvono a velocità esponenziale, la capacità delle organizzazioni di evolvere per coglierne appieno i benefici è al più lineare. Si crea così un gap sempre più profondo fra quello che si potrebbe ottenere con le tecnologie e le capacità delle organizzazioni di muoversi in questa direzione e cogliere le opportunità sottese a questa trasformazione (figura 1).
Per colmare questo gap non basta fare meglio quello che si sta facendo, impegnarsi di più o correre più velocemente: in questo modo la frustrazione e l’inadeguatezza non possono che aumentare. Il salto che le aziende devono fare per cogliere i benefici della trasformazione digitale ed evitare di esserne distrutte è innanzitutto un passo di discontinuità interno: abbandonare vecchi paradigmi e modi di fare e abbracciare la nuova era organizzativa.
I limiti delle tradizionali organizzazioni it
Sul fronte di questo cambiamento ci sono ovviamente le Direzioni IT delle aziende, in prima linea, per forza o per convinzione, nella gestione del cambiamento portato dalla trasformazione digitale. Le Direzioni IT devono oggi portare il peso di aspettative e pressioni sempre crescenti da parte del top management e delle altre direzioni aziendali.
Nella maggiore parte dei casi esistono però numerosi vincoli e impedimenti di taglio organizzativo che limitano la possibilità di raggiungere queste aspettative. Sono vincoli che troviamo oggi estremamente diffusi, nelle piccole aziende ma soprattutto nelle grandi, pur con differenze sostanziali legate alla capacità del management di lavorare attorno a questi vincoli.
A nostro avviso le principali caratteristiche organizzative che oggi costituiscono un ostacolo sono le seguenti:
- la presenza all’interno dell’IT di molteplici unità organizzative focalizzate e stabili nel tempo, fattore che ha causato la creazione di una quantità estremamente alta di ruoli di middle management (molto maggiore che in altre Direzioni) e che ha fatto proliferare i silos organizzativi, che tendono a lavorare in maniera isolata e a rifiutare le istanze di cambiamento che arrivano dall’esterno;
- l’elevata parcellizzazione dei compiti e la segregazione delle responsabilità fra le diverse unità organizzative ha creato la necessità di una maggiore collaborazione e conoscenza reciproca, cosa in realtà ostacolata e resa difficile dalla presenza dei silos organizzativi;
- nella Direzione IT tendono inoltre a proliferare funzioni di staff con ruolo di controllo o consultivo, che non entrano nell’operatività ma che vengono percepite come overhead o, nei peggior casi, come un impedimento rispetto agli obiettivi assegnati;
- il rapporto con il business è di tipo quasi contrattuale, con la pretesa di ricevere fin dall’inizio specifiche chiare e ben definite: l’intento è proteggere la Direzione IT dai cambiamenti e fare in modo che possa rispettare gli impegni presi, ma di fatto si pongono così vincoli impossibili da rispettare agli interlocutori interni;
- spesso il focus è sulla creazione di processi e regole interne standard e immutabili, sulla base della presunzione di riuscire a contemplare tutte le casistiche e di avere perfette capacità previsionali, tutti elementi che si scontrano con la complessità della realtà ponendo un freno al buon senso e alla capacità di adattamento delle persone.
Da questo quadro emerge un’organizzazione IT che, nei casi migliori, può essere assimilata a una macchina complessa, fatta di elementi specializzati che lavorano insieme secondo regole predefinite. Una macchina rifinita e perfezionata nel tempo, in grado di garantire prestazioni importanti quali la continuità, l’affidabilità, il contenimento dei costi, la sicurezza (almeno nella maggior parte dei casi). Peccato che la trasformazione digitale richieda oggi di mettere in primo piano prestazioni notevolmente diverse, in primo luogo la capacità di adattarsi a un contesto esterno in rapido e imprevedibile cambiamento.
I pilastri del cambiamento
Per le Direzioni IT è dunque oggi impellente ripensare al funzionamento dei propri meccanismi interni e delle proprie interfacce verso l’esterno. Riprendendo gli elementi alla base dei più moderni stili organizzativi possiamo identificare due temi chiave: la centralità dei team e la collaborazione continua.
Dare centralità ai team vuol dire organizzare il lavoro tramite strutture temporanee, in grado di riunire tutte le competenze e le risorse necessarie per raggiungere un determinato obiettivo. Dare potere ai team vuol dire: toglierlo ai responsabili funzionali, consentire a ogni team di auto-organizzarsi sulla base delle reali necessità e non sulla base di strutture e regole predefinite. I team si possono creare velocemente, possono sciogliersi o potenziarsi, assecondando in tal modo in maniera estremamente rapida l’evolversi delle priorità aziendali.
Mentre una parte dell’attenzione si sposta allora nelle logiche e nelle dinamiche di funzionamento interno dei team, l’altra parte si focalizza sulle relazioni con gli attori esterni. Obiettivo è abbattere le barriere esistenti che interrompono il flusso delle informazioni e delle attività. Sono barriere che nascono da differenze nella cultura e nel linguaggio, da obiettivi e valori differenti, da processi e modalità di lavoro ottimizzati localmente.
- La prima grande barriera che deve cadere è quella fra la Direzione IT e il business, che infatti spesso viene considerato un “cliente”. Far cadere questa barriera vuol dire far passare l’utente da spettatore passivo a parte integrante del processo di creazione e gestione di un sistema.
- L’altra barriera da superare è quella che esiste fra chi realizza i progetti e chi gestisce i sistemi. Il tipico passaggio del testimone, con piani e priorità che faticano a collimare, tempi di setup sempre troppo stretti e problemi tecnici non affrontati nella fase progettuale che ricadono sulla gestione, non ha senso se si pensa ai sistemi informatici come a oggetti in continua evoluzione. Rispetto alla tradizionale consequenzialità fra analisi, realizzazione e gestione, si lavora quindi in parallelo e continuamente su tutti questi filoni con una stretta collaborazione fra gli attori coinvolti.
Le nuove metodologie che trasformano l’it
Sulla base di questi principi si sono sviluppate e affermate nel corso del tempo, pur con maturità e diffusione molto diversificate, alcune metodologie che toccano tutte le fasi del processo core delle Direzioni IT: partendo dall’analisi delle esigenze, per proseguire con lo sviluppo e terminare con il rilascio in esercizio. Sono metodologie di cui si discute ormai da alcuni anni, ma che in realtà vediamo essere ancora scarsamente comprese. Non stupisce infatti, come si evidenzia dalla recente ricerca dell’Osservatorio Enterprise Application Governance della School of Management del Politecnico di Milano, che la barriera primaria all’adozione di queste metodologie sia ancora la scarsa conoscenza da parte delle aziende.
L’analisi delle esigenze
Nella discussione che avviene fra IT e utenti per la definizione delle specifiche è spesso difficile trovare un terreno e un linguaggio comune che non può che essere quello degli obiettivi: partire dalla comprensione degli obiettivi dell’utente consente di chiarire al meglio lo scope dei sistemi e prioritizzarne correttamente le funzionalità. Ancora più importante, consente all’IT di rimuovere i falsi vincoli imposti dagli utenti e di muovere tutte le possibili leve tecniche per identificare soluzioni che abbassino complessità e rischio. Le metodologie di analisi più moderne hanno nell’analisi sistematica degli obiettivi l’elemento chiave: si parla infatti di Goal Based analysis o Impact Mapping, e anche l’Agile requirements definition si basa sulla esplicitazione degli interlocutori e degli obiettivi attesi da parte del sistema. Questo percorso, che parte dalla definizione degli obiettivi prioritizzati di tutti gli stakeholder, offre all’IT una visione completa e chiara delle aspettative reali e delle condizioni per poterle esaudire.
La definizione e ridefinizione delle funzionalità
Lavorando a partire da questi due elementi, obiettivi e stakeholder, e raffinandoli sempre di più, si arriva a definire congiuntamente tutte le funzionalità attese dal prodotto e il relativo ordine di importanza (utilizzando ad esempio la metodologia user story mapping).
Questo tipo di analisi non avviene solo all’inizio del progetto, i requisiti sono elementi “vivi”, che possono variare nel corso del tempo e che vengono via via raffinati e dettagliati per arrivare alle specifiche necessarie allo sviluppo. L’approccio just in time dell’analisi di dettaglio evita di prendere decisioni quando non si hanno ancora tutti gli elementi o quando c’è ancora tempo per cambiare idea. Definire i dettagli e prendere decisioni all’ultimo momento possibile è quello che consente di avere una qualità e una affidabilità molto maggiore delle specifiche.
Questo approccio si sposa bene con le metodologie Agile (vedi riquadro e articolo I livelli di adozione del DevOps) di gestione dei progetti, che partono proprio dalla mappatura del prodotto da realizzare e dalla sua suddivisione in cicli iterativi.
Le metodologie Agile, e in particolar modo SCRUM, dividono infatti il lavoro in cicli di analisi e sviluppo dalla durata limitata, con l’obiettivo di dare massima flessibilità nella composizione del prodotto e di mantenere un elevato controllo sull’andamento delle attività.
L’obiettivo di realizzare sistemi funzionanti alla fine di ogni ciclo iterativo mette il team a confronto diretto con l’utente, che può utilizzare con le proprie mani e verificare fin dall’inizio quello che si sta realizzando. Sulla base di questo feedback è possibile ritarare e aggiustare il contenuto delle iterazioni successive, incorporando fin da subito le modifiche richieste.
Per garantire fluidità in tutto questo processo sono stati definiti in maniera molto puntuale i diversi ruoli di progetto, le modalità di coordinamento, gli strumenti da utilizzare e i formalismi da impiegare.
Il passaggio in esercizio
La velocità e l’approccio iterativo delle metodologie Agile sarebbe vanificato se non si riuscisse a rilasciare in maniera continuativa quello che si è prodotto nei diversi ambienti. Per questo motivo si è sviluppato il DevOps, per rimuovere le barriere e le incomprensioni fra questi due mondi: da un lato chi si occupa del progetto, dall’altro chi controlla la qualità di quanto fatto, prepara gli ambienti necessari e ne assicura il corretto funzionamento. DevOps è una vera e propria filosofia di collaborazione fra lo sviluppo e le operations, basata sulla standardizzazione e sull’automazione dei rilasci, fino ad arrivare al continuous delivery. La collaborazione si ottiene facendo in modo che chi sviluppa possa testare in maniera più rapida il comportamento di quanto prodotto sui vari ambienti, mentre dall’altra parte le operations possano osservare e valutare fin da subito il comportamento dell’applicazione e verificare cosa sta facendo chi sviluppa.
L’impatto del cambiamento
Secondo la recente ricerca dell’Osservatorio Enterprise Application Governance anche in Italia l’interesse per queste metodologie è in fase di forte crescita, con il 33% delle aziende che sta già impiegando metodologie evolute di analisi, 53% approcci Agile allo sviluppo e il 39% il paradigma DevOps.
È però evidente come non abbia senso prendere spunti da queste metodologie e provare ad applicarle all’interno di un contesto organizzativo invariato, o pensare di confinarle solo a porzioni limitate del proprio portafoglio applicativo. La tendenza che rileviamo essere ancora diffusa, causata da scetticismo o da interpretazioni troppo limitative, porta a introdurre queste metodologie solo in progetti sperimentali e lontani dal core business aziendale. Ma è proprio in questi ambiti che la trasformazione è più impellente, e può dare maggiori benefici: la visione a tendere deve considerare il reale potenziale di trasformazione a 360° delle modalità organizzative e delle performance della Direzione IT.
Il cambiamento richiesto è perciò estremamente significativo e sfidante, proprio per questo abbiamo visto nel corso degli ultimi anni numerosi tentativi non andati a buon fine o benefici reali inferiori alle aspettative teoriche. Analizzando meglio questi fallimenti, appaiono evidenti molti errori: creare unità organizzative ad hoc per gestire questi temi, fare sperimentazioni con team isolati senza comprendere le implicazioni su tutti gli altri aspetti pertinenti la gestione dell’IT, pensare di ottenere benefici nell’immediato senza avere fatto prima esperienze significative, non considerare la necessità di coinvolgere nel cambiamento il business, e molti altri.
In tutti questi casi si è sottovalutato l’impatto del cambiamento e non si sono attuate le dovute azioni preventive, che devono invece andare in diverse direzioni:
- fondamentale è costruire una visione chiara e condivisa della profondità di tale cambiamento, perché non sia banalizzato;
- le competenze della direzione IT devono adeguarsi ed evolversi;
- i ruoli delle persone e le relative responsabilità vanno ridefiniti, ponendo in primis in discussione le figure manageriali;
- i processi e i meccanismi che coinvolgono il business e che regolano le relazioni fra le diverse parti della Direzione IT vanno riplasmati, nell’ottica di facilitare la collaborazione e la flessibilità;
- i tradizionali processi di budgeting e di allocazione delle risorse per i progetti devono evolversi anch’essi per non fare da freno e vincolo;
- le modalità di selezione e di ingaggio dei fornitori cambiano per privilegiare approcci di partnership basati sulla trasparenza reciproca.
Tutto questo può accadere se cambia prima di tutto la mentalità con cui l’IT interpreta il proprio ruolo nei confronti dell’azienda e del business.
Un nuovo ruolo
All’interno di questo scenario manca però un tassello fondamentale: il ruolo che devono giocare la Direzione aziendale e le altre unità di business. Pensare che la Direzione IT possa essere l’unico attore coinvolto in questo cambiamento è pericoloso, perché la trasformazione digitale è un tema che tocca tutto il business. In questi ultimi anni, grazie anche all’emergere dei servizi cloud, c’è stato un progressivo appropriarsi da parte degli utenti del dominio tecnologico e della possibilità di muoversi autonomamente per creare “il proprio sistema informativo”.
In questa situazione non è affatto scontato che la Direzione IT sia vista come principale attore dell’innovazione digitale, e sempre più spesso viene relegata al ruolo di gestore dell’esistente o a passaggio obbligatorio dallo scarso valore aggiunto. Siamo quindi di fronte ad un bivio fondamentale per chi opera nelle Direzioni IT: evolversi per andare incontro alle opportunità offerte da questo ruolo strategico che ogni azienda vorrebbe avere, o finire relegati in un ruolo sempre più secondario e operativo.
L’innovazione digitale non può che passare da una collaborazione profonda fra Direzioni IT e Business, ed entrambi devono vivere un cambiamento nel modo di affrontare questi temi. Abbiamo oggi a disposizione approcci, metodologie e soluzioni che ci spingono in questa direzione e che ci spiegano concretamente come fare. Abbracciarle vuol dire accettare la discontinuità, fare un salto deciso per adottare nuovi processi e nuovi stili organizzativi e manageriali. L’obiettivo è portare l’azienda, tutta l’azienda, in una nuova era.
*Marco Mazzucco è Chief Innovation Officer di WebScience, società specializzata nel supportare le aziende nel loro percorso di Digital Transformation; è inoltre ricercatore senior per gli Osservatori Digital Innovation del Politecnico di Milano
I principi dell’Agile
Il “manifesto per lo sviluppo agile del software” è stato pubblicato nel 2001 a opera di un gruppo di progettisti software che si sono
riuniti nell’Agile Alliance. Il documento contiene i quattro principi alla base delle successive applicazioni pratiche di questo concetto:
- Gli individui e le interazioni più che i processi e gli strumenti
- Il software funzionante più che la documentazione esaustiva
- La collaborazione col cliente più che la negoziazione dei contratti
- Rispondere al cambiamento più che seguire un piano
La metodologia SCRUM
All’interno del movimento Agile sono state progettate diverse metodologie attuative per permettere di passare dai principi generici alla pratica dei progetti. Fra queste la più diffusa è SCRUM, utilizzata nel 58% dei casi (come riportato nel 10th annual State of Agile Report del 2016), mentre sono minoritarie altre tecniche come Kanban, Extreme Programming o Lean Development.
Gli elementi alla base della metodologia SCRUM sono, in estrema sintesi:
- la definizione di ruoli specifici: in SCRUM non ci sono Project Manager, ma Product Owner, SCRUM Master e Team Member, rinunciando quindi ad un approccio gerarchico per promuovere l’autonomia e la responsabilità del team;
- il product backlog, la lista prioritizzata delle “storie”, ovvero delle funzionalità contenute nel sistema da realizzare;
- gli story point, l’elemento utilizzato per stimare la complessità relativa delle diverse storie mediante un processo che coinvolge direttamente gli sviluppatori;
- gli sprint (iterazioni), ovvero i blocchi unitari di lavoro, tipicamente della durata variabile da una a quattro settimane, pianificati sulla base della quotaparte di product backlog assegnata alla specifica iterazione;
- le modalità di coordinamento, che comprendono meeting all’inizio di ogni iterazione, i daily meeting e gli incontri di chiusura iterazione (sprint review e retrospective)
La metodologia User Story Mapping
Questa metodologia, sviluppata in seno al movimento Agile, ha l’obiettivo di creare una visione sistemica e completa del sistema che si sta andando a creare, utilizzando un approccio visuale e collaborativo che facilita la reciproca comprensione fra IT e business.
La mappa che rappresenta il sistema ha questi elementi chiave:
- gli utenti, che sono tutte le figure che hanno obiettivi e interessi legati al sistema;
- il Backbone, ovvero l’insieme degli obiettivi di alto livello dei diversi utenti e delle macrofunzionalità necessarie per raggiungere questi obiettivi;
- le user stories, che rappresentano i casi d’uso che il sistema deve garantire;
- le Release, che sono insiemi consistenti di task che sono insiemi consistenti di user stories.
