Alguém do seu time abre um code review e pergunta por que aquele SQL tem que ser escrito daquele jeito. Você responde que é o padrão. A pessoa insiste e pergunta por quê. E você percebe que não sabe. A decisão foi tomada anos atrás por gente que já saiu da empresa, e o motivo se perdeu no caminho.
A partir daí seu time só tem dois caminhos: aceitar a decisão sem entender ou mudar cegamente. Os dois são ruins. É o mesmo problema daquele comentário no código dizendo para não remover a linha porque o sistema para de funcionar, e ninguém sabe dizer o porquê.
Essa aula trata documentação arquitetural como ferramenta de comunicação e alinhamento de propósito, não como processo pesado. Você sai com artefatos curtos, que cabem em uma folha, e que o time de negócio consegue ler.
O que você ganha com essa aula
- Aprende a resumir a arquitetura de um sistema inteiro em uma única folha A4, cobrindo objetivos de negócio, restrições e atributos de qualidade, e usa isso para alinhar time técnico e negócio na mesma conversa.
- Para de projetar para problemas que você não tem. Descobre como perguntar ao negócio quanto de escala ele realmente espera antes de desenhar uma arquitetura inteira em cima de escalabilidade.
- Passa a priorizar atributos de qualidade de verdade. Você decide o que vem primeiro entre disponibilidade, desempenho, confiabilidade e segurança, ao invés de dizer que tudo é importante.
- Registra o porquê das decisões de arquitetura para que a próxima pessoa que chegar entenda o contexto sem depender de quem estava lá.
- Sai do "isso aqui é muito bom" e passa a exigir prós e contras. Quando alguém do time propõe uma tecnologia nova, você tem a pergunta que revela o custo escondido.
- Ganha argumento para negociar com o negócio o tempo parado para atualizar framework e pagar dívida técnica, traduzindo isso em risco e custo ao invés de opinião técnica.
- Reduz o custo do onboarding. Você para de gastar o tempo de uma pessoa sênior explicando o mesmo sistema toda vez que alguém novo entra.
- Escolhe a notação visual certa para cada público, para que o desenho no quadro continue fazendo sentido dois dias depois.
Para quem é
Tech Leads, arquitetos e gestores de tecnologia que sentem o time tomando decisões desalinhadas. Quem herdou um sistema cheio de escolhas sem justificativa registrada. Quem precisa defender decisões técnicas diante da área de negócio. Quem sofre para fazer onboarding sem depender de um padrinho para cada pessoa nova.