GUIA
Team Health: Toil, Bus Factor e Mais Explicado
Toil ratio, bus factor, rework rate e cancellation rate — sinais sobre quão sustentável é o ritmo real de um time, não só quão rápido ele entrega.
Por que isso não são métricas DORA ou Flow
Métricas DORA descrevem o pipeline de entrega; métricas Flow descrevem como o trabalho se move por um time. Nenhuma das duas responde uma pergunta diferente, igualmente importante: o jeito como um time atinge esses números é sustentável, ou está rodando silenciosamente em cima de práticas insustentáveis que vão aparecer como problema mais tarde — burnout, uma pessoa só da qual o time inteiro depende secretamente, trabalho que é jogado fora depois de esforço real aplicado nele. Esses sinais não vêm de um framework unificador único como o DORA (DORA Research/Google Cloud) ou as métricas Flow (o Flow Framework) — alguns, como bus factor, são termos de engenharia com décadas de existência; outros são mais específicos de como o moasy.tech olha pra saúde do dia a dia de um time. O que compartilham é o mesmo propósito: pegar um problema em como o trabalho é feito, não só medir o que foi feito.
Os sinais centrais de team health
| Sinal | O que mede | Por que importa |
|---|---|---|
| Toil Ratio | Fatia da capacidade do mês gasta em trabalho operacional recorrente. | Toil alto tira espaço do trabalho que de fato move o produto pra frente. |
| Bus Factor | Quão concentrado o trabalho está em uma ou duas pessoas. | Um time que depende inteiramente de uma pessoa está a uma ausência de um problema real. |
| Rework & Review Health | Quanto código entregue é reescrito logo depois, e quão minuciosamente PR é revisado. | Os dois são sinais antecipados de problema de qualidade, bem antes de virar incidente. |
| Cancellation Rate | Fatia de trabalho abandonado em vez de entregue. | Cancelamento alto geralmente aponta pra um problema de escopo, não de execução. |
Por que times acompanham isso
Um time pode parecer excelente em todo número DORA e Flow enquanto caminha silenciosamente pra um problema de burnout, uma crise de bus factor, ou um problema de qualidade que ainda não virou incidente — esses sinais existem porque velocidade de entrega sozinha não revela nada disso. São deliberadamente menos sobre resultado e mais sobre como o trabalho é feito: é uma pessoa só carregando o peso, "concluído" está de fato ficando concluído, o time está gastando sua capacidade no trabalho que devia estar gastando.
Como times costumam acompanhar isso manualmente (e onde vira bagunça)
Parte disso aparece informalmente muito antes de alguém medir — "só a Maria entende o serviço de billing" é uma observação de bus factor que ninguém escreveu. Transformar isso num número em vez de um comentário de corredor é o que fica difícil na mão: toil precisa de hora rastreada contra capacidade do time, não só uma sensação; review health precisa de histórico de pull request processado pra saber quem revisou o quê; cancellation rate precisa de um fluxo de trabalho que de fato rastreie "abandonado" como diferente de "concluído" pra começo de conversa, o que a maioria dos rastreadores de issue não distingue por padrão.
Como o moasy.tech calcula isso automaticamente
O moasy.tech recalcula os quatro sinais a partir do que já está sincronizado do Jira, Linear, GitHub e Azure DevOps — só leitura, sem pesquisa manual ou planilha. Toil ratio usa as mesmas regras de categoria configuráveis do Flow Distribution; bus factor e review health vêm direto do histórico de PR e item de trabalho; cancellation rate depende de um estado genuíno de "cancelado", distinto de "concluído", então trabalho abandonado para de inflar silenciosamente os números de entrega. Sem IA no pipeline — todo número é um cálculo direto.
Veja cada sinal em detalhe: Toil Ratio, Bus Factor, Rework & Review Health, e Cancellation Rate, ou a implementação completa na página de Capacity & Workload.
Dado ilustrativo, apenas para demonstração.
Perguntas sobre métricas de team health
Isso é usado pra ranquear ou avaliar pessoas individualmente?
Não — cada um desses é um sinal em nível de time ou de trabalho (capacidade, concentração, prática de review, escopo), não uma nota de performance individual. Bus factor em particular é sobre a estrutura de dependência de um time, não sobre qual pessoa é "melhor".
Preciso dos quatro pra tirar valor de qualquer um deles?
Não — cada um é útil sozinho, embora sejam frequentemente lidos juntos. Um time investigando problema de qualidade pode começar por rework e review health; um preocupado com resiliência pode começar por bus factor.
Existe uma fonte oficial pra isso, tipo o State of DevOps Report do DORA?
Não uma única — bus factor é um termo de engenharia bem estabelecido sem um dono único; os outros estão mais perto de prática comum de gestão de engenharia do que um programa de pesquisa publicado. Trate os conceitos como padrão de indústria, não um benchmark específico atrelado a um relatório.
Veja as métricas de team health do seu próprio time
Começar grátis