O seu melhor engenheiro acabou de se demitir. E agora?

Toda equipe de engenharia tem uma pessoa que sabe por que o pipeline de deploy funciona da forma que funciona, por que o esquema do banco de dados tem aquela convenção de nomenclatura estranha, o que aconteceu durante a queda em 2023 que moldou a configuração de monitoramento atual e quais partes do código legado são paredes de sustentação que absolutamente não devem ser tocadas.

Quando essa pessoa sai, e eventualmente ela sairá, todo esse contexto vai embora com ela. A equipe descobre as lacunas ao longo das semanas e meses seguintes, um incidente doloroso de cada vez: um deploy que quebra porque ninguém sabia sobre a etapa manual que não estava documentada, uma refatoração que remove inadvertidamente uma solução de contorno que existia por um motivo que ninguém consegue mais lembrar, uma nova contratação que passa três semanas tentando entender um sistema que o engenheiro que saiu poderia ter explicado em vinte minutos.

Este é o problema do "fator ônibus" (bus factor), nomeado a partir da pergunta mórbida "quantos membros da equipe teriam que ser atropelados por um ônibus antes que o projeto não pudesse continuar?" A maioria das equipes de engenharia tem um fator ônibus de um ou dois para partes significativas do seu sistema, o que significa que uma ou duas saídas poderiam causar semanas ou meses de interrupção.

O que realmente vai embora

Quando um engenheiro experiente sai, o código fica. Os PRs ficam. As mensagens do Slack ficam, pelo menos até sumirem da janela de retenção. O que vai embora é a camada interpretativa: o entendimento de por que as coisas são do jeito que são, quais decisões foram trade-offs conscientes e quais foram acidentes, onde estão os segredos ocultos e o que vai quebrar se você tocar na coisa errada.

Isso é conhecimento tribal em sua forma mais concentrada, e é o tipo de conhecimento mais difícil de transferir porque a pessoa que o detém muitas vezes não percebe o quanto sabe. Ela o acumulou ao longo de meses ou anos trabalhando de perto com o sistema, e muito disso se tornou tão automático que ela não conseguiria produzir um documento abrangente sobre o assunto, mesmo se tentasse.

Entrevistas de desligamento e sessões de transferência de conhecimento ajudam, mas capturam uma fração do que a pessoa que está saindo sabe. Você não consegue transferir dois anos de contexto acumulado em um período de aviso prévio de duas semanas.

A alternativa da captura contínua

A resposta para o problema do fator ônibus é capturar o conhecimento de forma contínua, em vez de correr para extraí-lo no momento da demissão.

A documentação autoescriturável faz isso convertendo a atividade de engenharia que já está acontecendo em documentação estruturada e pesquisável à medida que ocorre. Quando um engenheiro explica uma decisão de arquitetura em uma thread do Slack, essa explicação é capturada e integrada à documentação do sistema. Quando um PR inclui uma descrição de por que uma abordagem específica foi escolhida, esse raciocínio é preservado junto ao código. Quando uma reunião discute os prós e contras de um plano de migração, a discussão é documentada e vinculada ao sistema relevante.

O conhecimento não é extraído do engenheiro em uma sessão especial. Ele é capturado como um subproduto do trabalho que ele já está fazendo, o que significa que ele se acumula continuamente e se mantém atualizado à medida que o sistema evolui.

Quando esse engenheiro eventualmente sai, a documentação que ele gerou durante seu tempo de casa permanece. A próxima pessoa que precisar entender por que o pipeline de deploy funciona da forma que funciona pode pesquisar nos documentos em vez de descobrir a resposta por tentativa e erro.

O custo de não resolver isso

O custo de uma saída importante sem a documentação adequada é difícil de medir com precisão, mas fácil de sentir. As equipes normalmente relatam de dois a seis meses de velocidade reduzida após perderem um detentor crítico de conhecimento, dependendo de quanto do sistema aquela pessoa entendia e de quão bem o conhecimento estava documentado.

Considerando um salário de engenheiro sênior de $180.000 a $220.000, mesmo dois meses de produtividade significativamente reduzida em uma equipe representam dezenas de milhares de dólares em perda de produtividade. Para sistemas críticos onde o engenheiro que saiu era o único detentor do conhecimento, o custo pode ser muito maior: incidentes de produção que demoram mais para serem resolvidos, recursos que são adiados porque ninguém entende o sistema bem o suficiente para modificá-lo com segurança e um onboarding que leva meses em vez de semanas porque não há nada para os novos contratados lerem.

O problema do fator ônibus é um dos poucos riscos de engenharia onde a solução (documentação que captura o conhecimento continuamente) é mais barata do que o problema que ela evita.

Perguntas frequentes

Não podemos apenas fazer sessões de transferência de conhecimento? Você pode e deve, mas elas capturam apenas o que o engenheiro que está saindo lembra de mencionar, o que é uma fração do que ele sabe. Grande parte do conhecimento mais valioso é contextual e só surge em resposta a situações específicas que não acontecem durante uma sessão de transferência.

Quanta documentação é suficiente para reduzir o fator ônibus? Foque em decisões e raciocínios em vez de detalhes de implementação (o código se documenta no nível da implementação). Se um novo engenheiro conseguir entender por que o sistema está estruturado da forma que está lendo os documentos, o risco do fator ônibus é substancialmente reduzido.

Isso se aplica a equipes pequenas? Equipes pequenas são, na verdade, mais vulneráveis, porque cada pessoa detém uma proporção maior do conhecimento total. Uma equipe de cinco pessoas que perde um engenheiro perde 20% do seu contexto coletivo. Uma equipe de cinquenta pessoas que perde um engenheiro perde 2%.

Leitura recomendada: O custo oculto do conhecimento tribal, Débito de documentação, Seu código está documentado, suas decisões não estão. Páginas relacionadas: Docs autoescrituráveis, Retenção de conhecimento, Para equipes de engenharia.