Há uma pergunta que faço com muita frequência quando uma equipe me apresenta uma solução:

Por que fizemos dessa forma?

Não pergunto esperando uma resposta específica, nem porque acredito que necessariamente exista uma solução melhor. Quero entender a decisão. E há uma resposta que aparece com bastante frequência:

“Porque já estava feito assim.”

É nesse momento que costumo parar.

Não porque a decisão esteja necessariamente errada, mas porque deixamos de falar de uma decisão e começamos a falar de uma herança.

Toda decisão já teve um contexto

Por trás de praticamente qualquer sistema existe uma história. Talvez fosse necessário lançar rapidamente, a equipe fosse muito menor, determinada tecnologia fosse a única disponível ou um cliente precisasse de uma solução urgente. Talvez alguém simplesmente tenha tomado uma decisão razoável com as informações disponíveis naquele momento.

O problema não é herdar decisões.

É herdá-las sem herdar também as razões que levaram a elas. Porque o contexto pode ter mudado completamente enquanto a solução permaneceu igual.

A resposta que eu gostaria de ouvir

Quando pergunto por que fazemos algo de determinada maneira, não espero necessariamente uma longa explicação técnica. Uma resposta como esta me parece muito mais valiosa:

“Tomamos essa decisão por estas razões. Essas condições continuam válidas. E, se alguma delas mudar, devemos revisá-la.”

Existem três elementos muito importantes nessa resposta:

  1. Razões: sabemos por que a decisão foi tomada.
  2. Premissas: sabemos quais condições fazem com que ela continue fazendo sentido.
  3. Gatilhos: sabemos o que precisaria mudar para que a decisão fosse reavaliada.

Isso transforma uma decisão herdada em uma decisão que ainda conseguimos explicar.

Mas surge outro problema.

Onde guardamos essa explicação?

Decisões também precisam de memória

Se a justificativa de uma decisão existe apenas na cabeça de quem a tomou, mais cedo ou mais tarde vamos perdê-la. Essa pessoa pode mudar de equipe, assumir outra função ou sair da empresa. Meses depois, alguém encontrará a solução, perguntará por que ela funciona daquela maneira e receberá uma resposta perfeitamente honesta:

“Porque já estava feito assim.”

Uma ferramenta simples para evitar isso são os Architecture Decision Records (ADRs). Eles não precisam ser documentos enormes. Para muitas decisões, pode ser suficiente registrar:

  • qual problema estávamos tentando resolver;
  • qual decisão tomamos;
  • quais alternativas avaliamos;
  • quais eram as principais premissas;
  • e quais condições deveriam nos levar a revisar a decisão.

Na prática, a resposta que eu gostaria de ouvir de uma equipe é praticamente um ADR resumido:

Tomamos esta decisão por estas razões, sob estas premissas, e sabemos o que precisaria mudar para revisá-la.

Documentar decisões não elimina decisões ruins. Evita algo diferente: que percamos o contexto tanto das boas quanto das ruins.

A forma de perguntar também importa

Aprendi algo ao longo do tempo: quando a pergunta “Por que vocês fizeram dessa forma?” vem de um CTO ou de qualquer pessoa em posição de liderança, ela pode não soar como curiosidade.

Pode soar como uma auditoria.

Por isso, tanto a intenção quanto a forma de perguntar são importantes.

Em vez de:

“Por que você fez isso assim?”

prefiro algo como:

“Qual problema precisávamos resolver quando essa decisão foi tomada?”

Também costumo deixar clara minha intenção desde o início:

“Não estou dizendo que precisamos mudar. Quero entender por que está assim.”

E, sempre que possível, prefiro que essas conversas aconteçam com a equipe, e não como um interrogatório individual. O objetivo não é encontrar quem foi responsável pela decisão. É reconstruir o contexto que tornou aquela decisão razoável — ou descobrir que ela deixou de ser.

Dar alguns passos para trás

Quando uma equipe está desenvolvendo uma funcionalidade, naturalmente se concentra em resolver o problema que está à sua frente. E isso é necessário. Mas muitas vezes vejo valor em dar alguns passos para trás e observar o problema como um todo. Se estamos adicionando uma nova condição a um processo, por exemplo, podemos simplesmente adicionar outro if.

O primeiro if pode ser exatamente a solução correta. O segundo talvez seja uma coincidência. Mas, quando aparece o terceiro, vale a pena perguntar se realmente estamos diante de exceções ou se descobrimos que aquilo que codificamos como regra deveria ser um dado ou uma configuração.

Também existe o erro oposto.

Criar uma abstração genérica quando aparece o primeiro if pode ser igualmente caro. Podemos acabar construindo uma plataforma para resolver problemas que nunca existirão. Portanto, não se trata de sempre abstrair. Trata-se de reconhecer quando o problema deixou de ser excepcional.

Questionar não significa mudar

Essa distinção é fundamental.

Quando pergunto por que algo funciona de determinada maneira, não estou dizendo que precisa ser modificado. Muitas vezes questionei uma solução, analisamos juntos e chegamos exatamente à mesma conclusão:

está boa como está.

Isso é saudável.

Se algo funciona, não gera custos desproporcionais, não introduz riscos relevantes e continua atendendo às necessidades do negócio, mudá-lo pode ser um péssimo uso de recursos. O objetivo não é criar uma cultura em que tudo esteja permanentemente em discussão. O objetivo é criar uma cultura em que as decisões possam ser explicadas e questionadas quando necessário.

Em outro artigo, explorei uma questão relacionada: como determinar quando o custo de não mudar começa a superar o custo da mudança. Aqui me interessa algo anterior a esse cálculo.

Saber qual decisão estamos avaliando e por que ela existe.

Reutilização não significa projetar todos os futuros possíveis

Quando pergunto às equipes se algo pode ser feito de forma mais reutilizável, não estou propondo construir uma plataforma capaz de resolver todos os problemas que talvez apareçam nos próximos dez anos. Isso seria outra forma de desperdício. O objetivo é identificar quando já temos informações suficientes para saber que determinadas condições provavelmente mudarão.

Existe uma diferença importante entre:

projetar para todos os futuros possíveis

e

não fechar desnecessariamente as possibilidades futuras.

A segunda me interessa muito mais.

Uma boa decisão tecnológica não precisa antecipar tudo o que acontecerá. Mas deveria evitar que uma escolha desnecessariamente rígida transforme cada mudança futura em uma reconstrução.

A liderança também precisa poder ser questionada

Questionar tem outra consequência: às vezes estamos errados. Isso já aconteceu comigo muitas vezes. Estar em uma posição de liderança não significa que nossas perguntas sejam automaticamente melhores, nem que precisemos encontrar algo para mudar toda vez que revisamos uma solução.

Se, depois da discussão, a equipe demonstra que a decisão faz sentido, existe uma resposta perfeitamente válida:

“Você tem razão.”

Se queremos equipes capazes de questionar decisões, a primeira pessoa que precisa estar disposta a ser questionada é quem lidera. Caso contrário, não estamos criando pensamento crítico. Estamos substituindo uma resposta automática:

“Sempre fizemos assim.”

por outra:

“Fazemos assim porque o CTO disse.”

E não melhoramos nada.

A IA pode tornar esse problema ainda mais importante

Desde 2014, o DORA estuda como capacidades técnicas, processos e cultura afetam o desempenho das organizações de software. O State of AI-assisted Software Development 2025, baseado em quase 5.000 profissionais de tecnologia, apresenta uma ideia que considero particularmente interessante: a IA funciona como um amplificador.

Ela não necessariamente corrige o sistema no qual é introduzida.

Ela amplifica o que já existe.

Segundo o DORA, a adoção de IA entre profissionais de desenvolvimento chegou a 90% em 2025. A pesquisa encontrou melhorias em throughput, mas também aumento na instabilidade das entregas. Isso torna a discussão sobre decisões herdadas ainda mais relevante. Pense em uma instrução extremamente comum para uma ferramenta de desenvolvimento assistida por IA:

“Siga os padrões existentes neste repositório.”

É uma instrução razoável.

Mas, se ninguém se lembra por que esses padrões existem, acabamos de criar uma ferramenta extraordinariamente eficiente para reproduzi-los. Uma decisão que antes era copiada por algumas pessoas agora pode se propagar muito mais rapidamente.

A IA pode acelerar boas práticas.

Também pode industrializar decisões que ninguém voltou a questionar.

Sistemas fortes não dependem de respostas históricas

Uma boa organização de tecnologia não é aquela que sempre tomou as decisões certas.

Isso é impossível.

É aquela que preserva a capacidade de explicar por que tomou suas decisões, entender as premissas que as sustentam e revisá-las quando essas premissas deixam de ser válidas.

Por isso, talvez o problema com:

“Sempre fizemos assim”

não seja o fato de a decisão ser antiga. O problema é que perdemos o original e ficamos apenas com a cópia. Na próxima vez que alguém perguntar:

“Por que fazemos dessa forma?”

eu gostaria que conseguíssemos responder:

“Tomamos essa decisão por estas razões. Essas condições continuam válidas. E, se alguma delas mudar, vamos revisá-la.”

Não precisamos ter todas as respostas. Mas deveríamos tentar preservar as razões por trás das nossas decisões. Porque construir uma organização capaz de mudar começa com algo bastante simples:

continuar sabendo por que fazemos o que fazemos.

Fontes e leituras