Affinare e scalare
Iterazione e cadenza di release
Un ritmo prevedibile per spingere modifiche di configurazione senza ricadere in modalità progetto. Sprint, mese o trimestre, scelga il passo che si adatta e lo mantenga.
Aggiornato il 18 mag 2026
Refine · 6.2
Perché è importante ora
Due pattern comuni dopo il go-live: (1) non cambia più nulla (“siamo live, fatto”) e (2) cambia tutto ad hoc (ogni modifica è una crisi). Entrambi portano a stallo o caos. Una cadenza di release è il modo per evitare entrambi: piccole modifiche, prevedibili, con gli stessi passaggi.
Cosa consegna?
Calendario di release
Ritmo fisso (es. primo martedì del mese) con scope e finestre di freeze.
Flusso RFC
Template Request for Change: richiesta → triage → impatto → approvazione → release.
Strategia di test
Ambiente di accettazione + smoke test per release, con sign-off per service owner.
Template di comunicazione
Cosa cambia, quando, per chi, release notes che gli utenti capiscono.
Tre tipi di modifica, tre cadenze
Piccole e sicure
Quando serve
Aggiungere un campo, pubblicare un articolo KB, cambiare un template. L'owner la spinge, la registra nel change register.
Medie
Release mensile
Modifica di workflow, estensione di classificazione, nuovo report. Flusso RFC, test di accettazione, comunicazione.
Grandi / strutturali
Release trimestrale
Attivare un nuovo modulo, aggiungere un'integrazione, portare l'AI al livello successivo. Mini-progetto, decisione del comitato direttivo.
Domande chiave
- 1Quale ritmo calza, sprint (2 settimane), mese o trimestre per il livello "medio"? Quanto cambiamento possono assorbire gli utenti?
- 2Chi fa il triage delle richieste in ingresso? Quali criteri (impatto × frequenza × sforzo) usa?
- 3Approvazione, quale change board approva cosa? Quali modifiche può fare un admin da solo, quali richiedono lo sponsor?
- 4Ambiente di accettazione, ne dispone? Come sincronizza la config di produzione con quella di test? Quanto si testa prima di andare in produzione?
- 5Smoke test per release, un set minimo di scenari che deve sempre passare, indipendentemente dal contenuto della release.
- 6Roll-back per modifica, soprattutto per i workflow tweak: può tornare indietro se il comportamento va male?
- 7Release notes, chi le scrive, in quale lingua, con quale livello di dettaglio? Per gli utenti: brevi e nella loro lingua. Per gli admin: dettaglio tecnico.
- 8Momenti di freeze, nessuna modifica durante la settimana di audit, chiusura fiscale, fine anno? Li blocchi a calendario.
- 9Backlog, dove vive l'elenco delle richieste aperte? Chi prioritizza, quanto spesso?
- 10Update prodotto di Gfacility stessa, leggere release notes, controllare regressioni, informare gli utenti finali. Chi è owner di questo ritmo?
Template — Scheda RFC
| Campo | Esempio |
|---|---|
| Titolo | Aggiungere categoria "AI assistant" al flusso ticket IT |
| Richiedente / service owner | Sara Janssen (Service manager) |
| Tipo | Media, estensione di classificazione |
| Perché | 15% dei ticket riguarda strumenti Copilot/AI, attualmente "altro" |
| Impatto | Reporting, regola di routing AI, tag KB |
| Rischi | I ticket "altro" esistenti vanno riclassificati |
| Roll-back | Disattivare la categoria, i ticket esistenti mantengono il valore |
| Release proposta | Release mensile di novembre |
| Approvazione | CAB (service mgr, configuratore, PM), sponsor non necessario |
Template — Calendario di release
| Mese | Data release | Freeze da/a | Focus dello scope | Comunicazione |
|---|---|---|---|---|
| Ott | Mar 7 ott 20:00 | Ven 3 ott — Mer 8 ott 9:00 | Modifiche workflow IT | Release notes ven |
| Nov | Mar 4 nov 20:00 | Ven 31 ott — Mer 5 nov 9:00 | Estensione classificazione | Release notes ven |
| Dic | — (nessuna) | Intero mese | Freeze per chiusura di fine anno | Annuncio fine nov |
| Gen | Mar 13 gen 20:00 | Ven 9 gen — Mer 14 gen 9:00 | Release trimestrale: nuova dashboard | Release notes + briefing |
| … | … | … | … | … |