Costo della manutenzione software: cosa deve coprire il budget

Il costo della manutenzione software dipende dal sistema che avete e dalla responsabilità che volete affidare a qualcuno. Un budget utile separa il lavoro necessario per prendere in carico l’applicazione, il lavoro ricorrente che la mantiene affidabile e le modifiche che volete mettere in produzione.

Se state confrontando più fornitori, chiedete a ciascuno un preventivo per lo stesso ambito di lavoro. Un canone mensile che esclude deploy, aggiornamento delle dipendenze e analisi degli incidenti non è confrontabile con uno che li include.

Partite dall’applicazione, non da una percentuale

Il prezzo della realizzazione originale non dice a un nuovo fornitore se i vostri backup si ripristinano, se le dipendenze sono ancora supportate o se l’integrazione dei pagamenti fallisce in silenzio. Prima di considerare una stima come un impegno, stabilite cosa gira in produzione e quali parti richiedono attenzione.

Annotate:

• Cosa fa l’applicazione e quali flussi contano di più.
• Se è un’applicazione web, un prodotto SaaS, un’API o un sistema interno.
• Il runtime, il framework, il database e l’hosting, se li conoscete.
• Chi ha accesso al repository, ai deploy e agli account dei fornitori.
• I guasti recenti, gli aggiornamenti rimandati e le prossime modifiche previste.
• Gli orari in cui l’azienda ha bisogno di assistenza e chi gestisce gli incidenti urgenti.

Se lo sviluppatore originale se n’è andato, usate la checklist per la presa in carico del codice per individuare gli accessi e le conoscenze che mancano. Potete raccogliere queste informazioni anche senza aver ancora scelto un nuovo fornitore.

Dividete il budget in quattro parti

1. Presa in carico iniziale e stabilizzazione

Un nuovo team deve capire cosa gira in produzione, verificare gli accessi, impostare un deploy ripetibile e controllare che il ripristino funzioni. Documentazione mancante o un framework non più supportato possono aggiungere lavoro prima che inizi la manutenzione ordinaria.

Chiedete cosa consegna l’ambito iniziale e cosa comporterebbe una revisione della stima. Tenetelo separato dall’impegno mensile continuativo, così entrambe le parti vedono il costo di ereditare il sistema.

2. Manutenzione ordinaria ricorrente

Elencate il lavoro pianificato: aggiornamenti delle dipendenze e di sicurezza, controlli sui rilasci, prove di ripristino dei backup, monitoraggio e documentazione operativa. Concordate con che frequenza avviene ciascuna attività e quali riscontri ricevete.

Anche le fatture di hosting, database, email e altri fornitori rientrano nel budget di esercizio. Specificate se le pagate direttamente o tramite il fornitore della manutenzione. Il tempo di sviluppo e le fatture dell’infrastruttura sono costi diversi.

3. Assistenza e gestione degli incidenti

Specificate gli orari di copertura, il fuso orario, il canale di contatto e cosa si considera urgente. Il tempo di risposta indica che qualcuno inizia a valutare il problema; non significa che il problema sia risolto entro quel tempo.

Per un’azienda che si affida a un team remoto, discutete la sovrapposizione degli orari in modo esplicito. Non date per scontato che un accordo di manutenzione mensile comprenda risposte notturne o nel fine settimana.

4. Miglioramenti pianificati

Separate la correzione dei difetti dalle modifiche al funzionamento del prodotto. Una nuova integrazione o una modifica importante a un flusso richiedono un ambito di lavoro, anche quando manutenzione e sviluppo sono affidati allo stesso team.

Concordate come si definiscono le priorità, come si approvano le stime e cosa succede quando in un mese c’è più lavoro della capacità disponibile. Questa discussione conta più dell’etichetta sul pacchetto.

Un foglio di calcolo del budget da inviare ai fornitori

Compilate queste voci prima di confrontare i preventivi:

• Lavoro iniziale: accessi mancanti, impostazione del deploy, verifiche di ripristino e riparazioni urgenti.
• Lavoro tecnico ricorrente: attività, frequenza e capacità inclusa.
• Fatture dei fornitori: hosting, database, email, monitoraggio e altri servizi.
• Assistenza: orari di copertura, aspettative di risposta e perimetro degli incidenti.
• Modifiche al prodotto: priorità e un percorso di approvazione separato.
• Incertezza: le aree che il fornitore deve ispezionare prima di impegnarsi.

Per ogni preventivo, chiedete al fornitore di indicare cosa è incluso, escluso o ancora non noto. Chiedete come vengono trattati la capacità non utilizzata e il lavoro oltre l’ambito concordato. Non date per scontato che l’una venga riportata al mese successivo né che l’altro sia fatturato automaticamente.

Quando un preventivo basso lascia lavoro scoperto

Un fornitore può legittimamente offrire un servizio circoscritto. Il rischio è un vuoto di cui nessuno è responsabile: assistenza all’applicazione senza aggiornamento delle dipendenze, monitoraggio senza una persona che riceva gli avvisi, backup senza una verifica di ripristino.

Chiedete chi è responsabile di ciascun vuoto. Potete tenere internamente un’attività, assumere uno specialista o includerla nell’ambito della manutenzione. Il risultato utile è una responsabilità esplicita.

Riparazione, modernizzazione o manutenzione continuativa?

Se l’applicazione è supportata e semplice da rilasciare, può bastare una manutenzione ordinaria ricorrente. Se prima serve un aggiornamento del framework, la riparazione del deploy o una migrazione dei dati, definite quel lavoro a parte.

La nostra guida riparare o riscrivere il software aiuta a distinguere un intervento mirato da una sostituzione. Il budget di manutenzione dovrebbe riflettere questa decisione, senza nascondere un progetto di modernizzazione dentro la manutenzione di routine.

Parliamo della manutenzione della vostra applicazione

AL+ offre servizi di manutenzione software per applicazioni web e prodotti SaaS esistenti, compresi i sistemi realizzati da un altro sviluppatore o da un’altra agenzia.

Scrivete a paul@alplustech.com della manutenzione software. Descrivete l’applicazione, il suo stack se lo conoscete, il vostro paese, il problema attuale e gli orari di assistenza di cui avete bisogno. Inviate prima una descrizione; password, chiavi API e dati dei clienti non vanno nell’email.