Manutenzione e supporto dopo la consegna
Un sistema deve restare sicuro, stabile e comprensibile dopo il go-live. Definiamo la manutenzione come un ambito di responsabilità chiaro — non come disponibilità indefinita.
Quando questo approccio ha senso
- Un sistema è operativo e necessita di assistenza tecnica continua.
- Aggiornamenti di sicurezza e gestione delle dipendenze richiedono attenzione regolare.
- Si verificano errori che devono essere risolti rapidamente senza compromettere le operazioni.
- Nuove funzionalità devono essere aggiunte gradualmente senza destabilizzare il sistema.
- Monitoraggio e backup non sono configurati o sono insufficienti.
- Il team interno non ha capacità o competenze per la manutenzione tecnica continua.
Ambito del servizio
- Monitoraggio operativo e allarmi
- Backup regolari e test di ripristino
- Gestione incidenti e risoluzione errori
- Aggiornamenti dipendenze e sicurezza
- Miglioramenti e adattamenti minori
- Roadmap funzionalità e sviluppo prioritario
- Modello di tempi di risposta e processi di escalation
- Report di stato regolari
- Aggiornamento documentazione in caso di modifiche
Applicazioni tipiche
- Manutenzione continua di un'applicazione sviluppata da Base 17
- Presa in carico della manutenzione di un sistema esistente dopo valutazione tecnica
- Aggiornamenti di sicurezza e monitoraggio per applicazioni web in produzione
- Estensione graduale di un sistema dopo la consegna iniziale
- Supporto ai team interni per questioni tecniche e interruzioni
- Preparazione ed esecuzione di upgrade pianificati
Processo di sviluppo
Il processo è volutamente semplice e trasparente: ambito chiaro, fasi brevi, una versione utilizzabile. Così si riduce il rischio e il lavoro resta allineato al modo reale di operare.
Raccolta dei requisiti
Insieme definiamo cosa deve risolvere il sistema. L'obiettivo è una prima versione utilizzabile — un minimo affidabile nel lavoro quotidiano — non tutto subito.
User story, casi d'uso e bozze
I requisiti si spezzano in parti piccole: chi fa cosa, perché e con quale risultato. Dove serve, usiamo bozze di flusso o wireframe semplici.
Stima di tempi e costi
Ogni unità di lavoro ha una stima realistica. La somma dà durata e costo. I requisiti possono cambiare — con impatto trasparente su tempi e prezzo.
Backlog delle priorità
Prima dello sviluppo, gli elementi concordati entrano in un elenco di priorità: funzioni, integrazioni, correzioni e tutto il necessario per una consegna sostenibile.
Definizione delle fasi
Il lavoro si divide in fasi brevi (di solito una o due settimane). Ogni fase ha un ambito concordato e un obiettivo verificabile.
Iterazioni e revisioni
A fine fase rivediamo i progressi, correggiamo le assunzioni e scegliamo il lotto successivo. Restate padroni della direzione.
Messa in produzione
Quando una versione è pronta: preparazione dati, verifiche in condizioni reali e supporto ai primi utilizzi.
Qualità e sicurezza
- Monitoraggio proattivo invece di risoluzione reattiva degli errori
- Processi di incident documentati e percorsi di escalation
- Aggiornamenti di sicurezza secondo un processo documentato
- Backup testati e ripristino tracciabile
- Le modifiche vengono versionate e documentate
- Nessun SLA pubblicato senza accordo contrattuale
Cosa ci serve dal committente
- Accesso al sistema, all'infrastruttura e alla documentazione rilevante
- Referente per la prioritizzazione e l'approvazione delle modifiche
- Informazioni su cambiamenti aziendali pianificati che riguardano il sistema
- Definizione chiara dei tempi di risposta e delle aspettative di disponibilità
- Disponibilità ad approvare per iscritto modifiche più significative
- Colloqui di revisione regolari sull'ambito di manutenzione