O que é bus factor no desenvolvimento de software (e por que quase ninguém mede isso)

O bus factor (ou truck factor) é o número mínimo de pessoas que teriam que sair de um time de um dia para o outro —por demissão, licença ou qualquer imprevisto— antes de o projeto travar por falta de alguém que entenda como seguir em frente. Um bus factor de 1 significa que basta uma pessoa sair para que ninguém mais saiba mexer em determinado módulo, acessar produção ou explicar por que uma decisão de arquitetura importante foi tomada. Quanto mais alto o número, mais distribuído está esse conhecimento crítico entre o time — e menos o projeto depende de que nada aconteça com uma pessoa em particular.

O termo surgiu na comunidade de desenvolvimento de software no início dos anos 2000 como uma forma coloquial de nomear um risco que já existia: o conhecimento concentrado em poucas cabeças. Hoje ele é usado tanto em auditorias de due diligence técnica —para avaliar quão frágil é um time antes de uma aquisição— quanto na gestão do dia a dia de qualquer time de engenharia.

Como se calcula o bus factor de um time?

Não existe uma fórmula única. A abordagem acadêmica mais citada —usada em um estudo de Avelino, Passos, Hora e Valente (2016) sobre centenas de repositórios populares do GitHub— estima o bus factor observando qual porcentagem do código de um projeto está concentrada nos commits dos autores principais: se duas ou três pessoas já cobrem a maior parte do histórico, esse é o número. Na prática, a forma mais simples é fazer uma pergunta para cada área crítica do projeto: se essa pessoa saísse amanhã, alguém mais conseguiria assumir o lugar dela sem travar tudo?

• Decisões de arquitetura e por que foram tomadas
• Acesso a produção e resposta a incidentes
• Os módulos de código mais complexos ou menos documentados
• Infraestrutura, DevOps e credenciais ou acessos de fornecedores
• O contexto do cliente: o que foi combinado, o que foi testado, o que não funcionou antes

Por que o bus factor real da maioria dos times é mais baixo do que parece?

O mesmo estudo de Avelino e sua equipe encontrou que 65% dos repositórios do GitHub analisados tinham um bus factor de 2 ou menos —ou seja, duas pessoas (ou menos) concentravam conhecimento suficiente para travar o projeto se saíssem. Não é um problema de projetos pequenos ou descuidados: são os mesmos repositórios populares que qualquer um assumiria como bem organizados.

Um estudo posterior, específico sobre como times da indústria vivem isso (Jabrayilzade et al., ICSE 2022), encontrou algo ainda mais desconfortável: a maioria dos desenvolvedores sabe que o risco existe, mas as práticas para reduzi-lo —documentar, revezar o código crítico, fazer pair programming— são aplicadas de forma inconsistente até que alguém saia e o problema se torne real.

E a probabilidade de esse "alguém sair" acontecer não é baixa: segundo dados do LinkedIn, a rotatividade no setor de tecnologia ficou entre 20% e 25% em 2025, bem acima da média de 10,9% de todas as indústrias. Um bus factor baixo em um setor de alta rotatividade não é um risco teórico —é uma aposta com as probabilidades contra.

Um squad já formado tem um bus factor melhor do que um freelancer ou uma consultoria montada ad hoc?

Um freelancer trabalhando sozinho tem, por definição, um bus factor de 1 —não há mais ninguém para perguntar. Uma consultoria que monta um time novo para cada projeto também não começa muito melhor —o time ainda está no estágio literal de "formação" do modelo de Tuckman, e ainda não construiu o terreno comum que faz o conhecimento circular em vez de se acumular em uma única pessoa.

Um squad que já trabalhou junto em projetos anteriores parte de outro lugar: as decisões de arquitetura, o padrão de código e o contexto de cada milestone já circularam entre várias pessoas antes mesmo de o projeto atual começar. Isso não elimina o risco —nenhum time tem bus factor infinito— mas o distribui desde o primeiro dia, em vez de precisar construir essa distribuição às pressas com o projeto já em andamento.

Como reduzir o bus factor sem dobrar o custo do time?

A forma mais cara de resolver isso é a mais óbvia: colocar duas pessoas em cada função, em tempo integral. A abordagem que realmente escala é tornar o conhecimento visível à medida que ele é gerado, em vez de reconstruí-lo depois que alguém já saiu. Documentar decisões no momento em que são tomadas —não em uma wiki separada que ninguém atualiza—, revezar a revisão de código nos módulos mais críticos, e garantir que o acesso a produção nunca dependa de uma única pessoa são práticas baratas comparadas ao custo de reconstruir esse conhecimento do zero.

A evidência também ajuda a medir isso de fora: quando o avanço de um projeto fica documentado no repositório —quem mexeu no quê, em qual milestone, sob qual critério de aceitação— o conhecimento deixa de viver só na cabeça de uma pessoa e nas reuniões que ela participou. É a mesma lógica que torna substituir um squad no meio do projeto muito mais simples quando o trabalho feito até aquele ponto é verificável, e não apenas uma promessa de que "já está quase pronto".

Antes de um squad aparecer como opção em um match da Zenit, ele já passou pela verificação do ZenitRank —que mede sinais como cumprimento de milestones e diversidade de clientes, não só currículo. Um bus factor baixo tende a aparecer ali antes de virar um problema no meio de um projeto real.