Tech
Il debito tecnico spiegato a chi paga
Il debito tecnico è la somma delle scorciatoie prese per consegnare prima: ogni scorciatoia si ripaga con interessi sotto forma di modifiche sempre più lente e costose. Non è sempre un errore — a volte è la scelta giusta — ma va reso visibile, misurato e rimborsato con regolarità invece che ignorato fino al rifacimento.
C'è un momento, in ogni progetto software che dura da qualche anno, in cui la conversazione cambia tono. Chiedete una modifica che vi sembra piccola e la risposta è "servono tre settimane". Chiedete perché, e ricevete una spiegazione tecnica che non chiarisce niente.
Non vi stanno prendendo in giro, e quasi mai è incompetenza. Vi stanno descrivendo, male, un fenomeno che ha un nome preciso: il debito tecnico. Ed è un concetto economico, non informatico — per questo vale la pena capirlo da chi firma, non solo da chi programma.
Cos'è, in una riga
Il debito tecnico è la somma delle scorciatoie prese per consegnare prima. Come un prestito: prendete valore adesso — la funzione esce a marzo invece che a maggio — e lo restituite dopo, con gli interessi, sotto forma di modifiche che costano sempre di più.
La metafora regge fino in fondo, compresa la parte scomoda: gli interessi si pagano anche se non rimborsate il capitale. Un sistema pieno di scorciatoie non è fermo: rallenta ogni singola cosa che ci farete sopra da qui in avanti.
Perché nasce (e non sempre è un errore)
Contrariamente a quello che si dice, il debito tecnico non è solo il frutto di lavoro fatto male. Nasce in quattro modi, e due sono legittimi.
- Scelta consapevole. Serve arrivare prima di un concorrente o rispettare una scadenza normativa: si prende la strada corta sapendo che andrà sistemata. È un debito buono, come un finanziamento per un macchinario.
- Il mondo è cambiato. Il software è stato costruito per venti utenti e adesso ne ha duecento. Nessuno ha sbagliato: le ipotesi iniziali sono scadute.
- Fretta cronica. Ogni richiesta è urgente, non c'è mai tempo per sistemare. Qui il debito si accumula senza che nessuno decida di accenderlo.
- Nessuno l'ha mai reso visibile. Il caso più comune: il debito esiste, chi lavora al codice lo sa, ma non è mai stato tradotto in un numero che chi decide possa vedere.
Il problema non è avere debito tecnico. È averlo senza saperlo, e quindi non poterlo mettere a bilancio.Come lo trattiamo nei progetti che ereditiamo
I sintomi che riconoscete anche voi
Non serve leggere il codice per accorgersene. Bastano quattro segnali che vedete dal vostro lato:
- Le stime crescono a parità di richiesta. Una modifica che due anni fa era "tre giorni" oggi è "due settimane", e la funzione non è diventata più complicata.
- Ogni correzione ne rompe un'altra. Sistemate una cosa e si guasta qualcosa di apparentemente scollegato: significa che i pezzi sono legati fra loro più di quanto dovrebbero.
- Nessuno vuole toccare quella parte. Esiste un'area del sistema di cui si parla a bassa voce e che si evita nelle riunioni di pianificazione.
- Il fornitore chiede di rifare tutto. È il sintomo più avanzato: quando il rimborso graduale non è più credibile, si propone il rifacimento — che è come estinguere un mutuo accendendone uno più grande.
Quanto costa ignorarlo
Il costo non arriva come una fattura: arriva come lentezza. Una squadra che spende metà del tempo a girare intorno ai problemi del passato consegna la metà delle cose, a parità di spesa. È una tassa che si paga tutti i mesi, e proprio perché è distribuita non compare da nessuna parte.
C'è poi un costo peggiore e meno prevedibile: l'impossibilità di reagire. Il giorno in cui il mercato chiede una cosa nuova e la risposta è "non con questo sistema", il debito ha smesso di essere una questione tecnica ed è diventato un limite competitivo.
Come si rimborsa, senza fermare tutto
La strategia che funziona non è "fermiamoci tre mesi e sistemiamo": è un rimborso costante, invisibile nel piano ma continuo.
- Rendetelo visibile. Chiedete al fornitore un elenco dei punti critici con l'effetto pratico di ciascuno: "questa parte rallenta ogni modifica sugli ordini del venti per cento". Se non sanno rispondere, è già un'informazione.
- Riservate una quota fissa. Fra il dieci e il venti per cento del tempo di sviluppo dedicato al rimborso, ogni ciclo, senza chiedere il permesso ogni volta. È la voce che rende sostenibile tutto il resto.
- Sistemate dove passate. Ogni volta che si tocca un'area per una funzione nuova, la si lascia un po' meglio di come la si è trovata. È il metodo meno costoso perché non richiede progetti dedicati.
- Rifate solo l'inevitabile. Il rifacimento totale ha una percentuale di successo bassa e nel frattempo il sistema vecchio va comunque mantenuto: due costi insieme. Va riservato ai casi in cui la tecnologia non è più sostenibile, non a quelli in cui il codice è brutto.
Le domande da fare al vostro fornitore
- Quali sono le tre parti del sistema che rallentano di più il lavoro, e quanto ci costano in termini di tempo?
- Quanto del vostro tempo, ogni mese, va in manutenzione e quanto in cose nuove?
- Se domani dovessimo aggiungere una funzione nell'area più delicata, quanto costerebbe rispetto alla stessa funzione altrove?
Sono domande che un fornitore serio aspetta da anni: gli permettono finalmente di far vedere un problema che vi ha già segnalato in modo tecnico, e che non è stato capito.
Il debito tecnico non si elimina: si governa, come qualsiasi altra forma di indebitamento. La differenza fra le aziende che ci convivono bene e quelle che ci si strozzano è una sola: le prime sanno quanto ne hanno.