La manutenzione di un software su misura va pianificata prima che arrivi la prima urgenza. Serve a correggere problemi, mantenere compatibili i collegamenti e valutare le nuove richieste senza confondere ogni intervento con un guasto. Il punto di partenza è un accordo operativo: chi segnala, chi decide, quali verifiche precedono il rilascio e che cosa rientra nel budget.
A cura di Matteo Dosi, E-ROE. Questa guida riguarda un sistema già in uso; per decidere se la prima versione è pronta, consulta invece il collaudo con criteri di accettazione.
In copertina: schermata pubblica reale di Carbonetica Registry dall’archivio portfolio autorizzato. Le situazioni descritte sono esempi didattici, non incidenti o impegni di assistenza relativi a quel progetto.
Separa correzioni, adeguamenti e nuove funzioni
Le etichette aiutano a decidere, ma il perimetro concreto deve essere scritto nell’accordo. Descrivi prima il risultato atteso e poi classifica il lavoro.
- Correzione: un comportamento concordato non funziona. Per esempio, un documento non viene prodotto con i dati previsti.
- Adeguamento: cambia l’ambiente o un servizio collegato e bisogna conservare il funzionamento. Per esempio, un’integrazione richiede un formato diverso.
- Evoluzione: l’azienda chiede una capacità nuova, come un’approvazione aggiuntiva o un report non previsto.
- Prevenzione: si interviene su una fragilità prima che provochi problemi, per esempio rendendo più chiaro un controllo o aggiornando un componente da valutare.
Un nuovo requisito non diventa una correzione soltanto perché è urgente. Allo stesso tempo, la presenza di un errore non dice da sola chi debba sostenerne il costo: contano accordo, cause e perimetro verificato.
Assegna responsabilità che il team possa usare
Individua un referente aziendale che descriva l’impatto sulle attività e un referente tecnico che valuti dipendenze e rischi. Stabilisci chi può approvare spese e nuove funzioni. Se le responsabilità sono distribuite fra più fornitori, chiarisci chi coordina il problema quando non è ancora nota la causa.
Nel piano indica chi segue applicazione, hosting, backup, account e servizi esterni. Un contratto di sviluppo non implica automaticamente che la stessa persona controlli ogni componente. Le pratiche di sviluppo sicuro del NIST SSDF considerano anche la gestione delle vulnerabilità lungo il ciclo di vita: è un riferimento di metodo, non una certificazione del progetto.
Descrivi una segnalazione che si possa verificare
Una richiesta utile permette di distinguere il comportamento osservato da quello atteso. Puoi usare questa scheda:
- attività interrotta e persone coinvolte;
- ora del problema e versione, se disponibile;
- passaggi che lo riproducono;
- risultato atteso e risultato effettivo;
- presenza di un percorso temporaneo per continuare;
- riferimento del caso, con dati riservati rimossi;
- referente che può verificare la soluzione.
Esempio fittizio: un operatore non riesce a chiudere una richiesta, mentre gli altri possono lavorare. Prima di assegnare la massima priorità, verifica quale ruolo è coinvolto, se il problema è ripetibile e se esiste una procedura temporanea approvata. Perdita di dati o accessi impropri richiedono invece una valutazione urgente anche se coinvolgono pochi utenti.
Concorda priorità e tempi senza confonderli
Definisci l’urgenza in base a impatto, diffusione e possibilità di proseguire. La presa in carico conferma che qualcuno sta valutando la segnalazione; la risoluzione richiede diagnosi, intervento e verifica. Specifica orari di copertura, canale, frequenza degli aggiornamenti e percorso per le urgenze.
Non esiste un tempo universale adatto a ogni applicativo. Chiedi quali impegni siano effettivamente sostenibili e quali dipendano da terzi. Una richiesta evolutiva dovrebbe entrare in una lista ordinata, con beneficio atteso, stima da approvare e criteri per riconoscere il lavoro concluso.
Verifica la modifica prima e dopo il rilascio
Il piano deve indicare dove provare la modifica, chi dà il via libera e quali percorsi esistenti ricontrollare. Registra versione, test svolti, problemi aperti e modalità di recupero se qualcosa va storto. Per cambiamenti ai dati, valuta con il tecnico come evitare perdite o duplicazioni: ripristinare il codice non ripristina automaticamente lo stato dei dati.
La guida Microsoft alle pratiche di rilascio sicuro, riferita ad Azure, raccomanda cambiamenti piccoli e controlli fra le fasi. Il principio utile per il committente è rendere ogni intervento riconoscibile e verificabile; lo strumento concreto dipende dal sistema.
Rivedi il piano insieme al budget
Nel controllo periodico confronta richieste concluse, problemi ricorrenti, aggiornamenti da programmare e lavoro ancora aperto. Separa il costo della gestione ordinaria, dei servizi esterni e delle evoluzioni approvate. Chiedi anche come trasferire documentazione e accessi se cambia il fornitore.
Un aumento dei ticket può dipendere da più utenti o da un nuovo processo, non soltanto da qualità peggiore. Leggi i numeri insieme al contesto e alle attività che il software deve sostenere.
Stai pianificando un software su misura con E-ROE? Porta il processo principale, le dipendenze esterne e le fasce orarie in cui un fermo sarebbe più dannoso. Sono elementi utili per valutare fattibilità e responsabilità successive al lancio, senza presumere un servizio di reperibilità già incluso.
