Decisões que ficam anos, tomadas em semanas

Toda decisão de arquitetura é tomada com menos informação do que se gostaria. Isso não é falha de processo — é a condição do trabalho. A informação que faltava só aparece depois de conviver com a escolha.

O que dá para melhorar não é a quantidade de informação. É saber quais decisões merecem demora.

Duas categorias, não uma

Existem decisões que se desfazem em uma tarde. Trocar uma biblioteca de formatação de data, mudar a estrutura de uma pasta, renomear um endpoint interno. Se estiver errado, corrige.

E existem decisões que ficam. O modelo de dados. O limite entre serviços. O contrato público de uma API. O provedor de identidade. A escolha entre síncrono e assíncrono num fluxo central.

Essas você não desfaz — você convive, ou paga um projeto inteiro para sair.

O erro mais comum não é decidir errado. É tratar as duas categorias com o mesmo cuidado. Times que discutem uma semana sobre nome de variável costumam ser os mesmos que escolhem o modelo de dados numa reunião de meia hora.

O critério prático

Antes de abrir a discussão, uma pergunta:

Se isso estiver errado em seis meses, quanto custa mudar?

Se a resposta for "algumas horas", decida rápido e siga. Errar é mais barato que deliberar.

Se a resposta for "um trimestre e a confiança de quem consome", vale trazer mais gente, escrever o porquê, e considerar as alternativas que você já descartou mentalmente.

Escreva o porquê, não só o quê

O código mostra o que foi decidido. Ele não mostra o que foi considerado e descartado — e é essa parte que some.

Dois anos depois, alguém encontra uma solução que parece obviamente melhor. Às vezes é. Às vezes é a alternativa que já foi tentada e falhou por um motivo que ninguém registrou.

Um parágrafo curto — o problema, as opções, o que pesou — economiza semanas depois. Não precisa ser documento formal. Precisa existir.

O que a experiência muda

Não é acertar mais. É reconhecer a categoria mais cedo.

Depois de ver o mesmo tipo de escolha algumas vezes, dá para sentir quando uma decisão vai encostar em todo o resto do sistema. É esse reconhecimento que permite gastar tempo onde ele rende, e decidir rápido no resto.