Come organizzare la manutenzione del software dopo il rilascio

Un software personalizzato non smette di aver bisogno di attenzione quando viene pubblicato. Può comparire un errore in un caso che non era emerso nei test, può cambiare una libreria, può smettere di funzionare un servizio collegato oppure può cambiare il modo in cui lavora l'azienda. Sono richieste diverse, anche se arrivano tutte alla stessa persona e finiscono sotto la parola «manutenzione».

Se stai valutando un accordo di manutenzione software personalizzato, chiarisci prima che cosa deve restare in funzione, chi controlla cosa succede e cosa, invece, va considerato sviluppo nuovo. Servono anche regole su accessi, priorità, backup, monitoraggio, assistenza e costi ricorrenti.

Il costo iniziale riguarda la prima versione che hai deciso di costruire. La manutenzione riguarda il periodo in cui quella versione viene usata, aggiornata e collegata al resto del lavoro. Sono decisioni collegate, ma non sono la stessa voce: la guida sui fattori che cambiano il preventivo di un software riguarda il progetto iniziale.

Bug, aggiornamenti e nuove funzioni chiedono accordi diversi

Se un pulsante salva un dato sbagliato, una pagina non si apre o un flusso si interrompe in un caso già previsto, si parla di malfunzionamento. La correzione serve a riportare il software al comportamento concordato. Se vuoi cambiare una regola, aggiungere un report o far lavorare un altro reparto nello stesso flusso, stai chiedendo una modifica. Può essere un lavoro sensato, ma non dovrebbe essere confuso con la correzione di un errore.

Anche gli aggiornamenti tecnici e di sicurezza hanno un compito diverso. Un software dipende dall'ambiente in cui gira, dalle librerie, dal database e dai servizi che lo ospitano. Questi componenti possono richiedere aggiornamenti anche quando il lavoro dell'azienda non è cambiato. Nell'accordo dovrebbe essere chiaro chi controlla gli avvisi, chi prova gli aggiornamenti e cosa succede se una modifica crea un problema. Scrivere soltanto «sistema aggiornato» non dice quali controlli verranno fatti.

Un servizio esterno può cambiare le sue regole, il modo di autenticarsi o i dati che restituisce. Se il gestionale comunica con un servizio di fatturazione, un e-commerce o un altro archivio, l'adattamento può richiedere lavoro anche se il software interno non ha bug. Nell'articolo su quando conviene collegare un gestionale con un'API spiego perché bisogna chiarire prima la fonte principale dei dati e cosa succede quando il collegamento non risponde. L'accordo di manutenzione dovrebbe dire chi segue questi cambiamenti e come vengono gestiti i casi che dipendono dal fornitore esterno.

Backup e monitoraggio servono ancora ad altro. Il backup conserva una copia dei dati; il ripristino verifica che quella copia possa davvero essere usata quando serve. Il monitoraggio controlla invece se il software è raggiungibile, se compaiono errori o se un'attività automatica resta ferma. Un avviso non risolve da solo il problema: bisogna sapere chi lo riceve, chi lo controlla e quale intervento può seguire. Per entrambe le attività vanno chiariti dati coinvolti, frequenza dei controlli, accessi e responsabilità.

L'assistenza riguarda il modo in cui le persone chiedono aiuto: una domanda sull'uso, un permesso da correggere, un errore da riprodurre o un dubbio su un dato. Una nuova funzione, invece, cambia ciò che il software deve fare e richiede una priorità, una valutazione e spesso una stima separata. Metterle entrambe sotto «assistenza inclusa» rende difficile capire cosa succederà quando la richiesta arriverà davvero.

Le domande da fare prima di accettare l'accordo

Non serve trasformare l'accordo in un capitolato tecnico. Deve però essere abbastanza chiaro da poterlo usare davanti a un caso reale. Chiedi almeno:

• quali situazioni vengono considerate bug e quali diventano nuove attività di sviluppo;
• chi controlla aggiornamenti tecnici, problemi di sicurezza e cambiamenti dei servizi esterni;
• quali sono gli accessi necessari a repository, ambiente di esecuzione, database, account delle API e strumenti di monitoraggio;
• che cosa viene salvato nei backup, dove si trova la copia, chi può ripristinarla e come si verifica che il recupero funzioni;
• quali eventi vengono monitorati, dove arrivano gli avvisi e chi decide il primo intervento;
• come si invia una richiesta di assistenza, come si stabilisce la priorità e quali informazioni deve fornire chi segnala il problema;
• quali costi ricorrenti restano a carico dell'azienda e come viene valutato il lavoro che esce dal perimetro concordato.

L'ultimo punto comprende anche i servizi che il software usa ma che non sono sviluppo: hosting, database, spazio per i file, email, mappe, pagamenti o API a consumo. Possono essere intestati direttamente all'azienda oppure gestiti da chi sviluppa il software, ma va scritto chi li paga, chi possiede gli account e cosa succede se cambiano condizioni o fornitore.

Gli accessi e i dati meritano la stessa attenzione delle funzioni. Se un giorno dovrai correggere il progetto con un'altra persona o spostarlo altrove, repository, account e dati devono essere recuperabili. I controlli prima di migrare i dati sono utili anche qui: sapere oggi come esportare le informazioni e chi decide sui dati aiuta anche se non hai ancora in programma un passaggio.

Il prezzo del progetto e i costi dopo il rilascio vanno separati

Nel preventivo iniziale possono rientrare analisi, prototipo, sviluppo, test e pubblicazione della prima versione. Dopo il rilascio possono comparire costi per mantenere l'infrastruttura, usare servizi esterni, conservare i dati o svolgere interventi tecnici. Alcuni sono ricorrenti, altri dipendono da quanto usi un servizio o dal lavoro richiesto da un cambiamento.

Non esiste una forma unica di accordo adatta a ogni software. Può esserci un canone, un pagamento per singolo intervento o una combinazione delle due cose. Qualunque formula scegli, devi sapere che cosa è già compreso, che cosa parte da una nuova valutazione e quali spese arrivano da fornitori terzi. Se esiste una fase di correzione dopo la consegna, vanno indicati anche i suoi confini, senza lasciare tutto alla formula generica «assistenza inclusa».

Per confrontare due proposte di manutenzione, il totale non basta. Un accordo più ampio può includere controlli e responsabilità che in un altro caso restano all'azienda. Un accordo più limitato può essere sufficiente se hai persone interne, accessi ordinati e un software stabile. Prima di scegliere, metti per iscritto chi farà ogni attività e con quali accessi e dati lavorerà.

Quando la manutenzione non basta più

Le richieste che arrivano dopo il rilascio possono mostrare un problema più grande. Se il team continua a lavorare su fogli paralleli, copia gli stessi dati in più posti e chiede correzioni per ogni passaggio importante, non è detto che serva soltanto un accordo più ampio. Può essere necessario correggere il processo, aggiungere un'integrazione o valutare un sistema diverso.

Nell'articolo su quando cambiare gestionale aziendale parto proprio da questa distinzione: prima si osserva un'attività reale, poi si capisce se basta una regola, un modulo, un collegamento o se il limite è strutturale. La manutenzione dovrebbe tenere in ordine uno strumento utile; non dovrebbe diventare il modo per nascondere che il lavoro principale non riesce più a seguirlo.

Per valutare un progetto nuovo o rivedere quello che hai già, il servizio dedicato a software e gestionali su misura parte da flussi, ruoli, dati ed eccezioni. La stessa chiarezza serve dopo: quando sai chi usa il software, quali dati deve proteggere e cosa può cambiare, è più semplice decidere quale manutenzione ti serve.

Prima di accettare un accordo, provalo su tre casi: un bug comparso dopo un aggiornamento, un'API esterna che cambia e una richiesta di nuova funzione. Per ciascuno dovresti poter rispondere a cinque domande: chi se ne accorge, chi interviene, quali accessi servono, se il lavoro è compreso e come si stabilisce la priorità. Se le risposte sono chiare, l'accordo può accompagnare il software nel tempo. Se trovi soltanto «assistenza inclusa», hai ancora qualcosa da chiarire.