Conhecimento Preso — Quando o Suporte Depende da Manutenção

O que fazer quando as regras de negócio e o funcionamento do software vivem só no código e na cabeça de poucas pessoas, sem documentação — e o suporte não resolve nada sem interromper o time de manutenção para descobrir "como isso funciona" a cada dúvida.

É o Pilar 5 — Conhecimento Distribuído na prática, do ponto de vista de quem sofre com a ausência dele. Se cada pergunta do suporte vira uma interrupção no dev, você está pagando o "imposto do conhecimento preso" todos os dias.

O custo duplo

Quando o conhecimento está preso, cada dúvida cobra dois preços ao mesmo tempo:

E o pior: como nada disso é registrado, a mesma pergunta volta semana que vem e o ciclo recomeça. Cada interrupção é um custo pago de novo, do zero. É uma fonte silenciosa de Modo Crise: o time nunca sai do reativo porque o suporte drena a capacidade gota a gota.

Você tem conhecimento preso se...

• O suporte não fecha certos chamados sem "perguntar pro dev"
• As regras de negócio só existem no código (e às vezes nem lá está claro)
• "Só o Fulano sabe como esse cálculo funciona"
• A mesma dúvida é respondida várias vezes, sempre de forma verbal
• Não existe base de conhecimento — ou existe uma desatualizada que ninguém confia
• Quando alguém-chave tira férias, o suporte trava
• Ninguém sabe dizer por que o sistema faz X — só que "sempre foi assim"

Marcou vários? O conhecimento é tribal (passa de boca em boca) e o suporte é refém da manutenção. A meta deste documento é libertar esse conhecimento — extraí-lo de onde está preso e torná-lo acessível.

Por que chegou nesse ponto

• A doc nunca foi escrita — no aperto da entrega, documentar é o primeiro corte.
• O conhecimento parece "óbvio" para quem o tem — o guardião não percebe que ninguém mais sabe.
• Regras de negócio se acumulam sem registro — cada "só nesse caso faz diferente" vira uma regra invisível enterrada num if.
• Rotatividade — quem sai leva o mapa mental junto; quem entra recomeça do zero.

Extrair regras sem documentação (engenharia reversa)

Quando não há doc, o conhecimento precisa ser arqueologicamente recuperado. Cinco fontes, da mais confiável à mais trabalhosa:

1. Ler o código — a fonte da verdade

As regras de negócio moram em lugares previsíveis. Procure ali primeiro:

• Validações — o que o sistema aceita ou recusa revela as regras (ex: "CPF obrigatório acima de R$ X").
• Condicionais (if/else, switch) — cada ramo costuma ser uma regra de negócio.
• Cálculos e fórmulas — impostos, descontos, prazos, comissões.
• Constantes e configurações — limites, faixas, flags que ligam/desligam comportamento.

2. Observar o comportamento (caixa-preta)

Quando ler o código é caro ou arriscado, trate o sistema como caixa-preta:

• Reproduza o caso num ambiente seguro e observe entradas → saídas.
• Varie uma entrada por vez para isolar qual regra muda o resultado.
• Útil quando a regra está espalhada ou o código é ilegível.

3. Minerar logs e banco de dados

Os dados denunciam as regras:

• Consultas no banco revelam padrões (ex: "todo pedido desse tipo tem status Y").
• Logs mostram o fluxo real e as decisões que o sistema tomou.
• Bom para descobrir o que de fato acontece vs. o que se imagina que acontece.

4. Entrevistar os "guardiões" — e registrar na hora

As poucas cabeças que sabem são uma fonte rica, mas volátil:

• Pergunte o porquê, não só o como ("por que esse caso é tratado diferente?").
• Documente durante a conversa, não depois — senão o conhecimento evapora de novo.
• Trate cada entrevista como uma extração única: aquela pessoa pode sair amanhã.

5. Garimpar o histórico de tickets

O suporte já acumulou um tesouro sem perceber:

• Chamados antigos + suas resoluções são regras de negócio já documentadas de fato.
• As perguntas que mais se repetem mostram exatamente o que documentar primeiro.

🧩 Cada regra recuperada deve virar um registro permanente — use o template Regra de Negócio, anotando onde ela vive no código e como foi descoberta.

Documentação sob demanda

Você não vai (e não deve) documentar o sistema inteiro de uma vez — seria um projeto interminável e a maior parte nunca seria consultada. A estratégia é deixar a demanda real guiar o que documentar.

A regra de ouro

Nenhuma dúvida escalada ao dev pode ser respondida sem virar um artefato permanente.

Toda vez que o suporte precisa interromper a manutenção, a resposta é capturada numa base de conhecimento. Assim, a interrupção é paga uma única vez: da próxima vez, a resposta já está lá. As interrupções deixam de ser desperdício e viram investimento que se acumula.

Como construir a base de conhecimento

• Comece vazia e deixe crescer por uso — só entra o que alguém realmente perguntou. Isso garante que 100% do conteúdo é útil.
• Priorize pelo que mais se repete — as perguntas frequentes primeiro (maior alívio por esforço).
• Dois tipos de artefato:
• Catálogo de Regras de Negócio — o "porquê" e o "o quê" das regras (a verdade do sistema).
• Runbooks / FAQ de Suporte — o "como resolver" cada situação comum (a ação do suporte).
• Documente onde as pessoas vão procurar — de nada adianta uma doc perfeita num lugar que ninguém abre. Coloque a base onde o suporte já trabalha e torne-a pesquisável.
• Mantenha viva — quando uma regra muda, o artefato muda junto (idealmente no mesmo fluxo da mudança de código).

Isso é a Fase 3 — Otimizar aplicada ao conhecimento: pagar a dívida de documentação de forma incremental e priorizada, em vez de um mutirão único que envelhece rápido.

Reduzir a dependência do suporte com a manutenção

Com a base crescendo, o objetivo passa a ser estruturar o atendimento para que o dev seja a última opção, não a primeira.

Níveis de suporte

O alvo é que a maioria dos chamados morra no N1. O dev (N3) só vê o que é realmente inédito.

Self-service e caminho de escalação

• Self-service: a base de conhecimento permite ao N1 (e até ao próprio cliente) resolver sozinho o que antes exigia um dev.
• Escalação com contexto: quando precisa subir de nível, o chamado sobe com o que já foi investigado — nada de o dev começar do zero. Um caminho claro de "quando e como escalar" evita tanto o escalonamento precoce quanto o tardio.
• A meta que fecha o ciclo: cada escalação ao dev deve reduzir a probabilidade da próxima — porque virou artefato. Se a mesma coisa escala duas vezes, a captura falhou.

Critérios de saída (conhecimento libertado)

Você saiu do "conhecimento preso" quando:

• ✅ O suporte resolve a maioria dos chamados sem interromper a manutenção
• ✅ Existe uma base de conhecimento viva e confiável, que cobre o recorrente
• ✅ As principais regras de negócio estão catalogadas — não só na cabeça de alguém
• ✅ O bus factor subiu: férias/saída de uma pessoa não travam o atendimento
• ✅ Novas dúvidas viram artefato por padrão, sem precisar cobrar

A partir daí, as interrupções param de drenar a manutenção, o que devolve capacidade para a preventiva — reforçando o Pilar 5 e ajudando a manter distância do Modo Crise.

➡️ Relacionado: Pilar 5 — Conhecimento Distribuído · Roadmap — Fase 3: Otimizar · Modo Crise (interrupções) · Templates: Regra de Negócio e Runbook de Suporte