Manutenzione software: piani, costi e priorità

Lanciato il software, una percezione comune è "il difficile è finito". In realtà inizia la fase più lunga: quella della manutenzione. Il software che vive a lungo è quello manutenuto bene; quello che si trascura entro 24 mesi è solitamente da rifare.

In questa guida vediamo cosa serve davvero per mantenere un software in salute nel tempo: tipi di manutenzione, livelli di servizio, costi orientativi, errori comuni.

I tre tipi di manutenzione

La parola "manutenzione" copre attività diverse, con effort e priorità diverse.

1. Manutenzione correttiva

Risolvere problemi che emergono in produzione: bug, malfunzionamenti, errori segnalati dagli utenti.

Frequenza: continua, picco nei primi 90 giorni post-lancio. Volume tipico: 2-10 ore/mese a regime stabile.

2. Manutenzione evolutiva

Aggiungere nuove funzionalità, migliorare quelle esistenti, adattare a nuovi requisiti di business.

Frequenza: pianificata, in cicli (es. nuovo modulo ogni trimestre). Volume tipico: variabile, da scope.

3. Manutenzione preventiva

Aggiornamenti di sicurezza, refactoring tecnico, ottimizzazioni proattive, manutenzione delle dipendenze.

Frequenza: regolare (settimanale o mensile). Volume tipico: 5-15 ore/mese.

Manutenzione evolutiva: come si pianifica e come si mette a contratto

La manutenzione evolutiva è il lavoro che fai su un software già in produzione per adattarlo a bisogni nuovi: funzioni che prima non servivano, modifiche a quelle esistenti, adeguamenti a un processo aziendale o a un obbligo che è cambiato. Si distingue dalla correttiva perché non nasce da un difetto: il programma fa quello che era stato chiesto, è la richiesta che si è spostata. E si distingue dalla preventiva perché non riguarda la salute tecnica del sistema (dipendenze, patch, prestazioni) ma quello che il sistema deve saper fare.

La differenza pratica sta nei tempi di reazione. Una segnalazione correttiva ha una scadenza imposta dall'esterno, perché c'è qualcuno fermo. Una richiesta evolutiva no: puoi deciderne tu il momento, ed è l'unica delle tre che si riesce a pianificare davvero. Il rischio è simmetrico: siccome non urge mai, senza un metodo resta ferma per mesi e ritorna sotto forma di lamentela.

Da dove arrivano le richieste

Un backlog evolutivo utile raccoglie da quattro fonti diverse, e ognuna va cercata dove sta, perché nessuna arriva da sola in modo ordinato.

Le prime due fonti si presentano da sole. La terza va chiesta due volte l'anno a chi segue amministrazione e contratti, perché di solito emerge tardi. La quarta la porta soltanto chi mette le mani nel codice: se non chiedi esplicitamente al fornitore che cosa gli rende difficile lavorare su quel software, quella voce non entra mai in elenco. Tieni tutto in un unico posto, con data di arrivo e nome di chi ha chiesto: ti serve per rispondere quando la richiesta torna.

Come si mettono in ordine, e come si dice di no

Un criterio scritto vale più di qualsiasi discussione a voce. Dai a ogni voce tre valutazioni da 1 a 3: il valore per chi usa il software (quante persone, quante volte al giorno), il costo di realizzazione stimato da chi sviluppa, il rischio se non si fa (nessuno, fastidio crescente, blocco o adempimento mancato). Le voci con valore alto e costo basso partono per prime; quelle con rischio 3 saltano la fila a prescindere dal resto.

Il "no" fa parte del metodo. Non rifiutare la richiesta in astratto: comunica la posizione in elenco e il motivo del punteggio, così chi l'ha portata sa cosa dovrebbe cambiare perché salga. Una voce che resta ferma per tre cicli e che nessuno rivendica più si chiude, con una riga scritta a chi l'aveva proposta. Dire che una cosa non si farà quest'anno costa una conversazione; lasciarla in sospeso costa la fiducia di chi la aspetta.

Monte ore ricorrente o intervento a scope

Sono due modi di comprare la stessa cosa e convivono bene. Il monte ore ricorrente è un numero di ore al mese riservate al tuo software: si adatta a un flusso continuo di richieste piccole e ti evita di trattare un preventivo ogni volta. L'intervento a scope è un preventivo su un perimetro definito, con collaudo dedicato: è la forma giusta per un modulo nuovo o per un'integrazione, dove il lavoro ha un inizio e una fine riconoscibili.

Qualunque forma scegli, in contratto conviene che siano scritte cinque cose: chi decide le priorità (una persona sola, con nome e ruolo), ogni quanto si rilascia, come si collauda e chi firma l'accettazione, che fine fanno le ore non consumate nel periodo, e a chi appartengono codice e documentazione. Sono clausole ordinarie, ma è la loro assenza a generare quasi tutti gli attriti del secondo anno. Falle rileggere da un legale prima della firma.

Il ciclo di lavoro, passo per passo

1. Raccogli le richieste in un unico elenco, con data e proponente, senza filtrarle mentre arrivano. A fine mese hai una lista comparabile invece di una serie di conversazioni sparse.
2. Assegna i punteggi in una riunione breve con chi decide e chi sviluppa, davanti alla stessa tabella. Esci con un ordine condiviso, non con una discussione rimandata.
3. Fai stimare solo le prime voci della lista, quelle che entrano davvero nel ciclo successivo. Ottieni stime attendibili e non spendi ore a valutare cose che non farai.
4. Rilascia a data fissa, anche se entra meno del previsto. Il software cambia con un ritmo prevedibile e chi lo usa impara ad aspettarsi le novità.
5. Verifica sul campo dopo due settimane, parlando con chi la funzione la usa davvero. Sai se la richiesta è stata chiusa o se torna in elenco riformulata.

Un esempio concreto

Marelmi Srl (nome di fantasia), 40 dipendenti, produce componenti meccanici e lavora su un gestionale su misura da tre anni. Le richieste arrivavano a voce e in copia a mezza azienda, così sono state convogliate su una casella unica, evolutivo@esempio.it, e raccolte in un elenco: 23 voci in due mesi. Con i punteggi, la prima è diventata la generazione automatica del documento di trasporto dai dati dell'ordine, valore 3 (tre persone in spedizione, ogni giorno), costo 1, rischio 1. Un adeguamento chiesto dal cliente più grande, con una scadenza contrattuale a marzo, è passato davanti per rischio 3. Quattro richieste di reportistica sono rimaste ferme per tre cicli e sono state chiuse con una mail di due righe. Il contratto è un monte ore da 12 ore al mese con rilascio ogni terzo giovedì e collaudo firmato dal responsabile di produzione; gli interventi più grandi restano fuori e si preventivano a parte.

Cosa contiene un piano di manutenzione tipico

Quello che includiamo nei nostri pacchetti standard:

Servizi sempre inclusi

• Monitoraggio uptime e performance 24/7
• Aggiornamenti di sicurezza critici applicati entro 48 ore
• Backup automatici con restore testato mensilmente
• Aggiornamento periodico dipendenze
• Reportistica mensile sullo stato del sistema
• Supporto via canale dedicato per segnalazioni

Su richiesta (a scope)

• Sviluppo nuove feature
• Refactoring di parti specifiche
• Migrazione a nuove versioni di linguaggi/framework
• Audit di sicurezza periodici
• Ottimizzazione performance mirata

In caso di incident

• Intervento prioritario entro SLA concordato
• Root cause analysis
• Fix + comunicazione utenti se necessaria
• Post-mortem documentato

Tabella livelli di servizio

La scelta dipende dal costo dell'eventuale downtime, dalla complessità del sistema, dalla rapidità di evoluzione del business.

Errori comuni nella manutenzione

1. Niente manutenzione

"Lo abbiamo lanciato, funziona, basta così." Risultato: dopo 12-18 mesi il software è obsoleto, vulnerabile, lento. Spesso da rifare.

2. Manutenzione solo reattiva

"Interveniamo solo quando si rompe qualcosa." Risultato: problemi gestiti in emergenza, costi alti, qualità del fix scarsa.

3. Manutenzione senza monitoring

"Se ci segnalano problemi, agiamo." Risultato: problemi noti agli utenti per giorni prima che il team se ne accorga. Perdita di fiducia.

4. Mancanza di documentazione operativa

Quando il problema arriva, nessuno sa esattamente come è configurato il sistema. Diagnosi rallentate del 50-100%.

5. Cambio fornitore senza handover strutturato

Dal vecchio fornitore al nuovo, senza passaggio di consegne formale. Mesi di onboarding del nuovo team durante i quali la manutenzione è di fatto sospesa.

Anchoring: il costo del non manutenere

Per concretezza:

Investire in manutenzione regolare è quasi sempre l'opzione economicamente più conveniente.

Come strutturiamo i nostri contratti di manutenzione

Per trasparenza, ecco il nostro modello:

Setup iniziale

• Audit del software esistente per dimensionare il pacchetto
• Setup monitoring se non già presente
• Documentazione operativa creata o aggiornata
• Definizione degli SLA condivisi

Esercizio mensile

• Review settimanale dello stato del sistema
• Applicazione patch di sicurezza in finestra concordata
• Aggiornamento dipendenze (con test)
• Report mensile con metriche chiave

Su richiesta

• Sviluppo nuove feature a scope
• Audit periodici (semestrali o annuali)
• Consulenza strategica su evoluzione del software

Tutto trasparente: ore consumate visibili in un dashboard, niente sorprese in fattura.

Conclusione

La manutenzione del software non è un costo opzionale: è la condizione perché l'investimento iniziale conservi valore. Un software non manutenuto è capitale che si svaluta velocemente.

Il piano di manutenzione giusto non è il più economico: è quello dimensionato sulla criticità del sistema e sul valore del business che lo utilizza. Spesso una conversazione di un'ora con un partner serio basta per definirlo correttamente.

Investire nella manutenzione è investire nella longevità del progetto. È sempre più conveniente di rifare da zero.