Gestire il debito tecnico: guida pratica

Per gestire il debito tecnico devi renderlo visibile, ordinarlo in base all'impatto sul business, riservare una quota fissa di ogni sprint o di ogni budget per ripagarlo e verificare se il lavoro sta dando frutti. Non ti servono una riscrittura né un blocco delle nuove funzionalità. Ti serve un breve elenco scritto del debito che pesa di più e l'abitudine costante di sistemarlo.

Questa guida segue il processo nell'ordine: che cos'è il debito tecnico, come valutarlo, come dargli priorità, quanta capacità mettere da parte e come capire se sta funzionando.

In breve

• Il debito tecnico è il costo futuro delle scorciatoie prese oggi. Si accumula: più resta lì, più diventa caro.
• Parti da un audit: metriche di consegna di riferimento, uno sguardo ad architettura, codice e infrastruttura, colloqui con i tuoi sviluppatori e un unico registro condiviso.
• Ordina ogni voce in base all'impatto sul business e al costo del ritardo, non in base a quanto è brutto il codice.
• Riserva una fetta ricorrente di capacità. I dati pubblicati vanno da circa il 15% al 30% dei budget IT: scegli un numero che riesci a mantenere e tienilo stabile.
• Monitora poche misure, come frequenza di rilascio, tempo di ripristino e rapporto di debito tecnico, e rivedile ogni trimestre.

Che cos'è il debito tecnico e perché costa soldi veri

Gartner definisce il debito tecnico come the deviation of a system from its nonfunctional requirements, cioè lo scostamento di un sistema dai suoi requisiti non funzionali. I team lo creano con sacrifici a breve termine, scorciatoie e soluzioni tampone adottate per rispettare una scadenza. La definizione accademica di lavoro di un Dagstuhl seminar dice la stessa cosa in modo più formale: scelte di progettazione o di realizzazione convenienti adesso, ma che rendono il cambiamento futuro più costoso o impossibile.

La metafora finanziaria regge. IBM describes il debito tecnico come qualcosa che matura interessi nel tempo: più a lungo resta irrisolto, più costa sistemarlo. Nella pratica gli interessi si vedono in rilasci più lenti, bug che tornano e sviluppatori che passano la settimana ad aggirare il sistema invece di migliorarlo.

È anche molto diffuso. Un sondaggio Gartner condotto da dicembre 2022 a marzo 2023 ha rilevato che 93% of respondents currently experienced technical debt, cioè il 93% degli intervistati aveva debito tecnico in quel momento, più spesso nell'architettura (67%), nell'infrastruttura (58%) e nel codice (53%). Gartner prevede inoltre che entro il 2027 80% of technical debt will be architectural, cioè l'80% del debito tecnico sarà di tipo architetturale, rispetto al 30% del 2024. Questo conta per il modo in cui lo gestisci: il debito costoso sta sempre più nel modo in cui i sistemi si incastrano tra loro, non nelle singole righe di codice.

L'impatto sul business è misurabile. Un sondaggio Morning Consult del 2024 su 500 dirigenti statunitensi del business e della tecnologia ha rilevato che 80% had delayed or canceled business-critical projects, cioè l'80% aveva rinviato o annullato progetti critici per il business nei 12 mesi precedenti a causa del debito tecnico, e il 79% ha segnalato costi software più alti. Chi ha finanziato il sondaggio vende software e il campione è americano: leggilo come un'indicazione, non come un parametro svizzero.

Non tutto il debito è un errore

Prima di provare a eliminare il debito, separa quello che hai scelto da quello in cui sei scivolato senza accorgertene. I quadranti di Martin Fowler, summarized by Asana, lo classificano lungo due assi: deliberato o involontario, prudente o avventato.

Quadrante	Come si presenta	Cosa fare
Prudente e deliberato	Rilasci in fretta e prevedi di affrontare le conseguenze dopo	Registralo con una condizione che faccia scattare il rimborso
Avventato e deliberato	Sai qual è il modo migliore, ma lo salti per andare veloce	Interrompi lo schema, sistema per primi gli elementi più rischiosi
Prudente e involontario	Trovi un progetto migliore dopo aver costruito	Pianifica il refactoring per la prossima volta che tocchi quell'area
Avventato e involontario	Al team mancavano le conoscenze per farlo bene	Aggiungi revisione, pair programming o supervisione senior, poi sistema

Assumere debito di proposito può essere la scelta giusta. Il rapporto Dagstuhl osserva che Dagstuhl seminar, cioè può essere giustificato in un mercato in rapida crescita dove il tempo di arrivo sul mercato è essenziale. Una startup che lancia un MVP in otto settimane sta facendo uno scambio, non un errore. L'errore è fare lo scambio e non metterlo mai per iscritto.

Gli autori di InfoQ aggiungono un punto utile: quasi ogni decisione architetturale trades one quality against another, cioè sacrifica una qualità a favore di un'altra, come la sicurezza contro l'usabilità o la scalabilità contro il tempo di arrivo sul mercato. Quindi una parte del debito è semplicemente il prezzo di qualsiasi decisione, e l'obiettivo è sapere dove si trova.

Passo 1: valuta il tuo debito tecnico

Una valutazione, o audit del debito tecnico, ti dà un quadro condiviso di ciò che devi. Una sequenza pratica, ispirata alla GainHQ’s audit guide, è questa.

Raccogli le metriche di consegna di riferimento

Estrai i dati dagli strumenti che già usi, come GitHub, GitLab, Azure DevOps o Jira. Guarda la frequenza di deploy negli ultimi 6-12 mesi, il tempo medio di ripristino dopo gli incidenti e il tasso di rilasci falliti. Questi numeri mostrano se il debito ti sta rallentando e diventano la tua fotografia del "prima".

Esamina architettura, codice e infrastruttura

Ripercorri gli schemi dell'architettura attuale e confrontali con ciò che gira davvero. Usa l'analisi statica per trovare i punti caldi: file con complessità alta o scarsa copertura dei test. GainHQ suggerisce di considerare valori di complessità ciclomatica superiori a 10 come segnale di alto rischio di manutenzione. Prendilo come una regola empirica, non come una sentenza, e guarda i punti caldi che vengono anche modificati spesso.

Se il tuo debito comprende un sito web pubblico, un automated technical website audit può segnalare i problemi a livello di sito insieme alla revisione del codice, così i risultati finiscono in un unico elenco.

Parla con chi ci convive ogni giorno

I dati si perdono molte cose. Chiedi a sviluppatori e stakeholder quali parti del sistema temono di toccare, quali rilasci fanno male e quali soluzioni tampone conoscono tutti. Un responsabile del supporto ti indicherà spesso un'integrazione fragile che nessuna dashboard mostra.

Costruisci un unico registro

Tieni ogni risultato in un solo registro del debito tecnico con campi coerenti: categoria, posizione nel codice, sintomi, sforzo stimato e impatto sul business. Per un team piccolo basta un foglio di calcolo. Le organizzazioni più grandi a volte tracciano gli stati del ciclo di vita, e l'IF4IT inventory model elenca stati che vanno da Suspected e Validated fino a Deferred, Approved for Remediation e Closed. Per un team piccolo ne bastano quattro: sospetto, accettato, pianificato, fatto.

Passo 2: decidi cosa sistemare per primo

La ricerca sulla definizione delle priorità parte da una domanda semplice. Una systematic literature review dice che chi lavora sul campo deve prima decidere se sta mettendo in ordine attività di refactoring tra loro, oppure un refactoring rispetto a nuove funzionalità e correzioni di bug, perché le due cose richiedono modi diversi di valutare l'impatto.

Per la maggior parte dei team la seconda è la domanda vera: questa voce di debito contro quella funzionalità. Un metodo di punteggio praticabile usa quattro domande per ogni voce:

1. Impatto sul business. Blocca ricavi, rallenta un elemento della roadmap o aumenta il rischio di un'interruzione o di un problema sui dati?
2. Frequenza di contatto. Quanto spesso gli sviluppatori toccano quest'area? Il debito in codice che nessuno modifica costa poco.
3. Costo del ritardo. Peggiora man mano che ci costruisci sopra? Il debito architetturale di solito sì.
4. Sforzo. Lo sistemi in qualche giorno o serve un progetto di più mesi?

Assegna un punteggio da 1 a 3 a ciascuna, moltiplica impatto, contatto e ritardo e dividi per lo sforzo. Il punto non è la precisione matematica. Serve a imporre una conversazione in cui tecnica e business usano le stesse parole.

Gartner avverte che ridurre il debito richiede che gli stakeholder the deviation of a system from its nonfunctional requirements, cioè concordino sul rischio e collaborino. Indica tre ostacoli: i risparmi a breve termine, la sindrome dell'oggetto luccicante e la paralisi fra stakeholder. Senza puntare sui problemi principali, scrive, l'azienda torna allo stato di partenza. Quindi scegli poche voci ad alto impatto e portale a termine, invece di distribuire lo sforzo a pioggia.

Un esempio concreto

Immagina un team di e-commerce di Zurigo con quattro voci nel registro:

Voce	Impatto	Contatto	Ritardo	Sforzo	Priorità
L'esportazione degli ordini verso l'ERP, fatta a mano, si rompe ogni mese	3	2	3	2	9
Framework del checkout obsoleto	3	3	3	3	9
Nomenclatura incoerente nelle schermate di amministrazione	1	3	1	1	3
Modulo di reportistica legacy inutilizzato	1	1	1	1	1

L'esportazione e il framework del checkout pareggiano, quindi il team sceglie prima l'esportazione: è un lavoro più piccolo e si può chiudere in un solo sprint. Il disordine nella nomenclatura aspetta la prossima volta che qualcuno metterà mano a quelle schermate. Il modulo inutilizzato viene cancellato quando capita. Nessuno discute di gusti, perché la classifica si regge su impatto e sforzo.

Passo 3: riserva capacità e mettila nel piano

Il lavoro sul debito che a ogni riunione di pianificazione compete con le funzionalità perde sempre. Il rimedio è un'allocazione fissa.

I dati pubblicati variano parecchio, segno che non esiste un numero giusto unico:

• Accenture dice che le aziende devono allocate about 15% of IT budgets, cioè destinare circa il 15% dei budget IT al risanamento del debito tecnico, e che le aziende con debito inferiore alla media si aspettano una crescita migliore (5,3% contro 4,4% per il periodo 2024-2026).
• Protiviti riporta che le organizzazioni spend on average 30% of IT budgets, cioè spendono in media il 30% dei budget IT e il 20% delle risorse per la gestione del debito tecnico.
• Uno studio vFunction del 2024 su oltre 1'000 dirigenti statunitensi ha rilevato che 51% of companies dedicate more than a quarter, cioè il 51% delle aziende dedica più di un quarto dei budget annuali IT e di ingegneria al risanamento.

Per un team piccolo, un punto di partenza pratico è un giorno su cinque, in linea con la regola empirica diffusa di circa il 15-20%. Mettilo nello sprint come lavoro con un nome e un responsabile, esattamente come una funzionalità. Se un rilascio è a rischio, riduci la portata della funzionalità prima di intaccare la quota dedicata al debito, altrimenti quella quota sparisce in silenzio.

Due abitudini impediscono al debito di ricrescere:

• Lascialo meglio di come l'hai trovato. Quando uno sviluppatore tocca un'area rischiosa per una funzionalità, aggiunge test o la semplifica nella stessa modifica.
• Definizione di "fatto". Una funzionalità non è finita finché le sue scorciatoie non sono registrate con una condizione di rimborso, per esempio "da rivedere quando superiamo i 1'000 ordini al giorno".

Passo 4: ripagalo a piccoli pezzi

Le riscritture in blocco sono il modo più costoso di ridurre il debito tecnico, perché paghi insieme il vecchio sistema e quello nuovo mentre il business aspetta. Il rimborso graduale funziona meglio:

• Refactoring protetto dai test. Prima aggiungi test attorno a un modulo fragile, poi ne cambi l'interno.
• Soffoca la parte legacy. Dirotta una funzione alla volta verso un nuovo componente e ritira il vecchio codice quando non lo chiama più nessuno.
• Prima avvolgi, poi sostituisci. Metti un'API pulita davanti a un sistema disordinato così il lavoro nuovo smette di dipendere dai suoi meccanismi interni, poi sostituisci l'interno in un secondo momento.
• Cancella. Funzionalità inutilizzate, codice morto e dipendenze abbandonate sono il debito più economico da eliminare.
• Rivedi il codice generato dall'IA. Il codice prodotto dagli assistenti ha bisogno della stessa revisione e degli stessi test di qualunque altro, altrimenti diventa debito nuovo più in fretta di quanto riesci a ripagare il vecchio.

Quando il debito sta nella piattaforma stessa, una migrazione a tappe o un cambio di piattaforma è a volte la risposta onesta. Pianificalo come una serie di rilasci con un sistema funzionante a ogni passaggio, non come un unico passaggio secco.

Passo 5: misura se sta funzionando

Scegli poche misure e rivedile ogni trimestre.

• Metriche di consegna. La frequenza di deploy, il tempo di ripristino e il tasso di rilasci falliti che hai raccolto nell'audit. Le tendenze in miglioramento sono il segnale più chiaro che il lavoro sul debito sta rendendo.
• Rapporto di debito tecnico. SonarSource describes lo descrive come il costo stimato per sistemare i problemi esistenti in proporzione al costo di scrivere il codice all'origine. Un rapporto in crescita segnala che il debito si accumula più in fretta di quanto lo ripaghi.
• Salute del registro. Voci chiuse rispetto a voci aggiunte per trimestre. Se il registro cresce e basta, la tua quota è troppo piccola o le tue abitudini non stanno cambiando.
• Umore del team. Una breve domanda trimestrale agli sviluppatori: quanto è difficile rilasciare una modifica in sicurezza? Spesso si muove prima dei numeri.

Comunica questi dati in termini di business, per esempio "adesso rilasciamo ogni settimana invece che ogni mese", perché è questo che tiene finanziata la quota.

Quando chiamare un aiuto esterno

Una revisione esterna ha senso quando il tuo team è troppo dentro al sistema per ordinarne i problemi, quando un ingegnere chiave se n'è andato, oppure prima di un investimento, di un'acquisizione o di un grosso cambio di piattaforma in cui ti serve un quadro indipendente.

In Ampersand ogni incarico è guidato da ingegneri senior dalla prima conversazione fino alla consegna, così chi esamina il tuo sistema è la stessa persona che ti spiega i risultati. La nostra offerta copre audit, due diligence tecnica, cambio di piattaforma e migrazione di sistemi legacy, oltre a ruoli di CTO a tempo parziale. Se vuoi un accompagnamento continuativo, il nostro piano Guidance costa CHF 799 al mese e il piano Run & monitor per il supporto continuativo costa CHF 750 al mese. Per i progetti e gli altri piani, guarda l'elenco completo di servizi e piani, oppure parti dalla nostra homepage.

Domande frequenti

Quanto tempo dovremmo dedicare al debito tecnico?

Non esiste una cifra universale. I numeri pubblicati parlano di circa il 15% dei budget IT secondo Accenture e del 30% in media secondo Protiviti. Un team piccolo può partire da un giorno su cinque e correggere il tiro dopo un trimestre, in base a come si muovono le metriche di consegna.

Dobbiamo fermare lo sviluppo di funzionalità per sistemare il debito tecnico?

Di solito no. Un blocco toglie slancio al business e raramente affronta le voci giuste. Riserva una quota costante di capacità, sistema per prime le voci a maggiore impatto e unisci le piccole riparazioni al lavoro sulle funzionalità nella stessa area.

Qual è la differenza fra una valutazione del debito tecnico e un audit?

Nella pratica i termini si sovrappongono. Entrambi raccolgono metriche, esaminano architettura, codice e infrastruttura, prevedono colloqui con il team e si chiudono con un registro dei risultati. L'audit tende a essere un esercizio una tantum e più formale, mentre una valutazione può essere un controllo più leggero e ricorrente.

Come spieghiamo il debito tecnico agli stakeholder non tecnici?

Usa il paragone finanziario: le scorciatoie hanno fatto risparmiare tempo adesso, ma applicano interessi sotto forma di rilasci più lenti e costi più alti. Poi mostra due o tre voci del registro con il loro impatto sul business, per esempio un guasto mensile che costa ore al team operativo.

Tutto il debito tecnico è negativo?

No. Una scorciatoia presa di proposito per arrivare sul mercato in tempo può essere una decisione sensata, a patto che sia registrata e che tu abbia un piano per tornarci sopra. Il danno arriva dal debito di cui nessuno sa nulla.

Fonti

• the deviation of a system from its nonfunctional requirements
• 80% of technical debt will be architectural
• 93% of respondents currently experienced technical debt
• Dagstuhl seminar
• IBM describes
• 80% had delayed or canceled business-critical projects
• summarized by Asana
• trades one quality against another
• GainHQ’s audit guide
• IF4IT inventory model
• systematic literature review
• allocate about 15% of IT budgets
• spend on average 30% of IT budgets
• 51% of companies dedicate more than a quarter
• SonarSource describes
• automated technical website audit