Ritmo de Entrega sem Travar no Planejamento

São 16h30 de sexta-feira. Você abre o calendário, conta os blocos de reunião marcados em azul e os soma. Nove horas esta semana. Sprint planning na segunda. Refinamento no meio do sprint na quarta. Um retro que virou outra sessão de planejamento na quinta. Três reuniões de estimativa que você agendou porque os tickets não estavam "prontos." E o time entregou uma feature.

Nem era a feature planejada. Um IC sênior do seu time percebeu algo obviamente quebrado na manhã de quarta, abriu um PR até o almoço e fez o merge antes do standup de quinta. A coisa que ninguém escreveu, ninguém pontuou, ninguém colocou no quadro.

Você pensa: meu time entregou apesar do meu planejamento, não por causa dele.

Se essa cena é familiar, este guia é para você. Já orientei gerentes de engenharia nesse padrão exato, e a solução não é "planejar melhor." A solução é planejar menos, estruturado de forma diferente, com um sinal real que você de fato acompanha.

Por que o Planejamento Consome Sua Semana (e não Resolve Nada)

Faça as contas. Seis engenheiros, duas horas de planning a cada duas semanas, mais uma hora de refinamento no meio do sprint, mais uma hora de retro. São 24 horas de engenheiro por sprint só em planejamento formal. Some a preparação do gerente de engenharia (tipicamente 3 a 4 horas por sprint), a preparação do tech lead (2 horas) e o refinamento assíncrono de tickets em threads do Slack (incalculável). Você está gastando o equivalente à semana completa de um engenheiro sênior, a cada duas semanas, em planejamento.

O que isso compra? Na maioria dos times que vi, compra estimativas erradas por um fator de 3 a 4, um backlog que é reprioritizado toda semana de qualquer forma, e um item de ação do retro que ninguém é dono na quarta-feira.

A pergunta real não é "como planejamos melhor?" É "para que serve o planejamento de verdade?" Reduza ao essencial. O planejamento produz três coisas que um time precisa: uma lista curta do que fazer a seguir, responsáveis nomeados e um senso compartilhado do que está em risco. Todo o resto é teatro.

A armadilha é que as cerimônias de planejamento parecem produtivas. Você sai da sala com um quadro de sprint populado. Parece que trabalho aconteceu. Mas quadros de sprint populados não entregam código. ICs escrevendo PRs entregam código. Cada hora que você mantém um engenheiro em uma reunião de planejamento é uma hora em que ele não está moldando um problema nem abrindo um PR.

Planejamento como Spike, Não como Cerimônia

Aqui está a reformulação: planejamento é um spike. Uma investigação curta e focada com insumos e resultados claros. Não uma cerimônia recorrente. Não um bloco de pavor no calendário.

Uma hora. Uma vez por semana. Time todo opcional, gerente de engenharia e tech lead obrigatórios.

Uma agenda de exemplo que usei com três times diferentes:

• 0 a 10 min, o que foi entregue, o que não foi. Percorra o quadro da semana passada. Sem culpa. Apenas status. Se algo não foi entregue, nomeie o motivo em uma frase: "bloqueado na revisão," "o escopo era maior do que pensávamos," "interrompido por um incidente." Só isso.
• 10 a 25 min, o que está bloqueado. Qualquer coisa parada por mais de 48 horas sem movimento. O tech lead e o gerente de engenharia decidem: desbloqueie agora, elimine ou escale. Decisões, não discussão.
• 25 a 50 min, os próximos 5 a 7 tickets. Não o sprint inteiro. As próximas 5 a 7 coisas. Para cada uma: responsável, apetite aproximado (pequeno, médio, grande) e o único risco que pode explodir. Sem story points. Sem Fibonacci. Sem planning poker.
• 50 a 60 min, questões abertas. Qualquer coisa que alguém está preocupado e que não coube acima. Registre por escrito se não puder ser resolvido em 10 minutos.

Só isso. O time com o qual trabalhei em uma área de engenharia de 40 pessoas cortou o planejamento de 8 horas por semana para 1 hora usando algo próximo disso. A vazão subiu, não caiu, no primeiro mês.

A parte mais difícil é a disciplina de sair da sala quando a hora termina. Questão aberta? Anote, resolva de forma assíncrona, decida de forma assíncrona. Não estenda a reunião. A reunião termina na hora, sempre, ou tudo volta a ser cerimônia.

O Debate entre Ciclos de 6 Semanas e Sprints de 2 Semanas

Há um debate de longa data na gestão de engenharia sobre cadência: sprints de 2 semanas (no estilo Scrum) versus ciclos de 6 semanas de shape-up (o modelo da Basecamp do livro "Shape Up"). Vou poupar você da guerra religiosa.

Use ciclos de 6 semanas quando o trabalho tem formato de feature. Você tem 3 a 6 semanas de escopo significativo e bem definido. O time pode se comprometer com uma grande aposta, trabalhar nela de forma deliberada e entregar algo substancial. O Shape Up brilha aqui porque o apetite (o tempo máximo que você vai gastar antes de cortar escopo) está embutido no modelo.

Use sprints de 2 semanas quando o trabalho é reativo. Escalações de clientes, incidentes de infraestrutura, engenharia de suporte, trabalho de plataforma onde as solicitações chegam mais rápido do que você consegue planejar. Sprints de 2 semanas oferecem um ciclo de feedback mais curto e permitem repriorizar sem que pareça uma reversão de estratégia.

O teste honesto: pergunte ao seu time esta questão sem aquecimento. "Vocês preferem se comprometer com uma grande aposta por 6 semanas ou com 5 apostas menores em 2 semanas?" Times diferentes dão respostas diferentes. Ambas são válidas. A resposta errada é misturar os dois. Rodar sprints de 2 semanas com trabalho de formato de 6 semanas faz cada sprint parecer uma falha parcial, e rodar ciclos de 6 semanas em trabalho reativo significa que o ciclo é detonado por um incidente de cliente na semana 2, sempre.

Escolha um. Comprometa-se por um trimestre. Reavalie.

Latência de Ticket para PR: O Sinal Real

Esqueça os pontos de velocidade. Esqueça os "gráficos de burn-down que são na prática burn-up porque continuamos adicionando escopo." Há um número que diz se o seu ritmo de entrega está funcionando: a latência de ticket para PR.

Definição: o tempo decorrido desde quando um ticket é atribuído a um engenheiro até quando ele abre o primeiro PR para esse ticket.

Só isso. Sem story points. Sem estimativas. Apenas dois timestamps.

Se esse número é de 4 ou mais dias em um ticket que você estimou como 5 dias, seu planejamento está quebrado. Não porque o engenheiro seja lento. Porque o ticket não está moldado o suficiente para começar. O engenheiro está gastando o dia 1, 2 e 3 descobrindo o que o ticket realmente significa, o que está no escopo, o que não está, e o que fazer quando encontra o inevitável caminho sem saída. Isso é planejamento vazando para a execução.

Como parece o bom resultado: latência mediana de ticket para PR abaixo de 24 horas. p75 abaixo de 48 horas. p90 abaixo de 5 dias. Se sua distribuição tem uma cauda longa (alguns tickets parados por 10 ou mais dias), esses são os tickets que estão consumindo seu sprint e são os que precisam ser investigados.

Construa o gráfico uma vez, na ferramenta que você usa. Linear, Jira e Shortcut expõem esses dados por meio de APIs. Puxe semanalmente. Observe a mediana. Quando sobe, o planejamento degradou. Quando cai, algo está funcionando.

O Padrão "Estimado em 3 Dias, Levou 11"

Todo gerente de engenharia já viveu isso. Ticket estimado em 3 dias. Onze dias depois, ainda em revisão. O engenheiro não foi negligente. O ticket estava sem forma.

Isso não é um problema de estimativa. Estimativas melhores não vão resolver. O trabalho em si estava ambíguo quando entrou no sprint, e "ambíguo mais vou descobrindo no caminho" é como um ticket de 3 dias vira 11 dias.

A solução é uma sessão de moldagem de 30 minutos antes de o ticket entrar no sprint. Conduzida pelo tech lead ou por um IC sênior. O resultado é um documento curto de moldagem cobrindo quatro coisas:

1. No escopo. O comportamento ou a capacidade específica que estamos construindo. Concreto, não abstrato.
2. Fora do escopo. As duas ou três coisas que pareceriam relacionadas mas que explicitamente não faremos. Esta é a seção mais importante. Sem ela, o escopo cresce toda vez.
3. O caminho sem saída. O risco conhecido: "isso pode exigir mexer no auth service e, se exigir, paramos e redefinimos o escopo." Nomear antecipadamente significa que o engenheiro não vai desaparecer nesse buraco por uma semana.
4. O apetite. O tempo máximo que vamos gastar antes de cortar escopo ou escalar. Não é uma estimativa. É um orçamento.

Trinta minutos. Um documento. Um ticket que passou pela moldagem tem 4 a 5 vezes mais probabilidade de ser entregado próximo ao apetite do que um que não passou. Vi isso se sustentar em times de 6 e em times de 60. O cálculo do investimento de tempo é evidente.

Orçamento de Dívida Técnica: A Regra dos 20%

Vinte por cento de cada sprint vai para dívida técnica. Não "se sobrar tempo." Não "vamos resolver no próximo trimestre." Uma alocação comprometida, nomeada e com linha de orçamento.

Se você pular isso, a dívida se acumula. No terceiro trimestre, a velocidade de entrega é metade do que era, e ninguém consegue explicar bem por quê. O teste instável que precisa de três tentativas para passar. A migração que deveria ser temporária há 18 meses. O serviço que ninguém sabe fazer deploy, exceto um engenheiro que está prestes a tirar licença parental.

Vinte por cento não é um número mágico. É o piso abaixo do qual a dívida se acumula mais rápido do que você consegue pagá-la. Alguns times precisam de 30% em períodos de recuperação. Alguns podem operar em 15% se a base de código é genuinamente nova. Abaixo de 15%, você está tomando emprestado da velocidade de entrega do próximo trimestre e vai sentir isso.

Como escolher qual dívida pagar, em ordem de prioridade:

1. Dor visível para o cliente. Bugs com os quais o time conviveu, mas que os clientes ainda encontram. Problemas de performance que aparecem em tickets de suporte. Sempre primeiro.
2. Dor visível para o desenvolvedor. Testes lentos, ambiente de desenvolvimento local quebrado, armadilhas de deploy. Qualquer coisa que custa ao time uma hora ou mais por semana.
3. Limpeza teórica. Refatorações que seriam agradáveis mas não têm um motivo urgente. Última prioridade. Seja honesto sobre se realmente pertencem ao sprint.

Torne os 20% visíveis no quadro. Marque os tickets com "tech-debt." Reporte o percentual no seu spike semanal de planejamento. Se um sprint fica abaixo de 20% por três semanas seguidas, isso é um alerta.

Padrões de Desbloqueio: SLA de Revisão de PR e Calendário de Decisões

Dois mecanismos específicos que movem o ponteiro mais do que qualquer mudança de planejamento:

SLA de revisão de PR. Primeira revisão em até 4 horas durante o horário de trabalho. Não uma diretriz. Um compromisso bloqueante. Se um PR está sem revisão por 4 ou mais horas, o revisor designado larga o que está fazendo e o revisa. Parece severo. Funciona.

Os times que vi adotar isso entregam 2 a 3 vezes mais do que antes, e o motivo é direto: PRs parados em revisão por 2 a 3 dias fazem os engenheiros mudarem de contexto para outra coisa, depois voltarem quando a revisão chega e mudarem de contexto novamente para responder ao feedback. Cada mudança custa de 30 a 60 minutos de tempo produtivo real. Um SLA de 4 horas colapsa esse ciclo.

O texto que eu colocaria no acordo de trabalho do seu time, exatamente assim:

Primeira revisão em até 4 horas durante o horário de trabalho, exceto quando um engenheiro está em um bloco de foco sinalizado com antecedência. Revisões bloqueiam outros trabalhos, incluindo o ticket ativo do próprio revisor. Revisões apenas com comentários contam. A expectativa é feedback, não aprovação.

Calendário de Decisões. Um slot de 30 minutos por semana onde o gerente de engenharia e o tech lead decidem tudo o que está pendente. Decisões de arquitetura. Escolhas de fornecedor. Decisões do tipo "devemos usar a biblioteca A ou a B?" Qualquer pergunta que esteja numa thread do Slack por mais de 48 horas.

Sem isso, as decisões se arrastam por semanas. Os engenheiros perguntam uma vez, recebem um "deixa eu pensar," e a questão morre numa thread. O calendário de decisões faz um compromisso público: até sexta às 11h, aquela pergunta tem um sim, um não ou "precisamos de mais 30 minutos para analisar." Sem mais ciclos de "vou retornar depois."

Os dois mecanismos são operacionais. Não exigem uma mudança de cultura nem um roadshow de adesão. Você se compromete na segunda e começa a rodar na terça.

Quando Escalar (e o que "Escalar" Realmente Significa)

A maioria dos gerentes de engenharia usa mal a palavra "escalar." Acham que significa ir ao chefe quando algo está pegando fogo. Isso não é escalação. É uma atualização de status com etapas extras.

Escalação é tornar visível a decisão invisível certa.

Três gatilhos para uma escalação real:

1. O escopo é maior do que o apetite. Você moldou o ticket para um apetite de 1 semana. O engenheiro está te dizendo que é um problema de 3 semanas. A decisão (ainda fazemos isso? cortamos o escopo? adiamos para o próximo trimestre?) está fora do time. Escale.
2. A dependência de outro time está bloqueando você por 2 ou mais dias. Você perguntou. Deu seguimento. Nada se move. Escale para o gerente de engenharia do outro time, com um pedido específico e um prazo específico. Não "você pode nos ajudar?" mas "precisamos de um sim ou não sobre se o time de auth consegue priorizar isso até o fim do dia de quinta."
3. Uma decisão de arquitetura afeta mais do que o seu time. Você está prestes a introduzir um novo banco de dados. Um novo padrão de autenticação. Uma nova abordagem de deploy. Se o raio de impacto é maior do que o seu time, escale para que a decisão seja tomada no nível certo.

Um template de escalação de 3 linhas que funciona no Slack ou por e-mail:

Decisão necessária: [a pergunta específica, formulada como sim/não ou escolha uma opção]
Por que agora: [o que está bloqueado, quem é afetado, qual é o custo de esperar]
Prazo: [quando você precisa de uma resposta, com data e hora específicas]

Esse é o template completo. Três linhas. Sem parágrafo de contexto. Se o destinatário precisar de contexto, vai perguntar. A clareza em si é o desbloqueador.

Os Primeiros 30 Dias com Este Novo Ritmo

Não implemente tudo isso na segunda-feira. A forma mais rápida de perder a confiança do time é anunciar um novo modelo operacional e pedir que o sigam antes de terem visto qualquer parte funcionando.

Um plano de 30 dias que se sustenta:

Semana 1: elimine uma reunião recorrente. Escolha a que ninguém gosta. O refinamento de meio de sprint, provavelmente. Cancele. Observe o que quebra. Geralmente nada. Se algo quebrar, você aprendeu o que essa reunião estava realmente fazendo.

Semana 2: implante o novo spike de planejamento de 1 hora. Rode uma vez. Envie uma nota curta ao time explicando qual é o novo formato e por quê. Passe pela hora. Respeite o bloco de tempo.

Semana 3: instrumente a latência de ticket para PR. Puxe os dados da sua ferramenta. Faça o gráfico. Não compartilhe ainda. Apenas olhe você mesmo por uma semana para entender como é a sua distribuição de verdade.

Semana 4: revise os dados com o time e ajuste. Traga o gráfico. Pergunte: "o que vemos? o que nos surpreende? qual é uma coisa que mudaríamos?" Deixe o time opinar. Ajuste o ritmo com base no que disserem.

No dia 30 você vai ter substituído 6 ou mais horas de planejamento por 1 hora, instrumentado o único sinal que importa e dado ao time um ritmo que conseguem defender. Você também vai ter seu tempo de volta. Use-o para fazer o trabalho pelo qual um gerente de engenharia é realmente pago: moldar problemas, desbloquear pessoas e desenvolver seus engenheiros.

A cena de sexta à tarde do início deste artigo? Em 60 dias você não vai reconhecê-la. Seu calendário vai ter um bloco de planejamento, um bloco de calendário de decisões e muito espaço vazio. Seu time vai estar entregando mais. E o IC sênior que costumava entregar coisas apesar do seu processo vai estar entregando por causa dele.

Saiba Mais

• Job Description de Staff Software Engineer
• Conduzindo 1:1s que Seus Subordinados Diretos Esperam Ansiosos
• Definindo Metas com um Time Relutante