Como capturar o que está na cabeça das pessoas
A gente sempre subestima o quão difícil é transformar conhecimento tácito em explícito. Sabe aquele funcionário que resolve um problema em três segundos porque "tem intuição" mas não consegue explicar o caminho das pedras? Isso acontece todo dia. Eu já perdi dois dias tentando documentar um processo que uma analista fazia de olhos fechados, e no final percebi que ela própria não conseguia descrever o critério que usava para decidir o fluxo de dados. O que muita gente não entende é que conhecimento tácito e explícito não são dois compartimentos separados. Eles vivem num espectro. A maior parte do que você sabe tecnicamente é tácito de primeira mão. Você sabe quando um código está errado sem conseguir provar matematicamente antes de rodar. Isso não é mágica. É acumulação de padrão reconhecido pelo cérebro.
conhecimento tacito x explicito na prática
A ferramenta básica para capturar conhecimento explícito ainda é documentação. Mas a questão é que ninguém lê documentação. Se você escrever um manual de 40 páginas sobre o processamento de dados, vai ter exatamente duas pessoas que vão abrir até a página cinco. O que funciona é documentar o menor fragmento possível, no momento em que o problema aparece. Eu trabalho com extração de conhecimento tácito usando uma técnica que eu chamo de gravação de sessão comentada. Não é entrevista. Não é questionário. É gravar a tela da pessoa enquanto ela trabalha e pedir que ela continue falando em voz alta como se estivesse ensinando alguém pela primeira vez. O resultado costuma ser muito diferente do que a pessoa escreveria em qualquer manual porque o raciocínio dela fica exposto em tempo real. O processo leva entre 45 minutos e uma hora para cada especialista mapeado, e eu recomendo fazer isso no turno da manhã, quando o raciocínio ainda está mais límpido.
Tem um detalhe que ninguém conta sobre isso. A pessoa precisa estar confortável com o fato de estar sendo gravada. Eu já vi casos em que o funcionário mudava completamente o comportamento quando percebia que estava sendo observado, e a documentação que saía dali era completamente distorcida da realidade. A solução foi mais ou menos acidental: eu comecei a deixar a câmera ligada por uns vinte minutos antes da gravação efetiva começar, sem pedir nada, só para a pessoa se acostumar com a presença do equipamento. Depois eu pedia para ela continuar normalmente e ir narrando. O resultado mudou drasticamente.
Por que a maioria das tentativas de documentar conhecimento falha
O principal erro é achar que basta perguntar. Quando você vai atrás de alguém dizendo "me explica como você faz isso", a pessoa vai te dar a versão idealizada dela. Ela não vai mencionar os atalhos, as exceções, os erros que ela aprendeu a contornar com décadas de experiência. Ela vai te dar a versão de currículo, não a versão real. Outro erro comum é tentar transformar tudo em escrito. Processos escritos são úteis quando são mínimos e específicos. Um procedimento com quinze passos genéricos não substitui conhecimento tácito nenhum. O que funciona são decisões condicionais anotadas: se acontecer X, faça Y; se acontecer Z, não faça nada e avise fulano.
Também tem o problema do contexto. Conhecimento tácito muitas vezes está ancorado em contexto que não está no documento. Eu fiz um exercício para extrair conhecimento de um analista de risco que levava trinta segundos para identificar uma transação suspeita. Ele era imbatível nisso. A documentação que fizemos dizia que ele "observava padrões incomuns". O que a documentação não dizia era que ele olhava especificamente para o horário do dia, o valor fracionário e a sequência de caracteres no campo de observação. Três coisas que ele nunca citou em nenhuma entrevista porque eram absolutamente óbvias pra ele.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Quando esse modelo não funciona
A extração de conhecimento tácito tem limitações sérias. Primeiro, não funciona bem com conhecimento muito recente. Se alguém aprendeu algo há três semanas, o conhecimento ainda nem solidificou o suficiente para ser explicitado. Segundo, não adianta muito para habilidades puramente físicas. Um cirurgião ou um mecânico especializado pode saber exatamente o que está sentindo nas mãos, mas transformar isso em texto é quase impossível. Terceiro, pessoas muito experientes às vezes desenvolvem tal automatismo que perdem a capacidade de articular o raciocínio. É como pedir para alguém explicar como caminhar. Você já nem lembra os detalhes de cada passo. Se o objetivo é realmente preservar conhecimento, o mais honesto é combinar documentação explícita com mentorias estruturadas. Ninguém substitui a observação direta e a prática guiada. Documentação serve para referência rápida e padronização, não para transferência completa de expertise.
Método prático para começar
Se você quer colocar isso em funcionamento na sua equipe, o caminho mais enxuto que eu encontrei segue esses passos: Identifique as pessoas-chave. São aquelas que resolvem problemas que travam todo mundo. Geralmente são de três a cinco pessoas por área.
Marque sessões de gravação de sessão comentada. Cada sessão deve focar em um tipo específico de problema, não no trabalho geral. Quanto mais específico, melhor. Uma sessão de trinta minutos sobre resolução de erros de deploy rende mais do que duas horas de conversa vaga sobre a rotina da equipe. Na gravação, faça perguntas pontuais. "O que te levou a escolher essa abordagem?" "Que tipo de erro você esperava encontrar?" "O que você verificaria primeiro se isso acontecesse de novo?" Evite perguntas abertas demais.
Após a gravação, transforme os trechos mais densos em decisões condicionais. Não escreva parágrafos. Escreva fluxos simples. Se X, então Y. Distribua para a equipe e peça feedback dentro de quarenta e oito horas. A pessoa que foi entrevistada vai notar erros que você não viu. Corrija antes de publishar. Isso leva cerca de quinze minutos por sessão.
O processo completo, desde a identificação do especialista até a documentação final, leva em média cinco horas. Não é rápido, mas é muito mais eficiente do que tentar criar um manual geral que ninguém vai usar. Se você quiser uma ferramenta prática para organizar essas gravações e transformá-las em documentos, o Obsidian com a plugin de transcrição automática funciona razoavelmente bem para gravações de até quarenta minutos. Para sessões mais longas, o Descript tem uma interface mais amigável, mas o custo por minuto de transcrição sobe consideravelmente depois do plano gratuito.
O resultado final não vai substituir a experiência das pessoas. Mas vai reduzir o tempo de onboarding de quem entra na equipe em cerca de quarenta por cento, segundo dados que eu coletei em três projetos diferentes. Não é nada dramático. É apenas o que funciona quando se para de tentar transformar intuição em dogma e começa a tratar conhecimento como algo que precisa ser observado antes de ser documentado.
