La produzione aggiunge condizioni che la demo non mostra
In una demo qualcuno sceglie il documento, osserva l’esecuzione e risolve subito un problema. Nel lavoro reale arrivano richieste simultanee, persone assenti, allegati inattesi e sistemi esterni lenti. Il piano di rilascio deve rendere esplicite queste differenze e assegnare chi ne gestisce le conseguenze.
Prima di ampliare il perimetro, registra versione attiva, processi inclusi, account, limiti e criteri per fermarsi. Un buon passaggio in produzione non dipende dalla presenza continua della persona che ha costruito il prototipo. Il team operativo deve conoscere la procedura alternativa e poterla attivare.
Quattro modalità da scegliere in base al processo
La modalità ombra va progettata perché non produca effetti esterni: anche un connettore apparentemente di prova può scrivere dati se usa credenziali operative. Il confine deve essere verificabile tecnicamente.
Fai scorrere la tabella per confrontare tutte le colonne.
| Modalità | Cosa fa il sistema | Evidenza prima di avanzare |
|---|---|---|
| Prove offline | Elabora casi senza modificare sistemi reali | Esiti attesi e casi critici verificati |
| Modalità ombra | Produce risultati paralleli senza influenzare il processo | Confronto con il lavoro reale e carico misurato |
| Bozze approvate | Prepara azioni eseguite solo dopo revisione | Coda sostenibile e controlli di approvazione funzionanti |
| Perimetro operativo limitato | Esegue azioni ammesse su una categoria definita | Monitoraggio, arresto e recupero provati |
Esempio illustrativo: attivare l’estrazione di documenti
Il pilota legge un solo formato di documento e prepara una bozza. Il primo rilascio include quel formato e un gruppo di utenti individuato; altri documenti seguono il percorso manuale. Il team controlla campi corretti, revisioni, tempo di attesa e casi non riconosciuti.
Se un fornitore cambia impaginazione, il sistema può inviare quel formato a revisione senza fermare gli altri. L’estensione a una seconda lingua o a documenti diversi richiede casi di prova propri. Il successo sul primo formato non è una prova sufficiente per qualsiasi documento aziendale.
Prepara l’arresto e il recupero prima di averne bisogno
Il canary release descritto da Google SRE espone una modifica a una parte del traffico per osservarla prima di estenderla. Nei processi aziendali, il principio va adattato a categorie, utenti o sedi realmente distinguibili, senza inventare una percentuale valida per tutti.
- Indica chi può sospendere nuove elaborazioni e con quale comando o procedura.
- Definisci cosa succede ai casi già in corso e a quelli in attesa.
- Separa il ritorno alla versione precedente dalla correzione degli effetti già prodotti.
- Conserva un elenco dei casi da riconciliare dopo un incidente.
- Prova il percorso manuale e la riattivazione, non soltanto il pulsante di stop.
Una consegna che rende il team autonomo
Consegnare significa lasciare istruzioni operative, account sotto controllo aziendale, contatti per gli incidenti e casi di valutazione ripetibili. Associa ogni avviso a un responsabile e a un’azione: un cruscotto che nessuno guarda non è una procedura di gestione.
Concorda quando riesaminare il perimetro e quali segnali richiedono una verifica anticipata: più eccezioni, nuovi formati, cambi di modello o integrazione. Documenta la decisione di estendere, mantenere o ridurre l’autonomia. Il rilascio è l’inizio della gestione ordinaria del sistema.
Un modello su cui lavorare.
Piano di rilascio AI
Un piano per fasi con responsabilità, evidenze di accettazione e istruzioni per fermare e recuperare il lavoro.
Scarica il modello MarkdownRunbook di gestione operativa AI
Istruzioni accessibili al personale incaricato: segnali, allarmi, diagnosi iniziale, ripristino e revisione periodica.
Scarica il modello MarkdownPassaggio di consegne dell’automazione
Un verbale di consegna con materiali accessibili, responsabilità accettate, prova di gestione e attività residue assegnate.
Scarica il modello MarkdownDomande pratiche
Quanto deve durare il pilota?
Finché produce evidenza sufficiente sui casi e sulle condizioni concordate. Una durata fissa senza volumi rappresentativi o prove delle eccezioni non dimostra che il processo sia pronto.
Possiamo passare direttamente all’automazione completa?
Dipende dal processo e dalle conseguenze. Se lo fai, devi comunque avere evidenze sui casi reali, limiti eseguibili, monitoraggio e un recupero provato. Le bozze sono spesso una fase utile per misurare.
Fare rollback annulla le azioni eseguite?
No. Ripristinare una versione non cancella email inviate o modifiche già registrate in un altro sistema. Occorre un piano distinto di riconciliazione e correzione.
Riferimenti e metodo
Principio dei rilasci progressivi e dell’osservazione prima dell’estensione. Le modalità e l’esempio sono adattamenti operativi proposti da Stolen Orbit.