Il prezzo di un software non è quello che costa svilupparlo, ma quello che costa possederlo per tutti gli anni in cui rimarrà in produzione. Svilupparlo è diventato economico; gestirlo, ripararlo, integrarlo ed evolverlo, invece, non lo è. Confrontare due proposte basandosi sul budget di realizzazione è come confrontare due edifici basandosi sul costo del cemento.
Negli ultimi diciotto mesi, questa distinzione è diventata urgente. Il costo di produzione del codice è diminuito in modo reale e verificabile: lo Stanford HAI ha documentato che il costo di inferenza per un sistema equivalente a GPT-3.5 si è ridotto di oltre 280 volte tra novembre 2022 e ottobre 2024. Di conseguenza, anche il costo di ingresso di molte proposte di sviluppo è calato. Ciò che non è diminuito è il costo di manutenzione di quanto costruito.
Il budget di un progetto in genere copre l'analisi, la progettazione, lo sviluppo e l'implementazione. Ciò rappresenta tra il 30% e il 40% del denaro che il sistema consumerà durante il suo ciclo di vita. La parte restante viene allocata in seguito, suddivisa in voci che quasi mai sono incluse nella proposta iniziale.
Partenza | Cosa è incluso | Quando compare? |
Costruzione | Analisi, progettazione, sviluppo, implementazione | Mesi 1-9 |
Infrastruttura | Cloud, archiviazione, backup, ambienti | Dal primo giorno, per sempre |
Correzione | Difetti, regressioni, incidenti di produzione | Dalla prima settimana |
Evoluzione | Cambiamenti aziendali, nuovi requisiti, nuove integrazioni | Continuo |
Sicurezza e conformità | Patch, audit, adattamento normativo | Continuo, con picchi regolatori |
Dipendenza | Il costo di avere un solo fornitore che sa come giocarci | Appare quando vuoi cambiare |
Le prime cinque voci possono essere stimate. La sesta non compare in nessun bilancio ed è quella che, quando si concretizza, costa di più perché non viene pagata in euro all'inizio: viene pagata in termini di perdita di potere contrattuale.
Il debito tecnico viene solitamente spiegato come un concetto ingegneristico, motivo per cui i comitati di gestione spesso lo ignorano finché non è troppo tardi. In termini finanziari, è più semplice: si tratta del costo aggiuntivo che si sostiene ogni volta che si desidera modificare qualcosa, derivante da decisioni prese all'epoca per accelerare i tempi.
Secondo le stime del settore, l'onere della manutenzione e del debito tecnologico si aggira intorno al 401% del budget IT medio di un'azienda. Questa cifra va considerata come un ordine di grandezza, non come un dato verificato, poiché le metodologie variano considerevolmente tra i diversi studi. Tuttavia, la tendenza è coerente in tutte le fonti: la maggior parte della spesa tecnologica di un'azienda consolidata non finanzia nuove funzionalità, bensì la manutenzione di decisioni obsolete.
C'è un'ulteriore informazione che cambia completamente la prospettiva quando la si presenta a un direttore finanziario: IBM stima che la riduzione del debito tecnico dei sistemi legacy possa migliorare il ritorno sugli investimenti in intelligenza artificiale fino a 291 volte. In altre parole, il debito tecnico non si limita a comportare costi di manutenzione, ma riduce anche le prestazioni di tutto ciò che viene costruito su di esso.
E il problema sta crescendo, non diminuendo. GitClear, basandosi su un'analisi di 211 milioni di righe di codice, ha documentato che la duplicazione dei blocchi di codice è aumentata vertiginosamente a partire dal 2024 e che il lavoro di refactoring – l'attività che ripaga il debito – è diminuito da circa il 25,1% del totale delle modifiche nel 2021 a meno del 10,1% nel 2024. Si costruisce più velocemente e si fa meno pulizia.
Non è necessario un audit formale per individuare i primi sintomi. Questi sono gli indicatori che compaiono per primi:
Quando si manifestano tre o più di questi sintomi, aumentare la capacità di sviluppo non accelera nulla. Aumenta solo il numero di persone in attesa che venga presa una decisione di progettazione.
Quando si confrontano i fornitori, queste quattro domande distinguono chi vende un singolo prodotto da chi vende un sistema. Nessuna di esse è di natura tecnica; sono tutte di natura contrattuale.
Di chi è questo codice? Se la risposta include sfumature, licenze o "accesso al repository", la risposta è no, non ti appartiene. La proprietà del codice, della documentazione e della proprietà intellettuale deve essere trasferita tramite contratto. Senza tale contratto, qualsiasi preventivo è provvisorio, poiché il fornitore ha un potere di determinazione del prezzo illimitato sulla tua transazione.
Cosa succede se domani volessi cambiare fornitore? La risposta utile non è "non ci riuscirai". È: la documentazione architetturale esiste, i moduli espongono contratti versionati, ci sono ambienti separati e qualsiasi team competente può subentrare entro un lasso di tempo ragionevole. Se per effettuare questa transizione è necessario che qualcuno del fornitore originale "spieghi come funziona", significa che il sistema non è documentato, ma è memorizzato.
Chi paga per i difetti? Un difetto nel codice consegnato non costituisce una modifica dell'ambito del progetto. Dovrebbe essere corretto senza costi aggiuntivi, e ciò dovrebbe essere messo per iscritto. Noi di The Cloud Group lo chiamiamo "Garanzia Rain" ed è incluso nel contratto: correggiamo i difetti nel codice consegnato, a vita. Non si tratta di generosità, ma di coerenza: se affermate che il vostro approccio ingegneristico è disciplinato, dovete accettare i costi derivanti da una sua inosservanza.
Qual è il costo operativo stimato su tre anni? Qualsiasi fornitore affidabile può offrirti una gamma di opzioni per infrastrutture, supporto e aggiornamenti. Chi non può farlo o non le ha prese in considerazione o preferisce che tu non le prenda.
Sono esattamente le domande che aiutiamo a formulare quando agiamo come parte indipendente in un processo di Selezione dei fornitori e redazione delle richieste di offerta (RFP). [link interno], senza partecipare come candidati alla gara d'appalto che stiamo valutando.
Non è una coincidenza, è una relazione causale. Le decisioni che riducono i costi di costruzione sono quasi sempre quelle che aumentano i costi di manutenzione.
Nessuna di queste decisioni è visibile in una demo. Sono tutte visibili nel disegno di legge del terzo anno.
Esiste anche il caso opposto, ed è misurabile. Nei progetti di modernizzazione dei sistemi legacy – che prevedono audit, refactoring e modernizzazione anziché la riscrittura da zero – abbiamo riscontrato riduzioni dei costi di manutenzione fino a 60%. Non perché il nuovo codice sia magico, ma perché il costo di manutenzione è in gran parte il costo dell'incertezza: quando il sistema è comprensibile e testato, ogni modifica cessa di essere un azzardo.
L'errore più comune del team tecnico è quello di richiedere un budget "per saldare il debito tecnico". Si tratta di una richiesta che nessun comitato approva con entusiasmo, perché suona come un tentativo di rimediare a qualcosa che è stato fatto in modo errato.
La formula che funziona è diversa e onesta:
La conversazione si sposta da "il software è fatto male" a "questa è la differenza di costo tra le due opzioni". Questa seconda conversazione si può vincere.
Una proposta economica che non includa la proprietà del codice, la documentazione, i test o i contratti di integrazione non è una proposta economica: è un prestito con un tasso di interesse che scoprirai solo in seguito.
La domanda da porsi quando si decide di acquistare un nuovo software non è quanto costa svilupparlo, bensì quanto costa possederlo, chi ne è il proprietario e cosa succede se si vuole cambiare idea.
Si tratta della somma di tutti i costi associati a un sistema durante tutto il suo ciclo di vita: costruzione, infrastruttura, correzione dei difetti, evoluzione funzionale, sicurezza e conformità, nonché il costo derivante dall'affidamento a un unico fornitore. Il budget di costruzione rappresenta in genere solo tra il 301% e il 401% del totale.
Le stime del settore collocano questa voce di spesa intorno al 401% del budget IT, sebbene la cifra vari a seconda della metodologia di studio. La tendenza è coerente: nelle aziende consolidate, la maggior parte della spesa tecnologica è destinata a consolidare decisioni passate piuttosto che a sviluppare nuove capacità.
Si stima una durata di almeno tre anni e si comprendono sei elementi: costruzione, infrastrutture e ambiente, correzione dei difetti, evoluzione funzionale, sicurezza e conformità normativa, e costi di uscita o di cambio fornitore. Un fornitore affidabile può fornire una stima motivata per i primi cinque elementi.
Perché le decisioni che riducono i costi di costruzione – saltare la fase di progettazione, non eseguire i test, non documentare, rattoppare le cose – sono le stesse che aumentano il costo di ogni successiva modifica. I risparmi si concentrano nel primo trimestre, mentre i costi aggiuntivi si distribuiscono negli anni successivi.
Quattro elementi fondamentali: la proprietà del codice, della documentazione e della proprietà intellettuale; contratti di integrazione versionati e documentati; la correzione gratuita dei difetti; e un piano di transizione che consenta a un altro team di subentrare senza dipendere dal fornitore originale.
Nella maggior parte dei casi, sì, a condizione che vi sia una diagnosi preliminare. L'analisi, il refactoring e la modernizzazione per dominio consentono una significativa riduzione dei costi di manutenzione (fino a 60% nei progetti che abbiamo realizzato), mantenendo al contempo le operazioni in corso, cosa che una riscrittura completa non permette.
Sai quanto ti costerà il software tra tre anni? Il nostro audit tecnico fornisce un report scritto sullo stato della vostra architettura, del codice, del debito tecnico e della sicurezza, a un prezzo fisso e entro 10 giorni lavorativi. È il modo più efficace ed economico per individuare un problema costoso. Richiedi la tua verifica → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
