Como dar e receber feedback em one-on-ones como dev

1. Por que one-on-ones são o palco ideal para feedback técnico

A revisão de código (code review) é o espaço público onde decisões técnicas são questionadas e refinadas. Já o one-on-one é o espaço privado onde o desenvolvedor pode refletir sobre padrões de comportamento, crescimento técnico e impacto no time sem o ruído da aprovação imediata de um PR.

A principal diferença está na profundidade do contexto. Enquanto um comentário em PR foca em uma linha específica, o one-on-one permite discutir tendências: "Nas últimas três sprints, percebi que você tem evitado RFCs para mudanças de arquitetura. Isso tem gerado retrabalho no time." Esse tipo de observação não cabe em uma revisão de código, mas é essencial para o desenvolvimento do dev.

Outro ponto crítico é o feedback acumulado. Quando um gerente guarda observações por meses e as despeja em uma avaliação formal, o dev se sente traído. One-on-ones semanais ou quinzenais criam um ritmo de microfeedback que evita surpresas e permite correções de rota rápidas.

2. Preparação: o que levar para a conversa (e o que deixar de fora)

Antes de entrar no one-on-one, colete evidências concretas. Exemplos:

# Evidências concretas para feedback técnico
- Commits: 12 commits na sprint, 8 com mensagens genéricas ("fix", "update")
- PRs: 3 PRs abertos por mais de 48h sem interação
- Métricas: cobertura de testes caiu de 78% para 65% nos últimos 30 dias
- ADRs: 2 decisões de arquitetura tomadas sem documentação

Diferencie feedback de desempenho técnico (qualidade do código, cobertura de testes, documentação) de feedback comportamental (comunicação, proatividade, alinhamento com produto). Misturar os dois na mesma conversa gera confusão.

Ferramentas úteis para anotação:

  • ADRs (Architecture Decision Records): use como objeto de discussão quando o dev tomou decisões sem registrar os trade-offs.
  • Logs de decisão: anote em um doc compartilhado de 1:1 as principais escolhas técnicas do sprint.
  • Histórico de 1:1: mantenha um registro simples com data, tópico e ação combinada.

3. Estrutura SBI (Situação-Comportamento-Impacto) aplicada a devs

A estrutura SBI é uma das mais eficazes para feedback técnico porque separa julgamento de observação. Veja como aplicá-la em one-on-ones:

Situação: "Na última sprint (sprint 12), durante a implementação do módulo de pagamentos..."
Comportamento: "...você optou por não criar um ADR para a decisão de usar fila assíncrona em vez de processamento síncrono."
Impacto: "Isso gerou retrabalho de 2 dias para o time, pois o backend lead precisou refazer a análise quando descobriu a mudança na revisão de código."

A chave aqui é evitar adjetivos. Em vez de "você foi displicente", use "você não documentou a decisão". O comportamento precisa ser observável e mensurável. O impacto deve conectar ao time, à dívida técnica ou à previsibilidade do sprint.

4. Como receber feedback sem ficar na defensiva (modo dev)

Receber feedback é mais difícil do que dar, especialmente para devs que investem orgulho técnico no próprio código. A técnica do silêncio ativo ajuda: quando receber uma crítica, espere 5 segundos antes de responder. Isso evita a reação instintiva de explicar a decisão técnica.

Perguntas de esclarecimento são suas aliadas:

Perguntas para esclarecer feedback técnico:
- "Você pode me dar um exemplo de quando essa falta de documentação impactou o time?"
- "Qual seria o comportamento ideal nesse cenário, na sua visão?"
- "Isso é um padrão que você tem observado em mais de um contexto?"

Separe crítica ao código de crítica pessoal. Se o reviewer diz "essa implementação está frágil", ele está falando do código, não da sua capacidade como dev. Internalizar essa distinção é essencial para evoluir.

5. Feedback sobre débito técnico e decisões de arquitetura

Débito técnico é um tema delicado porque muitos devs o veem como um atalho necessário, enquanto gerentes o veem como risco. O one-on-one é o lugar certo para alinhar essas visões.

Abordagem recomendada:

Feedback sobre débito técnico:
Situação: "Na implementação da feature de relatórios, você usou uma consulta N+1 que funciona para 100 registros..."
Comportamento: "...mas sabia que escalaria para 10.000 registros no próximo mês."
Impacto: "Isso pode gerar timeout em produção e custar 3 dias de hotfix, além de afetar a confiança do produto no time."

Use RFCs e ADRs como objeto de discussão no one-on-one. Em vez de "você não pensou na escalabilidade", diga "vamos revisar juntos o ADR que você escreveu para essa decisão e ver se os trade-offs estão claros".

Alinhamento com produto é outro ponto. Traduza débito técnico em risco de prazo:

Tradução técnica para produto:
- Débito técnico: "Componente monolítico sem testes"
- Risco de prazo: "Qualquer mudança nesse componente leva 3 dias de testes manuais"
- Impacto no produto: "Feature X atrasará 1 sprint se precisar modificar esse componente"

6. Feedback sobre colaboração e alinhamento com produto

Devs frequentemente reclamam de requisitos vagos ou mudanças de escopo. O one-on-one é o momento de dar feedback sobre isso sem soar como reclamação.

Feedback sobre comunicação com PM:
Situação: "Na sprint passada, o PM alterou o escopo da feature de login duas vezes..."
Comportamento: "...e não houve uma comunicação formal sobre o impacto no prazo."
Impacto: "O time trabalhou 16h extras e a estimativa original perdeu credibilidade."

Da mesma forma, receba feedback sobre falta de visibilidade. Se o tech lead diz "você não atualizou o board por 3 dias", não reaja com "mas eu estava codando". Pergunte: "Qual frequência de atualização você espera? Diária? A cada mudança de status?"

O feedback reverso também é bem-vindo. O dev pode avaliar a atuação do tech lead ou do gerente:

Feedback reverso (dev para tech lead):
"Percebo que nas últimas duas sprints, as revisões de código demoraram mais de 24h. Isso atrasou meu fluxo. Podemos ajustar as prioridades?"

7. Ações pós-one-on-one: registro, acompanhamento e iteração

Feedback sem ação é ruído. Transforme cada ponto em um item acionável no backlog pessoal do dev.

Exemplo de registro pós-one-on-one:
Data: 15/10/2024
Tópico: Documentação de ADRs
Feedback: Dev não documentou 2 decisões de arquitetura na sprint
Ação: Criar ADR para a decisão de fila assíncrona até 18/10
Ação do gerente: Disponibilizar template de ADR e exemplo pronto
Check-in: 22/10 (próximo 1:1)

Use um doc compartilhado de 1:1 (Google Docs ou Notion) com seções fixas:

Template de doc de 1:1:
- Realizações da sprint
- Desafios técnicos
- Feedback recebido
- Ações combinadas
- Tópicos para a próxima reunião

No próximo one-on-one, comece retomando as ações anteriores: "Na última conversa, combinamos de documentar o ADR da fila. Como foi? Encontrou alguma dificuldade?" Isso mostra que o feedback não foi esquecido e cria um ciclo de melhoria contínua.

8. Armadilhas comuns e como evitá-las

O sanduíche de feedback (elogio-crítica-elogio) é uma armadilha clássica. O dev sai da reunião confuso sobre o que realmente precisa melhorar. Em vez disso, separe momentos: comece com feedback positivo genuíno, depois entre no feedback de melhoria com a estrutura SBI.

Feedback genérico sem exemplos de código ou decisões é inútil. "Você precisa melhorar a qualidade do código" não diz nada. Prefira: "Nos PRs #42 e #45, encontrei variáveis sem tipo definido e funções com mais de 50 linhas. Vamos revisar juntos o guia de estilo do time?"

Misturar one-on-one com revisão de código pública é humilhante. Se o dev cometeu um erro grave em um PR, o feedback público já foi dado na revisão. No one-on-one, discuta o padrão, não o erro específico. Nunca diga "lembra daquele PR que você fez errado?" em público.

Referências