Indice dell'articolo

I CIO hanno lottato per decenni con il debito tecnico, eppure molti lottano ancora per gestirlo adeguatamente. E gli sta costando. La società di consulenza gestionale Protiviti ha intervistato più di 1.000 dirigenti tecnologici per il suo Global Technology Executive Survey 2023 e ha scoperto che il debito tecnico è uno dei principali ostacoli all’innovazione per quasi il 70% delle organizzazioni. I dirigenti hanno anche riferito che il debito tecnologico consuma il 31% dei budget IT e richiede il 21% delle risorse IT per essere gestito.

L’IT Cost Optimization Survey 2023 di LeanIX ha ottenuto un risultato simile: il 56% degli intervistati ha affermato che la tecnologia obsoleta e il debito tecnico contribuiscono particolarmente allo spreco di budget IT.

Ne consegue che i responsabili IT che gestiscono con successo il debito tecnico consentono alle loro organizzazioni di ottenere prestazioni migliori. Secondo la società di ricerca e consulenza Gartner i responsabili delle infrastrutture e delle operazioni che gestiscono attivamente e riducono il debito tecnico possono ottenere tempi di fornitura dei servizi all’azienda almeno del 50% più rapidi.

Alla luce di tali risultati, molti CIO si sono concentrati sulla ricerca di modi per ridurre il proprio debito tecnico. I responsabili tecnologici esperti condividono cinque strategie che utilizzano per tenere sotto controllo il debito tecnologico.

1. Misurare in modo analitico il debito tecnico

Andrew Sharp, direttore della ricerca per l’infrastruttura e la pratica operativa presso Info-Tech Research Group, è un forte sostenitore della “catalogazione” del debito. L’analista consiglia ai responsabili IT di stilare un elenco dei loro debiti tecnici critici, riconoscere l’impatto sul business di tale debito e disporre di un processo per affrontarlo.

Secondo Sharp e altri, molti CIO troppo spesso mancano su queste tre questioni fondamentali.

“Una delle maggiori sfide è comprendere e organizzare l’ambito del debito tecnico“, afferma Sharp, spiegando come i team IT abbiano difficoltà a conoscere l’ammontare e l’impatto del debito “perché si estende in sistemi diversi e ha effetti a catena”.

Ma, come quasi tutti gli ambiti del business, il debito non può essere gestito con successo se non viene misurato. “L’IT deve migliorare nell’identificare, monitorare e misurare il debito tecnologico. L’IT ha sempre un’idea di dove si trovano i problemi, quali armadi contengono degli scheletri, ma spesso non c’è un’analisi formale”, aggiunge Sharp. “Penso che un approccio strutturato sia un’opportunità per pensare a cose che non erano state considerate in precedenza. Quindi non si tratta solo di sapere che abbiamo dei problemi, ma anche di sapere quali sono i problemi e comprenderne l’impatto. La visibilità è davvero fondamentale”.

Tuttavia, mette in guardia dal tracciare ogni frammento di debito tecnologico, sottolineando invece la necessità di tracciare il debito che si intende riparare.

Anche Ken Knapton, vicepresidente senior e CIO di Progrexion, sottolinea dell’importanza di conoscere i dettagli sul debito accumulato dal suo reparto IT.

A tal fine, lui e il suo team IT hanno sviluppato un metodo per misurare il loro debito. Valutano il debito in base ad attributi tecnologici chiave (sostenibilità, durata di vita prevista, stabilità e durata) e quindi in base a due attributi aggiuntivi (criticità aziendale e allineamento strategico). Moltiplicano la somma dei quattro attributi chiave per la somma degli ultimi due e quindi normalizzano i valori in un rapporto compreso tra 0 e 1.

Knapton afferma che un debito con un tasso compreso tra 0 e 0,4 è accettabile, un valore compreso tra 0,5 e 0,7 è preoccupante e un valore superiore a 0,7 è critico.

“Ora che abbiamo un quadro per misurare il debito tecnico, siamo in grado di monitorarlo”, aggiunge. “Possiamo concentrarci su quale parte del nostro debito tecnico affronteremo e su cosa lavoreremo“.

2. Ripagare il debito dandogli la priorità nelle tabelle di marcia

Knapton afferma di aver visto in prima persona il costo del mancato pagamento del debito tecnico.

Indica un incidente passato in cui un team di sviluppo ha utilizzato una libreria Java, ma non è tornato indietro per aggiornare il codice in nome del tempo e della velocità di immissione sul mercato. Tale decisione, sebbene giustificata al momento dello sviluppo iniziale e dell’implementazione del prodotto, ha ostacolato la capacità del team di aggiungere aggiornamenti o apportare le modifiche necessarie in un secondo momento.

Knapton dice di aver imparato che “non c’è niente di così permanente come una decisione temporanea” se quella decisione temporanea non viene rivista.

“Poiché consenti tutte queste piccole decisioni, il debito tecnico può rimanere in vigore e quindi hai soluzioni eccessivamente difficili e complesse, che non ostacolano l’agilità. È allora che il debito tecnico inizia a essere un peso, quando non lo ripaghiamo”, afferma. “Ora lo misuriamo, lo gestiamo e riconosciamo che se vogliamo assumerci un debito tecnico per essere i primi sul mercato, dobbiamo successivamente ripagare quel debito tecnico dopo il rilascio“.

Per assicurarsi che tali pagamenti vengano effettuati, per Knapton è importante aggiungere alla tabella di marcia una sequenza temporale per gestirli e risolverli. I team di Knapton, che lavorano in modo Agile in tutto l’IT, hanno spostato l’obiettivo per includere la mitigazione del debito tecnico.

“Un progetto non è finito finché non torni indietro e aggiusti qualunque cosa tu abbia assunto come debito tecnico; e tutti concordano che questo è il modo in cui definiamo ‘finito’”, afferma Knapton, osservando che il debito tecnico fa parte dell’arretrato di un team fino al completamento del lavoro di mitigazione. “Non voglio che una soluzione temporanea diventi permanente, quindi l’abbiamo inserita ufficialmente nella nostra tabella di marcia“.

Altri sostengono allo stesso modo l’allocazione delle risorse (tempo e denaro) e la creazione di responsabilità per far fronte al debito.

Sharp, per esempio, parla di “migliorare la verifica del valore fornito da un progetto, conoscere e monitorare i bug, il budget per la manutenzione e qualsiasi nuova attrezzatura necessaria“.

3. Trattare il debito tecnico come un rischio aziendale

Enoche Andrade, che in qualità di specialista dell’innovazione delle applicazioni digitali presso Microsoft ha consigliato i dirigenti sul debito tecnico, afferma che il debito tecnico non è solo un problema per l’IT; è anche un rischio aziendale, perché ha implicazioni commerciali, finanziarie e di sicurezza.

In quanto tale, Andrade afferma che il debito tecnico è un tema per tutti i dirigenti e i responsabili delle funzioni aziendali, non solo per l’IT, e le decisioni su quando e quanto debito tecnico sostenere e quando e come viene pagato dovrebbero allinearsi a strategia ed esigenze aziendali.

“I CIO hanno la responsabilità fondamentale di aumentare la consapevolezza sul debito tecnico tra il consiglio di amministrazione e i team di leadership“, afferma. “Per promuovere una cultura di consapevolezza e responsabilità in merito al debito tecnico, le aziende dovrebbero incoraggiare i team interfunzionali e stabilire obiettivi e parametri condivisi che incoraggino tutti i gruppi a lavorare insieme per affrontare il debito tecnico e promuovere l’innovazione. Ciò può includere la creazione di un ambiente sicuro in cui gli sviluppatori possano sperimentare nuovi approcci e tecnologie, portando all’innovazione e al miglioramento continuo”.

Knapton concorda con la necessità di coinvolgere tutta l’azienda quando si decide di assumere debiti tecnici, misurandone l’impatto e dando priorità a cosa pagare.

4. Essere consapevoli di contrarre nuovi debiti

Mike Huthwaite, CIO di Hartman Executive Advisors, confronta il debito tecnico con il debito finanziario. “Il debito è qualcosa che contrai, e poi restituisci“.

Proprio come a volte è saggio assumersi un debito finanziario, Huthwaite afferma che spesso è più intelligente optare per un debito tecnico piuttosto che non farlo. Come altri, afferma che i team possono decidere di contrarre debiti tecnici in favore di velocità e agilità, vantaggi di mercato che superano i costi del debito tecnico.

“È sempre un compromesso, e se continui sull’analogia del debito personale, ci sono punti o decisioni in cui assumersi un debito ha valore. Ma è comunque un debito, quindi va contratto in modo consapevole”.

Huthwaite istruisce i team IT a essere deliberati sull’assunzione di debiti tecnici, soppesando vantaggi e svantaggi nell’utilizzo di un codice non ottimale, per esempio. Lo definisce “debito tecnico intenzionale” , in contrapposizione con il debito tecnico non intenzionale che è contratto senza tale valutazione.

“Il debito tecnico intenzionale ha il suo posto e il suo valore; il debito tecnico non intenzionale è un problema maggiore“, afferma.

Andrade ha consigli simili, affermando che sebbene le organizzazioni non possano realisticamente eliminare tutto il debito tecnico, possono adottare misure per limitarne la creazione (e in particolare la creazione di debito non intenzionale).

Consiglia ai team di adottare la metodologia di sviluppo Agile, refactoring, automatizzare i test e semplificare i processi. I team dovrebbero anche utilizzare strumenti di analisi del codice per identificare il debito tecnico e sottoporsi a regolari revisioni del codice da parte di colleghi e parti interessate per garantirne la qualità e identificare potenziali problemi. Dovrebbero anche abbracciare la semplificazione dell’architettura, la componentizzazione e la standardizzazione.

5. Riconoscere che la gestione del debito è un processo continuo

Wayne F. McGurk, CIO e SVP dell’IT per la National Rural Electric Cooperative Association, non vede il debito tecnico come una cosa buona o cattiva, ma piuttosto “un risultato naturale del processo di sviluppo, che si verifica perché si sta costruendo qualcosa di nuovo“.

“C’è la tendenza ad andare il più velocemente possibile per battere la concorrenza, e all’inizio non si crea necessariamente un’applicazione industrializzata“, afferma. I team fanno compromessi, optando per tecnologie che funzionano, ma che sanno essere insufficienti con la scalabilità delle soluzioni.

Quindi McGurk tiene conto non solo del suo ciclo di sviluppo, ma anche delle operazioni IT, adottando varie strategie per creare un approccio olistico per la gestione del debito su base continua. Come parte di questo approccio, il team di McGurk documenta e descrive in dettaglio l’introduzione di qualsiasi nuovo debito tecnico, che viene quindi monitorato attraverso il sistema di ticketing dell’organizzazione in modo che i team IT “possano raccogliere tutto, segnalarlo e esaminarlo“.

McGurk considera anche come ogni parte del debito influisce sulle operazioni in cinque aree chiave: semplicità, flessibilità, continuità, sicurezza e trasparenza.

“Quando il debito tecnico inizia a ostacolare uno qualsiasi di questi principi operativi, allora è salito al livello in cui dobbiamo affrontarlo“, spiega.

McGurk e il suo team IT prendono in considerazione il livello di impatto, il rischio per l’organizzazione e la strategia complessiva dell’organizzazione per poi dare la priorità a ciò che richiede attenzione. Quindi rendono note tali determinazioni, creando visibilità sull’argomento in tutta l’organizzazione.

“Tutto questo viene inserito nel flusso di lavoro del reparto IT”, afferma McGurk, “in modo che la gestione del debito tecnico non sia trattata come un progetto una tantum, ma sia invece gestita in modo continuativo”. Per esempio, ci si aspetta che i team Scrum identifichino nuovi debiti tecnici e determinino quando e come affrontarli.

“Il CIO deve costruire la cultura della responsabilità in modo che i stuoi team sappiano che solo perché un progetto viene consegnato, non è finito”, conclude. “È un viaggio senza fine, quindi diventa parte della strategia di gestione della domanda, che comprende sia la domanda di nuovo lavoro che il lavoro tradizionale e il debito tecnico“.