Rework rate

A maioria dos líderes de engenharia subestima quanta capacidade seus squads perdem com trabalho feito duas vezes. Rework rate mede a proporção do esforço de engenharia gasto corrigindo, revisando ou refazendo algo que já estava concluído. Uma rework rate alta drena a velocidade silenciosamente, infla os cycle times e corrói o moral do squad antes que alguém consiga nomear o problema. Esta página explica como definir, medir e fazer benchmark de rework rate, além de passos concretos para reduzi-la.

Pontos principais

• Rework rate mede a fatia do esforço de engenharia consumida por correções ou retrabalho em algo que já estava pronto. Ela importa porque um rework alto comprime silenciosamente a capacidade disponível para entregar novas funcionalidades, sem aparecer em nenhum sprint plan.
• A fórmula padrão é: Rework Rate = (commits ou issues de rework / total de commits ou issues) × 100. Não existe um benchmark publicado oficialmente, mas times que entregam abaixo de 10% de rework são considerados de alta performance. Taxas acima de 25% geralmente indicam falhas sistêmicas de processo em revisão, planejamento ou qualidade de requisitos.
• O erro mais comum dos times é tratar rework como um problema de pessoas, e não como um sinal de processo. Uma rework rate alta quase sempre aponta para problemas upstream: critérios de aceite vagos, code review superficial ou cobertura de testes insuficiente, não para a performance individual de cada player.
• O DevStats identifica sinais de rework rate automaticamente conectando ao seu provedor Git e ao seu issue tracker, com benchmarks comparados a mais de 1.000 times de engenharia. Comece um teste gratuito e veja os números do seu time em menos de dois minutos.

Definição de rework rate

Rework rate é o percentual do trabalho de engenharia que envolve corrigir, revisar ou refazer algo que estava marcado como concluído. Ela captura correções não planejadas: bug fixes em código recém-entregue, PRs que precisam de revisão significativa após o review e issues reabertas depois do fechamento.

Tecnicamente, o cálculo é: Rework Rate = (itens de rework / total de itens de trabalho) × 100. Os itens de rework são identificados por padrões de commit marcados como bug fixes, issues reabertas dentro de uma janela definida ou PRs que voltam a uma etapa anterior do processo de revisão. Acompanhar essa métrica com os dados de code review dá o sinal mais claro de onde a qualidade está falhando no pipeline de entrega. Quando a rework rate sobe, o investimento de engenharia que deveria financiar novas capacidades é redirecionado silenciosamente para manutenção, acumulando ao longo do tempo em compromissos de roadmap não cumpridos e atrito com stakeholders.

Por que rework rate importa para times de engenharia

Quando os squads não acompanham a rework rate, o custo fica invisível. Os engenheiros estão ocupados, os sprints parecem cheios e os números de velocidade parecem razoáveis até o time perder uma data de entrega sem conseguir explicar o motivo. O rework não rastreado absorve capacidade do sprint sem aparecer no planejamento, o que degrada sua planning accuracy por razões que parecem falha de estimativa, mas são na verdade falha de qualidade.

Rework rate se conecta diretamente aos KPIs pelos quais líderes de engenharia respondem. Um rework alto infla o PR cycle time, que você pode explorar no DevStats para ver onde os loops de revisão estão adicionando mais atraso. Ele reduz o throughput, porque os players voltam para trabalho já concluído em vez de avançar. E ainda gera burnout: nada corrói o moral do squad mais rápido do que corrigir repetidamente algo que deveria ter sido feito certo da primeira vez.

Dentro do SPACE framework, rework rate fica na interseção entre qualidade e eficiência. É um sinal de processo, não um julgamento de performance de nenhum player individualmente. Medir é o primeiro passo. O que você faz com esse sinal é onde a liderança de engenharia faz a diferença.

Como medir rework rate

A abordagem mais confiável combina duas fontes de dados: seu provedor Git e seu issue tracker. No Git, você identifica commits ou PRs marcados como bug fixes, hotfixes ou reverts dentro de uma janela de tempo definida após o merge do trabalho original. No issue tracker, você conta as issues reabertas dentro de 30 dias do fechamento. A fórmula combinada é: Rework Rate = (commits de rework + issues reabertas) / (total de commits + total de issues fechadas) × 100.

Não existe um benchmark universal publicado para rework rate da mesma forma que existem DORA benchmarks para frequência de deployment ou change failure rate. A tabela abaixo reflete limites qualitativos observados em times de engenharia, e as metas reais variam por tamanho de time, maturidade do codebase e cadência de releases. Você pode comparar seus números com times similares usando os benchmarks do DevStats.

Observação: esses limites são qualitativos e devem ser tratados como direcionais. Os benchmarks variam por tamanho de time, idade do codebase e modelo de release. Use-os como ponto de partida, não como meta rígida.

Rework rate na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que a velocidade do sprint parecia estável, mas a entrega do roadmap continuava atrasando uma a duas semanas por trimestre. Ela puxou os dados de cycle time das issues e viu que uma parcela desproporcional das issues fechadas estava sendo reaberta dentro de duas semanas do fechamento. A rework rate do time estava em 28%. O padrão estava concentrado em um squad responsável pela integração de pagamentos, e as issues reabertas quase sempre estavam ligadas a edge cases não cobertos nos critérios de aceite originais.

Ela não realocou players nem apontou indivíduos. Em vez disso, mudou a definição de "pronto" para aquele squad: nenhuma issue entrava em desenvolvimento sem pelo menos dois critérios de aceite cobrindo estados de erro. Ela também adicionou uma etapa de revisão async leve para PRs relacionados a pagamentos antes do merge. Nos dois sprints seguintes, a rework rate daquele squad caiu para 14%. Ela acompanhou a mudança usando dados de issue cycle time para confirmar que as issues reabertas estavam diminuindo de verdade, não apenas sendo reclassificadas.

Como melhorar a rework rate

1. Refine os critérios de aceite antes do trabalho começar. A maior parte do rework tem origem em lacunas de requisitos, não de execução. Exija que cada issue inclua pelo menos dois cenários de edge case antes de entrar em um sprint. Essa é a mudança de maior alavancagem que a maioria dos squads pode fazer. Acompanhe a contagem de issues reabertas no sprint como indicador antecipado.
2. Audite a profundidade do code review, não apenas a cobertura. Um PR aprovado em menos de cinco minutos em uma feature complexa é um risco de rework. Analise seus dados de code review para identificar padrões onde aprovações rápidas se correlacionam com bug fixes posteriores. Defina uma norma de squad para tempo mínimo de revisão em mudanças de alta complexidade.
3. Classifique o rework explicitamente no seu issue tracker. Se você não está marcando bug fixes e issues reabertas de forma consistente, não consegue medir rework rate com precisão. Adicione um label ou tipo de issue "rework" e torne um hábito nas cerimônias de sprint aplicá-lo. Isso leva um sprint para implementar e melhora imediatamente a qualidade do sinal.
4. Conecte rework rate à sua change failure rate. O rework que passa pela revisão e chega à produção aparece como uma change failure rate mais alta. Se ambas estão elevadas, o problema está upstream em requisitos ou revisão. Se o rework é alto mas a change failure rate é baixa, seu processo de revisão está capturando os problemas, mas tarde demais no ciclo.
5. Revise os padrões de alocação. Squads que gastam mais de 30% da capacidade em trabalho não planejado, o que você pode identificar pelos dados de allocation, frequentemente mostram rework rate elevada como sintoma downstream. Reequilibrar trabalho planejado e não planejado é um pré-requisito para uma redução sustentável de rework.

Rework rate vs. change failure rate

Rework rate e change failure rate medem problemas de qualidade, mas capturam pontos de falha diferentes no processo de entrega.

Use rework rate para diagnosticar problemas antes que cheguem à produção, e use change failure rate para medir com que frequência esses problemas escapam para ambientes em produção.