Como usar os 60 dias?

Use os 60 dias para trabalhar de trás para frente. Defina a data do lançamento, reserve tempo para diagnóstico, correções, reteste e contingência. O primeiro passo é selecionar as jornadas críticas e estimar o maior volume de usuários simultâneos.

Esse prazo não é folga — é o mínimo razoável. A recomendação recorrente na literatura de performance é concluir o primeiro ciclo de teste de carga, estresse e volume com pelo menos 3 a 4 semanas de antecedência em relação ao deploy final, justamente para sobrar tempo de reagir ao que o teste encontrar. Isso porque encontrar um problema não é o fim do trabalho — é o começo dele.

Por que testar em cima da hora não é teste, é aposta

Um caso documentado de upgrade de interface de um sistema ERP ilustra bem o risco: a equipe rodou o primeiro teste de carga, volume e estresse apenas 4 dias antes do deploy em produção. O ambiente revelou tempos de resposta inaceitáveis e múltiplos pontos de degradação. Diagnosticar e corrigir os problemas levou quase duas semanas de trabalho de engenheiros de teste, DBA, infraestrutura e middleware — tempo que simplesmente não existia no cronograma, forçando o adiamento do lançamento e um custo estimado em dezenas de milhares de dólares só em atraso.

O exemplo mais conhecido em escala é o lançamento do Healthcare.gov, em 2013: o site recebeu mais de quatro milhões de visitantes únicos no primeiro dia e travou dentro de cerca de duas horas, com apenas seis inscrições concluídas naquele dia. Análises técnicas posteriores mostraram páginas simples levando até 8 segundos para carregar e o registro de conta chegando a 71 segundos de latência total, em grande parte porque o sistema nunca havia sido validado sob volume real de usuários e dados de produção antes do dia do lançamento. O reparo do sistema custou uma fração relevante dos mais de US$ 2 bilhões investidos no projeto — dinheiro e tempo que um ciclo de teste-correção-reteste, feito com antecedência, teria evitado.

O padrão nos dois casos é o mesmo, só muda a escala: o problema técnico existia antes do lançamento, mas só foi descoberto perto demais da data para ser corrigido com segurança. 60 dias existem exatamente para que isso não aconteça.

O que fazer com o tempo restante?

Depois de mapear jornadas críticas e volume esperado, execute carga e estresse em um ambiente autorizado, correlacione latência com infraestrutura e banco e priorize as correções por impacto. Em termos de cronograma reverso, uma divisão razoável para uma janela de 60 dias é:

  • Semanas 1-2 — Discovery e primeira medição: mapeamento das jornadas críticas, definição de SLAs de resposta e execução do primeiro teste de carga/estresse para estabelecer a baseline e localizar os principais gargalos.
  • Semanas 3-5 — Correção: ajustes de query, índice, pool de conexões, cache ou arquitetura, priorizados pelo impacto medido, não por suposição.
  • Semanas 6-7 — Reteste e validação: nova execução de carga e estresse para confirmar que as correções realmente resolveram o problema e não introduziram regressão.
  • Última semana — Congelamento e contingência: code freeze, plano de rollback documentado e folga para lidar com bloqueios de ambiente ou aprovação de última hora.

O período restante deve incluir sempre uma nova execução para confirmar a evolução — pular o reteste é a forma mais comum de descobrir, tarde demais, que uma correção não funcionou como esperado.

Por que travar o código antes do lançamento

Um code freeze — período em que novas mudanças de código param de entrar no repositório principal, com exceção de correções críticas aprovadas — costuma durar entre 5 e 14 dias antes do lançamento na maioria das equipes; menos que isso deixa pouca margem para o QA validar um alvo estável, e mais que isso geralmente sinaliza problemas de planejamento em etapas anteriores. Uma prática comum é escalonar o congelamento em duas fases: freeze de conteúdo cerca de duas semanas antes do lançamento, seguido de freeze de código uma semana antes — dando à equipe uma janela final de testes contra um sistema que já não está mudando debaixo dos pés dela.

Sem esse período de estabilidade, cada correção de performance feita nos últimos dias é também um novo risco de regressão, testado às pressas — exatamente o padrão que aparece nos casos de lançamento malsucedido.

E se o escopo for maior?

Se o escopo envolver vários canais, integrações complexas ou IA generativa, o planejamento pode exigir prazo maior e um pacote Custom. Transforme a data crítica em um cronograma com diagnóstico, remediação e reteste, mantendo uma margem para bloqueios de ambiente.

Próximo passo: calcule o cronograma reverso a partir da data do lançamento e inicie o discovery técnico o quanto antes — o tempo entre encontrar um problema e ter margem para corrigi-lo é o que separa um lançamento estável de uma manchete ruim.

Referências