Um checklist de go / no-go transforma "parece pronto" em uma decisão que você consegue explicar. Cada critério tem um responsável, um limite e uma evidência. Se você é um desenvolvedor solo, você é todos os responsáveis, e escrever tudo ainda impede que você pule os critérios incômodos.
Template (copie e cole)
DECISÃO DE LANÇAMENTO: [App], versão [x.y.z] (build [n]), data [data]
Quem decide: [nome]
| # | Critério | Responsável | Evidência (link / nota) | Ok? |
|---|------------------------------------------------|-------------|---------------------------|-----|
| 1 | Nenhum bug aberto de crash ou perda de dados na build | [nome] | [lista de issues, log de crash] | S/N |
| 2 | Fluxos principais passam na build de lançamento | [nome] | [notas de teste, data] | S/N |
| 3 | Instalação e atualização a partir da versão anterior | [nome] | [aparelho, versões] | S/N |
| 4 | Problemas conhecidos documentados e aceitos | [nome] | [lista de problemas conhecidos] | S/N |
| 5 | Login, pagamentos e permissões funcionam | [nome] | [notas de teste] | S/N |
| 6 | Ficha da loja, notas e capturas batem | [nome] | [link do rascunho] | S/N |
| 7 | Existe plano de rollback ou de interrupção | [nome] | [link do plano] | S/N |
| 8 | Alguém acompanha os crashes após o lançamento | [nome] | [quem, até quando] | S/N |
Qualquer "N" nos itens 1-3 ou 5 = NÃO LANÇAR, a menos que quem decide escreva o motivo.
Decisão: LANÇAR / NÃO LANÇAR / LANÇAR com condições: [condições]
Exemplo (inventado)
DECISÃO DE LANÇAMENTO: Pocket Budget, 1.2.0 (build 57), 2026-10-17
Quem decide: Sam
1 Crash/perda de dados: nenhum aberto - lista de issues conferida às 10:15 - S
2 Fluxos principais: adicionar, editar, excluir registro passam na build de lançamento - S
3 Atualização a partir da 1.1.4: testada em dois aparelhos - S
4 Problemas conhecidos: exportação CSV lenta, aceita - S
5 Login/permissões: caminho de permissão de notificação negada não testado - N
...
Decisão: LANÇAR com condições: testar o caminho de permissão negada antes de enviar.
Como adaptar
- Mude os critérios para o seu app. Um app offline-first precisa de uma linha sobre offline; um app com compras no app precisa de uma linha sobre compras.
- Escreva limites como sim/não. "Parece estável" não é um critério. "Nenhum bug de crash aberto na build de lançamento" é.
- Teste a build de lançamento, não a de debug. O comportamento pode ser diferente, então evidências do artefato errado não valem.
- Defina uma pessoa que decide. Grupos que votam tendem a se dispersar. Uma pessoa decide depois de ouvir os responsáveis.
- Guarde o checklist preenchido. No próximo lançamento, você vê o que aceitou da última vez.
Relacionados: checklist de hotfix, plano de rollback e interrupção, e o hub checklists de teste de apps mobile.
Precisa de testadores na build de lançamento antes de decidir? Comece grátis.