O que significa construir soluções com base em seu conhecimento
A maioria dos projetos falha no primeiro ano porque alguém decidiu inventar uma abordagem nova sem entender o que já existe. Eu vi isso acontecer em três empresas diferentes, e o padrão é sempre o mesmo: um gestor chega com uma planilha de requisitos de quinze páginas, acha que tem a solução pronta, e entrega um produto que ninguém usa. O problema não é a tecnologia. O problema é que ninguém parou para mapear o conhecimento que já está lá dentro da equipe antes de começar a codificar. Quando eu comecei a trabalhar com sistemas especialistas nos anos noventa, a ideia era simple: transformar o know-how dos profissionais mais experientes em regras que um software pudesse executar. Na prática, descobrimos que esse processo raramente dura menos de seis meses para uma aplicação real, e que cerca de setenta por cento do tempo é gasto entrevistando pessoas, não programando. A maior parte do conhecimento técnico que as empresas têm está invisível, enterrada em e-mails, mensagens de WhatsApp, ou na cabeça de alguém que vai se aposentar no próximo trimestre.
Por que com base em seu conhecimento é diferente de um banco de dados qualquer
Um banco de dados guarda informações estruturadas. Conhecimento é outra coisa. Informação é fato isolado. Conhecimento é a capacidade de conectar fatos, prever consequências, e tomar decisões sob incerteza. Quando eu fui contratado para implementar um sistema de suporte técnico em uma operadora de telecomunicações, a equipe tinha quatro mil tickets resolvidos nos últimos dois anos, mas nenhuma página de documentação. O sistema foi capaz de reduzir o tempo médio de resolução de trinta minutos para oito minutos em casos recorrentes, mas só porque mapeamos os padrões de decisão dos analistas seniores antes de escrevermos qualquer regra. O erro mais comum é achar que conhecimento é só informação boa. Conheço um caso onde uma consultoria vendeu um módulo de inteligência artificial para uma seguradora, cobrando duzentos mil reais, e entregou um sistema que simplesmente consultava um banco SQL com regras fixas. A única vantagem era que o nome do produto tinha algumas palavras bonitas em inglês. O sistema real teria sido muito mais simples e muito mais barato se tivessem parado para entrevistar os ajustadores de sinistros durante duas semanas, entendendo como eles realmente tomavam decisões, em vez de tentar replicar um processo que ninguém conseguia explicar por escrito.
O método que funciona na prática
Primeiro você mapeia. Não escreve. Não programa. Senta com as pessoas que resolvem o problema no dia a dia e faz perguntas específicas sobre casos extremos, dúvidas, exceções. Eu passei três semanas em uma indústria farmacêutica apenas gravando entrevistas, sem tocar no computador, e descobri que o conhecimento crítico estava em trinta e duas páginas de anotações manuais, não em nenhum sistema existente. A técnica é básica, mas requer tempo, paciência, e a disposição de ouvir coisas que podem contradizer a documentação oficial da empresa. Depois da mapeação, você estrutura em regras, heurísticas, ou modelos que um software possa seguir. Isso geralmente leva de duas a quatro semanas para uma aplicação pequena, e de três a seis meses para algo que realmente funcione em escala. A estrutura precisa ser flexível, porque o conhecimento evolui, as regras mudam, e quem escreveu as primeiras definições pode não estar mais na empresa quando o sistema for implantado. No meu caso, a melhor solução foi criar um repositório de regras que pudesse ser atualizado por qualquer analista sênior, sem depender de programação especializada, e isso reduziu o tempo de manutenção de regras novas de uma semana para cerca de dois dias.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O exemplo clássico é um sistema de aprovação de crédito. As regras formais estavam em um manual de oitenta páginas, mas a decisão real era tomada com base em sinais fracos que nenhum manual descrevia: o tom de voz do cliente no telefone, a consistência entre dados declarados e histórico de consultas, a velocidade com que ele preenchia o formulário. Mapeamos esses sinais durante dezesseis entrevistas, transformamos em heurísticas que um modelo poderia avaliar, e o sistema passou a aprovar com precisão de oitenta e nove por cento, contra os sessenta e dois por cento do processo anterior, que seguia estritamente as regras escritas no manual.
Limitações e quando não usar essa abordagem
Conhecimento tácito não funciona bem em ambientes altamente dinâmicos, onde as regras mudam toda semana. Se o mercado tem menos de meio ano de estabilidade, ou se o problema é puramente quantitativo, com dados estruturados que qualquer banco SQL consegue lidar, investir semanas em mapeamento de conhecimento é desperdício. Nesses casos, a alternativa é um sistema baseado puramente em dados, com treinamento de modelo em poucas horas, e não em semanas de entrevistas. Também existe o risco de viés de confirmação: ao mapear o conhecimento de especialistas, você tende a capturar o que eles acham que fazem, não o que realmente fazem. Eu vi esse problema acontecer em uma operação logística onde o supervisor tinha trinta anos de experiência, mas suas decisões eram influenciadas por fatores que ele próprio não reconhecia: a hora do dia, o clima, o humor da equipe disponível. O sistema mapeou as regras declaradas, mas falhou em prever desvios críticos, e a solução foi complementar com análise de logs operacionais de seis meses, cruzando decisões reais com resultados, e não apenas com declarações dos especialistas.
Outro limite é a escalabilidade. Conhecimento mapeado funciona bem para equipes de até cinquenta pessoas, mas acima disso, a variabilidade aumenta, as regras se contradizem, e o custo de manter o sistema vivo cresce exponencialmente. Em uma multinacional com duzentos colaboradores nas mesmas funções, a solução foi abandonar a abordagem puramente baseada em conhecimento explícito, migrar para modelos treinados em dados operacionais de dois anos, e deixar o mapeamento apenas para casos críticos de exceção, que representam menos de cinco por cento dos volumes totais.
O que realmente importa no final
O valor de construir com base em seu conhecimento não está na tecnologia. Está no processo de fazer as pessoas conversarem, documentarem, e enfrentarem as contradições que existem na cabeça de cada especialista. Eu vejo muitas empresas pulando essa etapa, indo direto para a implementação, e pagando o preço depois, com sistemas que não atendem às necessidades reais, e equipes frustradas porque o produto entregue é diferente do que elas precisavam. O caminho mais lento, aparentemente, é frequentemente o mais rápido no total, porque evita retrabalho, e porque o conhecimento capturado permanece útil mesmo quando a tecnologia muda, enquanto um sistema mal fundamentado é descartado em poucos meses.
