Como aplicar o princípio de só sei que nada sei na prática profissional
O princípio de só sei que nada sei está longe de ser apenas uma citação bonita para colocar no currículo. Na prática, ele funciona como um mecanismo de defesa contra overconfidence em projetos técnicos. A maioria dos problemas aparece quando alguém assume que já sabe o suficiente para tomar uma decisão sem validar as premissas.
Por que o só sei que nada sei funciona (quando funciona)
Em ambientes de desenvolvimento ou arquitetura de sistemas, a primeira versão quase sempre esconde uma premissa errada. A questão é descobrir qual. Eu já passei por um caso em que uma equipe inteira construiu uma camada de caching inteira sobre uma suposição de que certos dados seriam acessados com frequência alta. Depois de três semanas de trabalho, descobrimos que a consulta chave era usada menos de duas vezes por semana. O cached estava mais caro do que a operação original. Aplicar o tão falado princípio de que só sei que nada sei no início teria pego isso em dois dias, com uma investigação mínima. O funcionamento real é simples: você lista explicitamente tudo o que acha que sabe sobre o problema antes de escrever qualquer código ou tomar qualquer decisão estrutural. Isso inclui premissas sobre comportamento do usuário, constraints de performance, integrações com sistemas externos, e edge cases que você imagina serem improváveis. A lista fica visível para todo o time e pode ser questionada.
O método que uso atualmente
Antes de começar qualquer entrega com prazo acima de uma semana, eu peço para o time preencher um documento com três seções. A primeira é "O que sabemos". Aqui entram dados concretos, métricas existentes, documentação técnica. Nada de suposições. A segunda seção é "O que achamos que sabemos". É exatamente o que parece: inferências, estimativas, analogias com outros projetos. A terceira é "O que não sabemos". Essa é a mais importante e a mais ignorada. Eu costumo levar uns quinze minutos para fazer esse exercício em projetos pequenos. Em projetos maiores, como o de caching que citei, levou cerca de duas horas e meia. O resultado foi que identificamos seis premissas que estavam na seção "achamos que sabemos" e que não tinham nenhuma base real. Cinco delas estavam erradas. Uma não conseguimos validar nem invalidar na época, e se mostrou problemática três meses depois, quando tivemos um pico de tráfego inesperado.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Existe um detalhe prático que poucas pessoas levam em conta: a seção "o que não sabemos" nunca termina. Você sempre descobre novas lacunas conforme avança. O importante não é preencher tudo, é ter consciência do que falta saber. Quando o documento vira uma mera formalidade, o exercício perde o valor. Nesse ponto, eu costumo sugerir parar e relançar a discussão com outra perspectiva, trazendo alguém que não esteja envolvido no projeto para revisar as premissas.
Onde esse abordagem falha
O método não serve para tudo. Em situações de resposta a incidentes críticas, onde cada minuto conta e você precisa decidir com informação incompleta, passar meia hora listando premissas é contraproducente. Nesses casos, a experiência acumulada e a intuição treinada funcionam melhor. O problema é que intuição treinada é diferente de achismo disfarçado. A diferença é que você consegue rastrear a origem de uma decisão baseada em intuição até padrões que você viu antes. Se não consegue, você provavelmente está no terreno da suposição non validated. Outro ponto fraco: times muito novos ou juniores tendem a usar o exercício como forma de procrastinação. Já vi casos em que o documento de premissas crescia até ficar irrelevante, com entradas genéricas e redundantes, sem que ninguém questionasse. A solução mais prática que encontrei foi limitar o documento a uma página e exigir que cada item da seção "o que achamos que sabemos" tenha pelo menos uma fonte, mesmo que seja "conversamos com o Carlos que trabalhou nisso no projeto X". Sem fonte, o item cai para a seção "o que não sabemos".
Alternativas quando o método pesado não cabe
Em contextos ágeis com sprints curtos, o documento completo não se encaixa. Nesse cenário, eu substituo por uma conversa de dez minutos no início do sprint, de pé, em frente ao quadro branco. Cada pessoa fala três coisas que acha que sabe sobre o problema e três coisas que teme não saber. Anota-se tudo. No final do sprint, revisa-se o que era verdade e o que era suposição. Esse ciclo rápido de feedback é mais eficiente do que o documento formal em muitos casos, especialmente quando a incerteza está mais ligada a requisitos do que a complexidade técnica. A versão light do só sei que nada sei também funciona bem para reviews de código. Em vez de apenas aprovar ou reprovar uma implementação, a pergunta direta "o que você não tem certeza sobre essa abordagem?" costuma revelar gaps que passeriam despercebidos. Eu faço isso de forma consistente há cerca de quatro anos e notei que a taxa de retrabalho pós-merge caiu significativamente após adotar esse hábito como rotina.
Não existe ferramenta automática que replique esse processo. Ele depende de disciplina individual e de uma cultura que permita admitir ignorância sem punição. Em ambientes onde errar é estigmatizado, o exercício vira teatro. As pessoas preenchem o que acham que o gestor quer ouvir, não o que realmente pensam. Nesse caso, o método é pior do que inútil, porque dá uma falsa sensação de segurança. Se o seu contexto não permite honestidade intelectual básica, considere focar em mecanismos de validação mais concretos antes de confiar em listas de premissas. Protótipos rápidos, provas de conceito com métricas reais, e canary releases são formas mais resistentes a viés cognitivo do que documentos bem preenchidos.
