La decisione go/no-go: come prepararla e chi decide

Cosa decide il go/no-go

Il go/no-go è il momento in cui il business dice: questa versione del CRM può andare in produzione, in questa data. Oppure dice: non ancora. Non è una formalità alla fine del test. È il motivo per cui il test è stato fatto.

Un buon go/no-go ha tre parti:

• Fatti. Cosa è stato testato, cosa è passato, cosa è ancora aperto. Presi dai risultati dei test, non dalla memoria.
• Un giudizio. I responsabili dei processi dicono se possono svolgere il loro lavoro con questa versione, e a quali condizioni.
• Una decisione. Il comitato guida confronta i fatti e i giudizi con la data del go-live, e decide.

Alla maggior parte delle riunioni go/no-go che vanno male manca la prima parte. Si discute su quanto sia grave un'anomalia, o se un processo sia stato testato davvero, perché nessuno ha i numeri. Il resto di questa guida spiega come fare in modo che i fatti ci siano prima che la riunione inizi.

Criteri di uscita: concordali prima della prima giornata di test

I criteri di uscita dicono quando il test è abbastanza buono per andare in produzione. Concordali con il comitato guida prima della prima giornata di test. Alla fine gli animi si scaldano e le date sono vicine. È il momento sbagliato per decidere cosa conta.

Criteri che funzionano per la maggior parte dei go-live di CRM:

• Nessuna anomalia Critical è aperta.
• Tutti i casi di test Must sono stati superati.
• Ogni anomalia High aperta ha un workaround o una data per la correzione che il business accetta.
• Ogni caso di test nell'ambito ha un risultato.
• Il responsabile di ogni processo ha dato il sign-off.

Concorda cosa significano le parole

I criteri funzionano solo se tutti usano la stessa scala. Scrivi cosa significa ogni livello di gravità e condividilo sia con i tester sia con il comitato guida:

Fai lo stesso per la priorità. Un caso di test contrassegnato come Must copre ciò che deve funzionare dal primo giorno, come creare un preventivo o instradare un caso. Se un caso di test Must fallisce, il go-live è a rischio. Vedi Scrivere casi di test comprensibili per i tester business per come impostare le priorità.

Scrivi cosa non viene testato

Ogni UAT lascia fuori qualcosa: un paese che va in produzione più tardi, un report non ancora pronto, un'integrazione testata solo nel system test. Mettilo per iscritto prima del test. Così al go/no-go nessuno può dire di aver dato per scontato che fosse coperto.

Chi decide

Partecipano due gruppi di persone, con ruoli diversi.

I responsabili dei processi danno il sign-off

Per ogni processo o gruppo nel test, una persona del business dà il sign-off: il direttore commerciale per il lead to cash, il responsabile del servizio clienti per la gestione dei casi, il responsabile finance per la fatturazione. Sanno di cosa hanno bisogno i loro team e convivranno con il risultato. Il loro sign-off dice: le mie persone possono svolgere il loro lavoro con questa versione.

Nominali all'inizio del progetto, non nell'ultima settimana. Un responsabile di processo che vede il test per la prima volta nella riunione go/no-go firmerà senza leggere, oppure chiederà un'altra settimana.

Il comitato guida decide

Il comitato guida prende la decisione per l'intero go-live. Di solito ne fanno parte lo sponsor del business, il project manager, un responsabile dell'IT e, se c'è un partner di implementazione, qualcuno del partner. Valuta cose che un singolo responsabile di processo non vede: un contratto con il vecchio CRM in scadenza, un piano di formazione, un weekend di migrazione, altri progetti nella stessa data.

Il test lead prepara, ma non decide

Il test lead porta i fatti e un parere. Il test lead non dà il sign-off per il business e non prende la decisione. Tenere separati questi ruoli è ciò che fa reggere la decisione quando qualcosa va storto dopo il go-live.

Il report: cosa contiene

Il report go/no-go è per persone che non hanno partecipato al test. Tienilo breve: una pagina, con i dettagli dietro per chi li vuole.

• Un parere. Go, go con condizioni o no-go, con le motivazioni in una o due righe.
• Ambito. Quali processi e user story erano nel test, e cosa non è stato testato.
• Cosa è stato testato. L'ambiente, la release e la build. Un risultato appartiene a una sola versione del sistema.
• I numeri. Casi di test superati, falliti, bloccati e non completati.
• Per gruppo o processo. Gli stessi numeri, con il sign-off di ogni gruppo.
• Per priorità. Quanti casi di test Must, Should e Could sono stati superati, e quali casi di test Must non lo sono.
• Anomalie per gravità. Quante sono aperte, pronte per il retest e chiuse, con le anomalie Critical e High aperte indicate per nome.
• I sign-off. Chi ha firmato, quando, con quale decisione e quali condizioni.
• Rischi noti. I workaround che il business userà nelle prime settimane, e chi li supporta.

Invia il report il giorno prima della riunione. Chi lo legge a casa fa domande migliori.

In UAT StudioIl Go/no-go report nella dashboard contiene l'indicazione (GO, GO with conditions o NO-GO, con le motivazioni), i numeri, l'avanzamento per giorno, i risultati per gruppo, per epic e per priorità, le anomalie per gravità, le anomalie Critical e High aperte per nome e ogni sign-off del round. L'indicazione segue regole fisse ed è un parere: decide il comitato guida. Condividilo in PDF o scaricalo come slide per la presentazione al comitato guida.

Cosa fare con le anomalie aperte

Alla fine di un UAT ci sono sempre anomalie aperte. La domanda non è se ce ne siano, ma se ognuna abbia una decisione. Esaminale prima della riunione, con il business e il team di sviluppo, come nel triage quotidiano.

Riclassifica con cautela

Negli ultimi giorni c'è pressione per spostare un'anomalia da Critical a High. A volte è giusto: salta fuori un workaround, o il processo si rivela raro. Fallo apertamente, nel triage, con il responsabile del processo, e scrivi perché. Non farlo mai di nascosto per far sembrare migliori i numeri. È così che un go-live fallisce nella prima settimana.

I desideri non sono difetti

I tester trovano cose che vorrebbero diverse. Se il sistema funziona come progettato, è una change request: va nel backlog, non in questa release, e non conta contro il go-live.

In UAT StudioIl triage assegna a ogni anomalia una gravità, una priorità, un assegnatario e una decisione: Fix, Reject o Change request. Con il modulo AI test design, Summarize with AI nella scheda Issues scrive un breve riepilogo delle anomalie aperte per la riunione go/no-go: raggruppate per tema, con ciò che blocca il go-live. Senza il modulo, Summarize with your own AI fornisce un prompt da incollare nell'AI della tua azienda.

Un go con condizioni

Molti go-live di CRM ottengono un go con condizioni. Il sistema è abbastanza buono, a patto che qualcosa venga fatto prima o subito dopo il go-live. È una decisione corretta, purché le condizioni siano reali.

Una buona condizione è:

• Concreta. L'approvazione degli sconti per gli ordini sopra 50.000 è corretta e ritestata, non le approvazioni funzionano.
• Assegnata. Una persona, indicata per nome, ne è responsabile.
• Datata. Prima del go-live, o una data nelle prime settimane successive.
• Verificata. Qualcuno conferma che è stata soddisfatta, e il comitato guida ne viene informato.

Tieni d'occhio il numero di condizioni. Due o tre sono normali. Quindici significano che il test non è finito. Un go con condizioni non è un modo per evitare un no-go.

Go-live per parti

A volte un processo non è pronto e il resto sì. Puoi allora andare in produzione senza quel processo, oppure con un paese o un team più tardi. Decidilo esplicitamente, scrivi la nuova data per la parte che aspetta e pianifica per essa un proprio round UAT e un proprio sign-off.

Sign-off per gruppo

Chiedi un sign-off per processo o gruppo, non una firma unica per tutto. Un direttore commerciale non può giudicare la gestione dei casi, e non dovrebbe doverlo fare. Ogni responsabile sceglie una di tre risposte:

• Accettato: le mie persone possono svolgere il loro lavoro con questa versione.
• Accettato con condizioni: a patto che le condizioni vengano soddisfatte. Scrivile una per una, con chi se ne occupa ed entro quando.
• Rifiutato: non abbastanza buono per andare in produzione. Chiedi cosa cambierebbe la risposta.

Raccogli i sign-off prima della riunione, così il comitato guida decide sul quadro completo. Un sign-off appartiene a una sola versione: quando seguono una nuova build o un nuovo round di test, dai di nuovo il sign-off.

In UAT StudioLa card Sign-off nella dashboard ha una riga per l'intero progetto e una per ogni gruppo, con Accepted, Accepted with conditions o Rejected. Vengono registrati la data, l'ora e il numero di anomalie Critical aperte. Per impostazione predefinita, nessuno può accettare finché è aperta un'anomalia Critical; con No sign-off while Must test cases have not passed spuntato, l'accettazione attende anche che ogni caso di test Must sia superato. Rifiutare è sempre possibile. Un sign-off appartiene al round corrente.

Condurre la riunione go/no-go

Pianifica la riunione quando pianifichi le giornate di test, con la data nel calendario del comitato guida. Riserva un'ora. Un ordine tipico:

1. Il test lead mostra il report: ambito, numeri, anomalie aperte, sign-off. Dieci minuti, con i numeri sullo schermo.
2. Ogni responsabile di processo spiega in una o due frasi perché ha firmato così, e quali sono le sue condizioni.
3. Domande sulle anomalie Critical e High aperte: c'è una correzione, un workaround, una data?
4. Domande al di fuori del test: formazione, migrazione dei dati, supporto nelle prime settimane, il piano di rollback.
5. La decisione: go, go con condizioni o no-go. Leggila ad alta voce, con le condizioni, i responsabili e le date.

Se la decisione è no-go, chiudi con un piano: cosa deve cambiare, un nuovo round di test e una data per il prossimo go/no-go. Un no-go con un piano è una normale decisione di progetto. Un no-go senza piano sembra un fallimento.

Il registro delle decisioni

Metti per iscritto la decisione il giorno stesso. Mesi dopo, dopo un incidente o durante un audit, qualcuno chiederà chi ha deciso di andare in produzione con quell'anomalia aperta. La risposta dovrebbe trovarsi in un minuto.

Un registro delle decisioni contiene, per ogni go/no-go:

• La data, e chi era presente alla riunione.
• La decisione: go, go con condizioni o no-go.
• Ogni condizione, con il suo responsabile, la sua data e, in seguito, quando è stata soddisfatta.
• Le anomalie aperte che il business ha accettato, con il motivo.
• Il report su cui si è basata la decisione, così com'era in quel momento.

Conservalo con i documenti di progetto e segui le condizioni nelle prime settimane dopo il go-live, finché ognuna non è soddisfatta.

In UAT StudioSave snapshot nel report go/no-go conserva il report così com'era quando è stata presa la decisione; non cambia più, e Show lo riapre in seguito. Ogni sign-off resta nella cronologia, anche quelli sostituiti o ritirati. Per un auditor, gli amministratori scaricano l'Evidence pack: il report, i casi di test, i risultati e le anomalie, la cronologia di ogni anomalia, ogni sign-off e il registro di audit, con un checksum per ogni file.

Gratuito

I criteri di uscita, il sign-off e il report sono anche nella checklist UAT per il go-live di un CRM, come file Excel gratuito. Per il test nel suo insieme, vedi le guide per un UAT Salesforce e un UAT Dynamics 365.