9 min leitura • Guide 709 of 877
Lista de Verificação de Preparação para Lançamento
Os lançamentos falham por detalhes negligenciados, não por grandes erros. O GitScrum ajuda a coordenar atividades de lançamento com listas de verificação, rastreamento de tarefas e recursos de coordenação de equipe que garantem que nada passe despercebido.
Framework da Lista de Verificação de Lançamento
Categorias
CATEGORIAS DE PREPARAÇÃO PARA LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PREPARAÇÃO TÉCNICA: │
│ O produto está estável e testado? │
│ • Funcionalidade verificada │
│ • Performance testada │
│ • Segurança revisada │
│ • Infraestrutura pronta │
│ • Monitoramento implementado │
│ │
│ PREPARAÇÃO OPERACIONAL: │
│ Podemos dar suporte em produção? │
│ • Equipe de suporte treinada │
│ • Documentação completa │
│ • Runbooks prontos │
│ • Processo de incidentes definido │
│ │
│ PREPARAÇÃO DE NEGÓCIO: │
│ O negócio está pronto para lançar? │
│ • Marketing preparado │
│ • Vendas habilitadas │
│ • Legal/conformidade aprovado │
│ • Stakeholders alinhados │
│ │
│ CONTINGÊNCIA: │
│ E se algo der errado? │
│ • Plano de reversão testado │
│ • Templates de comunicação prontos │
│ • Caminhos de escalação claros │
│ • Sala de guerra agendada │
└─────────────────────────────────────────────────────────────┘
Lista de Verificação Técnica
LISTA DE VERIFICAÇÃO DE PREPARAÇÃO TÉCNICA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TESTES: │
│ ☐ Todas as funcionalidades testadas (aprovação QA) │
│ ☐ Suíte de testes de regressão passando │
│ ☐ Testes de aceitação do usuário completos │
│ ☐ Testes cross-browser/dispositivo feitos │
│ ☐ Testes de acessibilidade aprovados │
│ ☐ Problemas conhecidos documentados e aceitos │
│ │
│ PERFORMANCE: │
│ ☐ Testes de carga completados │
│ ☐ Performance sob carga esperada aceitável │
│ ☐ Performance sob carga de pico aceitável │
│ ☐ CDN configurado e testado │
│ ☐ Consultas de banco de dados otimizadas │
│ │
│ SEGURANÇA: │
│ ☐ Varredura de segurança completa (sem problemas críticos) │
│ ☐ Testes de penetração feitos (se aplicável) │
│ ☐ Autenticação/autorização testadas │
│ ☐ Criptografia de dados verificada │
│ ☐ Gerenciamento de segredos revisado │
│ │
│ INFRAESTRUTURA: │
│ ☐ Ambiente de produção provisionado │
│ ☐ DNS configurado │
│ ☐ Certificados SSL instalados │
│ ☐ Auto-scaling configurado │
│ ☐ Backups verificados │
│ │
│ MONITORAMENTO: │
│ ☐ Monitoramento de aplicação ativo │
│ ☐ Rastreamento de erros habilitado │
│ ☐ Alertas configurados │
│ ☐ Dashboards prontos │
│ ☐ Rotação de plantão definida │
└─────────────────────────────────────────────────────────────┘
Lista de Verificação Operacional
LISTA DE VERIFICAÇÃO DE PREPARAÇÃO OPERACIONAL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DOCUMENTAÇÃO: │
│ ☐ Documentação do usuário completa │
│ ☐ Documentação da API publicada │
│ ☐ Notas de release escritas │
│ ☐ FAQ atualizado │
│ ☐ Limitações conhecidas documentadas │
│ │
│ SUPORTE: │
│ ☐ Equipe de suporte informada sobre novas funcionalidades │
│ ☐ Documentação de suporte atualizada │
│ ☐ Problemas comuns e soluções preparados │
│ ☐ Caminho de escalação definido │
│ ☐ Canal de suporte pronto (chat, email, etc.) │
│ │
│ RUNBOOKS: │
│ ☐ Runbook de deploy atualizado │
│ ☐ Procedimento de reversão documentado │
│ ☐ Runbook de problemas comuns pronto │
│ ☐ Contatos de emergência listados │
│ │
│ TREINAMENTO: │
│ ☐ Equipes internas treinadas (suporte, vendas, CSM) │
│ ☐ Materiais de treinamento disponíveis │
│ ☐ Ambiente de demo pronto │
└─────────────────────────────────────────────────────────────┘
Processo de Lançamento
Cronograma
CRONOGRAMA DE LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ T-2 SEMANAS: PREPARAÇÃO │
│ • Completar desenvolvimento de funcionalidades principais │
│ • Começar revisão sistemática da lista de verificação │
│ • Agendar todas as atividades de teste │
│ • Alertar todos os stakeholders │
│ │
│ T-1 SEMANA: TESTES E POLIMENTO │
│ • Foco em testes, não em novas funcionalidades │
│ • Apenas correções de bugs │
│ • Finalização da documentação │
│ • Primeira reunião de ir/não ir │
│ │
│ T-2 DIAS: PREPARAÇÃO FINAL │
│ • Congelamento de funcionalidades │
│ • Passagem final de testes │
│ • Deploy em pré-produção │
│ • Todos os itens da lista de verificação verdes │
│ │
│ T-1 DIA: IR/NÃO IR FINAL │
│ • Revisar todas as listas de verificação │
│ • Aprovação dos stakeholders │
│ • Confirmar agendamento da sala de guerra │
│ • Comunicações finais preparadas │
│ │
│ DIA DO LANÇAMENTO: │
│ • Executar plano de deploy │
│ ☐ Monitorar de perto │
│ ☐ Sala de guerra ativa │
│ ☐ Comunicar sucesso │
│ │
│ T+1 SEMANA: ESTABILIZAÇÃO │
│ • Monitorar métricas │
│ • Resolver feedback inicial │
│ • Retrospectiva pós-lançamento │
└─────────────────────────────────────────────────────────────┘
Decisão de Ir/Não Ir
REUNIÃO DE IR/NÃO IR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUTURA DA REUNIÃO (30 min): │
│ │
│ 1. REVISÃO DA LISTA DE VERIFICAÇÃO (15 min) │
│ Percorrer cada categoria │
│ Status vermelho/amarelo/verde para cada item │
│ │
│ 2. AVALIAÇÃO DE RISCO (10 min) │
│ Quais são os riscos restantes? │
│ Qual é o plano de mitigação? │
│ O que poderia causar um não ir? │
│ │
│ 3. DECISÃO (5 min) │
│ IR: Prosseguir com o lançamento │
│ IR CONDICIONAL: Prosseguir se X for resolvido até Y │
│ NÃO IR: Adiar até que os problemas sejam resolvidos │
│ │
│ CRITÉRIOS DE DECISÃO: │
│ │
│ 🟢 IR: │
│ • Todos os itens críticos verdes │
│ • Problemas conhecidos têm mitigações │
│ • Plano de reversão testado │
│ │
│ 🟡 CONDICIONAL: │
│ • Itens menores pendentes │
│ • Caminho claro para resolução │
│ • Nível de risco aceitável │
│ │
│ 🔴 NÃO IR: │
│ • Itens críticos não prontos │
│ • Risco inaceitável │
│ • Nenhuma mitigação viável │
└─────────────────────────────────────────────────────────────┘
Dia do Lançamento
Execução
EXECUÇÃO DO DIA DO LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRÉ-LANÇAMENTO (Manhã): │
│ ☐ Sala de guerra ativa (virtual ou física) │
│ ☐ Todos os membros da equipe confirmados disponíveis │
│ ☐ Dashboards de monitoramento abertos │
│ ☐ Canais de comunicação prontos │
│ ☐ Script de reversão pronto │
│ │
│ DEPLOYMENT: │
│ ☐ Executar runbook de deployment │
│ ☐ Verificar deployment bem-sucedido │
│ ☐ Executar testes de fumaça │
│ ☐ Verificar monitoramento (sem alertas) │
│ ☐ Verificar fluxos de usuário chave │
│ │
│ MONITORAMENTO PÓS-DEPLOYMENT (Primeiras 2 horas): │
│ ☐ Observar taxas de erro │
│ ☐ Observar métricas de performance │
│ ☐ Observar problemas reportados por usuários │
│ ☐ Observar fila de suporte │
│ │
│ CONFIRMAÇÃO DE SUCESSO: │
│ ☐ Métricas estáveis por 2+ horas │
│ ☐ Sem problemas críticos │
│ ☐ Stakeholders internos notificados │
│ ☐ Comunicações externas enviadas │
│ ☐ Sala de guerra fechada (deixar plantão ativo) │
│ │
│ SE PROBLEMAS SURGIREM: │
│ Ver framework de decisão de reversão │
└─────────────────────────────────────────────────────────────┘
Decisão de Reversão
FRAMEWORK DE REVERSÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ GATILHOS DE REVERSÃO: │
│ │
│ REVERSÃO AUTOMÁTICA: │
│ • Taxa de erro > 5x baseline │
│ • Funcionalidade core completamente quebrada │
│ • Problemas de integridade de dados │
│ • Vulnerabilidade de segurança exposta │
│ │
│ DECISÃO NECESSÁRIA: │
│ • Taxa de erro 2-5x baseline │
│ • Funcionalidade não-core quebrada │
│ • Performance degradada mas funcional │
│ • Muitas reclamações de usuários │
│ │
│ MONITORAR E CORREÇÃO PARA FRENTE: │
│ • Problemas menores │
│ • Workarounds disponíveis │
│ • Correção pode ser deployada rapidamente │
│ │
│ PROCESSO DE REVERSÃO: │
│ 1. Decisor confirma reversão │
│ 2. Executar runbook de reversão │
│ 3. Verificar reversão bem-sucedida │
│ 4. Comunicar status │
│ 5. Agendar post-mortem │
│ 6. Planejar re-lançamento │
│ │
│ DECISOR: [Pré-definido - geralmente tech lead ou PM] │
└─────────────────────────────────────────────────────────────┘
Pós-Lançamento
Revisão
ATIVIDADES PÓS-LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ T+1 DIA: │
│ • Revisar métricas do dia do lançamento │
│ • Resolver quaisquer problemas imediatos │
│ • Coletar feedback inicial │
│ • Agradecer a equipe │
│ │
│ T+1 SEMANA: │
│ • Revisão abrangente de métricas │
│ • Análise de feedback de usuários │
│ • Revisão de tickets de suporte │
│ • Tendências de performance │
│ │
│ RETROSPECTIVA DE LANÇAMENTO: │
│ • O que foi bem? │
│ • O que não foi bem? │
│ • O que estava faltando na lista de verificação? │
│ • O que devemos fazer diferente da próxima vez? │
│ │
│ ATUALIZAÇÃO DA LISTA DE VERIFICAÇÃO: │
│ Baseado na retrospectiva: │
│ • Adicionar itens que foram perdidos │
│ • Remover itens que não foram úteis │
│ • Ajustar cronograma se necessário │
│ • Documentar lições aprendidas │
│ │
│ CELEBRAR: 🎉 │
│ Lançamentos são conquistas da equipe - reconheça o esforço!│
└─────────────────────────────────────────────────────────────┘