Há uma cena que se repete em quase toda empresa de tecnologia: alguém recebe uma tarefa, abre o editor e começa a digitar antes de terminar de entender o problema. Duas semanas depois, o time descobre que construiu a coisa errada — com perfeição técnica. Este texto é sobre o profissional que faz o oposto.
Existe um mito silencioso na engenharia de software: o de que o valor de um profissional se mede pela velocidade com que ele produz código. É um mito confortável, porque código é visível, mensurável, versionável. Conversa não aparece no git blame.
Mas observe qualquer engenheiro sênior de verdade em ação — não o que tem mais anos de casa, mas o que as empresas disputam a peso de ouro — e você vai notar um padrão contraintuitivo: ele passa uma fração desproporcional do tempo perguntando, parafraseando, desenhando no quadro, discordando educadamente, até então abrir o editor. E quando abre, escreve rápido, porque já sabe exatamente o que está construindo e por quê.
O código é o efeito, não a causa
O que diferencia esse perfil não é talento de digitação. É que ele enxerga o fluxo de valor de ponta a ponta — do problema de negócio até o resultado que o usuário sente — e trata o código como um meio para chegar lá, não como o objetivo em si. Isso muda a ordem das operações: primeiro alinhar o que é valioso e por quê, depois desenhar o caminho técnico, só então escrever.
“Bons programadores escrevem código que os humanos conseguem entender.”
Martin Fowler — Refactoring: Improving the Design of Existing Code
Fowler escreveu isso pensando em legibilidade de código, mas a ideia vale um passo antes: escrever para ser entendido também é o que se faz numa conversa de alinhamento. Quem só escreve para a máquina compilar tende a pular a etapa de escrever — falado ou em texto — para as pessoas entenderem.
A pergunta que todo mundo já fez
Se conversar não gera commits, por que isso deveria contar como trabalho de verdade?
Porque comunicação malfeita é o maior gerador de retrabalho que existe — e retrabalho é código também, só que descartado. Frederick Brooks, arquiteto de software do IBM System/360 e autor de The Mythical Man-Month, mostrou que projetos grandes não falham por falta de gente digitando: falham porque o custo de coordenação cresce mais rápido que o número de pessoas. Ele chamou de “conceitual integrity” a ideia de que um sistema bom precisa vir de poucas mentes alinhadas — não porque comitês são burros, mas porque cada nova pessoa multiplica os caminhos de comunicação necessários para todo mundo entender a mesma coisa.
Na visão dele, publicada em 1975 e ainda citada hoje, “conceptual integrity is the most important consideration in system design” — a integridade conceitual é a consideração mais importante no design de um sistema. Conversa é como essa integridade se propaga entre pessoas antes de virar código.
O preço do mal-entendido
Barry Boehm estudou projetos reais na TRW e na IBM e chegou a uma conclusão que hoje parece óbvia mas continua sendo ignorada na prática: um mal-entendido descoberto na fase de requisitos custa uma fração do que custa descobri-lo depois do sistema estar em produção — em análises citadas por engenheiros da NASA, essa diferença chega à ordem de cem vezes. A curva ficou menos exponencial com práticas modernas de entrega contínua, mas a direção da seta nunca mudou: quanto antes você entende errado, mais barato é corrigir.
Kent Beck, criador do Extreme Programming, levou essa ideia a sério de um jeito diferente: em vez de tentar acertar tudo de uma vez no papel, ele propôs achatar a curva com ciclos de feedback curtíssimos — testes antes do código, integração constante, conversas frequentes no lugar de documentos grossos escritos uma única vez. A lição comum aos dois: o problema nunca foi documentar demais ou de menos, foi quando você descobre que entendeu errado.
“...é sempre um problema de pessoas.” - Kent Beck — Extreme Programming Explained
Beck escreveu isso sobre um contexto específico — não importa o que o cliente diga que é o problema técnico, na raiz costuma haver um desalinhamento entre pessoas. É por isso que times que conversam bem corrigem defeitos de entendimento antes que eles virem defeitos de código.
Pergunta seguinte
Então a solução é documentar tudo antes de sair codando?
Não exatamente — é pensar em prosa antes de pensar em sintaxe. A Amazon institucionalizou isso com o processo interno conhecido como Working Backwards: antes de qualquer linha de código, o time escreve um comunicado de imprensa fictício e uma lista de perguntas frequentes descrevendo o produto já pronto, do ponto de vista do cliente. Jeff Bezos resumiu a lógica dizendo que a empresa “start[s] with the customer and work[s] backwards” — começa pelo cliente e trabalha de trás para frente.
O caso mais citado é o da AWS: Bezos e Andy Jassy identificaram a oportunidade em 2004, mas os serviços fundacionais (S3 e EC2) só foram lançados em 2006 — mais de um ano foi gasto escrevendo, revisando e discutindo esses documentos antes de qualquer infraestrutura ser construída. A empresa também substituiu apresentações de slides por memorandos narrativos de até seis páginas nas reuniões de decisão, exatamente porque escrever em prosa força a explicitar relações de causa e efeito que um slide deixa passar batido.
Por que isso não é burocracia
Vale uma ressalva científica aqui. O próprio Brooks fez uma comparação reveladora: a física lida com sistemas tão complexos quanto o software, mas o físico trabalha com fé de que existem princípios unificadores por trás do caos — a complexidade da natureza é, em certo sentido, honesta. A complexidade de um sistema de software, ao contrário, é muitas vezes arbitrária: nasce de decisões humanas, de interfaces que mudam de equipe para equipe, de contexto que não está escrito em lugar nenhum a não ser na cabeça de quem participou da conversa original.
É por isso que engenheiros de alto nível conversam antes: não para seguir processo, mas porque a complexidade arbitrária do software só existe na cabeça das pessoas até alguém a transformar em linguagem compartilhada — falada, escrita ou desenhada. Código é a última tradução dessa cadeia, não a primeira.
Técnicas para não errar a especificação, o entendimento e os testes
Especificação
Reescreva o pedido com suas próprias palavras antes de abrir o editor, e mande de volta para quem pediu confirmar. Se a paráfrase não bater, o requisito não estava claro — só parecia estar.
Pergunte pelo que não deve acontecer, não só pelo que deve. Casos de borda e comportamento não-funcional (performance, segurança, limites) raramente aparecem no pedido original.
Escreva um mini “PR/FAQ” antes de uma POC: qual pergunta este experimento responde e o que provaria que ele falhou. Sem isso, toda POC “funciona” — porque ninguém definiu o que seria fracasso.
Entendimento
Em sistemas legados, mapeie o comportamento atual antes de mudar (testes de caracterização / golden master). Documente o que o sistema faz hoje, não o que a documentação diz que ele deveria fazer — raramente são a mesma coisa.
Traga alguém de fora da equipe técnica (produto, suporte, dados) para ouvir sua leitura do problema antes de estimar prazo. Se você não consegue explicar em termos simples, ainda não entendeu o suficiente para estimar.
Em reuniões de kickoff, seja o último a falar sobre solução. Alinhar o problema antes da solução evita que a primeira ideia técnica vire âncora da conversa inteira.
Testes
Escreva o teste que evidencia a intenção — dado, quando, então — antes ou junto da implementação, mesmo sem seguir TDD à risca. Um teste escrito depois tende a confirmar o código, não a intenção original.
Em MVPs, escreva por escrito o que deliberadamente não será testado (non-goals). Isso transforma débito técnico invisível em decisão explícita, revisável mais tarde.
Revisão de código deve avaliar se o código cumpre o que a conversa combinou, não só se está limpo ou idiomático. Sintaxe correta não é o mesmo que intenção correta.
3 práticas para levar à próxima conversa com seu gestor ou PM
Tudo isso pode soar abstrato se você ainda não tem uma década de bagagem para “simplesmente perceber” quando uma conversa evitaria um problema.
As três práticas abaixo não exigem experiência — só um script pronto e a coragem de usá-lo antes de abrir o editor.
1 · Antes de começar — traduza o pedido em uma frase que se responde com “sim” ou “não”
Você não precisa entender o negócio a fundo para fazer isso. Precisa só devolver o que ouviu, em uma frase curta, e esperar confirmação antes de escrever a primeira linha de código.
“Antes de começar, só confirmando: o objetivo é [o que você entendeu], para que [resultado que a pessoa quer] aconteça. É isso mesmo?”
Se a resposta vier rápida e direta, você entendeu. Se vier uma correção — “não bem, na verdade...” — você acabou de evitar dias de trabalho na direção errada, pelo custo de uma mensagem.
2 · Durante a conversa — pergunte pelo cenário de fracasso, não só pelo de sucesso
PMs e gestores costumam descrever o que a funcionalidade deve fazer. Raramente descrevem o que ela não pode quebrar, porque isso parece óbvio para quem pensa no produto o dia inteiro. Não é óbvio para quem está chegando agora — e perguntar por isso não exige jargão técnico.
"O que aconteceria se essa parte desse errado, ou se ela simplesmente não existisse? Isso me ajuda a saber o que eu não posso quebrar sem perceber."
Essa pergunta funciona em qualquer nível de senioridade porque desloca a conversa do “o que construir” para “o que importa de verdade” — que é exatamente o tipo de informação que normalmente só aparece depois, em produção.
3 · Depois da conversa — feche com um resumo escrito de três linhas
Não precisa ser um documento. Precisa existir, e precisa ser curto o bastante para alguém corrigir em quinze segundos, no mesmo dia — não descobrir o mal-entendido na revisão final.
Entendi: [o problema, em uma frase]
Vou fazer: [o que você vai construir]
Pode dar errado se: [a maior dúvida ou risco que você identificou]
Esse mini-resumo é a versão rascunho do memorando narrativo da Amazon citado antes: força você a organizar o pensamento em texto simples, e dá para quem pediu a tarefa uma chance barata de corrigir o rumo — exatamente o ponto da curva de custo em que a correção ainda é quase de graça.
“A única maneira de ir rápido é ir bem.”
Robert C. Martin — Clean Architecture
Vale para código, e vale para o que vem antes dele. Pular a conversa para “ganhar tempo” costuma custar mais tempo depois — só que espalhado, invisível, disfarçado de imprevisto.
O perfil mais disputado do mercado hoje não é o que escreve mais rápido. É o que entende o fluxo de valor de ponta a ponta — do problema de negócio ao resultado sentido pelo usuário — e usa o código como meio, não como fim. Conversar antes de codar não é perder tempo: é onde esse profissional realmente trabalha.
Sua vez
Qual foi a vez em que uma conversa de dez minutos evitou uma semana de retrabalho? Ou o contrário — o que aconteceu quando o time codificou antes de entender? Conte abaixo.
Frederick P. Brooks Jr. — The Mythical Man-Month: Essays on Software Engineering (1975/1995)
Colin Bryar & Bill Carr — Working Backwards; processo PR/FAQ da Amazon (workingbackwards.com)
Barry Boehm — Software Engineering Economics (1981); síntese em relatório da NASA sobre custo de erro
Kent Beck — Extreme Programming Explained (2000), sobre o achatamento da curva de custo de mudança e mal-entendidos como problema de pessoas
Martin Fowler — Refactoring: Improving the Design of Existing Code (1999)
Robert C. Martin — Clean Architecture: A Craftsman’s Guide to Software Structure and Design (2017)
Simplesmente maravilhoso! Eu dedico boa parte da minha gestão a avaliações de performance qualitativas. Infelizmente esse não é o padrão. Mas é o único jeito, apesar de trabalhoso, de avaliar bem alguém. Adorei as sugestões de "templante" de conversas pra remover ruídos de comunicação, prático e útil. Parabéns!
MÃE CORRE AQUI O RAFAEL TÁ POSTANDO DE NOVO