Il costo di manutenzione software è il numero che trasforma un progetto riuscito in una conversazione difficile diciotto mesi dopo. La costruzione era stata preventivata, approvata e consegnata. Quello che succede dopo la messa in produzione è stato descritto come «assistenza» e gli è stata attribuita una cifra che qualcuno ha tirato a indovinare, e quella cifra era quasi sempre troppo bassa.

Il motivo è strutturale, non frutto di trascuratezza. Una costruzione ha un perimetro che si può quotare. La manutenzione non ha perimetro, perché è definita da cose che non sono ancora accadute: una libreria che rivela una vulnerabilità, un fornitore che cambia una API, un utente che incappa in un caso che nessuno aveva previsto.

La regola empirica che tutti citano, dal 15 al 20 per cento del costo di costruzione all’anno, è abbastanza vicina al vero da risultare pericolosa. Ci prende abbastanza spesso da dare un senso di sicurezza e sbaglia in una direzione prevedibile: sottostima il primo anno, quando emergono i difetti, e crolla del tutto per i sistemi con obblighi normativi o con molte integrazioni di terze parti, dove il lavoro è generato da eventi esterni e non dal vostro codice.


Che cosa copre davvero il costo di manutenzione software

Cinque categorie distinte, e confonderle tra loro è esattamente ciò che produce il numero sbagliato.

Lavoro correttivo. Correggere i difetti. Si concentra all’inizio, perché la maggior parte dei bug emerge nei primi mesi di uso reale, ed è la categoria che la regola percentuale gestisce meglio.

Lavoro adattivo. Stare al passo con ciò che non dipende da voi. Una dipendenza pubblica una patch di sicurezza. Un fornitore di pagamenti dismette una versione di API. Un browser cambia comportamento. Nulla di tutto questo aggiunge una funzionalità e tutto è obbligatorio.

Lavoro preventivo. Aggiornare prima di esservi costretti. Saltarlo non elimina la spesa, la rimanda e la fa crescere, ed è così che un normale aggiornamento del framework diventa un progetto di tre mesi.

Esercizio operativo. Hosting, monitoraggio, backup, certificati e il tempo delle persone che li tengono d’occhio. Spesso contabilizzato a parte, il che va benissimo purché qualcuno lo contabilizzi.

Piccole modifiche. Il flusso costante di aggiustamenti che un sistema in produzione genera appena ci sono utenti veri. Singolarmente irrilevanti, nel complesso la categoria più pesante quasi ogni anno.

Solo la prima è ciò che di solito si intende per manutenzione. Le altre quattro sono il motivo per cui il budget finisce.

Perché la regola percentuale inganna

Si àncora alla grandezza sbagliata. Lo sforzo di manutenzione segue il numero di parti in movimento e la velocità con cui il mondo esterno le cambia, non quanto è costata la costruzione.

Due sistemi costruiti con la stessa cifra possono differire di un fattore tre. Un’applicazione autonoma con due dipendenze e nessuna esposizione normativa costa poco da tenere in funzione. Un sistema che integra sei servizi di terze parti, tratta dati personali ed è soggetto a regole di settore no, perché ognuna di quelle integrazioni è una sorgente di lavoro che non pianificate voi.

La percentuale presuppone inoltre uno stato stazionario che nel primo anno non esiste. L’uso reale trova i difetti, e i primi sei mesi dopo il lancio stanno di norma ben sopra la media annua prima che la situazione si assesti.

Una stima migliore parte dalle parti in movimento. Contate le integrazioni, gli obblighi di conformità e il numero di utenti che generano contatti con l’assistenza, poi quotate il tempo che tutto questo consuma realisticamente. La nostra guida al costo dello sviluppo software su misura affronta il lato costruzione della stessa aritmetica.

Le voci che i team dimenticano

Aggiornamento delle dipendenze. Non è facoltativo, perché le librerie non aggiornate sono il modo in cui i sistemi vengono compromessi, e lo sforzo è davvero imprevedibile visto che dipende da ciò che fanno i manutentori a monte.

Cambiamenti nelle API di terze parti. Un fornitore dismette una versione e vi dà una scadenza. Non avete scelto voi i tempi e non potete rifiutare.

Rinnovo di certificati e domini. Banale, finché uno scade di sabato e il sito va giù.

Monitoraggio e risposta agli allarmi. Gli avvisi non servono a nulla senza qualcuno che reagisca, e quella reperibilità è un costo reale, che si rompa qualcosa oppure no.

Trasferimento di conoscenza. Le persone se ne vanno. Quello che costa alla persona successiva imparare il sistema è un costo di manutenzione, ed è proporzionale a quanto poco è stato messo per iscritto.

Crescita dei dati. Il costo di archiviazione sale, query che erano veloci rallentano, e il lavoro necessario arriva secondo un calendario deciso dal vostro stesso successo. La nostra guida alle prestazioni del database mostra come si presenta nella pratica.

Quanto costa nel Regno Unito

Intervalli annui indicativi per la manutenzione di un sistema su misura, ipotizzando un fornitore esterno anziché personale interno.

Tipo di sistemaCosto annuo tipico
Piccolo strumento interno, poche integrazionida £6.000 a £15.000
Applicazione rivolta ai clienti, più integrazionida £20.000 a £60.000
Piattaforma regolamentata o ad alto trafficoda £60.000 in su

Sono escluse le voci di hosting e licenze, fatturate a parte e con variazioni enormi. Si presume inoltre che il sistema sia in condizioni ragionevoli. Mantenere qualcosa che nessuno ha documentato, senza test e con una sola persona che lo capisce, costa di più e porta con sé un rischio che nessun contratto di manutenzione elimina.

Come impostare il rapporto

Un canone con ore definite funziona quando il volume è grosso modo prevedibile. Compra disponibilità, che è la parte più grande di quello che state pagando, e le ore non usate non sono uno spreco perché l’alternativa è non avere nessuno.

Il consuntivo a tempo e materiali si adatta ai sistemi che cambiano poco, ma il tempo di risposta diventa quello che consentono gli altri impegni del fornitore, e questo è lo scambio che accettate.

Un contratto di assistenza a prezzo fisso sposta il rischio sul fornitore, che quel rischio lo mette nel prezzo. Ragionevole per i sistemi critici, quando la prevedibilità vale più del margine.

Qualunque strada scegliate, mettetevi d’accordo su che cosa conta come manutenzione e che cosa conta come nuova funzionalità prima di averne bisogno. Quel confine è all’origine di quasi ogni controversia nei rapporti di assistenza, e definirlo all’inizio non costa nulla.

Mecanik mantiene sistemi che non ha costruito oltre a quelli che ha realizzato, nell’ambito del nostro lavoro di sviluppo software . Il primo mese di ogni presa in carico è quasi sempre documentazione, perché è questo a determinare il costo di ogni mese successivo.


Da leggere anche: Contratto a prezzo fisso o a tempo e materiali? , Come scrivere una richiesta di offerta software che porti preventivi utili , Software escrow: chi ne ha davvero bisogno e Sviluppo di un MVP: perimetro, costi e tempi .


Domande frequenti

Quanto costa la manutenzione software all’anno? La regola empirica più diffusa parla del 15 o 20 per cento del costo di costruzione ogni anno, ma sottostima il primo anno, quando emergono i difetti, e non regge affatto per i sistemi con molte integrazioni od obblighi normativi. Gli intervalli indicativi nel Regno Unito vanno da £6.000 a £15.000 per un piccolo strumento interno fino a £60.000 o più per una piattaforma regolamentata o ad alto traffico, hosting escluso.

Che cosa comprende davvero la manutenzione software? Cinque categorie: il lavoro correttivo che sistema i difetti, quello adattivo che sta dietro alle dipendenze e ai cambi di API di terze parti, quello preventivo che aggiorna prima di esservi costretti, l’esercizio operativo con hosting e monitoraggio, e il flusso costante di piccole modifiche che un sistema in produzione genera. Solo la prima è ciò che quasi tutti intendono per manutenzione.

Perché la regola della percentuale sul costo di costruzione è inaffidabile? Si àncora alla grandezza sbagliata. Lo sforzo di manutenzione segue il numero di parti in movimento e la velocità con cui il mondo esterno le cambia, non quanto è costata la costruzione. Due sistemi realizzati con la stessa cifra possono differire di tre volte a seconda del numero di integrazioni, dell’esposizione normativa e del volume di assistenza.

Quali costi di manutenzione i team dimenticano di mettere a budget? Gli aggiornamenti delle dipendenze, le API di terze parti dismesse con scadenze che non avete scelto, il rinnovo di certificati e domini, la reperibilità umana dietro gli allarmi di monitoraggio, il trasferimento di conoscenza quando le persone se ne vanno e l’effetto della crescita dei dati sul costo di archiviazione e sulla velocità delle query.

Meglio un canone o pagare a consumo? Un canone con ore definite si adatta a un volume prevedibile e compra disponibilità, che è la parte più grande di quello che state pagando. Il tempo e materiali si adatta ai sistemi che cambiano poco, ma il tempo di risposta dipende dagli altri impegni del fornitore. Qualunque cosa scegliate, definite che cosa conta come manutenzione e che cosa come nuova funzionalità prima di averne bisogno.