Comunicação no trabalho de tecnologia

1. Times de tecnologia trabalham por escrito

Com times remotos e híbridos, a maior parte da conversa acontece por escrito e sem resposta imediata: no Slack, no Teams, em comentários de issues (tópicos abertos para discutir um problema ou uma tarefa) e pull requests (propostas de mudança no código), em documentos. Isso tem um lado bom: quem escreve com clareza é entendido sem precisar estar na sala, e o que foi escrito fica registrado para quem chegar depois.

Três princípios valem para quase tudo nesta lição:

• Comece pelo ponto. A primeira frase diz o que você precisa ou o que aconteceu. O contexto vem depois.
• Escreva para quem não estava lá. Inclua o que a pessoa precisa para entender sem ter que perguntar.
• Facilite a resposta. Faça uma pergunta específica, que dê para responder com sim, não ou uma escolha.

2. Pedir ajuda

Pedir ajuda cedo é sinal de maturidade. Ficar dois dias travado em silêncio é o que costuma preocupar os times, não a pergunta. Uma regra comum: tente por uns 30 minutos a uma hora e, se não sair do lugar, pergunte.

Estou tentando [objetivo] e travei em [ponto].
O que fiz: [comando, código ou passos]
O que esperava: [resultado]
O que aconteceu: [erro completo, como texto]
O que já tentei: [o que pesquisou e testou]
Alguém já viu isso ou sabe para onde devo olhar?

Quando resolver, volte na conversa e conte o que era. Isso ajuda a próxima pessoa que tiver o mesmo problema e mostra respeito por quem tentou ajudar.

3. Escrever no chat do time

• Não mande só "oi". Escreva a pergunta inteira na primeira mensagem. Um "oi" solto obriga a outra pessoa a esperar, e a conversa demora o dobro.
• Pergunte no canal, não no privado, quando a dúvida for técnica. Mais gente pode responder, e a resposta fica para todos.
• Use as threads (respostas em fio) para manter cada assunto num lugar.
• Cole texto, não print, para erros e código. Texto dá para buscar e copiar. Use blocos de código: no Slack e no Teams, coloque o trecho entre três crases.
• Marque pessoas com moderação. Marque quem você sabe que pode ajudar, não o time inteiro.

oi
tudo bem?
posso te fazer uma pergunta?

Oi, Ana! Uma dúvida rápida sobre o deploy de ontem: a variável
DATABASE_URL de homologação mudou? Meu teste local começou a
falhar com "connection refused" depois da atualização.

No exemplo, deploy é a publicação de uma nova versão, e homologação é o ambiente de testes que imita o sistema real.

4. Relatar um problema

Um bom relato de problema (numa issue, num chamado ou no chat) deixa qualquer pessoa reproduzir o erro. Inclua:

• Um título que diga o problema: "Botão Pagar não responde no Safari", em vez de "Bug".
• Os passos para reproduzir, numerados.
• O resultado esperado e o resultado obtido.
• O ambiente: sistema, navegador, versão do app.
• Evidências: mensagem de erro, trecho de log, print quando ajudar.
• O impacto: quem é afetado e se existe um contorno.

5. Descrever um pull request

A descrição de um pull request (PR) é o que a pessoa revisora lê antes do código. Ajude-a a revisar rápido e com segurança:

## O que muda
Uma ou duas frases sobre a mudança e por que ela é necessária.

## Como testei
Os passos que você seguiu e o que conferiu.

## Pontos de atenção
O que merece um olhar mais cuidadoso, riscos e o que ficou de fora.

• PRs pequenos são revisados mais rápido e com mais cuidado. Prefira vários PRs pequenos a um gigante.
• Mensagens de commit claras. Muitos times usam o padrão Conventional Commits, como fix: corrige o cálculo do frete ou feat: adiciona filtro por data.
• Responda todos os comentários, mesmo que seja para dizer "feito" ou explicar por que você não mudou.

6. Dar e receber feedback

Para dar

• Fale do trabalho, não da pessoa. "Esta função ficou difícil de ler" em vez de "você escreve código confuso".
• Seja específico e sugira um caminho: "Que tal separar a validação numa função própria?".
• Diga o peso do comentário. Muitos times marcam o que é sugestão opcional com "nit:" (de nitpick, detalhe), para diferenciar do que precisa mudar.
• Elogie o que ficou bom, com a mesma especificidade.

Para receber

• Leia como informação sobre o trabalho, não como julgamento sobre você.
• Pergunte quando não entender: "Pode me dar um exemplo?".
• Agradeça e diga o que vai fazer. Discordar com argumentos é bem-vindo; levar para o lado pessoal, não.
• Peça feedback com frequência, e com perguntas concretas: "O que eu poderia ter feito diferente neste PR?".

7. Avisar antes que perguntem

Ninguém gosta de surpresa no dia da entrega. Se uma tarefa vai atrasar, avise assim que perceber, com o motivo e uma nova previsão. Um aviso cedo dá ao time tempo de se reorganizar.

Atualização sobre [tarefa]: vai atrasar até [nova data].
Motivo: [o que aconteceu].
O que já está pronto: [parte concluída].
Preciso de: [ajuda ou decisão, se houver].

E diga "não sei, vou descobrir" quando não souber. Chutar uma resposta e errar custa mais confiança do que admitir que precisa pesquisar.

8. Reuniões que valem o tempo

• Daily (reunião diária curta): diga o que fez, o que vai fazer e o que está impedindo. Detalhes técnicos ficam para depois, só com quem precisa.
• Prepare-se: leia a pauta e chegue com suas dúvidas anotadas.
• Fale quando não entender. Provavelmente mais alguém está com a mesma dúvida.
• Registre decisões: no fim, escreva o que foi decidido, quem faz o quê e até quando, e mande para todos.

9. Documentar o que você aprendeu

Resolveu algo que levou horas? Escreva um parágrafo no README do projeto, na wiki do time ou nas suas notas: o problema, a causa e a solução. A próxima pessoa, que pode ser você daqui a seis meses, vai agradecer.

Escrever também ajuda você a aprender. É a técnica de explicar com suas palavras, aplicada ao trabalho.

10. Missão final