Trentesima puntata del nostro viaggio
Abbiamo discusso nell’ultimo post la necessità di un diverso punto di vista sulla trasformazione digitale, riflettendo sul fatto che l’automazione dell’informatica equivale a sostituire le persone con “macchine cognitive”, che però non hanno la flessibilità e adattabilità di quelle.
Ignorare questo aspetto ha portato e sta portando ai tanti fallimenti in cui vediamo periodicamente incappare i sistemi informatici. Ecco cosa invece dovremmo fare.
Il tradizionale flusso di acquisizione di servizi e prodotti informatici prevede una fase iniziale di definizione dei requisiti del servizio/prodotto necessario con la scrittura di specifiche di dettaglio, a fronte delle quali i potenziali fornitori propongono offerte. La migliore (con criteri basati sul costo e sulla valutazione tecnica, che sono molto rigidi nelle procedure di acquisto della Pubblica Amministrazione e più flessibili nelle aziende private) vince e il contraente inizia a realizzare quanto richiesto. Al termine, se il servizio/prodotto supera i test finali, si entra nella fase operativa.
Quali sono le conseguenze dell’attuale approccio? La triste realtà è che i programmi di sviluppo che prevedono la realizzazione di componenti software sono sempre quelli in maggior ritardo e con i maggiori sforamenti di costi. Periodicamente, le riviste del settore elencano i disastri più eclatanti che si sono verificati nello sviluppo di sistemi informatici: ecco un’analisi di quanto accaduto solo nel 2024. Nel 2018, il direttore della Divisione Acquisti del Ministero della Difesa USA (il Department of Defense), Will Roper, aveva dichiarato che il sistema di acquisizione tradizionale usato per decenni per comprare navi e aeroplani, non poteva funzionare per il software perché «un sistema software non è mai finito, è un processo continuo».
Le aziende informatiche più innovative al mondo hanno da tempo capito che questo metodo non funziona. Se gli utenti vedono il software solo alla fine, è altamente probabile che non solo i requisiti inizialmente definiti non saranno stati soddisfatti, ma anche che ciò di cui hanno bisogno è nel frattempo cambiato. Dalla collaborazione tra il mondo della ricerca e quello dell’industria è emerso, proprio all’inizio del XXI secolo, un approccio radicalmente diverso allo sviluppo del software, l’approccio cosiddetto “agile” (anche in inglese il termine è lo stesso, solo pronunciato diversamente), che è quello appunto usato dalle aziende informatiche all’avanguardia, perché consente loro di sviluppare servizi/prodotti di successo.
D’altro canto, se ci pensate bene, questo è quello che vediamo nelle App che tutti noi usiamo ogni giorno. A noi sembrano sempre le stesse, ma dietro la facciata c’è un lavorìo continuo di aggiornamento ed evoluzione. Come accade con le persone che, dietro la facciata di un’organizzazione, ci forniscono i suoi servizi. Si evolvono al cambiare delle condizioni di contesto o in funzione di un’eventuale cambiamento deciso dalla direzione. I sistemi informatici – in misura largamente maggiore rispetto ad ogni altro sistema costruito dall’uomo – sono sistemi in continuo adattamento, per il quale il ruolo dell’essere umano continua a essere essenziale. Ciò è vero nonostante gli impressionanti avanzamenti dell’intelligenza artificiale e fintanto che vogliamo che continui a esistere una società di persone e non di macchine. Come scrissi nel 2010, per la 6a edizione del convegno europeo di informatica (ECSS) a proposito dello sviluppo dei sistemi informatici: «la manutenzione è la vera implementazione».
Da un punto di vista procedurale, l’acquisizione di sistemi informatici non dovrà più, quindi, essere basata sulla definizione iniziale di tutti i requisiti, ma andrà individuato un ristretto insieme di obiettivi e casi d’uso iniziali, sui quali un piccolo gruppo congiunto di sviluppatori e utenti inizierà a lavorare con il compito di produrre un primo nucleo funzionante nel giro di qualche settimana. Da lì in avanti si continua con questo approccio iterativo, che è appunto quello definito “agile”, imparando costantemente da successi ed errori sul campo e aggiustando il tiro in funzione dell’evolversi degli scenari.
È un cambiamento epocale se si considera l’acquisizione di un sistema software alla stregua di un qualunque altro prodotto. È la soluzione naturale, se la guardiamo nell’ottica dell’acquisizione di personale.
Mentre questo nuovo paradigma di acquisizione può più agevolmente essere adottato da enti privati, purché chi le guida abbia maturato questa visione culturale dell’automazione informatica, la sua introduzione nel contesto della Pubblica amministrazione (PA) richiede una sintonia con il contesto legale di riferimento. Sarà quindi necessario cambiare l’intero apparato regolamentare che disciplina le procedure con le quali la PA acquisisce sistemi informatici. Qui è necessario uno sforzo fortemente interdisciplinare, perché vanno mobilitate tutte le competenze che entrano in gioco in questo processo: giuridiche, documentarie, informatiche, gestionali, psicologiche, sotto la guida – va da sé – di una politica che deve farsi carico in prima persona della gestione di tali problematiche.
E proprio al ruolo che deve svolgere la politica per governare l’uso dell’informatica nello sviluppo della società, ruolo necessario e insostituibile, che dedicheremo l’ultimo tratto di questa passeggiata.
( I post di questa serie sono basati sul libro dell’Autore La rivoluzione informatica: conoscenza, consapevolezza e potere nella società digitale, al quale si rimanda per approfondimenti. I lettori interessati al tema possono anche dialogare con l’Autore, su questo blog interdisciplinare, su cui i post vengono ripubblicati a partire dal terzo giorno successivo alla pubblicazione in questa sede. )