Proposta técnica travada: 3 princípios Cialdini

“Proposta tecnicamente correta que não passa.” Engenheiro com um pouco de estrada já sentiu essa frustração pelo menos uma vez. Renovar a arquitetura, trocar a estratégia de testes, adotar uma nova ferramenta. Explicar a pertinência técnica em detalhes e ouvir “não dá pra manter como está?”.

O problema talvez não esteja no conteúdo da proposta. O problema costuma estar na forma de transmitir.

O psicólogo social Robert Cialdini publicou em 1984 o livro Influence: The Psychology of Persuasion, onde sistematizou princípios da persuasão humana a partir de anos observando o funcionamento de vendedores, fundraisers e negociadores no campo. A edição original identificou seis princípios; em Pre-Suasion (2016) ele adicionou um sétimo (unidade). Os princípios viraram leitura obrigatória em cursos de marketing e psicologia aplicada, mas seguem subutilizados na engenharia de software.

Este post aplica três deles a situações em que o engenheiro precisa fazer uma proposta passar: prova social, escassez e autoridade. O quarto princípio relevante no contexto, a reciprocidade, já foi tratado em outro post deste blog e fica de fora aqui.

Em situações de incerteza, as pessoas se apoiam no comportamento alheio para decidir. É o princípio da prova social. Se outras pessoas já fizeram algo, o risco percebido daquele caminho cai, mesmo quando a própria base de evidência não mudou.

Na proposta técnica, prova social aparece em três formas.

Citar casos de empresas conhecidas. “Netflix, Spotify e Airbnb migraram para essa arquitetura.” Casos de empresas do mesmo setor ou de nomes grandes funcionam como prova social forte porque o interlocutor atribui reputação às decisões técnicas dessas empresas. O cuidado é usar com honestidade: citar ignorando diferenças de escala e requisitos perde poder de persuasão no momento em que o outro percebe o descompasso. Ao citar, explique também “por que a situação dessa empresa é parecida com a nossa”.

Aliar-se a early adopters do time. Antes de propor adotar uma nova ferramenta para todos, deixe uma ou duas pessoas experimentarem primeiro. Com retorno positivo em mãos, a proposta de ampliar o uso vira “duas pessoas testaram de verdade e gostaram”. Isso persuade mais do que “ainda ninguém usou, mas parece bom”. Quem ouve não precisa ser o primeiro a arriscar.

Mostrar escala em números públicos. “1 milhão de downloads semanais no npm”, “40 mil estrelas no GitHub”, “aparece no State of DevOps há três anos consecutivos”. Esses números são prova social quantitativa. São o outro lado do efeito manada: do lado de quem propõe, o número vira argumento.

Lado defensivo: viés do sobrevivente

Quando prova social vem na forma “todo mundo usa X”, pergunte:

Esse “todo mundo” é quem? Empresas com escala e requisitos parecidos com os seus, ou nomes grandes jogados na conversa?
Os casos de sucesso citados estão livres de viés do sobrevivente? Quantas empresas tentaram o mesmo caminho e voltaram?
Download e estrela são indicadores de popularidade, não de qualidade. Biblioteca com 40k estrelas pode estar morta há dois anos. Verifique o último commit, o número de issues abertas sem resposta, e se o autor ainda responde.

Prova social persuade porque reduz o custo cognitivo de quem decide. Quem recebe a proposta não tem obrigação de fazer esse corte sozinho. Quem propõe tem.

Princípio 2: Escassez

O princípio da escassez diz que aquilo que é percebido como limitado ou com prazo para acabar ganha atratividade. “Oferta por tempo limitado” funciona na loja porque funciona no cérebro humano, não porque o produto ficou melhor.

A versão honesta desse princípio na engenharia não é inventar urgência. É reconhecer as janelas de escassez que já existem na realidade técnica do time e usá-las como enquadramento da proposta.

Janela de release. “Se essa mudança não entrar no release 2.6, só volta a pauta no 3.0, que é daqui a quatro meses.” A escassez aqui é real: o calendário de release existe independentemente da sua proposta. Explicitar essa janela faz a decisão sair do “podemos pensar depois” para “precisamos decidir essa semana”.

Deadline de deprecação ou fim de suporte. Quando uma dependência anuncia um fim de suporte, as datas viram escassez natural. “A versão N do runtime deixa de receber patch de segurança em novembro; precisamos migrar antes.” Antes de citar uma data específica, abra a documentação oficial do fornecedor e confirme. Datas de deprecação mudam, e deprecação anunciada no AWS blog, no roadmap do Node.js ou no release notes do framework são fontes distintas: cite qual.

Janela de RFC ou ADR. Times que usam processo formal de proposta de mudança (RFC, ADR, design review) costumam ter janela para comentários. “O RFC fica aberto até sexta, depois disso a decisão fecha no estado atual.” A proposta compete melhor quando encontra o processo aberto do que quando chega depois.

Capacidade limitada do time. “A pessoa que conhece esse módulo sai de licença em três semanas. Se a decisão de refactor não sair antes, perdemos a janela de ter contexto do dono.” Escassez de contexto humano é tão real quanto escassez de calendário.

A fronteira ética da escassez

Escassez funciona melhor quando é real. Inventar urgência que não existe produz o efeito contrário no primeiro momento em que o interlocutor percebe. “Precisamos decidir hoje” dito duas semanas seguidas sobre a mesma proposta corrói confiança.

A escassez válida se apoia em alguma coisa fora da sua vontade: o calendário de release do time, a data de fim de suporte do fornecedor, a janela aberta de um processo formal, o ciclo de capacidade humana. Se a data e a janela dependem só de você, não é escassez. É pressão. E pressão sem base não dura.

Princípio 3: Autoridade

O princípio da autoridade diz que, diante de incerteza, as pessoas tendem a aceitar mais rapidamente a recomendação de quem é percebido como autoridade na área. O mecanismo é economia cognitiva, não confiança cega. Avaliar o mérito técnico de cada argumento sozinho é caro; delegar parte dessa avaliação para alguém reconhecido reduz o custo.

Autoridade na proposta técnica tem três formas de uso que cabem na engenharia honesta.

Citar documentação oficial. “A doc do Postgres, na seção sobre índices parciais, recomenda esse padrão para o caso de distribuição enviesada.” Fonte oficial do produto que você está propondo adotar é a autoridade mais forte disponível, porque ela é a autoridade por definição sobre o próprio produto. Inclua o link para a página específica, não para a raiz da documentação.

Citar artigos ou livros canônicos da área. Alguns textos são referência quase universal no assunto: Designing Data-Intensive Applications (Kleppmann 2017) para sistemas distribuídos, Accelerate (Forsgren, Humble, Kim 2018) para métricas de DevOps, o artigo original do Raft (Ongaro & Ousterhout 2014) para consenso. Quando sua proposta se apoia nesse tipo de fonte, cite com autor, ano e seção. “Como descrito no Capítulo 2 de Designing Data-Intensive Applications…” carrega mais peso do que “li num blog”.

Reconhecimento no próprio time. A autoridade mais imediata é a interna. O principal engenheiro que já resolveu um caso parecido, a pessoa que escreveu o módulo em questão, o head que fez a última decisão arquitetural desse escopo. Alinhar a proposta com essa pessoa antes do grupo não é politicagem. É reconhecer que a autoridade existe e que ignorá-la só aumenta o atrito.

Lado defensivo: ad verecundiam e autoridade fora do domínio

A falácia clássica do apelo à autoridade (argumentum ad verecundiam) aparece quando a autoridade citada está fora do seu domínio de competência. Linus Torvalds sobre kernel Linux é uma autoridade fortíssima. Linus Torvalds sobre arquitetura de microsserviços de negócio é só uma opinião num comentário de lista de e-mail.

Quando receber uma proposta ancorada em autoridade:

A pessoa citada é autoridade neste subdomínio, ou só em um adjacente?
O artigo citado trata deste problema, ou de um parecido? Problemas parecidos nem sempre têm a mesma solução.
A documentação citada é a versão corrente, ou uma edição anterior que já foi substituída?

Autoridade fora do domínio enfraquece mais a proposta do que fortalece, quando o outro lado faz a verificação.

Caso composto: aplicar os três em uma proposta

Imagine uma proposta real, sem nomes reais: você quer que o time pare de usar um ORM caseiro e adote uma biblioteca estabelecida, reduzindo bug recorrente de SQL mal gerado.

Sem os três princípios, a proposta vira “a lib X é melhor porque mapeia melhor os tipos”. Discussão abstrata, decisão arrastada por semanas.

Com os três:

Prova social. “A lib X aparece como dependência direta em [N] dos 100 repositórios de maior popularidade da linguagem no GitHub, incluindo o framework A e o framework B. Dentro da nossa stack, o time de infraestrutura adotou no serviço Y em janeiro e relatou redução no número de bugs relacionados a query.” (Antes de escrever esse parágrafo, você conferiu os números no GitHub e perguntou ao time de infra os dados reais. Se os números não baterem, você muda o texto; não inflaciona.)
Escassez. “Nosso ORM caseiro depende de uma versão do runtime que entra em modo de manutenção em [data da documentação oficial]. Se vamos revisar essa camada de qualquer jeito, essa é a janela em que a mudança compete bem com os outros itens de refactor na fila.” (A data foi conferida na página oficial; se a informação envelhecer até a próxima reunião, você atualiza a proposta.)
Autoridade. “O capítulo 2 de Designing Data-Intensive Applications trata explicitamente do descasamento entre o modelo de objetos e o modelo relacional, e discute os limites de ORMs que tentam esconder esse descasamento em cenários onde a escrita de SQL é o ponto principal de performance. A doc oficial da lib X confirma essa posição no guia de uso para alto volume.”

Repare no que não está no texto. Não tem “reduzi em 62% os incidentes depois que eu migrei um cliente”. Não tem “a AWS anunciou que o serviço acaba em junho de 2027”. Não tem “o paper Z define esse padrão” quando o paper Z fala de outra coisa. Os três princípios só funcionam quando a prova social é verificável, a escassez é real e a autoridade está no domínio certo. Qualquer atalho aqui estraga os três ao mesmo tempo.

Pré-requisito comum: confiança

Os três princípios têm um pré-requisito comum que o próprio Cialdini destaca no livro: a confiança em quem propõe. Sem isso, prova social vira “manipulação de números”, escassez vira “pressão artificial”, autoridade vira “apelo vazio à fama”.

Confiança não se constrói com técnica de persuasão. Constrói-se com qualidade da revisão de código, contribuição real em incidentes, precisão das decisões técnicas do dia a dia. Os princípios de Cialdini são ferramenta para otimizar a forma de transmitir uma proposta quando a confiança já existe. Não são ferramenta para substituí-la. Trocar a ordem produz o efeito oposto.

Se você acabou de chegar no time, invista primeiro em reviews cuidadosos, documentação dos próprios PRs e ajuda em incidentes alheios. É o caminho descrito no post sobre reciprocidade em code review, que trata do quarto princípio relevante no mesmo kit. Reciprocidade constrói o chão. Prova social, escassez e autoridade são o que você monta em cima.

Resumo em uma frase

Proposta técnica correta que não passa raramente falha por falta de mérito técnico. Costuma falhar porque o interlocutor não tem gancho cognitivo para atravessar a incerteza. Prova social dá o gancho “outros já fizeram”. Escassez dá o gancho “a janela está passando”. Autoridade dá o gancho “quem entende disso recomenda”. Os três juntos, aplicados com honestidade, transformam o 1:1 em uma conversa na qual o “não dá pra manter como está?” perde força sem você precisar levantar o tom.

Este post faz parte de uma série baseada no livro Engenharia da Mente: Truques de Psicologia para Engenheiros (edição PT-BR), onde o capítulo 9 trata especificamente de persuasão aplicada à engenharia.

Princípio 1: Prova social