In molte aziende esistono applicazioni che continuano a funzionare da anni e che, osservate dall’esterno, non sembrano presentare problemi particolari. Gestiscono ordini, pianificazione, produzione, fatturazione, logistica o processi amministrativi; vengono utilizzate ogni giorno e magari non generano neppure un numero anomalo di ticket. Eppure basta proporre una modifica apparentemente semplice perché emerga una frase che dovrebbe attirare immediatamente l’attenzione del management: “su quella parte può intervenire soltanto quella persona”.
È uno dei segnali più evidenti di una forma di debito tecnico che raramente compare nei diagrammi architetturali e quasi mai nei bilanci IT: la conoscenza necessaria per comprendere e modificare il sistema non appartiene realmente all’organizzazione, ma è concentrata nella memoria di una o poche persone. Il codice esiste, il database esiste, l’infrastruttura è operativa, ma una parte sostanziale del funzionamento effettivo del software è custodita in conoscenze implicite: perché una determinata regola è stata introdotta, quali integrazioni hanno comportamenti anomali, quali procedure devono essere eseguite in un certo ordine e quali componenti è meglio non modificare senza conoscere conseguenze che nessun documento descrive.
In ingegneria del software questo rischio viene spesso ricondotto al cosiddetto “bus factor”, cioè al numero di persone la cui improvvisa indisponibilità sarebbe sufficiente a mettere in difficoltà un progetto o un sistema. L’espressione è volutamente provocatoria, ma il problema è molto concreto: quando il bus factor di un’applicazione critica è pari a uno, l’azienda possiede formalmente il software, ma non necessariamente possiede la capacità di governarlo.
Il software può funzionare perfettamente ed essere comunque ad alto rischio
Il problema della conoscenza concentrata è particolarmente insidioso perché non produce necessariamente malfunzionamenti immediati. Un’applicazione può avere uptime elevato, tempi di risposta accettabili e utenti soddisfatti, mentre contemporaneamente accumula un rischio crescente. Finché non occorre modificarla, integrare un nuovo sistema, sostituire un componente, aggiornare una libreria o affrontare un incidente importante, quel rischio rimane quasi invisibile.
Immaginiamo un gestionale sviluppato internamente quindici anni fa e progressivamente ampliato fino a gestire 500 utenti, 30 integrazioni e alcune centinaia di regole di business. Tre sviluppatori hanno lavorato sul sistema nel tempo, ma uno solo conosce davvero le logiche più delicate: sa, per esempio, che una procedura notturna non può partire prima della chiusura di un determinato flusso ERP, che alcune righe di una tabella apparentemente obsoleta vengono ancora utilizzate da un processo mensile e che una modifica alla gestione degli sconti ha effetti anche sulla generazione delle note di credito. Nulla di tutto questo è necessariamente evidente leggendo il codice.
Se quella persona è disponibile, una modifica può richiedere due giornate: una per individuare il punto corretto e una per implementare e verificare l’intervento. Se invece non lo è più, lo stesso cambiamento può trasformarsi in una settimana di analisi, test e ricostruzione delle dipendenze. Con un team di tre persone impegnato per cinque giornate, il costo non è più quello di 2 giornate/uomo ma di 15, senza considerare il ritardo sul progetto che dipende da quella modifica. Il differenziale non deriva dalla tecnologia utilizzata: deriva dalla conoscenza che l’organizzazione non ha reso trasferibile.
Il vero patrimonio non è sapere dove si trova il codice, ma sapere perché è fatto così
Quando si parla di documentazione tecnica si pensa spesso a manuali, diagrammi UML, descrizioni delle API o schemi del database. Sono strumenti importanti, ma non risolvono da soli il problema. La parte più preziosa della conoscenza è spesso quella che spiega le decisioni: perché una certa architettura è stata scelta, perché un vincolo apparentemente inutile non può essere rimosso, quali alternative sono già state provate e scartate, quali regole applicative derivano da esigenze del business e quali invece sono semplici conseguenze storiche di un vecchio sistema.
Consideriamo un’applicazione che, prima di confermare un ordine, esegua sette controlli. Dal codice è possibile capire che i controlli esistono; molto più difficile è capire perché esistano tutti e sette. Due potrebbero essere requisiti commerciali ancora validi, uno potrebbe derivare da una normativa, due potrebbero compensare limiti di un ERP sostituito cinque anni prima e gli ultimi due potrebbero essere stati introdotti per un cliente che non è più attivo. Se questa conoscenza non è disponibile, chi interviene tende comprensibilmente a non rimuovere nulla. La conseguenza è che il software continua ad accumulare regole, perché aggiungere sembra più sicuro che togliere.
È così che la conoscenza non formalizzata si trasforma progressivamente in debito tecnico. McKinsey stima che il debito tecnologico possa rappresentare una quota molto rilevante del patrimonio IT e che molte aziende paghino un “interesse” aggiuntivo superiore al 10% sui progetti proprio per affrontare complessità pregresse. La documentazione è soltanto una delle componenti del fenomeno, ma quando manca la comprensione delle decisioni storiche ogni evoluzione richiede più analisi, più verifiche e maggiore prudenza.
Quanto costa dipendere da una sola persona
Per rendere il problema più concreto, immaginiamo un sistema enterprise sul quale vengono realizzate 40 evolutive all’anno. In condizioni normali ogni intervento richiede mediamente 5 giornate tra analisi, sviluppo e test, per un totale di circa 200 giornate. Supponiamo però che il 30% di queste attività coinvolga componenti conosciuti realmente da un solo specialista e che, in sua assenza, il tempo necessario aumenti mediamente da 5 a 9 giornate a causa della ricostruzione del contesto, dei test aggiuntivi e delle verifiche sulle dipendenze.
Dodici interventi annuali genererebbero così 48 giornate aggiuntive. Valorizzando una giornata tecnica a 700 euro, stiamo parlando di oltre 33.000 euro all’anno di costo potenziale, senza avere introdotto una sola nuova funzionalità. Se poi una di quelle modifiche si trova sul percorso critico di un progetto commerciale o operativo, il costo reale può essere molto maggiore: un ritardo di tre settimane nell’attivazione di un nuovo canale B2B, per esempio, non pesa soltanto sul budget IT ma può posticipare ricavi, onboarding di clienti e attività organizzative già pianificate.
Il rischio aumenta ulteriormente durante incidenti e situazioni urgenti. Se un sistema che elabora 20.000 ordini al giorno si blocca alle 10 del mattino e soltanto una persona sa interpretare correttamente una determinata sequenza di log o conosce la procedura di ripristino, il tema non è più l’efficienza dello sviluppo ma la continuità operativa. Anche un fermo di poche ore può avere conseguenze molto superiori al costo necessario per distribuire preventivamente quella conoscenza.
La documentazione è necessaria, ma non basta
La risposta più immediata a questo problema è spesso “dobbiamo documentare tutto”. È una reazione comprensibile, ma rischia di produrre centinaia di pagine che nessuno mantiene aggiornate. La conoscenza tecnica non diventa patrimonio aziendale soltanto perché viene trasferita in un documento: deve poter essere trovata, compresa, verificata e soprattutto utilizzata da più persone.
Un approccio più efficace consiste nel concentrarsi sui punti nei quali la perdita di conoscenza avrebbe un impatto reale. Per un’applicazione critica può essere molto più utile avere una mappa aggiornata delle integrazioni, dieci decision record che spiegano le scelte architetturali principali, una descrizione dei processi batch più delicati, procedure di deploy e recovery realmente testate e una matrice che identifichi almeno due persone in grado di intervenire sui componenti strategici, piuttosto che produrre un manuale di 300 pagine destinato a diventare obsoleto dopo pochi mesi.
Anche il codice deve contribuire alla trasferibilità. Test automatici, naming comprensibile, modularità, pipeline riproducibili e osservabilità riducono la quantità di conoscenza che deve essere tramandata oralmente. Se per rilasciare un’applicazione occorre ricordare una sequenza di dodici operazioni manuali conosciuta soltanto dal senior developer, quella sequenza è già un rischio; se la stessa procedura è descritta e automatizzata in una pipeline, una parte della conoscenza è stata incorporata nel sistema e resa ripetibile.
Il passaggio di consegne non si fa nelle ultime due settimane
Il momento peggiore per scoprire una dipendenza critica è quando la persona che possiede la conoscenza ha già comunicato che lascerà l’azienda o quando il rapporto con il fornitore sta terminando. In quel momento il tempo diventa il vincolo principale e il trasferimento tende a concentrarsi in una serie di riunioni nelle quali si cerca di comprimere anni di esperienza in pochi giorni.
Supponiamo che uno specialista abbia lavorato per otto anni su una piattaforma e che disponga di dieci giornate per il passaggio di consegne. Anche dedicando sei ore effettive al giorno al trasferimento, avremmo circa 60 ore per ricostruire architettura, processi, anomalie, integrazioni, procedure operative e motivazioni delle scelte accumulate in migliaia di giornate di lavoro. È evidente che il problema non può essere risolto semplicemente aumentando il numero delle riunioni.
Il trasferimento deve quindi avvenire mentre il sistema viene gestito. Code review incrociate, rotazione sulle attività, pairing sui componenti critici, condivisione della gestione degli incidenti e revisione periodica della documentazione sono strumenti molto più efficaci di un passaggio di consegne concentrato alla fine. L’obiettivo non è fare in modo che tutti sappiano tutto, cosa irrealistica nei sistemi complessi, ma evitare che esistano aree nelle quali una sola persona rappresenti contemporaneamente documentazione, supporto e memoria storica.
Come capire se il problema esiste prima che diventi urgente
La concentrazione della conoscenza può essere misurata con indicatori relativamente semplici. Se per ciascuna applicazione critica si identificano i componenti principali e si registra quante persone sono realmente in grado di modificarli, gestirli in produzione e spiegarne le dipendenze, emerge rapidamente una mappa del rischio. Un sistema composto da 20 componenti nel quale 14 hanno almeno tre persone competenti, cinque ne hanno due e uno soltanto dipende da un singolo specialista presenta un profilo molto diverso da un sistema nel quale 12 componenti su 20 hanno un unico referente.
Lo stesso vale per le attività operative. Quante procedure di deploy possono essere eseguite da almeno due persone? Quante integrazioni dispongono di documentazione aggiornata? Quanto tempo impiega un nuovo sviluppatore per effettuare autonomamente la prima modifica significativa? Se l’onboarding su un’applicazione richiede quattro mesi e per le prime otto settimane ogni decisione deve essere validata sempre dalla stessa persona, il problema non è soltanto la velocità di inserimento del nuovo collega: è un segnale che la conoscenza del sistema non è sufficientemente distribuita.
Non serve necessariamente costruire KPI sofisticati. Anche una matrice applicazioni-competenze aggiornata trimestralmente può evidenziare dove intervenire. Se un sistema è classificato come mission-critical e presenta un solo referente su architettura, database e deploy, quella combinazione dovrebbe essere trattata come un rischio operativo esattamente come un’infrastruttura priva di ridondanza.
Ridurre il debito di conoscenza prima di modernizzare
Questo aspetto diventa decisivo anche nei progetti di modernizzazione. Prima di riscrivere un’applicazione legacy, migrare verso il cloud o sostituire un gestionale, è necessario capire quali informazioni siano realmente contenute nel sistema esistente. Il rischio è considerare il codice vecchio come qualcosa da eliminare e scoprire troppo tardi che proprio quel codice rappresentava l’unica descrizione disponibile di regole di business costruite in dieci o vent’anni.
Per questo una fase di assessment dovrebbe affiancare all’analisi tecnica una vera ricostruzione della conoscenza: componenti, dipendenze, dati, integrazioni, procedure operative, regole di business e persone che le conoscono. Se da un assessment di 20 giornate emerge che il 40% delle logiche critiche è concentrato in due persone prossime a cambiare ruolo, quel dato può modificare le priorità del progetto molto più della versione del framework utilizzato.
Un software è davvero governabile quando la conoscenza sopravvive alle persone
Le persone competenti restano naturalmente fondamentali e nessuna organizzazione può eliminare completamente la specializzazione. Il punto è evitare che la continuità di un sistema dipenda dalla permanenza di individui specifici. Un’architettura comprensibile, documentazione mirata, test, automazione, condivisione delle responsabilità e una conoscenza diffusa del dominio trasformano l’esperienza individuale in patrimonio organizzativo.
Quando questo non avviene, il software tende progressivamente a diventare intoccabile. Ogni modifica viene percepita come rischiosa, le stime si allungano per prudenza, gli aggiornamenti vengono rimandati e l’azienda finisce per adattare i propri processi ai limiti di un sistema che nessuno vuole più modificare. A quel punto il problema non è semplicemente avere un’applicazione legacy: è aver perso la capacità di decidere liberamente come farla evolvere.
In lab51 affrontiamo queste situazioni partendo da un assessment tecnico e funzionale che non si limita a leggere il codice, ma cerca di ricostruire il funzionamento reale del sistema, le sue dipendenze e la distribuzione della conoscenza tra persone, documentazione e strumenti. L’obiettivo è individuare i punti di dipendenza critica, definire cosa debba essere documentato o reso riproducibile e costruire un percorso che permetta di evolvere, subentrare o modernizzare l’applicazione con un rischio controllato.
Se nella tua azienda esiste un software sul quale “può mettere mano soltanto una persona”, o una piattaforma che nessuno vuole modificare perché non è chiaro cosa potrebbe succedere, lab51 può aiutarti a trasformare quella conoscenza implicita in un patrimonio tecnico governabile, prima che un cambio di ruolo, un nuovo progetto o un incidente trasformino una dipendenza nascosta in un problema operativo.
