BATNA para engenheiros: 3 técnicas de negociação Harvard

Engenheiro não negocia. É o que a gente se diz para não precisar negociar.

Só que a cada sprint eu negocio escopo. A cada release, prazo. A cada nova biblioteca, adoção. Sem framework nenhum, só na base do “acho que dá” e “então tá”. O resultado é sempre o mesmo: aceito o que veio, ou empurro na força da vontade, e nas duas pontas alguém sai chateado.

Passei a estudar as técnicas de negociação da Escola de Negociação de Harvard depois que percebi isso. Três delas mudaram como eu abro esse tipo de conversa hoje. Não são truque de vendedor: são framework de decisão sob assimetria de informação. Muito parecido com o que a gente faz em code review, só que com humanos do outro lado da mesa.

BATNA — o terreno em que a negociação acontece

BATNA (Best Alternative to a Negotiated Agreement) é o conceito central do Harvard Negotiation Project, formalizado por Roger Fisher e William Ury em Getting to Yes (1981). A ideia é simples: antes de negociar qualquer coisa, você precisa saber o que faz se a negociação não fechar.

Quem tem BATNA mais forte leva a conversa. Não porque manipula, mas porque não depende do acordo.

Onde isso aparece no dia do engenheiro:

• Salário. BATNA forte = você tem outra proposta na mão, com número. BATNA fraco = “acho que estou mal pago” sem referência externa. O primeiro conversa. O segundo reclama.
• Escopo de refactor. O PM pede mais uma feature no sprint. BATNA forte = “sem cortar essa outra feature, o release atrasa 1 semana e a dívida técnica sobe”. BATNA fraco = “não dá tempo”.
• Adoção de biblioteca. A liderança quer que a equipe adote uma stack. BATNA forte = “montei um POC de 3 dias com a alternativa e o custo de migração cai 40%”. BATNA fraco = “prefiro a outra”.

O padrão é o mesmo: o BATNA fraco é sempre uma opinião. O BATNA forte é sempre uma alternativa concreta que você já testou ou já pesquisou.

E aqui vale um cuidado: o BATNA do outro lado também existe. Se a empresa não tem gente na fila para te substituir, o BATNA dela é fraco. Se você é o único que conhece aquele sistema legado, o BATNA dela é fraco. Estimar isso muda quanto você pode pedir.

Regra de bolso que eu uso: antes de qualquer conversa importante, escrevo 3 alternativas concretas para o caso da conversa não fechar. Se não consigo escrever 3, o BATNA está fraco e é melhor esperar.

Porta na cara — Cialdini, 1975

A técnica “porta na cara” foi demonstrada por Robert Cialdini e colegas em 1975. O experimento original: pediram para universitários acompanharem jovens infratores em uma visita ao zoológico por 2 horas. 17% aceitaram.

Em outro grupo, pediram primeiro que os universitários se voluntariassem para 2 anos de tutoria semanal. Quase todos recusaram. Aí veio o mesmo pedido do zoológico. 50% aceitaram.

O mecanismo é a “concessão recíproca”: quando o outro lado diminui o pedido, você sente que também precisa ceder alguma coisa.

Como isso vira ferramenta técnica:

• Proposta de refactor. Abrir com “quero reescrever esse módulo do zero, 2 meses”. Depois da recusa esperada, propor “então deixa eu extrair só a parte crítica pra um serviço à parte, 2 semanas”. As 2 semanas passam com muito mais facilidade do que se você tivesse aberto direto nelas.
• Adoção de ferramenta. “Quero comprar a licença enterprise, R$ 100k/ano” → recusado → “então começo com 1 time em trial de 3 meses, R$ 20k”. O trial fica mais aceito.
• Bug prioritization. “Precisamos parar tudo pra resolver esse bug (2 semanas)” → recusado → “então alocamos 20% do sprint para ele nas próximas 4 sprints”. A concessão parece razoável em comparação.

O cuidado que a literatura destaca: se o pedido inicial soa impossível de propósito, o outro lado percebe a manobra e o efeito inverte. O primeiro pedido tem que ser algo grande mas defensável. “Reescrever tudo do zero” funciona se de fato há justificativa técnica. “Reescrever tudo em Rust semana que vem” soa como piada e queima crédito.

Pé na porta — Freedman & Fraser, 1966

Jonathan Freedman e Scott Fraser publicaram em 1966 o experimento inverso. Foram até casas pedindo às pessoas que colocassem uma placa gigante e feia no jardim, defendendo direção segura. 17% aceitaram.

Antes de repetir a experiência com outro grupo, os pesquisadores fizeram um pedido pequeno primeiro: colocar um pequeno cartaz na janela dizendo “seja um motorista seguro”. Quase todos aceitaram. Duas semanas depois, voltaram com o pedido da placa gigante. 76% aceitaram.

O mecanismo é o princípio da consistência: quando você já disse “sim” para algo pequeno, muda a sua auto-imagem (“eu sou o tipo de pessoa que apoia direção segura”), e ficar coerente com essa auto-imagem passa a valer mais que o incômodo da placa.

Aplicações técnicas quase óbvias:

1. “Posso escrever um teste no framework novo pra esse arquivo aqui?” (pedido pequeno)
2. “Já que os testes novos estão passando, escrevo os próximos também no framework novo?” (médio)
3. “Vou migrar os testes existentes aos poucos, 10 por sprint?” (grande)

Cada etapa mostra resultado, e a próxima fica mais fácil de aprovar. Se você tivesse aberto com “vou migrar todo o framework de testes”, quase sempre a resposta é não.

Onde isso funciona melhor:

• Migração de stack (linguagem, framework, banco)
• Introdução de processos novos (code review obrigatório, CI stricter, SLOs)
• Adoção de padrões de segurança (2FA, secrets management, threat model)

E onde tende a falhar: qualquer negociação que precise fechar numa única reunião. Aí o certo é “porta na cara”, não “pé na porta”.

Quando escolher qual

A tabela abaixo é a heurística que eu uso hoje. Não é rígida — cada situação tem um pouco das três.

BATNA é sempre pré-requisito das outras duas. Sem BATNA, “porta na cara” vira blefe e “pé na porta” vira estagnação.

O que eu deixei de fora de propósito

Este texto não fala de framing de perda, ancoragem, nem escuta ativa. Todas essas técnicas funcionam também, e Kahneman e Tversky (1979) demonstraram que uma perda pesa cerca de 2x mais que um ganho equivalente na cabeça de quem decide. Mas cabem em outro post.

Não falo também de CLT vs PJ, monotributo, ou de proposta em dólar. Não é do meu terreno — vivo em outro sistema fiscal e não vou fingir que entendo o seu. As três técnicas acima são universais e funcionam independentemente disso. A parte do salário é sempre a mesma: BATNA forte = outra oferta com número, BATNA fraco = opinião.

Se a única coisa que ficar deste post for “antes de abrir a boca em qualquer negociação, escreva 3 alternativas concretas para o caso de não fechar”, já valeu o tempo de leitura. É essa a diferença entre o engenheiro que pede e o engenheiro que só reclama.

Para quem quer aprofundar o lado psicológico dos vieses que aparecem em conversas técnicas, também escrevi sobre 3 vieses cognitivos que quebram estimativas de sprint e sobre os 5 vieses que fazem code review virar briga. Os três textos formam uma base útil junto.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews