Quando un progetto software arriva al go-live, è naturale che l’attenzione si concentri su alcuni indicatori ben precisi: il rispetto delle scadenze, il budget, la copertura funzionale e, naturalmente, il corretto funzionamento dell’applicazione. Se tutto procede secondo i piani, il progetto viene considerato un successo e il team può finalmente archiviare mesi di lavoro con la soddisfazione di aver raggiunto l’obiettivo.
Questa visione, tuttavia, racconta soltanto una parte della storia. Un software non è un prodotto destinato a rimanere immutato nel tempo, ma uno strumento che deve accompagnare l’evoluzione dell’azienda per molti anni, adattandosi a nuovi processi, nuovi modelli organizzativi, nuove tecnologie e, spesso, a strategie di business che nel momento della progettazione nemmeno esistevano. Per questo motivo il giorno del rilascio non rappresenta il momento in cui è possibile giudicare il valore reale del lavoro svolto: rappresenta semplicemente l’inizio della vita operativa del sistema.
Questa considerazione può sembrare scontata, ma nella pratica influenza profondamente il modo in cui un progetto viene progettato, sviluppato e governato. Se l’obiettivo diventa esclusivamente “arrivare al go-live”, molte decisioni saranno inevitabilmente orientate al breve termine. Se invece si considera il software come un patrimonio destinato a sostenere l’azienda negli anni successivi, allora cambiano le priorità, cambiano i criteri con cui si prendono le decisioni tecniche e cambia persino il modo in cui viene valutato il successo dell’intero progetto.
Un’azienda cambia continuamente, e il software deve fare lo stesso
Sono poche le organizzazioni che, a distanza di qualche anno, lavorano esattamente come lavoravano il giorno in cui hanno commissionato un nuovo software. Crescono, acquisiscono nuove società, aprono sedi, introducono nuovi servizi, modificano i processi interni, adottano nuove normative, integrano strumenti prima inesistenti o iniziano a utilizzare tecnologie che fino a poco tempo prima sembravano lontane dalla propria realtà.
Basti pensare alla rapidità con cui l’intelligenza artificiale è entrata nelle aziende. Soltanto pochi anni fa era difficile immaginare che sistemi di questo tipo sarebbero diventati parte integrante di processi commerciali, customer care, gestione documentale o analisi dei dati. Oggi, invece, molte imprese si trovano nella condizione di voler integrare funzionalità basate su modelli linguistici o sistemi di automazione intelligente all’interno di piattaforme sviluppate anche solo quattro o cinque anni fa.
In questo scenario emerge una domanda che raramente viene posta durante la fase iniziale di un progetto: il software sarà in grado di adattarsi a tutto questo senza dover essere ripensato da zero?
La risposta dipende molto meno dalle funzionalità implementate e molto più dalla qualità delle scelte progettuali effettuate all’inizio. Due applicazioni possono offrire oggi esattamente le stesse funzionalità agli utenti e produrre la medesima esperienza d’uso, ma comportarsi in modo completamente diverso quando l’azienda avrà bisogno di evolverle. In un caso sarà sufficiente intervenire in maniera mirata, mantenendo tempi e costi sotto controllo; nell’altro ogni nuova richiesta finirà per coinvolgere componenti apparentemente scollegate, rendendo ogni modifica lunga, costosa e potenzialmente rischiosa.
È proprio in quel momento che diventa evidente se il progetto sia stato costruito guardando soltanto al presente oppure anche al futuro.
Il costo di un software non termina con il progetto
Quando si valuta un investimento software, è naturale concentrare l’attenzione sul costo di realizzazione. È la voce economica più evidente, quella che compare nell’offerta e che deve essere approvata dal management. Molto meno immediato è invece comprendere quanto costerà convivere con quel software negli anni successivi.
Eppure, nella maggior parte dei casi, è proprio lì che si gioca la differenza tra un investimento che continua a produrre valore e uno che, progressivamente, diventa un freno all’innovazione.
Immaginiamo, ad esempio, un’azienda manifatturiera che sviluppi un sistema per la pianificazione della produzione perfettamente aderente alle proprie esigenze del momento. Dopo due anni, decide di automatizzare parte della logistica introducendo nuovi magazzini verticali, integra sensori sugli impianti per raccogliere dati in tempo reale e desidera utilizzare algoritmi predittivi per ottimizzare la pianificazione. Se il software è stato progettato con una struttura sufficientemente flessibile, queste evoluzioni rappresenteranno nuovi progetti, certamente impegnativi, ma perfettamente affrontabili. Se invece ogni componente è fortemente dipendente dagli altri, ogni modifica finirà per propagarsi all’intero sistema, aumentando progressivamente tempi, costi e complessità.
La differenza non dipende dalla bravura degli ingegneri che interverranno in quel momento, ma dalle fondamenta sulle quali il software è stato costruito anni prima.
È un principio che vale in qualunque ambito dell’ingegneria. Un edificio ben progettato non elimina la necessità di effettuare interventi nel tempo, ma rende quegli interventi prevedibili, sostenibili e proporzionati. Nessuno si aspetta che un immobile costruito oggi rimanga immutato per trent’anni; ci si aspetta però che possa essere mantenuto, ampliato e adattato senza dover essere demolito ogni volta che cambiano le esigenze di chi lo utilizza. Con il software accade esattamente la stessa cosa.
Le decisioni più importanti sono spesso quelle invisibili
Durante le riunioni di analisi è normale discutere di schermate, workflow, report, integrazioni e funzionalità. Sono gli elementi che gli utenti vedranno quotidianamente e rappresentano, comprensibilmente, la parte più tangibile del progetto. Parallelamente, però, viene presa una quantità di decisioni che resteranno invisibili agli occhi dell’organizzazione ma che influenzeranno il destino del sistema molto più di qualsiasi interfaccia grafica.
La definizione dell’architettura applicativa, la qualità delle API, la gestione dei dati, il livello di modularità del codice, la strategia di testing, la documentazione tecnica, le modalità di rilascio e la capacità di isolare le diverse responsabilità del sistema sono aspetti che difficilmente verranno citati durante la presentazione del progetto al management. Eppure, sono proprio questi elementi a determinare quanto sarà semplice introdurre una nuova funzionalità, sostituire un componente tecnologico, integrare un nuovo gestionale o adottare strumenti che oggi ancora non esistono.
Il paradosso è che le decisioni più importanti sono anche quelle di cui ci si accorge meno quando tutto funziona. Diventano improvvisamente evidenti soltanto quando qualcosa cambia e ci si rende conto che una modifica apparentemente semplice richiede settimane di analisi, coinvolge numerose persone e comporta un rischio elevato di compromettere funzionalità già esistenti.
In quei casi non è cambiata la richiesta del business. È il software ad aver perso la capacità di evolvere con sufficiente agilità.
Un partner non consegna semplicemente un software
Esiste un altro aspetto che viene spesso sottovalutato quando si avvia un progetto di sviluppo: la relazione tra azienda e fornitore non termina con il collaudo. Se il software è destinato a diventare un elemento centrale dell’operatività aziendale, è molto probabile che quella collaborazione continui per molti anni, accompagnando l’evoluzione del business e supportando decisioni che, al momento della firma del contratto, nessuno è ancora in grado di prevedere.
Per questo motivo scegliere un partner significa valutare molto più delle sole competenze tecnologiche. Significa capire se chi svilupperà il sistema è in grado di comprendere il contesto aziendale, di ragionare in termini di sostenibilità nel lungo periodo e di prendere decisioni che non siano corrette soltanto per il rilascio iniziale, ma anche per tutto ciò che verrà dopo.
In altre parole, significa scegliere qualcuno che non stia semplicemente realizzando un software, ma che stia contribuendo a costruire un patrimonio tecnologico destinato a sostenere la crescita dell’impresa.
Guardare oltre il go-live
Misurare il successo di un progetto esclusivamente il giorno del rilascio è comprensibile, perché rappresenta il momento più visibile dell’intero percorso. Tuttavia, è soltanto con il passare del tempo che emerge il valore delle scelte compiute durante la progettazione. Un software continua a dimostrare la propria qualità quando permette all’azienda di crescere senza ostacolarla, quando si integra con nuove tecnologie senza richiedere interventi invasivi, quando rende possibile introdurre nuovi processi mantenendo sotto controllo costi, tempi e rischi.
In lab51 affrontiamo ogni progetto con questa prospettiva. Il nostro obiettivo non è semplicemente consegnare un’applicazione che soddisfi i requisiti iniziali, ma realizzare soluzioni che possano accompagnare le aziende nel loro percorso di evoluzione, continuando a creare valore anche molti anni dopo il go-live. Perché il software non è un risultato da raggiungere, ma un investimento destinato a crescere insieme all’azienda che lo utilizza.
