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.

Aggiornamento del software in esercizio: cosa si aggiorna, quando e chi lo fa

Nel linguaggio di tutti i giorni "aggiornare il software" significa avere funzioni nuove. In un software aziendale in esercizio vuol dire un'altra cosa, e riguarda quasi sempre strati che l'utente non vede: le librerie su cui il programma è costruito, la versione del linguaggio che lo esegue, il sistema operativo del server, il database, i certificati, i browser e i dispositivi da cui ci si collega. Sono componenti che hanno un ciclo di vita deciso da chi le produce, non da te: escono dal supporto a una data stabilita, e da quel momento nessuno pubblica più correzioni di sicurezza per la versione che stai usando.

Aggiornamento e manutenzione di un software camminano insieme, ma non sono la stessa attività: questa è la parte che nessuno chiede, perché non nasce da una segnalazione né da una richiesta della direzione. Arriva da un calendario esterno, e proprio per questo va messa in agenda da qualcuno: il fornitore che segue il software, un responsabile IT interno, o entrambi con i compiti divisi per iscritto.

Che cosa si aggiorna davvero

La colonna delle cadenze è una traccia di lavoro, non una regola: un software usato da tre persone per la reportistica interna e un portale che raccoglie ordini dai clienti non hanno la stessa urgenza. Se non sai in quale dei due casi ti trovi, è già un buon motivo per farsi valutare il piano di manutenzione del proprio software da chi può leggere il codice e le dipendenze reali, invece di decidere a sensazione.

Quello che non può aspettare e quello che si programma

La distinzione utile non è fra aggiornamento grande e piccolo, ma fra aggiornamento con una scadenza imposta da fuori e aggiornamento che puoi collocare dove vuoi. Tre domande bastano a separarli.

La prima: la falla è già pubblica e la componente è raggiungibile da internet? Se sì, l'aggiornamento non si pianifica, si applica nella prima finestra utile, anche fuori dal ciclo ordinario. La seconda: esiste una data oltre la quale qualcosa smette di funzionare o di essere mantenuto? La fine del supporto di una versione, la dismissione di un'API di terzi, la scadenza di un certificato sono tutte date note in anticipo: si mettono in calendario a ritroso, con il lavoro pianificato nei mesi prima e non nella settimana in cui scadono. La terza: qualcuno in azienda è fermo o sta lavorando in modo peggiore per questo motivo? Se la risposta è no a tutte e tre, l'aggiornamento entra nel ciclo ordinario e va bene così.

Il modo più comune di sbagliare è trattare tutto come urgente, oppure niente. Nel primo caso la produzione viene toccata continuamente e ogni intervento porta un piccolo rischio senza un vero motivo. Nel secondo si arriva al giorno della scadenza con un lavoro di mesi da fare in una settimana.

Come si porta a termine un aggiornamento senza fermare l'azienda

1. Parti da un inventario scritto di quello che hai in esecuzione: versioni di linguaggio, librerie, database, sistema operativo, servizi esterni collegati, con la data di fine supporto di ognuno. Senza questo elenco non stai decidendo le priorità, stai indovinando.
2. Leggi le note di rilascio prima di toccare qualcosa. Ti dicono cosa è stato rimosso e cosa cambia comportamento: è lì che si annidano le sorprese, non nella riga di comando dell'aggiornamento.
3. Aggiorna prima l'ambiente di prova, con una copia dei dati reali (anonimizzati dove servono). Un aggiornamento che passa su un database vuoto non ha dimostrato niente.
4. Prova i percorsi che fermerebbero l'azienda, non tutto il software: accesso degli utenti, emissione o stampa dei documenti, le integrazioni verso l'esterno, i lavori pianificati notturni, i permessi di chi vede cosa. Scrivi l'elenco una volta e riusalo a ogni giro.
5. Scegli la finestra e avvisa chi usa il software, con orario di inizio, durata prevista e a chi segnalare eventuali anomalie. Un fermo annunciato di mezz'ora si organizza; lo stesso fermo a sorpresa diventa una serie di telefonate e di lavoro rifatto.
6. Tieni pronto il ritorno indietro: backup appena fatto e già verificato, versione precedente riattivabile, chi decide di tornare indietro e dopo quanto. Il piano di rientro si scrive prima, quando si ragiona lucidamente.
7. Rilascia un blocco per volta. Se aggiorni contemporaneamente linguaggio, librerie e database, quando qualcosa non torna non sai a chi imputarlo.
8. Guarda log, errori e prestazioni nelle ore e nei giorni successivi. Molti effetti collaterali non si vedono al rilascio, ma al primo lavoro notturno o alla prima giornata di traffico pieno.

Cosa succede quando si salta un giro

Un giro saltato non si nota. Il problema è che gli aggiornamenti non si sommano in modo lineare: più si resta indietro, più diventa difficile aggiornare una componente per volta, perché ognuna pretende una versione minima delle altre. Si arriva al punto in cui l'unica strada è muovere tutto insieme, ed è esattamente l'intervento più rischioso e più costoso da collaudare. Nel frattempo le correzioni di sicurezza pubblicate per le versioni nuove non arrivano su quella che hai in esercizio, e ogni richiesta di sviluppo nuovo si paga più cara, perché va scritta con gli strumenti di qualche anno prima.

Immagina un'azienda di logistica di trenta persone (esempio di fantasia) che rimanda per due anni gli aggiornamenti del suo gestionale su misura perché "funziona". Al terzo anno serve una nuova integrazione con il portale di un cliente: la libreria che la gestisce richiede una versione del linguaggio più recente, quella versione richiede un sistema operativo diverso, e quel sistema operativo non è più compatibile con il vecchio server. La funzione richiesta era piccola; il lavoro necessario per arrivarci no.

Il rimedio non è tecnico, è organizzativo: una cadenza scritta, un inventario aggiornato, una finestra concordata e una persona responsabile. Se sul tuo software oggi nessuna di queste quattro cose esiste, il primo passo sensato è un audit dello stato attuale e un piano di manutenzione dimensionato sul tuo caso, da cui capire cosa è indietro, cosa scade nei prossimi mesi e con che ritmo conviene rimetterlo in pari.

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.

Il rimedio è far leggere il codice prima di firmare il nuovo contratto: una code review del software esistente dice in che stato sono il codice e le dipendenze, cosa manca nella documentazione e quanto lavoro serve per rimetterlo in pari, così il pacchetto di manutenzione si dimensiona su dati veri e non su una stima.

Anchoring: il costo del non manutenere

Per concretezza:

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

Se il software di cui parli è un'app pubblicata sugli store, a queste voci se ne aggiungono altre che un gestionale web non ha: l'iscrizione agli store, l'adeguamento alle nuove versioni di iOS e Android e i servizi esterni che l'app usa. Le trovi una per una, con il modo di stimare il budget dell'anno, nella guida su quanto costa mantenere un'app.

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. Se vuoi capire da dove partire sul tuo software, la pagina sullo sviluppo e la manutenzione di software su misura descrive come impostiamo audit iniziale e piano di manutenzione.

Obly è un'agenzia di sviluppo software su misura con sede a Casale Monferrato (AL): sviluppiamo web app, app iOS e Android, gestionali e integrazioni, e prendiamo in carico la manutenzione di software esistenti, anche quando non li abbiamo scritti noi.