O PIOR PROJETO NÃO É O MAL ARQUITETADO.
É o que o cliente não viu valor.
————————————————————————————————————————
Eu já vi projeto tecnicamente impecável morrer.
Arquitetura limpa, testes bem escritos, deploy automatizado, código que qualquer dev abriria e diria "isso aqui foi feito por gente que sabe o que está fazendo". E mesmo assim, o cliente não renovou. Achou que tinha sido enganado, que pagou caro por nada, que o time não entregou.
E o pior: ele não estava completamente errado.
Esse é o tipo de história que ninguém conta nas conferências de tech. A gente fala de stack, de microsserviços, de design patterns, de boas práticas. Mas raramente fala desse buraco invisível entre o que o dev entrega e o que o cliente percebe que recebeu ou até mesmo casos onde o cliente pede algo que não vai resolver o problema dele. E é nesse buraco que projetos morrem.
Esse texto é sobre os 5 sintomas mais comuns desse desalinhamento.
————————————————————————————————————————
SINTOMA 01. A REUNIÃO DE PROGRESSO VAZIA.
Você passou a semana inteira refatorando. Limpou aquele módulo de auth que estava virando uma bola de neve, simplificou três classes que ninguém entendia, deixou o código pronto pra escalar.
Aí chega a reunião de status na sexta. O cliente pergunta: "o que foi feito essa semana?".
Você começa a explicar e percebe, no meio da frase, que do ponto de vista dele, nada foi feito. Nenhuma tela nova, nenhum botão diferente, nenhum recurso visível.
E ele não está sendo injusto. Ele tá olhando o produto pelos olhos dele, que é o único par de olhos que ele tem. Pra ele, o produto não andou.
A questão não é se a refatoração era necessária (talvez fosse). A questão é que você não preparou o terreno pra que o trabalho dessa semana fosse legível pra quem paga. Você fez um trabalho importante de forma silenciosa, e silêncio em projeto de cliente é quase sempre interpretado como ausência.
Não tem solução elegante pra isso, infelizmente. A solução é boba: fala. Antes da semana começar, fala. No meio, fala. Na sexta, fala de novo. "Essa semana eu vou mexer em coisa que você não vai ver, mas que reduz X risco e me permite entregar Y mais rápido nas próximas". O cliente que entende isso (a maioria entende, se você explicar) para de cobrar visibilidade onde não vai ter.
Uma das principais habilidades na minha visão é o alinhamento de expectativas.
————————————————————————————————————————
SINTOMA 02. O ORGULHO TÉCNICO INVISÍVEL.
Esse aqui é traiçoeiro porque vem disfarçado de produtividade.
Você descobriu que tinha uma query rodando em 800ms num endpoint crítico. Estudou o problema, criou índice, reescreveu, fez benchmark. Conseguiu derrubar pra 80ms. Dez vezes mais rápido. É um trabalho sólido, daqueles que você conta empolgado pra outro dev e ele entende a beleza da coisa.
Você manda pro cliente.
Silêncio.
Talvez ele responda "legal". Talvez nem isso.
E aí você sente aquela frustração específica, aquela coisa de "eu acabei de fazer um trabalho técnico relevante e ninguém percebeu". É legítima a frustração. Mas a leitura precisa ser outra.
Pro cliente, a query não existia. Ele nunca soube que ela rodava em 800ms, então não tem como ele se animar de virar pra 80ms. Pra ele, o produto continuou funcionando como antes. Pra ele, você gastou tempo (e dinheiro dele) numa coisa que ele não percebe.
Outra vez: o problema não é que você fez. O problema é que você fez sem traduzir.
A diferença entre dizer "otimizei a query" e dizer "antes desse ajuste o sistema travava em picos de acesso, agora aguenta 10x mais usuários simultâneos sem cair" é a mesma diferença entre o cliente achar que você gastou tempo dele e o cliente achar que você protegeu o negócio dele.
A engenharia foi a mesma. A percepção? Completamente diferente.
————————————————————————————————————————
SINTOMA 03. O PROTÓTIPO "FEIO" QUE VENDEU.
Esse eu aprendi na marra, e dói toda vez que eu sento e me sinto fazendo o projeto “ao contrário”.
Pega dois desenvolvedores. Um passa duas semanas construindo um backend sólido, com autenticação, banco bem modelado, endpoints documentados, tudo nos conformes. Não tem frontend ainda, é tudo Postman. O outro abre o Figma, monta um mockup tosco em três horas, com botões clicáveis, fluxo simulado, dados mockados. Sem nenhum código real por trás.
Adivinha qual dos dois consegue mostrar pro cliente e fechar a próxima fase?
O do mockup. Sempre.
E não é injustiça. Se o cliente tivesse o mesmo conhecimento que nós temos, ele faria o projeto. O cliente geralmente não tem imaginação para ver as telas funcionando, ele tem um problema que quer resolver, ele se relaciona com tela, com clique, com o produto sendo o produto. Quando ele vê o mockup, mesmo sabendo que é falso, ele consegue imaginar o produto pronto. E imaginar o produto pronto é o que faz ele decidir continuar pagando.
Isso não significa que arquitetura é dispensável. Significa que arquitetura é fundação, e fundação não vende casa. Foto da casa pronta é o que vende.
A consequência prática disso é importante: em todo projeto, especialmente nos primeiros estágios, vale gastar uma fração do tempo em algo visível, mesmo que tosco, mesmo que mockado. Não pra enganar o cliente. Pra dar a ele um lugar de onde ele consiga acompanhar o que está sendo construído. Sem esse lugar, ele só consegue acompanhar boletos saindo da conta.
————————————————————————————————————————
SINTOMA 04. TRADUZIR É PARTE DO TRABALHO.
Eu costumava achar que comunicar progresso era responsabilidade do PM, do product owner, do gerente de conta. Trabalho de "área de negócio". O dev escreve código, alguém traduz pro cliente.
Hoje eu acho que essa divisão é um dos maiores buracos da nossa profissão.
Quando o dev escreve "refatorei o módulo de auth e implementei rate limiting", ele acha que comunicou. Não comunicou. Mandou um relatório técnico pra alguém que não fala a língua técnica. É como mandar um e-mail em alemão pra alguém que só fala português. A informação está lá, mas não chegou.
Compara com: "reduzi o risco de cair o login na Black Friday e bloqueei tentativas automatizadas que podiam derrubar o sistema". Mesma engenharia. Comunicação completamente diferente.
E aqui tem uma coisa que muito dev não enxerga: traduzir e simplificar não é desvalorizar o que foi feito. Não é "fingir que o cliente não é inteligente". É reconhecer que cada profissional vive num conjunto diferente de preocupações, e a sua função, como pessoa contratada pra resolver um problema, inclui apresentar a solução numa linguagem que se conecta com as preocupações de quem te contratou.
Isso não é marketing. É engenharia. Engenharia inclui o usuário final do que você produz, e nesse caso o usuário do seu trabalho de comunicação é o cliente.
Bom dev escreve bom código. Ótimo dev escreve bom código e sabe contar pro cliente, com palavras que ele entende, por que aquele código importa.
————————————————————————————————————————
SINTOMA 05. OS DOIS CLIENTES INVISÍVEIS.
Esse é o sintoma mais conceitual da lista, mas é o que organiza todos os outros.
Todo projeto tem dois clientes simultâneos.
O primeiro é o óbvio: a pessoa ou empresa que paga. Ela quer ver progresso, quer enxergar entregas, quer sentir que o investimento está rendendo. Esse cliente vive no curto prazo, no que está visível, no que pode mostrar pra equipe dele.
O segundo é menos óbvio: o sistema em si. O código, a arquitetura, a fundação que vai sustentar tudo nos próximos anos. Esse cliente também tem demandas: precisa de testes, precisa de refatoração, precisa de documentação, precisa de escolhas que talvez não tragam valor visível imediato, mas evitam catástrofes três anos depois.
O dev mediano só serve um deles. Ou o dev "produtivo" que entrega tela atrás de tela e deixa o sistema virar uma bomba relógio. Ou o dev "perfeccionista" que arquiteta lindamente e nunca tem nada pra mostrar.
O dev que faz a diferença serve os dois, na ordem certa, com consciência da tensão entre eles. Ele entrega valor visível pro cliente que paga, com cadência, sem deixar a percepção morrer. E paralelamente cuida do sistema, faz as escolhas certas de fundação, refatora quando precisa, escreve teste quando faz sentido. E quando uma dessas atividades é "invisível" pro cliente, ele traduz, comunica, cria visibilidade onde não tem naturalmente.
Não é fácil. É o equilíbrio mais difícil da carreira de engenharia. Mas é exatamente esse equilíbrio que separa quem fica e quem é trocado.
————————————————————————————————————————
JUNTANDO TUDO.
Os cinco sintomas são, no fundo, manifestações do mesmo problema: a engenharia foi feita, mas a tradução não.
E aqui é onde mora a parte que mais incomoda dizer: a tradução é responsabilidade sua. Mesmo que tenha PM, mesmo que tenha gerente de conta, mesmo que tenha alguém intermediário entre você e o cliente. Você é a pessoa que fez o trabalho. Você é a única pessoa que sabe exatamente o que foi feito, por que foi feito, e por que importa. Se você não traduz, ou traduz mal, sempre vai sobrar buraco entre o que foi entregue e o que foi percebido.
Bom dev pensa nisso o tempo todo. Não como afterthought, não como "depois eu vejo se o cliente entendeu". Como parte da entrega. A entrega só está completa quando o cliente percebeu o valor do que foi feito.
A pergunta não é "você entrega bom código?". A pergunta é:
» Você entrega de um jeito que o cliente percebe o valor?
————————————————————————————————————————
Se você chegou até aqui, manda esse texto pra um dev que precisa ler. A maior parte da carreira de quem programa não é definida pela qualidade do código que escreve. É definida pela qualidade da relação que constrói com quem precisa do código. E essa parte ninguém ensina na faculdade.