Abra a página de estatísticas de quase qualquer bug tracker e você vai encontrar um monte de números. Total de issues registradas. Um gráfico de pizza por severidade. Um tempo médio de resolução. Uma barra por responsável.
Quase nenhum deles responde à pergunta que uma equipe faz de verdade numa segunda de manhã: estamos dando conta ou ficando para trás?
Essa pergunta tem uma resposta curta, e ela cabe em quatro números. Este post passa por esses quatro, pelas métricas populares que enganam sem alarde e por uma revisão semanal de cinco minutos que você pode fazer em cima deles. É também o raciocínio por trás do cabeçalho de pulso que acabei de colocar no topo do quadro do BugDump.
As métricas que parecem úteis e não são
Total de bugs já registrados. Só sobe. Um número que só pode subir diz há quanto tempo o projeto existe, não se ele está saudável.
Número de relatórios de bug. Relatórios medem tráfego tanto quanto qualidade. Um único botão de checkout quebrado pode gerar quarenta relatórios numa tarde, e isso é um bug, não quarenta. Conte relatórios e um lançamento popular parece um desastre; conte bugs e ele parece uma terça-feira qualquer.
Bugs por severidade, num gráfico de pizza. Descreve o backlog sem sugerir nada a fazer. Ninguém nunca olhou para um gráfico de pizza e fechou um ticket.
Tempo médio de correção. Esse faz um estrago de verdade, porque parece rigoroso. Volto a ele mais adiante.
O que essas métricas têm em comum é que são estoques, não fluxos. Elas descrevem uma pilha. As perguntas que valem a pena são para onde a pilha está indo e o que ficou preso no fundo dela.
1. Backlog aberto, e para que lado ele vai
Comece pelo número mais simples que existe: quantos bugs estão abertos agora. No BugDump, são todas as tarefas que não chegaram a uma coluna fechada.
Sozinho, esse número diz pouco. Vinte e nove bugs abertos é normal para uma equipe e alarmante para outra. O que importa é a direção, e direção é só aritmética numa janela de tempo:
variação líquida = bugs abertos − bugs resolvidos, no mesmo período
Negativa significa que o backlog está diminuindo. Positiva, que está crescendo. Zero com atividade significa que você está acompanhando o ritmo exatamente; zero sem atividade significa que ninguém mexeu em nada, o que é outra situação e merece outro rótulo.
Por isso o cabeçalho de pulso não mostra só «29 abertos». Ele diz pendentes caíram 4 neste período, pendentes subiram 6 neste período, pendentes estáveis ou período calmo, nada se moveu. O número dá a escala; a frase dá a direção.
Um backlog que cresce vários períodos seguidos raramente é problema de produtividade dos desenvolvedores. Quase sempre é problema de triagem: duplicatas não são mescladas, decisões de «não será corrigido» não são tomadas, e todo relatório vira morador permanente.
2. Corrigidos vs. abertos, comparados com o período anterior
O segundo número é quantos bugs você resolveu na janela, mostrado ao lado da janela anterior de mesma duração.
Comparar com o período imediatamente anterior, e não com uma média histórica, importa por dois motivos. Neutraliza a sazonalidade: duas semanas tranquilas de feriado são comparadas com as duas semanas movimentadas de antes, não com o seu melhor mês de todos. E deixa as semanas de lançamento legíveis: um lançamento que corrigiu um grupo de bugs aparece como um salto, não como ruído.
Melhor ainda: veja abertos e resolvidos no mesmo gráfico. Eu coloco os bugs abertos acima do eixo, os resolvidos abaixo, e o backlog como uma linha que atravessa os dois. Quando as duas áreas se espelham, você está dando conta. Quando a de cima ganha seguidamente, a linha sobe, e dá para ver exatamente em que dias isso começou.
3. Mediana do tempo de correção, não a média
Tempo de correção é a métrica que a maioria das equipes quer e que a maioria das ferramentas calcula errado.
A definição é direta: para cada bug resolvido na janela, meça o tempo entre a abertura e a resolução. A questão é como resumir essas durações, e a resposta quase nunca deveria ser a média.
Um exemplo mostra por quê. Digamos que sua equipe corrija dez bugs nesta quinzena. Nove são corrigidos em até um dia. O décimo é um bug de quatro meses atrás que alguém finalmente fechou numa sessão de limpeza, 120 dias depois de registrado.
Média: (9 × 1 + 120) ÷ 10 = 12,9 dias
Mediana: 1 dia
A média diz que sua equipe leva duas semanas para corrigir um bug. A mediana diz que sua equipe corrige bugs no dia seguinte, e está certa. Pior: a média pune a limpeza. A semana em que você finalmente fecha tickets antigos é a semana em que sua média fica horrível, o que ensina todo mundo a deixar tickets antigos em paz.
A mediana não se abala com esse único ponto fora da curva, então ela acompanha o que acontece com um bug típico. É o que o cabeçalho de pulso mostra como Mediana de resolução, em minutos, horas ou dias, conforme a escala.
Ela tem um ponto fraco real: só conta bugs que foram de fato corrigidos. Um bug que nunca é resolvido nunca entra no cálculo, então uma equipe pode ter uma mediana linda enquanto abandona em silêncio seus problemas mais difíceis. É exatamente por isso que você precisa do quarto número.
4. O bug aberto mais antigo
A mediana descreve o meio. O bug aberto mais antigo descreve a cauda, e é na cauda que a confiança se desgasta.
Coloque a idade dele bem ao lado da mediana: 5 meses, com o ID e o título embaixo. Deixe-o clicável, para que olhar para ele seja um passo só, não uma busca.
Um bug aberto há cinco meses quase nunca é um bug que ninguém conseguiu corrigir. É uma decisão que ninguém tomou. Olhar para ele obriga a um de três desfechos honestos:
Corrigir, porque no fim ele é pequeno.
Planejar, porque ele importa e ficou órfão.
Fechar de propósito, como «não será corrigido» ou obsoleto, e explicar o motivo a quem relatou.
Qualquer um dos três é melhor que mais um mês de silêncio. E quando o mais antigo é resolvido, o seguinte toma o lugar dele, então o número continua puxando a cauda para dentro.
Bônus: de onde vêm os relatórios
Os quatro números acima dizem se você está dando conta. Eles não dizem por que uma semana foi ruim.
Para isso, divida os relatórios da mesma janela por navegador, sistema operacional, tipo de dispositivo e página. Uma regressão raramente se espalha por igual. Quando um terço dos relatórios da semana vem do Safari no iOS, ou a página com mais relatórios é uma etapa do checkout publicada na quinta-feira, você encontrou a causa antes de abrir um único relatório.
No BugDump, ao expandir o cabeçalho de pulso, você vê exatamente essa divisão ao lado do gráfico, com as páginas que mais geram relatórios em ordem. Clicar num chip de navegador, sistema ou dispositivo filtra o quadro por ele, então o salto de «tem algo errado com o Safari» para os bugs do Safari é um clique.
É também aqui que contar relatórios, e não bugs, é a escolha certa. Quarenta relatórios de um bug são quarenta dados sobre quem esbarrou nele.
Como escolher a janela
A janela muda o que os números conseguem dizer, então escolha-a pela pergunta que você está fazendo:
7 dias para semanas de lançamento, quando você quer ver o efeito de um deploy.
14 dias como padrão sensato: longo o bastante para suavizar o ruído diário, curto o bastante para reagir.
30 ou 90 dias para perguntas de tendência e retrospectivas.
Cuidado com medianas em janelas curtas em projetos pequenos. A mediana de três correções é um fato sobre três bugs, não sobre a sua equipe.
Defina «resolvido» com honestidade
Cada uma dessas métricas depende do que conta como resolvido, e é aí que os dashboards mais mentem.
Se Pronto para QA ou Mergeado conta como resolvido, sua mediana de tempo de correção mede a velocidade com que o código é escrito, não a velocidade com que os usuários param de esbarrar no bug. Se Não será corrigido não conta, seu backlog carrega decisões que já foram tomadas.
No BugDump, um bug é resolvido quando entra numa coluna do tipo fechada, e tirá-lo de lá o reabre. Seja qual for a ferramenta, confira se os estados fechados dela significam o que seus usuários entenderiam por «corrigido».
A revisão semanal de cinco minutos
Com esses quatro números numa tela só, a revisão semanal de bugs deixa de ser uma reunião e vira um checklist:
O backlog está caindo ou estável? Se cresceu, olhe o que entrou, não quem está lento.
A equipe resolveu pelo menos tanto quanto entrou, em comparação com o período anterior?
A mediana do tempo de correção mudou? Se deu um salto, ache o bug ou os dois bugs que a puxaram.
Abra o bug mais antigo. Corrija, planeje ou feche com um motivo. Não deixe para a semana que vem.
Veja de onde vieram os relatórios. Qualquer navegador, dispositivo ou página com muito mais do que a sua parte é uma regressão até prova em contrário.
É a revisão inteira. Cabe numa daily, dispensa planilha e responde à única pergunta que o dashboard deveria responder desde o começo.
No BugDump, o cabeçalho de pulso no topo de cada quadro mostra esses quatro números e se atualiza a cada minuto.
Leia também
De 40 relatórios a 6 bugs: como a triagem deveria funcionar — por que separar relatórios de tarefas evita que a caixa de entrada vire um cemitério e transforma duplicatas em pistas.
Como fazer a triagem de bugs mais rápido: um fluxo guiado pelo teclado — onde a triagem perde tempo de fato e como tirar a navegação do caminho.
Níveis de prioridade de bugs: por que quatro opções fixas nunca servem — para que serve uma escala de prioridade, quantos níveis você precisa e por que as palavras têm de ser suas.