O que o go/no-go decide
Um go/no-go é o momento em que o negócio diz: esta versão do CRM pode ir para produção, nesta data. Ou diz: ainda não. Não é uma formalidade no fim do teste. É a razão pela qual o teste foi feito.
Um bom go/no-go tem três partes:
- Factos. O que foi testado, o que passou, o que continua em aberto. Retirado dos resultados dos testes, não da memória.
- Uma avaliação. Os donos dos processos dizem se conseguem fazer o seu trabalho com esta versão, e em que condições.
- Uma decisão. A direção do projeto pesa os factos e as avaliações face à data do go-live, e decide.
Na maioria das reuniões de go/no-go que correm mal, falta a primeira parte. Discute-se a gravidade de uma ocorrência, ou se um processo chegou sequer a ser testado, porque ninguém tem os números. O resto deste guia trata de garantir que os factos estão lá antes de a reunião começar.
Critérios de saída: combine-os antes do primeiro dia de teste
Os critérios de saída dizem quando o teste é suficientemente bom para o go-live. Combine-os com a direção do projeto antes do primeiro dia de teste. No fim, os ânimos estão exaltados e as datas estão próximas. É o momento errado para decidir o que conta.
Critérios que funcionam para a maioria dos go-lives de CRM:
- Nenhuma ocorrência Critical está aberta.
- Todos os casos de teste Must passaram.
- Cada ocorrência High aberta tem uma solução de contorno ou uma data de correção que o negócio aceita.
- Cada caso de teste do âmbito tem um resultado.
- O dono de cada processo deu o sign-off.
Combine o que as palavras significam
Os critérios só funcionam quando todos usam a mesma escala. Deixe por escrito o que significa cada gravidade, e partilhe-o tanto com os testers como com a direção do projeto:
| Gravidade | O que significa |
|---|---|
| Critical | Um processo essencial não funciona e não há alternativa, ou há dados perdidos ou errados. Bloqueia o go-live. |
| High | Um processo essencial só funciona com uma solução alternativa, ou uma função importante falha. |
| Medium | Uma função não funciona como devia, mas há uma alternativa razoável. |
| Low | Cosmético: texto, layout, um pequeno incómodo. |
Faça o mesmo para a prioridade. Um caso de teste marcado como Must cobre o que tem de funcionar no primeiro dia, como criar uma proposta comercial ou encaminhar um caso de suporte. Se um caso de teste Must falha, o go-live está em risco. Veja Escrever casos de teste que os testers do negócio entendem para saber como definir prioridades.
Deixe por escrito o que não é testado
Todo o UAT deixa algo de fora: um país que entra em produção mais tarde, um relatório que não está pronto, uma integração testada apenas no teste de sistema. Ponha-o no papel antes do teste. Assim, ninguém no go/no-go pode dizer que assumiu que estava coberto.
Quem decide
Participam dois grupos de pessoas, com funções diferentes.
Os donos dos processos dão o sign-off
Para cada processo ou grupo do teste, uma pessoa do negócio dá o sign-off: o diretor comercial para lead to cash, o responsável pelo apoio ao cliente para a gestão de casos de suporte, o responsável financeiro para a faturação. Sabem do que as suas equipas precisam, e vão viver com o resultado. O seu sign-off diz: a minha equipa consegue fazer o seu trabalho com esta versão.
Nomeie-os no início do projeto, não na última semana. Um dono de processo que só vê o teste na reunião de go/no-go ou assina sem ler, ou pede mais uma semana.
A direção do projeto decide
A direção do projeto toma a decisão para todo o go-live. Normalmente inclui o sponsor do negócio, o gestor de projeto, um responsável da TI e, com um parceiro de implementação, alguém do parceiro. Pesa coisas que um único dono de processo não vê: um contrato com o CRM antigo que termina, um plano de formação, um fim de semana de migração, outros projetos na mesma data.
O líder de teste prepara, mas não decide
O líder de teste traz os factos e um parecer. O líder de teste não dá o sign-off pelo negócio nem toma a decisão. Manter estas funções separadas é o que faz a decisão resistir quando algo corre mal depois do go-live.
O relatório: o que contém
O relatório de go/no-go é para pessoas que não estiveram no teste. Mantenha-o curto: uma página, com os detalhes por trás para quem os quiser.
- Um parecer. Go, go com condições ou no-go, com os motivos numa ou duas linhas.
- Âmbito. Que processos e user stories estiveram no teste, e o que não foi testado.
- O que foi testado. O ambiente, a release e o build. Um resultado pertence a uma versão do sistema.
- Os números. Casos de teste que passaram, falharam, ficaram bloqueados ou não foram concluídos.
- Por grupo ou processo. Os mesmos números, com o sign-off de cada grupo.
- Por prioridade. Quantos casos de teste Must, Should e Could passaram, e que casos de teste Must não passaram.
- Ocorrências por gravidade. Quantas estão abertas, prontas para reteste e fechadas, com as ocorrências Critical e High abertas identificadas pelo nome.
- Os sign-offs. Quem assinou, quando, com que decisão e que condições.
- Riscos conhecidos. As soluções alternativas que o negócio vai usar nas primeiras semanas, e quem as apoia.
Envie o relatório um dia antes da reunião. Quem o lê em casa faz melhores perguntas.
No UAT StudioO Go/no-go report no dashboard contém a indicação (GO, GO with conditions ou NO-GO, com os motivos), os números, o progresso por dia, os resultados por grupo, por epic e por prioridade, as ocorrências por gravidade, as ocorrências Critical e High abertas pelo nome, e cada sign-off do ciclo. A indicação segue regras fixas e é um parecer: quem decide é a direção do projeto. Partilhe-o em PDF ou descarregue-o como slides para a apresentação à direção do projeto.
O que fazer com as ocorrências abertas
No fim de um UAT há sempre ocorrências abertas. A questão não é se existem, mas se cada uma tem uma decisão. Reveja-as antes da reunião, com o negócio e a equipa de desenvolvimento, como na triagem diária.
| Gravidade | O que o negócio precisa antes do go-live |
|---|---|
| Critical | Corrigida e retestada. Se não puder ser corrigida a tempo, a resposta é no-go, ou o processo sai do go-live. |
| High | Corrigida, ou uma solução alternativa que o dono do processo aceita, com uma data para a correção. |
| Medium | Uma data para a correção, ou a decisão de conviver com ela por agora. |
| Low | No backlog. Não é motivo para esperar. |
Reclassifique com cuidado
Nos últimos dias há pressão para passar uma ocorrência Critical para High. Às vezes é correto: surge uma solução alternativa, ou o processo revela-se raro. Faça-o abertamente, na triagem, com o dono do processo, e deixe por escrito porquê. Nunca o faça às escondidas para melhorar os números. É assim que um go-live falha na primeira semana.
Desejos não são defeitos
Os testers encontram coisas que gostariam que fossem diferentes. Se o sistema funciona como foi desenhado, é um pedido de alteração: vai para o backlog, não para esta release, e não conta contra o go-live.
No UAT StudioA triagem dá a cada ocorrência uma gravidade, uma prioridade, um responsável e uma decisão: Fix, Reject ou Change request. Com o módulo AI test design, Summarize with AI no separador Issues escreve um breve resumo das ocorrências abertas para a reunião de go/no-go: agrupado por tema, com o que bloqueia o go-live. Sem ele, Summarize with your own AI dá um prompt para colar na IA da sua empresa.
Um go condicional
Muitos go-lives de CRM recebem um go com condições. O sistema é suficientemente bom, desde que algo seja feito antes ou logo depois do go-live. É uma decisão justa, desde que as condições sejam reais.
Uma boa condição é:
- Concreta. A aprovação de desconto para encomendas acima de 50.000 está corrigida e retestada, e não as aprovações funcionam.
- Atribuída. Uma pessoa é responsável por ela, pelo nome.
- Com data. Antes do go-live, ou uma data nas primeiras semanas depois dele.
- Verificada. Alguém confirma que foi feita, e a direção do projeto é informada.
Atenção ao número de condições. Duas ou três são normais. Quinze significam que o teste não está concluído. Um go condicional não é uma forma de evitar um no-go.
Go-live por partes
Às vezes um processo não está pronto e o resto está. Pode então entrar em produção sem esse processo, ou com um país ou uma equipa mais tarde. Decida-o de forma explícita, deixe por escrito a nova data da parte que espera, e planeie o seu próprio ciclo de UAT e sign-off.
Sign-off por grupo
Peça um sign-off por processo ou grupo, não uma assinatura para tudo. Um diretor comercial não consegue avaliar a gestão de casos de suporte, nem deveria ter de o fazer. Cada dono escolhe uma de três respostas:
- Accepted: a minha equipa consegue fazer o seu trabalho com esta versão.
- Accepted with conditions: desde que as condições sejam cumpridas. Deixe cada uma por escrito, com quem a cumpre e até quando.
- Rejected: não é suficientemente bom para o go-live. Pergunte o que mudaria a resposta.
Recolha os sign-offs antes da reunião, para que a direção do projeto decida com a visão completa. Um sign-off pertence a uma versão: quando se segue um novo build ou um novo ciclo de testes, dê o sign-off de novo.
No UAT StudioO cartão Sign-off no dashboard tem uma linha para todo o projeto e uma para cada grupo, com Accepted, Accepted with conditions ou Rejected. A data, a hora e o número de ocorrências Critical abertas ficam registados. Por padrão, ninguém pode aceitar enquanto houver uma ocorrência Critical aberta; com No sign-off while Must test cases have not passed marcado, a aceitação também espera até que todos os casos de teste Must tenham passado. Rejeitar é sempre possível. Um sign-off pertence ao ciclo atual.
Conduzir a reunião de go/no-go
Planeie a reunião quando planear os dias de teste, com a data na agenda da direção do projeto. Reserve uma hora. Uma ordem típica:
- O líder de teste apresenta o relatório: âmbito, números, ocorrências abertas, sign-offs. Dez minutos, com os números no ecrã.
- Cada dono de processo diz numa ou duas frases porque assinou como assinou, e quais são as suas condições.
- Perguntas sobre as ocorrências Critical e High abertas: há uma correção, uma solução alternativa, uma data?
- Perguntas fora do teste: formação, migração de dados, suporte nas primeiras semanas, o plano para reverter.
- A decisão: go, go com condições ou no-go. Leia-a em voz alta, com as condições, os responsáveis e as datas.
Se a decisão for no-go, termine com um plano: o que tem de mudar, um novo ciclo de testes e uma data para o próximo go/no-go. Um no-go com um plano é uma decisão normal num projeto. Um no-go sem plano parece um fracasso.
O registo de decisões
Registe a decisão no mesmo dia. Meses depois, após um incidente ou durante uma auditoria, alguém vai perguntar quem decidiu entrar em produção com aquela ocorrência aberta. A resposta deve encontrar-se num minuto.
Um registo de decisões contém, para cada go/no-go:
- A data, e quem esteve na reunião.
- A decisão: go, go com condições ou no-go.
- Cada condição, com o seu responsável, a sua data e, mais tarde, quando foi cumprida.
- As ocorrências abertas que o negócio aceitou, com o motivo.
- O relatório em que a decisão se baseou, tal como estava nesse momento.
Guarde-o com os documentos do projeto, e acompanhe as condições nas primeiras semanas depois do go-live, até cada uma estar cumprida.
No UAT StudioSave snapshot no relatório de go/no-go guarda o relatório tal como estava quando a decisão foi tomada; deixa de mudar, e Show volta a abri-lo mais tarde. Cada sign-off fica no histórico, incluindo os que foram substituídos ou retirados. Para um auditor, os administradores descarregam o Evidence pack: o relatório, os casos de teste, os resultados e as ocorrências, o histórico de cada ocorrência, cada sign-off e o audit log, com um checksum de cada arquivo.
De uso gratuito
Os critérios de saída, o sign-off e o relatório também estão na checklist de UAT para um go-live de CRM, como arquivo Excel gratuito. Para o teste completo, veja os guias de UAT para Salesforce e de UAT para Dynamics 365.