Bus Factor: O Custo de Depender de Um Único Desenvolvedor

Bus factor é o número de pessoas que precisariam sair do time para o projeto travar. Se uma única pessoa entende a integração de pagamento, o bus factor daquela parte é 1. O nome vem de uma pergunta desconfortável: o que acontece se essa pessoa for atropelada por um ônibus.

Na prática o ônibus quase nunca aparece. O que aparece é pedido de demissão, férias marcadas, licença médica e proposta melhor da concorrência.

Este artigo mostra como medir o bus factor do seu sistema, o que ele custa quando vale 1 e o que aumenta esse número sem paralisar a entrega.

O número é pior do que a intuição sugere

Em 2016, pesquisadores da UFMG e da Universidade de Waterloo mediram o bus factor de 133 sistemas populares do GitHub, em seis linguagens, somando mais de 2 milhões de commits. O resultado: 45 sistemas, ou 34%, tinham bus factor igual a 1. Outros 42, ou 31%, tinham bus factor igual a 2. Somados, 65% dos projetos dependiam de no máximo duas pessoas.

São projetos de código aberto, com contribuição distribuída e visibilidade pública. Uma empresa de médio porte, com time pequeno e rotatividade normal, não tem motivo para estar melhor.

Um estudo posterior, publicado em 2022 com 269 engenheiros, mostrou o outro lado do problema. Metade dos respondentes sabia o que era bus factor, 63% tinham trabalhado no último ano em ao menos um projeto com risco alto, e apenas 19% já haviam trabalhado em algum lugar onde o indicador era acompanhado de fato.

Ou seja, o problema é reconhecido e quase nunca medido. É risco que existe sem dono.

Como medir o bus factor do seu repositório em dez minutos

Não precisa de ferramenta paga nem de consultoria para ter a primeira leitura. O histórico do Git já tem o dado.

1. Concentração geral de autoria: git shortlog -sn --all. A saída lista cada pessoa e quantos commits fez. Se a primeira linha concentra mais de 70% do total, você já sabe a resposta.
2. Concentração por área: git shortlog -sn --all -- src/pagamentos repete a conta só naquele diretório. É aqui que a coisa aparece, porque o risco raramente está no sistema inteiro, está na parte que ninguém mais mexeu.
3. Quem tocou cada arquivo crítico por último: git log -1 --format='%an %ad' -- caminho/do/arquivo. Arquivo importante com última alteração feita há dois anos por alguém que não está mais na empresa é o caso mais caro.
4. Quem deveria revisar cada área: um arquivo CODEOWNERS no repositório transforma essa informação implícita em regra, exigindo revisão da pessoa responsável antes do merge.

Commits não são medida perfeita de conhecimento. Quem faz muitos commits pequenos aparece mais do que quem faz poucos e decisivos. Serve como primeira aproximação, e a primeira aproximação já costuma doer.

A armadilha que encontramos no nosso próprio repositório

Rodamos essa medição no repositório do site e do blog da Out Limit. O resultado foi bus factor 1, com 25 commits e uma pessoa só, o que era esperado num projeto conduzido por uma pessoa.

O que não era esperado estava na saída do comando. Apareceram duas identidades distintas, "Filipe Matos de oliveira" e "Matos de oliveira", com o mesmo endereço de email. É a mesma pessoa, com o user.name configurado de forma diferente em duas máquinas.

Isso importa mais do que parece. Uma medição automática que agrupa por nome teria contado dois contribuidores e reportado bus factor 2. O risco real continuaria sendo 1. Antes de confiar em qualquer número, normalize as identidades: agrupe por email, e use um arquivo .mailmap para unificar nomes diferentes da mesma pessoa. Sem isso, a ferramenta mente para o seu favor, que é o pior tipo de erro em medição de risco.

O que o bus factor 1 custa antes de virar crise

A pessoa não precisa sair para o custo aparecer. Ele já está sendo pago:

• Entrega serializada. Tudo que toca aquela área espera a agenda de uma pessoa, e a fila não aparece no board porque não é uma tarefa, é uma dependência.
• Revisão de código que não revisa. Quando ninguém mais entende a área, a aprovação vira formalidade e o erro chega em produção com carimbo.
• Férias que não acontecem. Time pequeno com conhecimento concentrado transforma descanso em risco operacional, o que acelera a saída que você teme.
• Estimativa que só uma pessoa sabe fazer. Isso contamina planejamento, orçamento e a conversa com a diretoria.
• Negociação enfraquecida. Cliente grande e investidor perguntam exatamente isso, e a resposta ruim aparece no preço ou no contrato.

Esse último ponto é concreto: a concentração de conhecimento é um dos itens avaliados em due diligence técnica e nos questionários de segurança que empresas grandes mandam antes de fechar contrato. Não é uma questão de engenharia interna, é uma questão comercial.

Quatro formas de aumentar o bus factor sem parar a entrega

A reação instintiva é anunciar que "vamos documentar tudo". Isso não funciona, e a próxima seção explica por quê. O que funciona é mudar como o trabalho é distribuído, não criar uma tarefa paralela de documentação.

1. Revisão de código obrigatória na área concentrada. Não para achar defeito, para obrigar uma segunda pessoa a ler aquele código toda semana. É a forma mais barata de transferir contexto, porque acontece dentro do fluxo que já existe.
2. Rotação deliberada de tarefas. A próxima demanda naquela área vai para quem não a conhece, com a pessoa que conhece disponível para consulta. Custa mais caro uma vez e resolve para sempre.
3. Programação em par nas mudanças de risco. Reservada para migração, integração nova e refatoração estrutural, não para o dia a dia. Duas pessoas presentes na decisão é o que se quer preservar.
4. Registro de decisão, não manual de uso. Um arquivo curto por decisão relevante, dizendo o que foi decidido, quais alternativas foram descartadas e por quê. Código mostra o que faz, não mostra o que foi rejeitado, e é justamente isso que se perde quando a pessoa sai.

Esses quatro itens têm algo em comum: não dependem de contratar ninguém, e todos cabem na entrega que já está em andamento.

O que não funciona

Vale ser direto sobre as saídas que parecem resolver e não resolvem.

Documentar tudo de uma vez, num esforço concentrado, produz um documento grande que ninguém lê, envelhece em três meses e cria a ilusão de que o risco foi tratado. Documentação que funciona é curta, fica perto do código e é escrita quando a decisão é tomada.

Gravar vídeo de passagem de conhecimento tem o mesmo problema, com o agravante de não ser pesquisável nem revisável.

Contratar mais uma pessoa sênior também não resolve sozinho. Sem rotação e sem revisão, você passa a ter duas ilhas de conhecimento em vez de uma.

E o pior de todos: tratar bus factor como problema de pessoa. Não é falta de generosidade de quem detém o conhecimento, é consequência de como o trabalho foi distribuído. Quem concentra conhecimento geralmente é quem mais entregou, e culpar essa pessoa é o caminho mais rápido para que ela realmente saia.

Por onde começar esta semana

Rode git shortlog -sn --all no seu repositório principal, normalizando as identidades por email. Depois repita o comando nos dois ou três diretórios mais críticos do sistema, aqueles que, parando, param o faturamento.

Se algum deles tiver uma pessoa com mais de 70% dos commits, você achou o ponto. A próxima tarefa naquela área vai para outra pessoa, com revisão obrigatória de quem conhece. É uma decisão de alocação que cabe na próxima sprint e não exige projeto novo, orçamento novo nem contratação.

A medição leva dez minutos. O que ela revela costuma mudar a próxima conversa de planejamento.

Checklist de continuidade técnica

Quer o levantamento completo, com os comandos, os limiares e o que fazer em cada faixa de risco? A Out Limit mantém um checklist de continuidade técnica usado nos nossos diagnósticos, cobrindo concentração de conhecimento, documentação de decisão, acessos críticos e dependência de fornecedor. Fale com a gente para receber.

Para quem quer entender o contexto mais amplo, dois artigos ajudam: dívida técnica, como medir e priorizar trata do custo acumulado das decisões antigas, e diagnóstico de TI antes de reestruturar mostra o levantamento que antecede qualquer mudança estrutural.