Fator ônibus: quando o sistema da empresa depende de uma pessoa só

Em quase toda empresa existe uma frase que resolve boa parte dos problemas no sistema antigo: “fala com o Jorge”. O Jorge sabe por que a rotina da madrugada às vezes trava, qual tabela precisa ser ajustada no fechamento do mês e o que fazer quando o banco muda o layout do arquivo de retorno. Ninguém mais sabe, e por muito tempo isso nem pareceu um problema.

Até o dia em que o Jorge sai de férias, pede demissão ou anuncia que vai se aposentar. Nessa hora, a diretoria descobre que um sistema essencial para o faturamento depende, na prática, da memória de uma única pessoa. Esse risco tem nome, e dá para medir e reduzir antes que ele vire uma crise.

O que é o fator ônibus?

Fator ônibus (em inglês, bus factor ou truck factor) é o número mínimo de pessoas que precisariam sair de repente de um projeto, “atropeladas por um ônibus”, na expressão um pouco mórbida que deu origem ao nome, para que ele pare. Se um sistema só continua de pé porque uma pessoa sabe mantê-lo, o fator ônibus dele é um.

O nome assusta, mas a ideia é simples: quanto menor o número, mais concentrado está o conhecimento e maior a chance de a empresa ficar sem saída quando essa pessoa não estiver disponível, seja por um motivo grave, seja por algo tão comum quanto uma troca de emprego.

O problema é mais frequente do que parece. Um estudo de pesquisadores da UFMG e de outras universidades analisou 133 projetos de software populares no GitHub, mantidos por comunidades grandes e abertas, e concluiu que 65% deles tinham fator ônibus igual ou menor que dois. Se isso acontece em projetos com milhares de colaboradores, imagine em um sistema interno mantido há quinze anos pela mesma equipe pequena.

Por que o risco é maior nos sistemas legados?

Em um sistema novo, parte do conhecimento costuma estar em documentação, testes automatizados e histórico de alterações. No legado, quase sempre está em dois lugares só: no próprio código e na cabeça de quem o escreveu ou o mantém há anos. E as duas coisas envelhecem juntas.

A tecnologia também pesa. Quem domina linguagens e ferramentas antigas, como COBOL, Delphi ou Visual Basic, está cada vez mais perto da aposentadoria, e o mercado forma pouca gente nova nelas. Quando o conhecimento do negócio e o conhecimento da tecnologia estão na mesma pessoa, substituí-la vira um problema duplo.

O caso mais conhecido aconteceu em abril de 2020, no estado de Nova Jersey, nos Estados Unidos. Com a pandemia, os pedidos de seguro-desemprego explodiram e o sistema que os processava, com mais de 40 anos e escrito em COBOL, não acompanhou. O governador Phil Murphy precisou pedir publicamente voluntários que soubessem programar em COBOL e resumiu o problema em uma frase: entre as lições a tirar daquela crise estaria entender como o estado chegou ao ponto de literalmente precisar de programadores COBOL. Na época, especialistas lembraram que quem conhecia a linguagem era, em boa parte, gente mais velha ou já aposentada.

A maioria das empresas não vai passar por algo dessa escala. Mas a lógica é a mesma: o sistema funciona bem até o dia em que precisa mudar depressa, e aí falta quem saiba mexer nele.

Como isso aparece no dia a dia?

O fator ônibus raramente aparece num relatório. Ele aparece em situações como estas:

A rotina que só uma pessoa reinicia. O processamento noturno de pedidos falha uma ou duas vezes por mês. Quem sabe em que ponto retomar, sem duplicar notas, é um único analista. Quando ele está de férias, o pedido do cliente espera.

A regra que não está escrita em lugar nenhum. Alguns clientes antigos têm condição especial de prazo ou desconto que foi colocada direto no código anos atrás, a pedido de um diretor que já saiu. O comercial não sabe que ela existe; o sistema simplesmente aplica.

A integração ajustada à mão. Sempre que o banco, a transportadora ou a prefeitura muda um arquivo ou um serviço, a mesma pessoa faz a correção em poucas horas. Sem ela, a mesma correção pode levar semanas, com o faturamento ou a cobrança parados.

O acesso que ninguém mais tem. A senha do servidor antigo, o certificado que vence todo ano ou o passo a passo para restaurar o backup estão anotados no computador de alguém, ou só na memória.

Em todos esses casos, o custo não está no salário de quem sabe. Está no tempo de operação parada, nos erros de quem tenta substituir sem saber e na dificuldade de modernizar um sistema que ninguém mais consegue explicar.

Como descobrir o fator ônibus da sua empresa?

Não é preciso ferramenta sofisticada para começar. Basta listar os sistemas que, se pararem, param a operação: faturamento, financeiro, estoque, folha, integrações com bancos e parceiros. Para cada um, faça três perguntas:

• Quem consegue explicar o que ele faz e por quê?
• Quem consegue fazer uma alteração com segurança?
• Quem consegue colocá-lo de volta no ar se ele cair?

Se a resposta for sempre o mesmo nome, o fator ônibus daquele sistema é um. Se for um fornecedor externo sem contrato de transferência de conhecimento, também. Quando o código está em uma ferramenta de versionamento, o histórico de alterações ajuda a confirmar quem de fato mexe em cada parte, e muitas vezes revela partes inteiras que só uma pessoa tocou nos últimos anos.

O resultado dessa conversa costuma ser uma lista curta e desconfortável. É justamente por ela que vale começar.

Onde a inteligência artificial ajuda, e onde não ajuda?

Durante muito tempo, documentar um sistema legado era um projeto caro, lento e que quase sempre ficava para depois. A inteligência artificial mudou a conta, porque faz bem uma parte do trabalho que antes consumia meses.

Ler o código e fazer o primeiro rascunho. A IA consegue percorrer milhares de linhas, inclusive em linguagens antigas, e produzir uma primeira descrição de cada rotina: o que recebe, o que calcula, que tabelas altera e de quais outras partes depende. É um ponto de partida que antes levava semanas de leitura.

Preparar a conversa com quem sabe. Com esse rascunho em mãos, a IA pode listar o que não ficou claro no código: por que existe essa exceção, o que acontece se esse campo vier vazio, quem usa esse relatório. Em vez de pedir ao especialista que “documente tudo”, a empresa faz perguntas objetivas, que ele responde em uma conversa gravada.

Transformar conversa em documento. A transcrição dessas conversas vira manual de operação, passo a passo de recuperação e descrição das regras de negócio, cruzados com o que o código de fato faz. O especialista revisa e corrige.

Deixar o conhecimento consultável. Depois de revisado, esse material pode alimentar um assistente interno que responde dúvidas da equipe com base nos documentos da empresa, como explicamos no artigo sobre RAG e IA conectada aos dados da empresa.

O que a IA não faz é saber o porquê. Ela lê o que o sistema faz, mas não sabe que aquela condição especial existe por causa de um acordo comercial de 2011, nem que um cálculo esquisito foi feito de propósito para bater com a contabilidade. Esse contexto só vem de quem viveu a história. Por isso, a IA acelera o trabalho do especialista, mas não substitui a validação dele.

Há também um cuidado de segurança: código-fonte e regras de negócio são informação sensível. A análise deve acontecer em um ambiente controlado pela empresa, com regras claras sobre o que a IA pode acessar, nos moldes do que descrevemos em guardrails de IA, e não colando trechos do sistema em ferramentas públicas.

Um plano em quatro passos

Reduzir o fator ônibus não exige parar a operação nem trocar o sistema. Um caminho que funciona bem:

• Mapear. Fazer o levantamento descrito acima e priorizar os sistemas em que o risco é maior: os mais críticos e os que dependem de alguém perto de sair.
• Documentar com IA e validar com quem sabe. Usar a IA para produzir o rascunho e as perguntas, e reservar algumas horas por semana do especialista para revisar. O tempo dele passa a render muito mais.
• Formar a segunda pessoa. Durante algumas semanas, outra pessoa executa as tarefas críticas enquanto o especialista acompanha: o fechamento, a recuperação da rotina noturna, o ajuste de uma integração. Só se considera o conhecimento transferido quando ela faz sozinha.
• Registrar o comportamento em testes. Criar testes automáticos que guardam o que o sistema faz hoje, com os mesmos dados de entrada e os mesmos resultados esperados. Eles protegem as regras escondidas de que falamos no artigo sobre a Lei de Hyrum e são a base para uma modernização sem risco no futuro.

O melhor momento para começar é enquanto o especialista ainda está na empresa e disposto a ajudar. Quando ele avisa que vai sair, o prazo já ficou curto; quando ele já saiu, sobra a engenharia reversa, que é mais cara e mais arriscada.

Conhecimento também é patrimônio

Ninguém deixaria o caixa da empresa em uma conta que só uma pessoa consegue movimentar. O conhecimento sobre os sistemas que faturam, cobram e entregam merece o mesmo cuidado. Não se trata de desconfiar de quem sabe, e sim de reconhecer o valor dessa pessoa e garantir que o que ela construiu continue funcionando depois dela.

A boa notícia é que, com a ajuda da IA, transformar o conhecimento de uma pessoa em conhecimento da empresa ficou mais rápido e mais barato do que nunca. O que continua indispensável é a decisão de começar.

Como a RETTA pode ajudar?

A RETTA, software house e empresa de outsourcing de TI de Lajeado/RS, atua na manutenção e modernização de sistemas legados: mapeamos quem sabe o quê, usamos inteligência artificial para documentar o código e as regras de negócio junto com o seu especialista, criamos os testes que protegem o comportamento atual e assumimos, com a sua equipe, a manutenção dos sistemas críticos. Assim, a operação deixa de depender de uma única pessoa: nós tiramos o conhecimento da cabeça do especialista e deixamos ele no time e nos testes, sem parar o faturamento.

Se existe um sistema na sua empresa em que só uma pessoa sabe mexer, fale com a nossa equipe e descubra por onde começar.

Fontes

• Avelino, Passos, Hora e Valente: A Novel Approach for Estimating Truck Factors (UFMG e outras universidades, 2016)
• CNBC: Nova Jersey pede voluntários que saibam COBOL para o sistema de seguro-desemprego (6 de abril de 2020)
• NJ.com: pedidos de seguro-desemprego processados por um sistema de 40 anos (abril de 2020)