Comunicação de Arquitetura
Visão Geral
A queixa mais comum de arquitetos sobre a organização é que "a diretoria não entende de tecnologia". O diagnóstico correto costuma ser o inverso: a mensagem foi entregue no eixo errado.
para engenheiros qual o desenho, quais as consequências técnicas
para produto o que isso permite ou impede, e quando
para diretoria que risco reduz, quanto custa, o que acontece
se não fizermos
para operação o que muda no plantão
para finanças qual o efeito na conta, e quando
A diferença entre essas versões não é de profundidade. É de eixo. A diretoria não precisa de um diagrama simplificado — ela precisa da mesma decisão expressa em risco e capacidade, com a mesma precisão.
Problema
O padrão que produz o fracasso:
o arquiteto prepara uma apresentação boa
ela descreve o problema técnico, a solução técnica e o desenho
a diretoria escuta, não faz perguntas, e não aprova
o arquiteto conclui que a organização não valoriza arquitetura
O que aconteceu: a apresentação respondeu a "qual é a arquitetura correta?", e quem estava na sala precisava responder a "isso vale o investimento, comparado às outras coisas que posso financiar?".
Nenhuma quantidade de rigor técnico responde à segunda pergunta. E simplificar o diagrama não ajuda — o problema não é complexidade, é irrelevância para a decisão em questão.
O erro simétrico: simplificar até perder a informação. Uma proposta reduzida a "precisamos modernizar" não permite avaliar nada, e quem escuta percebe que não há substância.
Conceitos Centrais
Altitude, não simplificação
altitude alta consequência para o negócio, risco, custo, prazo
altitude média capacidades, dependências, o que muda para quem
altitude baixa desenho, tecnologia, mecanismo
Uma mesma decisão existe nas três altitudes, com precisão total em cada uma. Subir de altitude não é remover detalhe — é mudar o que está sendo descrito.
baixa "vamos introduzir uma fila entre o pedido e a autorização
de pagamento, com caixa de saída transacional"
média "a criação de pedido deixa de depender da disponibilidade
do parceiro; o cliente passa a receber confirmação depois,
o que exige mudança na tela e no atendimento"
alta "hoje perdemos cerca de R$ 14 milhões por ano em vendas
durante indisponibilidades do parceiro. Esta mudança
elimina a maior parte disso, custa três meses de um time
e exige uma mudança de produto na tela de confirmação"
As três são verdadeiras e nenhuma é uma versão diluída das outras.
Comece pela consequência, não pelo contexto
Engenheiros são treinados a construir o argumento: contexto, análise, conclusão. Para públicos executivos, a ordem correta é inversa.
ordem de engenharia contexto → análise → proposta → pedido
ordem executiva pedido → razão → consequência de não fazer
→ detalhe sob demanda
A razão prática: quem escuta tem tempo limitado e vai decidir se quer ouvir mais. Entregar a conclusão primeiro permite que a conversa vá direto ao que interessa a quem decide, em vez de seguir o roteiro de quem apresenta.
Números em vez de adjetivos
fraco "o sistema atual é frágil e difícil de manter"
forte "tivemos 41 horas de indisponibilidade no último ano,
e o tempo entre pedido de mudança e produção é de
14 semanas"
Adjetivos são interpretáveis e descartáveis. Números são discutíveis, e uma discussão sobre números é uma conversa produtiva — ainda que ela conclua que o número está errado.
Nomeie o que acontece se nada for feito
Este é o elemento mais frequentemente ausente e o mais decisivo em conversas de investimento.
"se não fizermos nada, o custo de licença cresce 18% ao ano,
e as duas pessoas que sabem operar o sistema se aposentam
em 2028"
Sem isso, a proposta compete com outras propostas de investimento em igualdade. Com isso, ela compete com a alternativa de não fazer — que é a comparação real.
Fale a moeda de quem escuta
diretoria de negócio receita, risco, prazo de mercado
finanças custo, previsibilidade, contrato
operação plantão, incidentes, carga
produto capacidade, prazo, o que fica de fora
jurídico e compliance exposição, obrigação, prazo regulatório
engenharia desenho, trade-off, consequência técnica
Cada público tem uma unidade em que pensa. Traduzir para ela não é manipulação — é a condição para a informação ser utilizável por quem a recebe.
Escrever antes de apresentar
Um documento escrito força clareza que uma apresentação não força. Slides toleram lacunas de raciocínio que um parágrafo não tolera.
escrever primeiro expõe o argumento fraco antes da reunião
apresentar direto o argumento fraco aparece durante
E o documento tem uso posterior: ele é o que resta quando a reunião acaba, e o que as pessoas que não estavam lá vão ler.
O que não dizer também comunica
"não vou cobrir o custo operacional detalhado agora, mas ele
está no documento — o resumo é que aumenta em cerca de
R$ 40 mil por mês"
Sinalizar o que ficou de fora, com um resumo, é diferente de omitir. Omissões percebidas destroem credibilidade; omissões declaradas a constroem.
Modelo Mental
Mesma decisão, eixo diferente. Comece pela consequência, use números, e diga o que acontece se nada for feito.
Quando Usar
- Em qualquer comunicação de decisão arquitetural fora do time.
- Especialmente quando há investimento a aprovar.
- Sempre com o eixo escolhido a partir de quem escuta.
Quando Não Usar
Simplificando em vez de traduzir.
Começando pelo contexto com públicos executivos.
Com adjetivos onde há números disponíveis.
Sem dizer o que acontece se nada for feito.
Sem documento escrito para decisões relevantes.
Omitindo sem sinalizar.
Alternativas
- Documento em vez de apresentação — para decisões complexas, um texto lido antes da reunião rende mais que slides.
- Conversa individual antes — alinhar com cada interessado separadamente costuma ser mais eficaz que convencer um grupo.
- Demonstração — quando aplicável, mostrar funcionando vale mais que qualquer argumento.
A segunda é a mais subestimada: reuniões de decisão raramente mudam posições; elas confirmam posições formadas antes.
Trade-offs
| Detalhe técnico | Altitude alta |
|---|---|
| Precisão para quem constrói | Decisão para quem financia |
| Ilegível para executivos | Insuficiente para engenharia |
| Documento | Apresentação |
|---|---|
| Força clareza, persiste | Interativo, ajusta ao vivo |
| Exige que leiam | Tolera lacunas |
Modos de Falha
Eixo errado. Rigor técnico irrelevante para a decisão.
Simplificação. Perde substância sem ganhar relevância.
Adjetivos. Descartáveis.
Sem alternativa de não fazer. Compete no lugar errado.
Sem documento. Nada resta depois da reunião.
Omissão percebida. Destrói credibilidade.
Erros Comuns
Apresentar o diagrama a quem decide orçamento.
Construir o argumento em ordem de engenharia para públicos executivos.
Não quantificar o problema atual.
Não fazer as conversas individuais antes da reunião.
Achar que a organização não valoriza arquitetura, quando o problema é de tradução.
Exemplo Real
Uma empresa de varejo tinha uma proposta de modernização do sistema de estoque negada duas vezes pela diretoria. A área de arquitetura considerava a proposta obviamente correta.
A primeira apresentação, de 34 slides, cobria: arquitetura atual, problemas técnicos, arquitetura alvo, plano de migração, e riscos técnicos. A diretoria fez três perguntas e não aprovou.
A terceira tentativa foi reestruturada com ajuda da área financeira. Ela começou assim:
"Pedimos R$ 4,2 milhões e 14 meses para substituir o sistema
de estoque.
A razão: hoje perdemos cerca de R$ 9 milhões por ano em vendas
não realizadas por indisponibilidade e por ruptura falsa —
produto que existe na loja e o sistema não sabe. Esse número
vem do estudo que a área comercial fez em março.
Se não fizermos nada: o contrato do fornecedor reajusta 14% ao
ano, e o sistema não suporta a operação omnicanal que está no
plano de negócio para 2027. Sem ele, aquela iniciativa não
acontece.
O risco desta proposta é de execução. Detalho em seguida como
mitigamos, e o plano tem pontos de saída a cada fase."
Quatro parágrafos. Pedido, razão com número, consequência de não fazer, risco reconhecido.
A diretoria fez 22 perguntas e aprovou na mesma reunião. As perguntas foram sobre: a confiabilidade do número de R$ 9 milhões, os pontos de saída, quem operaria o sistema novo, e o que aconteceria com a equipe que mantém o atual.
Nenhuma pergunta foi sobre arquitetura.
O conteúdo técnico não mudou. A arquitetura alvo era a mesma das duas propostas negadas. O plano de migração era o mesmo. O que mudou foi o eixo e a ordem.
O número de R$ 9 milhões já existia. Ele estava num estudo da área comercial, e a área de arquitetura não o tinha usado porque não o considerava "argumento técnico".
A consequência de não fazer foi o elemento decisivo, segundo o próprio diretor: a conexão com a iniciativa de omnicanalidade transformou a proposta de "melhoria técnica" em "pré-requisito de uma aposta de negócio já aprovada".
Os 34 slides viraram anexo. Eles continuaram existindo e foram usados nas conversas com engenharia — no eixo certo, para o público certo.
A prática que ficou: toda proposta acima de um limite passou a exigir três versões — uma de uma página para diretoria, uma de duas para produto e operação, e o documento técnico completo. E a regra de que o número que quantifica o problema precisa vir de uma área que não seja engenharia, para não ser lido como interesse próprio.
Conceitos Relacionados
Exercício Prático
Pegue uma proposta arquitetural sua e escreva-a em quatro parágrafos: o pedido, a razão com número, o que acontece se nada for feito, e o risco reconhecido.
Se você não tiver o número, essa é a lacuna — e ela provavelmente é a razão de a proposta não ter avançado.
Perguntas de Entrevista
- Qual a diferença entre simplificar e mudar de altitude?
- Por que a ordem de apresentação para executivos é inversa à de engenharia?
- Por que "o que acontece se nada for feito" é o elemento mais decisivo?
Para Aprofundar
- Hohpe, Gregor. The Software Architect Elevator. O'Reilly, 2020.
- Minto, Barbara. The Pyramid Principle. Pearson, 2009.
- Larson, Will. Staff Engineer. Publicação do autor, 2021.