Bus factor: o que todo fundador não-técnico precisa saber quando um único dev segura a base de código
A Carla estava há três horas em uma viagem de cliente em Austin quando o WhatsApp apitou. O único developer dela, o Vinicius, estava na emergência com uma apendicite rompida. Ele ia ficar bem. O release de terça não. Havia um bug de pagamento em produção que ele estava corrigindo no canto, um pull request aberto em uma feature que ela tinha prometido a um cliente para a semana seguinte, e uma migração de banco que ele tinha escrito e que ninguém mais na empresa tinha sequer olhado. A Carla, COO e co-fundadora de uma legaltech de 14 pessoas, sentou no banco de trás de um Lyft e tentou pensar em quem, no time, conseguiria pelo menos abrir o repositório.
Ninguém conseguia. A resposta era ninguém.
É isso que o bus factor mede. O bus factor de um software é o número de pessoas do time que precisariam desaparecer, ao mesmo tempo, para o projeto travar. A versão clássica da pergunta é mórbida (o ônibus). A versão honesta é mundana: o developer aceita uma vaga na Anthropic, sai de licença-paternidade, tem apendicite, ou simplesmente rotaciona para outro cliente e agora responde o Slack três horas depois. Em todos esses casos o bus factor do seu produto é o mesmo número, e para a maioria das startups em estágio inicial construídas em torno de um único engenheiro, esse número é um.
Este artigo é para o fundador não-técnico que leu o parágrafo anterior com a sensação precisa de medo que vem de se reconhecer nele. Ele faz três coisas. Diz o que o bus factor de fato mede dentro da sua empresa, separado do que um blog de engenharia vai dizer que significa. Explica por que a solução óbvia (contratar um segundo developer) costuma piorar a dependência antes de melhorá-la. E entrega um plano de quatro passos que dá para rodar este trimestre sem dobrar o headcount.
O que o bus factor de fato significa, em um parágrafo
Bus factor é o número mínimo de pessoas em um projeto que, se de repente parassem de contribuir, deixariam o trabalho impossível de continuar. O termo surgiu em comunidades de programação nos anos 1990 como humor negro sobre risco de pessoa-chave. Um projeto com bus factor de um é um projeto onde exatamente uma pessoa consegue mover o código para frente. Um projeto com bus factor de três é um projeto onde três pessoas teriam que sumir ao mesmo tempo antes do trabalho parar. Mais alto é mais seguro. Mais baixo é mais frágil. Para um fundador não-técnico, a definição funcional é mais simples ainda: bus factor é a pergunta de quantas pessoas na sua empresa conseguem subir uma correção no software que está rodando amanhã de manhã, sem aviso, sem quebrar o resto. Para a maioria das startups com um único developer, a resposta é um. A resposta ser um não é incomum. A resposta ser um e você não saber é o problema de verdade.
Três problemas escondidos dentro de uma pergunta
Quando um fundador diz “estou preocupado com o que acontece se meu developer pedir demissão,” ele na verdade está preocupado com três coisas diferentes e elas se misturam. Separar é o primeiro movimento, porque cada uma é resolvida por uma intervenção diferente.
Concentração de conhecimento
O primeiro problema é que o software que está no ar é um sistema funcionando, mas a explicação de por que ele funciona daquele jeito mora na cabeça de uma pessoa. Por que a tabela de pagamentos foi desnormalizada? Por que o fluxo de autenticação tem timeout de 90 segundos? Por que existe um Cloudflare worker que reescreve a URL toda terça à noite? O código mostra o que está acontecendo. Ele não mostra o porquê. Raciocínio, trade-offs e o longo catálogo de “a gente tentou aquilo e quebrou a produção” são conhecimento tácito. Nunca entram no repositório. Quando seu único developer sai, o código continua lá. As razões pelas quais ele tem aquela forma, não.
O sinal de que esse é o seu problema: você consegue ver quem escreveu cada arquivo, mas não consegue achar um único documento, comentário ou reunião gravada que explique as escolhas de arquitetura que você já pagou para serem feitas.
Continuidade operacional
O segundo problema é que mesmo que o sistema continue rodando no automático, você não tem ninguém que consiga mudá-lo. Uma correção pequena em produção numa terça de manhã é um bicho diferente de reconstruir o sistema do zero. A primeira pergunta: alguém em quem você confia consegue abrir o projeto, achar o bug, subir um patch e não quebrar o resto? Se a resposta é não, uma inconveniência rotineira (um developer de férias, uma gripe, uma volta atrasada de feriado) vira uma indisponibilidade visível para o cliente. Esse é o problema do bus factor no seu sentido mais estreito e imediato, e é o que a maioria dos fundadores sente primeiro.
O sinal de que esse é o seu problema: uma feature está “quase pronta” há dois meses e ninguém além do developer original consegue responder em que ponto ela está.
Posse estratégica
O terceiro problema é mais abstrato e o que os fundadores raramente enxergam até estarem fundo nele. Quem decide no que a base de código vira em seguida? Quando a única pessoa que entende o sistema atual também é a única que consegue te dizer com credibilidade o que dá ou não dá para construir nos próximos seis meses, seu roadmap de produto está implicitamente sendo co-escrito por essa pessoa. Os incentivos dela e os seus podem se sobrepor perfeitamente. Podem não se sobrepor. De qualquer modo, um roadmap com um ponto único de falha estratégico é um roadmap frágil.
O sinal de que esse é o seu problema: quando você leva ideias de produto para o seu dev, toda resposta vem na forma “a gente teria que reconstruir X” ou “já tentamos Y” e você não consegue avaliar de forma independente se essas afirmações estão corretas.
Esses três problemas respondem a mesma pergunta de superfície. Eles não são resolvidos pela mesma intervenção. Um erro comum do fundador é tentar resolver os três contratando um segundo developer de uma vez, e esse movimento tende a falhar não endereçando nenhum em particular.
Por que seu bus factor provavelmente é 1 e você não sabe
A maioria dos fundadores não-técnicos, quando perguntados, dizem que acham que o bus factor deles é provavelmente 1, mas não sabem de verdade. Três confusões costumam ser as responsáveis.
A primeira é contar gente que tocou no repositório. Um fundador com um developer e um contractor parcial vai contar o contractor. O contractor subiu quatro pull requests neste ano, todos pequenos, todos em partes do sistema que o contractor já conhecia. Bus factor não é o número de pessoas que tocaram no repo. É o número de pessoas que conseguem abrir o laptop amanhã e corrigir o bug em produção que o fundador não consegue descrever. Esse número quase sempre é um.
A segunda é confundir “ter backup” com “ter redundância”. Backup protege dado. Redundância protege continuidade. O código está no GitHub. A infra roda em AWS. Todo segredo está no 1Password. Isso é redundância de dado, e é bom. Não diz nada sobre se alguém mais na empresa consegue subir o bus factor de um para dois. Backup é uma fotografia congelada do sistema. Redundância é uma segunda pessoa que consegue dirigir o carro.
A terceira é confundir “a gente tem documentação” com “a gente tem conhecimento transferível”. Uma página de wiki que diz “o fluxo de auth está em /src/auth” é tecnicamente documentação. Ela não transfere o conhecimento de por que o fluxo de auth tem timeout em 90 segundos. O teste de documentação não é se ela existe. O teste é se um developer competente, novo, com a documentação e o código nas mãos, consegue subir uma correção rotineira na primeira semana sem o autor original presente. Essa barra é muito mais alta do que a maioria dos fundadores percebe.
A solução comum que piora o problema
A reação mais comum de um fundador ao descobrir um bus factor de 1 é contratar um segundo developer. Às vezes é o movimento certo e quase sempre é executado errado. Você contrata o Developer Dois. Você traz ele, dá acesso a tudo, aponta para a base de código, e pede para “fazer onboarding”. Nos dois meses seguintes, o Developer Dois escreve algum código, aprende o sistema e pergunta contexto para o Developer Um o tempo todo. O Developer Um, que já estava em 110% de utilização, vira o gargalo da curva de aprendizado do Developer Dois, e então a empresa vai de um developer produtivo para um pouco menos de um developer produtivo mais uma folha de pagamento maior.
No mês três, uma de duas coisas acontece. O Developer Dois internalizou o suficiente do sistema para ser útil e o seu bus factor agora é 2. Ou o Developer Dois internalizou a superfície do sistema mas não as razões, e então o seu bus factor continua sendo 1, só escondido pela existência de uma segunda pessoa que consegue plausivelmente responder “vou olhar”. Esse segundo desfecho é mais comum e mais difícil de detectar porque o headcount dobrou.
O problema mais profundo é que “contratar um segundo developer” confunde folha de pagamento com redundância. Dois developers que dependem da mesma pessoa para explicar a base de código são um bus factor de 1, não importa quantas pessoas estejam no time. A redundância que você quer não está em headcount. Está em conhecimento transferível. O headcount só passa a ser útil depois que o conhecimento foi externalizado.
A sequência certa é externalizar primeiro, contratar depois. O resto deste artigo é o playbook de como fazer nessa ordem.
Cinco perguntas para fazer se você tem um único developer
Antes de fazer qualquer movimento, rode o diagnóstico de cinco perguntas. Cada resposta é um parágrafo, não um sim ou não. O ponto é ter um retrato lúcido da sua exposição real.
1. Um developer novo, com o repositório e a documentação na mão, conseguiria subir uma correção rotineira na primeira semana sem o seu developer atual presente? Esse é o teste prático de quanto conhecimento está capturado por escrito versus quanto mora em uma cabeça. Se a resposta honesta é “não”, você tem um problema de concentração de conhecimento, não um problema de contratação.
2. Seu developer atual consegue tirar dez dias de férias sem o seu negócio parar? Esse é o teste de continuidade operacional. Se umas férias normais já parecem arriscadas, você tem um problema de continuidade. A solução pode não ser uma segunda pessoa. Pode ser processo: um procedimento de release documentado, um playbook de suporte para bugs conhecidos, uma regra clara do que adiar versus o que escalar.
3. Quando você leva ideias de produto para o seu developer, você consegue avaliar de forma independente a resposta técnica que ele te dá? Esse é o teste de posse estratégica. Se todo “a gente não consegue construir isso porque…” é impossível para você contestar, você não tem um problema de roadmap com o seu developer. Você tem um problema de roadmap com você mesmo, e a resposta é parecer técnico independente, não uma segunda contratação.
4. Se o seu developer atual saísse amanhã com duas semanas de aviso, o que o documento de handover precisaria conter para a empresa continuar funcionando? Esse é o exercício único mais útil deste artigo. A maioria dos fundadores, ao serem perguntados, percebe que o documento não existe e não é fácil de escrever. O exercício de escrever o documento é a externalização.
5. Você está bancando software porque é central para o seu negócio, ou porque não pode mais deixar de bancar? Essa é a pergunta que ninguém faz. Algumas empresas têm um único developer porque essa é genuinamente a forma certa para o estágio. Outras empresas têm um único developer porque entraram em software custom e agora se sentem presas. O segundo caso às vezes se resolve não aumentando o bus factor mas reduzindo a superfície de código custom (ver como criar um software quando você não é o programador para o diagnóstico que distingue os dois).
As respostas dessas cinco perguntas dizem qual dos três problemas acima é o seu, e isso determina o que você faz em seguida.
Quatro passos para subir o bus factor sem dobrar o headcount
Se o diagnóstico confirma que você tem um problema de bus factor e não um problema de roadmap ou um problema de processo, aqui está a sequência que de fato funciona.
Passo 1: Externalize o conhecimento de maior risco primeiro
O primeiro movimento não é uma contratação. É um exercício de escrita. Sente com o seu developer duas horas por semana, toda semana, por quatro semanas, e produza um pequeno conjunto de documentos escritos para um developer novo que ainda não conhece a base de código. Não documentação autogerada. Texto corrido, real. O conjunto é curto.
Um mapa do sistema de uma página: quais são as peças principais, o que cada uma faz, o que chama o quê. Um runbook operacional de uma página: como acontecem os releases, para onde vão os alertas, o que fazer às 3 da manhã quando o gateway de pagamento cai. Um log de decisões arquiteturais de uma página: as quatro ou cinco decisões que restringem o sistema hoje, por que cada uma foi tomada, e o que foi considerado e descartado. Um documento de “se eu tivesse que sair amanhã”, escrito pelo developer na voz dele, listando as pontas soltas, as features pela metade, as partes do código que ele não deixaria um engenheiro júnior tocar sem orientação, e a lista explícita de coisas que ele anda querendo arrumar e ainda não arrumou.
Se o seu developer resistir a esse exercício, isso é em si uma descoberta. Alguns devs resistem a documentação porque o contrato implícito é “você não precisa saber o que eu sei”. Isso nem sempre é consciente e nem sempre é maldoso, mas é um sinal que vale notar. Levante o ponto diretamente: esse trabalho é para a empresa, não para você, e vai ajudar quando ele tirar férias também.
Passo 2: Compre a dependência em commits, não em headcount
O movimento de menor custo e maior alavancagem disponível para um fundador não-técnico com um único developer é trazer um segundo par de mãos parcial, não como uma contratação par a par, mas como um mecanismo de transferência de conhecimento. Três opções funcionam na prática. Um engenheiro sênior fractional que faz code review e pair programming por quatro horas por semana. Um time parceiro pequeno (uma software house focada ou uma dupla de contractors confiáveis) que pega uma frente de trabalho delimitada e a entrega sozinho enquanto roda dúvidas com o seu developer atual. Ou um único engenheiro sênior contratado especificamente para acompanhar e absorver, com o mandato explícito de que as primeiras seis semanas são de aprendizado, não de entrega.
A razão pela qual isso funciona melhor do que uma contratação par a par é que o objetivo explícito é transferência de conhecimento, não crescimento de headcount. O contrato é curto. O custo é baixo. O bus factor se move de 1 em direção a 2 em commits, devagar, e o que você está comprando é uma segunda pessoa que de fato encostou no código de produção. Para uma comparação mais funda dessas estruturas, a decisão entre time interno e outsourcing cobre o mesmo terreno pelo outro lado.
Passo 3: Converta conhecimento tácito em especificações explícitas, uma frente por vez
Enquanto o Passo 1 produz os documentos de fundação e o Passo 2 traz um segundo par de mãos para dentro do código, o terceiro passo é começar a converter o fluxo de trabalho novo de “guiado pelo developer” para “guiado por spec”. Toda feature nova ganha um documento de uma página antes de ser construída. A spec é escrita em conjunto. Ela explica o problema de negócio, a solução proposta, os trade-offs considerados, as alternativas descartadas e os critérios de aceitação. O ponto não é burocracia. O ponto é que o raciocínio por trás de toda adição nova à base de código entra na memória da empresa no momento em que é construída, em vez de ter que ser desenterrado depois.
Isso funciona melhor quando o fundador escreve o primeiro rascunho da spec e o developer marca em cima. A fricção dessa troca é exatamente a fricção que você quer. Ela obriga o fundador a perguntar por quê e o developer a escrever a resposta. Depois de três ou quatro ciclos, vocês dois vão estar mais rápidos nisso do que estavam no primeiro dia.
Passo 4: Rode o teste da “semana de férias”
O diagnóstico mais poderoso para saber se os três passos anteriores funcionaram é colocar o seu developer em férias por uma semana inteira de trabalho, sem laptop e sem Slack. Não como um teste punitivo, como umas férias pagas reais que ele já tinha conquistado. Enquanto ele está fora, o segundo par de mãos (do Passo 2) é a sua linha de frente para qualquer questão de produção. O seu time de suporte tem o runbook documentado do Passo 1. O backlog de specs do Passo 3 está lá para a segunda pessoa escolher de onde puxar.
Se uma semana normal passa sem um incidente que o time não consiga lidar, o seu bus factor se moveu. Se a semana desaba, você aprendeu exatamente qual dos três sub-problemas (concentração de conhecimento, continuidade, posse) ainda está vivo. A versão honesta do teste de férias também é uma decisão de bem-estar para o seu developer, que provavelmente carrega plantão invisível há muito tempo. O custo escondido de um bus factor de 1, frequentemente esquecido, é o custo pago pelo developer que não tem como genuinamente desconectar.
Como é “bom o suficiente”
Um bus factor razoável para uma startup em estágio inicial é dois ou três. Não dez. O custo de empurrar para acima de três antes da empresa ser grande o bastante para justificar é desperdiçado em contexto duplicado que ninguém está lendo. A maioria das empresas com menos de trinta pessoas é bem servida por um bus factor de dois, com a segunda pessoa sendo ou um time parceiro, ou um engenheiro sênior fractional, ou um co-fundador que escolheu manter as mãos perto o suficiente do código para ser útil em uma emergência.
Um bus factor de um não está sempre errado. Pode ser uma escolha deliberada e por tempo limitado. O fundador de uma empresa de cinco pessoas com um developer e runway para nove meses pode genuinamente estar fazendo a chamada certa. O erro é tratar essa condição como permanente. A forma correta de enxergar é que o bus factor de um é um estado com data de validade conhecida, e todo trimestre você deve perguntar se ainda deveria ser um.
O ponto mais profundo é que o bus factor não é de fato um número. É uma pergunta sobre quem mais dentro da empresa tem as chaves do sistema, na cabeça e no papel. Uma vez que você construiu os documentos, trouxe um segundo par de mãos e colocou o seu developer em férias sem o mundo desabar, você parou de ser um ponto único de falha na sua própria empresa. É isso que a pergunta de fato está perguntando.
FAQ
O que é um bus factor de 1? Um bus factor de um significa que uma única pessoa no projeto detém o conhecimento necessário para mantê-lo rodando. Se essa pessoa para de contribuir por qualquer razão (doença, férias, troca de emprego, emergência familiar), o trabalho não consegue continuar sem disrupção significativa. Para a maioria das startups em estágio inicial com um único developer, o bus factor é um, mesmo quando o time tem várias pessoas.
Como se calcula o bus factor? O cálculo honesto não é uma fórmula. É um experimento mental. Pegue o pedaço crítico do seu software que está no ar (o fluxo de pagamento, o sistema de autenticação, o modelo de dados de que todo o resto depende) e pergunte: quantas pessoas no time conseguem abrir o código amanhã de manhã e subir uma correção rotineira nesse pedaço sem quebrar o resto? A resposta é o bus factor daquela parte do sistema. O bus factor do projeto inteiro é o menor dessas respostas entre os caminhos críticos. Diversos grupos de pesquisa propuseram métricas automáticas baseadas em histórico de commits, mas para um fundador, o experimento mental é mais útil do que a fórmula.
O que é o bus factor na prática? Na prática o bus factor aparece não como uma catástrofe mas como uma série de pequenas fricções: um developer de férias e uma correção que você não consegue subir, uma feature que ninguém além do autor consegue explicar, um roadmap implicitamente co-escrito pela única pessoa que consegue avaliar a resposta técnica. Essas fricções diárias são a experiência vivida de um bus factor baixo, muito antes de alguém de fato ser atropelado por um ônibus.
Qual é um exemplo de bus factor? Um exemplo real: uma legaltech de 14 pessoas com um developer sênior e um contractor parcial. O developer sênior escreveu a base de código original, é dono do pipeline de deploy, segura as chaves de produção e é a única pessoa que já encostou na integração de pagamento. O contractor subiu quatro correções de bug, todas dentro de áreas que o contractor já conhecia. A empresa tem todo o código no GitHub, segredos no 1Password e infraestrutura na AWS. O bus factor é um. A CEO não está totalmente errada em se sentir exposta, e o que de fato ajudaria é o plano de quatro passos acima, não uma segunda contratação par a par.
Como aumentar o bus factor? Externalizando conhecimento antes de adicionar headcount. Documentos primeiro, segundo par de mãos depois, fluxo guiado por spec em terceiro, e uma semana de férias real como teste. Adicionar pessoas sem antes externalizar o conhecimento que elas precisariam absorver não aumenta o bus factor; só espalha a dependência por mais salários. A forma mais barata de ir de um para dois é quase sempre começar por um exercício de escrita, não por uma contratação. A mesma lógica aparece no custo de longo prazo de manter software custom: as linhas de orçamento que parecem escalar com headcount, na verdade escalam com conhecimento documentado.
Uma vez que um fundador não-técnico fez esse trabalho, a ansiedade original muda de forma. A pergunta deixa de ser “e se meu developer pedir demissão” e passa a ser “qual parte do sistema é o próximo ponto único de falha para derrubar”. Essa é uma pergunta bem melhor de se estar fazendo.