Como dar feedback técnico sem destruir a relação com o colega

1. Por que o feedback técnico é tão sensível?

O código é uma extensão do pensamento do desenvolvedor. Quando alguém aponta um problema em uma função, muitas vezes o receptor interpreta como um ataque à sua competência. Esse fenômeno, conhecido como identificação pessoal com o código, transforma revisões técnicas em campos minados emocionais.

Um estudo da Google (Projeto Aristóteles) mostrou que times de alta performance têm segurança psicológica — ou seja, os membros podem dar e receber críticas sem medo de retaliação. Quando o feedback técnico é mal dado, ele corrói essa segurança, gerando silêncio, ressentimento e até abandono de boas práticas por birra.

A diferença crucial está em criticar a solução (comportamento) versus criticar a pessoa (identidade). Dizer "sua lógica está falha" é muito diferente de "você é um mau programador". O primeiro é um fato observável; o segundo, um julgamento.

2. Os pilares de um feedback técnico saudável

Três pilares sustentam um feedback técnico eficaz:

  • Intenção clara: O objetivo não é mostrar superioridade, mas fortalecer o time. Antes de falar, pergunte-se: "Isso vai ajudar o colega a crescer ou apenas me fazer parecer mais experiente?"
  • Objetividade: Use dados observáveis. Em vez de "esse código está confuso", aponte "a função processData tem 80 linhas e mistura regras de negócio com formatação".
  • Temporalidade: O code review é o melhor momento para feedback técnico pontual. Já feedbacks sobre padrões recorrentes ou comportamento devem ser tratados em one-on-one, nunca em público.

3. A estrutura SBI (Situação, Comportamento, Impacto) aplicada à tecnologia

A técnica SBI é amplamente usada em liderança e se adapta perfeitamente ao contexto técnico:

  • Situação: Contexto específico e observável.
  • Comportamento: A ação concreta que ocorreu.
  • Impacto: Consequência para o código, o time ou o produto.

Exemplo prático:

Situação: No PR #142, na função `validateEmail()`, linha 23.
Comportamento: Você usou uma expressão regular sem validação de entrada nula.
Impacto: Se o campo vier vazio, o sistema lança uma exceção não tratada em produção, causando erro 500 para o usuário.

Perceba que não há julgamento pessoal. O foco está no código e no impacto, não na pessoa.

4. Como evitar as armadilhas comuns em code reviews

Armadilha 1: Tom acusatório

❌ "Você errou ao não testar essa função."

✅ "Que tal considerarmos adicionar um teste unitário para cobrir o cenário de borda aqui?"

Armadilha 2: Feedback vago

❌ "Isso está ruim."

✅ "Essa lógica pode ser simplificada com um array.map em vez do for manual. O código fica mais legível e performático."

Armadilha 3: Excesso de críticas

Equilibre cada apontamento com um reconhecimento de acerto. Se um PR tem 10 pontos positivos e 2 negativos, destaque os positivos primeiro. Isso treina o cérebro do receptor a não entrar em modo defensivo.

Pontos fortes:
- A estrutura de pastas ficou organizada.
- Os nomes das variáveis são descritivos.

Sugestões:
- Extrair a validação de CPF para um método separado.
- Adicionar um teste para o caso de CPF inválido.

5. A técnica do "sanduíche" e suas variações no contexto técnico

O sanduíche clássico é: elogio genuíno + crítica construtiva + incentivo. No contexto técnico, funciona assim:

Elogio: "Sua implementação da cache está muito boa — o uso de TTL evita dados obsoletos."

Crítica: "Só sugiro extrair a lógica de expiração para um helper separado, assim você pode reutilizá-la em outros módulos."

Incentivo: "Com esse ajuste, o código ficará ainda mais modular e fácil de manter. Ótimo trabalho!"

Cuidados importantes:
- Não force elogios falsos — o receptor percebe e perde a credibilidade.
- Não inverta a ordem de forma artificial. Se o PR só tem problemas, seja honesto: "Vamos focar em ajustar esses pontos críticos juntos."
- Para feedbacks recorrentes, o sanduíche pode soar manipulador. Use SBI nesses casos.

6. Como receber feedback sem se sentir atacado

Receber feedback é uma habilidade tão importante quanto dar. Aqui estão estratégias práticas:

Separe a identidade da solução: Seu código não é você. Um PR rejeitado não significa que você é um mau profissional — significa que aquela abordagem específica pode ser melhorada.

Faça perguntas de esclarecimento:

"Você pode me dar um exemplo concreto do que poderia quebrar nesse trecho?"
"Qual seria a alternativa que você sugere? Posso implementar e compararmos."

Transforme feedback em ação: Crie um plano de melhoria ou abra um PR de ajuste imediatamente. Isso mostra maturidade e transforma crítica em aprendizado.

7. Ferramentas e práticas para institucionalizar o feedback técnico

Checklists de code review: Crie um template que foque em comportamento, não em pessoa:

- [ ] A lógica resolve o problema proposto?
- [ ] Há testes para os cenários de borda?
- [ ] A nomenclatura é clara e consistente?
- [ ] O código pode ser simplificado?
- [ ] Há efeitos colaterais não previstos?

Rituais de retrospectiva técnica: Uma vez por sprint, reúna o time para revisar PRs emblemáticos — bons e ruins — de forma anônima. O foco é aprender, não culpar.

Templates de pull request: Inclua um campo "Sugestões de melhoria" já no template. Isso normaliza o feedback como parte do processo, não como crítica pessoal.

## O que foi feito
[descrição]

## Como testar
[instruções]

## Sugestões de melhoria (opcional)
[espaço para o revisor]

8. Quando escalar: feedback técnico que vira problema de relacionamento

Alguns sinais indicam que o feedback técnico transcendeu para uma questão comportamental:

  • Repetição do mesmo erro após múltiplos feedbacks.
  • Defensividade constante — o colega nunca aceita sugestões.
  • Clima de hostilidade — o code review vira campo de batalha.

Nesses casos, o tech lead ou gestor deve ser envolvido. A abordagem deve ser neutra:

"Percebi que nos últimos PRs temos tido divergências recorrentes sobre a mesma abordagem. Que tal conversarmos com o tech lead para definir um padrão para o time?"

A diferença entre feedback técnico e comportamental é sutil, mas crucial: feedback técnico é sobre código e pode ser resolvido com documentação, padrões e treinamento. Feedback comportamental é sobre atitudes e requer conversas de alinhamento de expectativas.

Quando um se torna o outro, a transição acontece quando o padrão de comportamento impede o crescimento técnico. Nesse momento, não trate como questão de código — trate como questão de time.

Referências