Review turnaround time

Código parado em review é código que não vai para produção. Estudos com times de engenharia mostram consistentemente que pull requests passam mais tempo esperando por um revisor do que em qualquer outra etapa do pipeline de entrega. O review turnaround time mede exatamente essa espera: quanto tempo um revisor leva para responder a um PR aberto. Acompanhar essa métrica dá aos líderes de engenharia um sinal claro sobre onde o trabalho trava antes de chegar à produção. Esta página cobre a definição, como medir, benchmarks do mercado, um exemplo real e como melhorar esse número no seu squad.

• Review turnaround time mede quanto tempo um pull request fica esperando antes de um revisor interagir com ele. Uma espera longa se acumula em cada PR que o seu squad entrega e infla silenciosamente o cycle time geral, tornando a entrega mais lenta sem uma causa óbvia.
• O cálculo é: Review Turnaround Time = timestamp da primeira ação de review menos o timestamp de abertura do PR (ou pronto para review). Não existe um benchmark publicado universalmente para essa métrica específica, mas times de alto desempenho no DevStats costumam ver tempos de primeira resposta abaixo de quatro horas durante o horário comercial, com squads de elite respondendo em menos de uma hora.
• O erro mais comum dos times é tratar o review turnaround time como uma medida de esforço individual do revisor. É um sinal de processo. Um turnaround médio alto geralmente aponta para falta de ownership claro, profundidade da fila de review ou capacidade desalinhada do squad, não para um player específico sendo lento.
• O DevStats rastreia o review turnaround time automaticamente ao conectar ao seu provedor Git, com benchmarks comparados a mais de 1.000 times de engenharia. Comece um teste gratuito para ver os números do seu squad em menos de dois minutos.

Definição de review turnaround time

Review turnaround time é o tempo que passa entre um pull request ficar disponível para review e o momento em que um revisor age pela primeira vez. Essa ação pode ser uma aprovação, uma solicitação de mudança ou um comentário relevante. A métrica mede a capacidade de resposta do processo de review, não a qualidade ou profundidade da revisão em si.

Tecnicamente, o cálculo é: Review Turnaround Time = timestamp da primeira ação de review menos o timestamp de pronto para review do PR. Isso é diferente do PR cycle time total, que cobre todo o caminho do primeiro commit até o merge. Quando o review turnaround time é alto, ele infla o cycle time e atrasa o valor que o time tenta entregar aos clientes.

Por que o review turnaround time importa para times de engenharia

Quando squads não acompanham o review turnaround time, reviews lentos se tornam invisíveis. Um player termina uma feature, abre um PR e fica esperando. Essa espera quebra o fluxo, força troca de contexto e muitas vezes deixa o trabalho parado enquanto o autor começa algo novo. Quando o review finalmente chega, a reorientação custa tempo real. Multiplique isso por um sprint inteiro e você tem um peso significativo no throughput que nunca aparece numa daily.

Para líderes de engenharia, essa métrica se conecta diretamente à entrega no prazo e à experiência do desenvolvedor. Ambos são componentes do SPACE framework, que avalia a performance de engenharia em Satisfação, Performance, Atividade, Comunicação e Eficiência. Um review turnaround lento corrói a satisfação dos players que esperam e degrada a eficiência de todo o squad. Também afeta a previsibilidade do sprint: trabalho tecnicamente concluído mas preso em review não conta como feito.

Medir é o primeiro passo. Quando você consegue ver onde os reviews estão travando, pode tomar uma decisão informada sobre o que mudar. Os dados mostram onde olhar; você decide o que fazer.

Como medir o review turnaround time

Para calcular o review turnaround time, você precisa de dados de PR com timestamp do seu provedor Git (GitHub, GitLab, Bitbucket ou Azure DevOps). A fórmula é simples: subtraia o timestamp de pronto para review do PR do timestamp da primeira ação de review. Agregue todos os PRs de um período para obter a média ou mediana do time. A mediana é mais útil do que a média aqui, porque alguns PRs parados por muito tempo podem distorcer a média de forma significativa.

Não existe um benchmark publicado como padrão de mercado para review turnaround time da mesma forma que os DORA metrics existem para frequência de deployment. Os benchmarks variam por tamanho do time, complexidade do código e cultura de review. A tabela abaixo reflete faixas qualitativas observadas em times de engenharia, e você pode comparar seu squad com outros usando os benchmarks do DevStats.

Observação: essas faixas são guias qualitativos, não limites publicados pelos DORA metrics. Sua baseline vai variar conforme o tamanho do time e o modelo de release.

Review turnaround time na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que a taxa de conclusão de sprint do seu squad vinha caindo por dois trimestres. Ao analisar os dados de PR, ela viu que o review turnaround time médio tinha subido de três horas para pouco mais de 18 horas no mesmo período. O time tinha crescido com oito engenheiros novos, mas as atribuições de revisor não tinham sido atualizadas. Um grupo pequeno de players sênior absorvia quase todos os pedidos de review, enquanto os players mais novos tinham quase nenhum atribuído a eles.

Ela reestruturou a rotação de revisores para distribuir a carga de forma mais equilibrada entre os players experientes, definiu uma norma explícita de review no mesmo dia para PRs com menos de 200 linhas e sinalizou PRs abertos por mais de 24 horas na sincronização semanal de engenharia. Após dois sprints, o review turnaround mediano voltou a ficar abaixo de quatro horas e a taxa de conclusão do sprint se recuperou. Os dados mostraram onde olhar; a intervenção foi decisão dela.

Como melhorar o review turnaround time

1. Defina normas explícitas de tempo de resposta por tamanho de PR. Um bug fix de 50 linhas e um PR de feature com 500 linhas não devem ter o mesmo SLA de review. Defina o que "dentro do prazo" significa para cada faixa de tamanho e transforme isso em um acordo escrito do time, não uma expectativa implícita.

2. Distribua a carga de revisores por capacidade, não por senioridade. Concentração na fila de review é a causa mais comum de turnaround longo. Use os dados de code review para ver se os pedidos de review estão distribuídos de forma equilibrada ou concentrados em dois ou três players.

3. Reduza o tamanho dos PRs para reduzir a fricção no review. PRs menores são revisados mais rápido. Se o tamanho mediano de PR do seu squad passa de 400 linhas, isso contribui estruturalmente para um turnaround lento. Defina um teto flexível e oriente os players a dividir o trabalho em unidades menores.

4. Adicione uma janela diária de review no calendário do time. Review assíncrono funciona melhor quando os players sabem que existe um bloco dedicado para isso. Uma janela de review de 30 minutos pela manhã elimina a ambiguidade de "quando devo verificar".

5. Acompanhe o PR cycle time como indicador antecipado. Se o review turnaround time melhora, mas o PR cycle time geral continua estável, o gargalo se moveu para outro lugar. O cycle time dá a visão completa.

Review turnaround time vs. PR cycle time

Review turnaround time e PR cycle time são relacionados, mas medem coisas diferentes. O review turnaround time isola a espera antes de um revisor agir; o PR cycle time cobre toda a vida útil de um pull request, do primeiro commit até o merge.

Use o review turnaround time quando quiser isolar especificamente a etapa de review. Use o PR cycle time quando quiser entender a performance de entrega de ponta a ponta.