A luz azul do monitor é a última coisa acesa. Seis e quarenta da tarde. O prédio já está quieto. Fico olhando o diagrama que desenhei para a reunião das 10h de amanhã, o checkpoint trimestral. É um inferno silencioso tentar encaixar três meses de refatoração de infraestrutura em uma folha A4 com caixas coloridas. Eles não vão querer saber do eventual consistency ou da latência que conseguimos cortar na API de pagamentos.
O problema não é o que eles não sabem. O problema é o que eles acham que precisam saber.
O tempo todo, as perguntas são as mesmas, só mudam as palavras. “Isso vai acelerar a entrega do roadmap?” “Qual a garantia de que não vamos quebrar no próximo Black Friday?” E, claro, a rainha de todas: “Qual é o ROI disso?”
A gente se afunda no detalhe. Quer mostrar que a mudança de framework resolveu aquele bug silencioso que derrubava a integração com o parceiro a cada 15 dias, um bug que só aparecia em produção sob carga. Queremos o reconhecimento de que, sim, tiramos o sistema do respirador. Mas é como tentar explicar o ruído branco para alguém que só se preocupa se o fone de ouvido funciona.
Tradução Cansada
Eu me pego desenhando setas e caixas que, na verdade, são atalhos. Não estou explicando a arquitetura; estou traduzindo consequências de negócio. O diagrama de amanhã não é sobre Microservices vs. Monolith; é sobre Risco e Custo Operacional.
Na última vez, tentei mostrar a curva de desempenho. Milissegundos a menos. A VP de Produto balançou a cabeça, mas o olhar estava vazio. Aquele silêncio não era de desinteresse, era de desentendimento. O que ficou de verdade, o que a fez anotar, foi quando eu disse: “Com essa mudança, a nova feature de personalização que você quer pode ser lançada sem a necessidade de comprarmos mais $10.000 em licenças de cache ou mais dois servidores, e a manutenção do código vai cair pela metade.”
Sem licenças. Manutenção pela metade. Lançamento sem custo extra.
A arquitetura se tornou uma forma indireta de falar sobre o saldo da conta. Não é sobre o quão elegante é o nosso código; é sobre o quão barato ele se torna de rodar e manter, e o quão rápido ele permite que a empresa ganhe dinheiro com a próxima ideia.
É exaustivo, porque o raciocínio é invertido. A gente pensa: “Como essa tecnologia resolve o problema técnico?” E precisa apresentar: “Qual problema de dinheiro essa tecnologia evita?”
O Custo da Falha Silenciosa
O pior é quando a gente tenta antecipar a falha. A famosa dívida técnica. Quando tentamos explicar que, se não refatorarmos agora, em seis meses o deploy que hoje leva 20 minutos pode levar duas horas, e vai ser sempre às 2 da manhã de uma sexta-feira.
O executivo não vê o deploy lento. Ele vê um alerta no Slack que o time de tecnologia resolveu antes que virasse crise. Ele só contabiliza o incidente que causa parada nas vendas. Tudo que fica abaixo do radar é custo.
É frustrante porque somos pagos para enxergar o risco antes que ele vire um problema de caixa. Mas a nossa métrica de sucesso é invisível. É a falha que não aconteceu. Como provar o valor de algo que você impediu de existir? O ROI de evitar um desastre é sempre nebuloso, uma estimativa negativa.
Eu gasto 70% do tempo de preparação da reunião de amanhã não com o diagrama de fluxo, mas com a tabela de economia projetada.
$30k/ano economizados em infra. $15k em horas de debugging que foram eliminadas. Time-to-market reduzido em 10 dias para a próxima versão.
Eu nem me importo mais em falar sobre escalabilidade de verdade. Uso “Escalabilidade” como um sinônimo para: “Não vamos ter que ligar para você às 3 da manhã quando o site cair, o que custa $X de vendas perdidas por hora.”
É um jogo de espelhos. A gente projeta a complexidade técnica na linguagem da simplicidade financeira. É quase uma admissão de que o nosso valor intrínseco de engenharia é inegociável, então a gente só negocia os benefícios colaterais.
Acredito que, no fundo, eles reconhecem que há uma complexidade. Eles sabem que não é mágica. Mas é a mesma coisa que eu pensar na conta de luz. Eu sei que há uma rede de distribuição complexa, usinas, manutenções, perdas… Mas na hora de pagar, só olho o número final e pergunto: “Está caro ou barato?”
É o fim do dia e o diagrama de amanhã está pronto. Não é o diagrama que eu queria desenhar, cheio de nuances e escolhas elegantes. É um diagrama de custos. Setas vermelhas para “Custo Evitado” e setas verdes para “Receita Acelerada”.
É o único idioma que parece gerar clareza naquelas reuniões. E a clareza, mesmo que seja sobre dinheiro, evita o pior: aquele silêncio de que a gente não está falando a mesma língua, que sempre dá margem para interpretações tortas, como desinteresse ou incapacidade de comunicação.
Eu apago o monitor. O que me faz pensar: o quanto dessa clareza é de fato sobre o que fizemos e o quanto é sobre as habilidades que usamos para vender essa ideia? Quer dizer, se a gente tem que ser tão bom em quantificar o ganho e evitar o custo, talvez o investimento mais crucial já não seja mais em code ou cloud, mas nas formas de transformar a nossa cabeça para falar essa língua. Mas aí, como é que se calcula o ROI de uma coisa dessas? É um número ainda mais escorregadio.
