Gestire il Debito Tecnico

Il tema del debito tecnico è una questione annosa e costante nell'ottica dello sviluppo software e che va affrontata in maniera molto diversa quando si passa dallo sviluppo alla gestione.

Intanto, senza tecnicismi, possiamo definire il debito tecnico come “il costo futuro del lavoro extra generato dalla scelta di una soluzione rapida oggi, invece di una soluzione migliore che richiederebbe più tempo”.

Come si vede, è tra l’altro una definizione applicabile in molti altri contesti oltre a quello dello sviluppo software, riassumibile in un proverbio popolare come "Presto e bene, raro avviene"

Quando si sviluppa software, spesso la dinamica è che per fare prima si lavora più in fretta, scendendo a compromessi che poi si pagano quando si vuole far evolvere il sistema oppure semplicemente quando ci sono errori di malfunzionamento ed è difficile capire il perché.

C'è inoltre un altro punto importante: la percezione di questo debito dovrebbe cambiare radicalmente in ottica di gestione, perché ci sono nuovi aspetti da considerare oltre a quello di qualità assoluta.

Vediamo alcuni nuovi punti di vista che un leader Tech dovrebbe considerare a riguardo:

• Il debito tecnico non è sempre un nemico: se da sviluppatore attento alla qualità il codice “sporco” è percepito come tale, da manager diventa chiaro come, a volte, indebitarsi consapevolmente sia la scelta necessaria per altri obiettivi. Il punto è proprio farlo consapevolmente.

• Il ROI decrescente: non tutto il codice deve essere perfetto e qualitativamente omogeneo ma è necessario capire quale parte merita davvero l’eccellenza (il “core” del business) e quale è meno prioritario, per cui si può essere meno rigorosi su di esso.

• Per ripagarlo, da developer si può intervenire direttamente, da manager il compito cambia perché il processo va gestito e, per poterlo farlo, servono altri strumenti, soprattutto comunicativi verso il business, per far comprendere impatti del non farlo.

Stante usarlo come strumento quando necessario e consci delle conseguenze, la parte forse più importante, come technical leader, è quello di trasmettere al business il ruolo che esso ha a livello di impatti e, quindi, la necessità di intervenire per “ripagarlo”.

Per farlo, serve abbandonare l’aspetto meramente tecnico e considerare anche altri punti di vista.

Vediamone alcuni:

• Cambio del linguaggio: refactoring, qualità del codice sono concetti poco chiari e interessanti per il business. Meglio parlare di “mitigazione del rischio”, degli “interessi passivi” su nuovi sviluppi (“le nuove feature costeranno il 30% in più se non sistemiamo…”) o degli impatti sul “time to market”.

• Rallentamento: ogni ora spesa a gestire un sistema fragile è un’ora persa per innovare, quindi un freno alla crescita e, di conseguenza, più costi per fare meno lavoro.

• Retention: a nessun sviluppatore piace lavorare su sistemi pieni di debito, in cui ogni cosa è più complicata di quello che dovrebbe e questo può avere impatti sul turnover.

• Incertezza: il debito tecnico rende il fare stime ancora più difficile e questo complica anche il business, che non può pianificare come potrebbe.

Inoltre, integrare anche con dati numerici (velocity, validità stime, tasso di retention, ecc) aiuta molto a visualizzare gli impatti e prendere decisioni a riguardo.

Infine due considerazioni su come gestire al meglio il debito tecnico:

• non tutto il debito va necessariamente pagato: se una parte di codice è orribile ma non viene mai toccata e funziona, lasciarla così è una decisione manageriale valida. Meglio concentrarsi su altro

• Il debito tecnico può essere pagato a rate: uno stop totale di nuovi sviluppi spesso spaventa il business che si sente “prigioniero”, mentre un 20% del tempo di uno sprint dedicato al ripagare il debito è sicuramente più accettabile

Come manager, il passaggio fondamentale è smettere di vedere il debito tecnico come una questione morale e iniziare a vederlo come uno strumento, che si può usare proprio perché consapevoli degli impatti (sia negativi che positivi, almeno sul breve termine) che esso porta.