Skip to main content

Processo de Go / No-Go e Liberação

Objetivo desta página

Esta página define como ocorre o processo de decisão de liberação de uma demanda na DBSeller, estabelecendo critérios claros para Go ou No-Go, responsabilidades envolvidas e a forma correta de registrar e comunicar essa decisão.

O processo de Go / No-Go garante que a liberação:

  • seja consciente

  • esteja baseada em dados

  • considere riscos reais

  • não seja tomada apenas por prazo

O que é Go / No-Go

Go

Indica que a demanda:

  • foi validada

  • atende aos critérios definidos

  • possui riscos conhecidos e aceitos

  • está apta para liberação

No-Go

Indica que a demanda:

  • apresenta riscos inaceitáveis

  • não atende critérios mínimos

  • possui pendências críticas

  • não deve ser liberada no momento

No-Go não é falha do processo, é proteção do sistema e do negócio.

Critérios avaliados na decisão

A decisão de Go / No-Go é baseada em um conjunto de critérios técnicos e operacionais.

Principais critérios avaliados

  • resultados dos testes executados

  • severidade e prioridade de bugs abertos

  • cobertura de testes realizada

  • riscos identificados e não mitigados

  • impacto no usuário e no negócio

  • tipo de demanda (bug, melhoria, hotfix)

Não existe decisão de Go baseada em “achismo”.

Exemplos práticos de critérios

Exemplo 1 – Go

  • todos os cenários críticos passaram

  • bugs abertos são S3 ou S4

  • regressão executada conforme impacto

  • riscos documentados e aceitos

Exemplo 2 – No-Go

  • bug S1 aberto

  • falha em cenário crítico

  • regressão não executada

  • comportamento inconsistente sem entendimento claro

Papel do QA no processo

O QA não decide sozinho, mas é responsável por fornecer insumos técnicos confiáveis para a decisão.

O QA é responsável por:

  • executar testes planejados

  • identificar e comunicar riscos

  • avaliar impacto de falhas

  • apresentar evidências

  • recomendar Go ou No-Go com base técnica

O QA não aprova por pressão e não reprova sem fundamento.

Uso da análise de risco para antecipar No-Go

Um dos papéis mais importantes do QA é antecipar riscos, evitando No-Go tardio.

Como isso acontece

  • análise ainda no refinamento

  • avaliação de impacto antes da execução

  • identificação de dependências críticas

  • histórico de falhas semelhantes

Quando o QA identifica risco alto com antecedência, ele:

  • comunica o risco

  • propõe alternativas

  • ajuda a redefinir escopo ou prazo

Isso evita retrabalho e desgaste na etapa final.

Exemplo prático de No-Go antecipado

Durante o planejamento, o QA identifica que:

  • a funcionalidade altera lógica crítica

  • não há tempo hábil para regressão mínima

  • existe histórico de regressões nesse módulo

Nesse cenário, o QA comunica:

Sem regressão mínima, o risco de impacto em produção é alto. A recomendação é No-Go nesta janela.

Essa comunicação não bloqueia o time, ela protege o produto.

Responsáveis pela decisão

A decisão de Go / No-Go é compartilhada, com responsabilidades bem definidas.

Papéis envolvidos

  • QA: fornece análise técnica e recomendação

  • Desenvolvimento: confirma status da implementação

  • Produto/Negócio: avalia impacto e prioridade

  • Gestão (quando aplicável): valida riscos assumidos

A decisão final deve ser explícita e registrada.

Registro da decisão

Toda decisão de Go ou No-Go deve ser registrada.

O registro deve conter

  • decisão tomada (Go ou No-Go)

  • resumo do motivo

  • riscos identificados

  • evidências de teste

  • responsáveis pela decisão

Isso garante:

  • rastreabilidade

  • transparência

  • histórico para análises futuras

Comunicação na etapa de liberação

Por que comunicação é essencial

Mesmo uma decisão tecnicamente correta pode gerar problema se for mal comunicada.

Boas práticas de comunicação

  • ser clara e objetiva

  • evitar termos ambíguos

  • registrar por escrito

  • alinhar todos os envolvidos

A comunicação deve responder:

  • o que foi decidido

  • por quê

  • quais os riscos

  • próximos passos

Exemplo de comunicação de Go

Todos os cenários críticos foram validados. Não há bugs bloqueantes. A regressão mínima foi executada conforme impacto identificado. Recomendação: Go para liberação.

Exemplo de comunicação de No-Go

Foi identificado bug de severidade S1 no fluxo principal, além de regressão não executada por falta de tempo hábil. O risco de impacto em produção é alto. Recomendação: No-Go nesta janela.

Resultado esperado deste processo

Com esse processo, a DBSeller garante:

  • decisões conscientes

  • menos incidentes em produção

  • QA atuando estrategicamente

  • comunicação clara entre áreas

Go / No-Go não é um checkpoint burocrático.
É o último guardião da qualidade antes da produção.

Back to top