Você travou. Abre o Slack ou o Teams, chama o colega que conhece o assunto e, para ele entender direito, conta tudo: o handoff de ontem, o PO cobrando atualização, os comentários do ticket desde segunda, o canal de pagamentos, o time de risco que estava em war room. Vinte linhas depois, lá no fim, aparece: "pode olhar quando puder?". O colega manda um joinha. A thread morre ali.
O hábito proposto aqui é pequeno. A primeira linha do recado é uma pergunta que o colega consegue responder ainda nesta semana, de preferência hoje. Depois dela vêm, no máximo, três linhas de apoio. O resto só vai se ele pedir. Vale para o pedido escrito e assíncrono, aquele que o colega lê entre duas outras tarefas.
Por que vinte linhas sem pergunta travam a thread
Quem recebe um recado no meio do dia passa os olhos por ele, não lê. A Nielsen Norman Group descreve isso em páginas web desde 1997: as pessoas raramente leem palavra por palavra, e a ideia que não prende a atenção nas primeiras palavras tende a ser pulada. O estudo do padrão de leitura em F traz um detalhe incômodo. Diante de um muro de texto, quem quer ser eficiente olha mais as primeiras linhas do que as seguintes, e o trecho pulado pode ser tão importante quanto o lido. E quem pulou não sabe que pulou.
Os guias de escrita chegam à mesma regra: o Microsoft Style Guide manda "Lead with what's most important.", e o curso de escrita técnica do Google pede que o começo responda às perguntas essenciais do leitor, porque o leitor ocupado pode ler só o primeiro parágrafo.
Duas ressalvas. Essas pesquisas falam de leitura na web, não de chat, e ninguém mediu em que linha uma thread de Slack morre. E "vinte linhas" é uma imagem, não um limite: um recado de vinte linhas que abre com a pergunta funciona, e um de seis que termina em "pode olhar?" não. O que trava é a pergunta fora da primeira tela, justamente onde a leitura apressada não chega. Sem ela, o colega precisa deduzir a tarefa pelo seu histórico ou deixar para depois. E "depois", numa thread de chat, costuma virar sexta-feira.
Primeira linha: a pergunta que dá para decidir
Inverta a ordem: o essencial vai no topo. No jornalismo isso é a pirâmide invertida, com os fatos essenciais no lead e o resto em ordem decrescente de importância, para que o essencial sobreviva mesmo se o final for cortado. No e-mail militar, a mesma ideia se chama BLUF (bottom line up front), descrita por Kabir Sehgal na HBR em 2016: uma frase curta que "declares the purpose of the email and action required", e o contexto depois, em tópicos. No Slack vale igual. Quem lê não quer necessariamente o histórico que trouxe você até ali. Quer saber o que aquilo muda para ele.
Para pedido de ajuda, a página da Stack Overflow sobre como fazer uma boa pergunta tem a instrução mais direta: "Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence." No seu caso nem é preciso fingir: o colega ocupado existe e está do outro lado da thread.
Dois cuidados completam a ideia. A gente costuma dar indireta em vez de pedir, e os outros têm muito mais chance de ajudar quando o pedido é aberto e diz como ajudar, observa Vanessa Bohns em entrevista à Cornell ILR. E quanto mais específico, melhor: "The more specific your request, the more effective it will be", resume Wayne Baker no Greater Good. Um prazo específico funciona melhor do que um genérico.
Nossa regra: a primeira linha precisa ser uma pergunta decidível. O colega responde com sim ou não, A ou B, um nome, um horário. "Pode olhar quando puder?" não se decide, porque pede atenção e não uma escolha. Compare:
> "Pode dar uma olhada no checkout?"
> "Você topa assumir o review do handoff de checkout até as 15h de hoje, ou prefere que eu peça para a Ana?"
Na primeira, o colega ainda precisa descobrir o que olhar e o que decidir. Na segunda, ele responde em três palavras.
O molde de quatro linhas
O molde é nosso; a ordem vem das fontes acima. São quatro campos, um por linha:
| Linha | O que entra | O que não entra |
|---|---|---|
| Pergunta | Uma frase que o colega responde: sim/não, A ou B, nome, horário | "Pode olhar?", "alguém sabe?" |
| Já tentei | O que você leu ou testou e onde parou | O diário de bordo desde segunda |
| Decisão | A escolha que precisa ser feita, com nome | "Ver o que dá para fazer" |
| Até quando | Um horário ou um dia | "Quando puder", "sem pressa" |
"Já tentei" está ali porque a Stack Overflow pede que você registre o que já pesquisou, mesmo quando não ajudou, para ninguém redescobrir o mesmo beco sem saída. "Até quando" segue o MIT EECS Communication Lab, que pede a ação desejada com prazo.
Um exemplo. Primeiro, o muro:
> Oi — ontem o handoff do item de checkout ficou pela metade, o PO pediu atualização, o ticket tem comentários desde segunda, eu olhei o doc antigo, o canal #pagamentos, a planilha da sprint, falei com o time de risco mas eles estavam em war room, o review do outro item atrasou, o cliente perguntou no e-mail das 9h, tem um print no ticket, o log é enorme, o diff mexeu em várias partes, eu não sei se o problema é o horário ou a regra de retry, de qualquer forma alguém precisa ver isso porque senão o deploy de amanhã fica comprometido, pode olhar quando puder? obrigado
Tem bastante coisa ali e nenhuma decisão. A única pergunta chega no fim e não pede escolha nenhuma. Agora, reescrito:
> Pergunta: você topa assumir o review do handoff de checkout até as 15h de hoje, ou prefere que eu peça para a Ana? > > Já tentei: li os comentários do ticket de segunda e o doc de handoff; não fechei a regra de retry. > > Decisão: preciso de um dono do review agora, você ou a Ana, para o PO não ficar sem atualização. > > Até quando: resposta em uma linha até as 11h; o review em si até as 15h.
O conteúdo útil é o mesmo. A diferença é que agora a pergunta é a primeira coisa que o colega lê.
O que fica fora do primeiro recado
O muro costuma crescer por boa intenção. Você não quer fazer o colega perder tempo, então manda tudo de uma vez. O resultado é que o log chega antes da pergunta e o colega gasta o tempo justamente lendo o log.
Fica fora do primeiro recado:
- o log completo e o diff inteiro;
- a novela cronológica do ticket;
- opiniões sobre a stack, o processo ou o cliente;
- qualquer frase que comece com "desde março…".
Nada disso some. Vira oferta: "posso mandar o recorte do log se ajudar".
Se você tem dois pedidos, mande dois recados. Um muro com duas perguntas escondidas é só um muro maior.
A checagem desta semana: a primeira resposta
O próximo passo cabe numa tarefa:
- Escolha um pedido travado de verdade, já enviado ou ainda no rascunho.
- Reescreva no molde de quatro linhas, com a pergunta na linha 1.
- Envie.
- Leia só a primeira resposta do colega.
Passou se a primeira resposta já responde à pergunta: "sim", "pede para a Ana", "mando até as 16h". Falhou se a primeira resposta é "não entendi", "me manda o contexto", "o que você precisa?", ou um joinha sem decisão nenhuma.
Se falhou, reescreva uma vez, com a pergunta mais decidível na linha 1. Não mande uma segunda reclamação nem uma segunda novela. Se o colega perguntou o que você precisa, mais contexto não resolve: o que faltou foi a pergunta.
Um despejo de vinte linhas sem uma primeira linha decidível é rascunho até ganhar a versão de quatro linhas. Se o recado já abre com uma pergunta que o colega responde em uma linha, ele pode ser longo e mesmo assim funcionar, e você não precisa encaixá-lo no molde.
Se o recado for, na verdade, um feedback para um colega, o SBI já tem post próprio; se for a fala de 60 segundos diante do Sprint Goal, a Daily também.
Esta semana, um recado reescrito basta. Se a primeira resposta vier com a decisão, você economizou a thread inteira.