Acabei de fechar o laptop. A luz da tela ainda está na retina. O dia, na real, rendeu. Aquele bug persistente no pipeline de deploy foi resolvido, o que me deu uma puta satisfação silenciosa. Aquela satisfação que só a gente entende: a máquina funcionou como deveria, a lógica venceu. Ninguém viu as três horas olhando o log na madrugada. Ninguém precisa ver.
Mas aí vem a daily.
É sempre a mesma coisa. O momento de sair do flow e entrar no modo apresentação. Você passa o dia focando na granularidade do código, na arquitetura do sistema, na complexidade que exige silêncio absoluto, e de repente, precisa sintetizar tudo isso em soundbites para o grupo. É contraintuitivo.
O PROBLEMA NÃO É O CONTEÚDO. O PROBLEMA É A PERFORMANCE
Lembro de uma vez que eu estava trabalhando numa refatoração pesada, que ia limpar uns cinco mil arquivos mortos de código legado. Era um trabalho invisível, que não gerava feature nova, mas que ia reduzir a dívida técnica drasticamente e agilizar futuros desenvolvimentos. Na hora da daily, eu senti a pressão de não ter “concluído” nada visível. Tentei explicar a complexidade da refatoração, o cuidado com as dependências, e acabei usando tipo uns três minutos, atropelando as palavras, e no fim, o Scrum Master só anotou: “Refatoração em andamento.” Foi inútil. E frustrante.
A gente, que é mais reservado, não lida bem com essa necessidade de “vender” o trabalho todo dia. A gente gosta de mostrar o código, o resultado. A fala, o palco, a exposição, isso cansa mais do que o debug de um NullPointerException em produção.
Essa dificuldade de se posicionar também aparece quando precisamos lidar com críticas inesperadas em reuniões, algo que aprofundo em 5 Frases para Responder Críticas Inesperadas em Reuniões.
Aí eu comecei a perceber que a daily é um protocolo de comunicação, não um fórum de debate técnico. O time, o gerente, o PO, eles não querem a topologia do seu raciocínio. Eles precisam de três pontos de sincronização para saber se o comboio está andando e se você não vai bater no Zé da feature ao lado.
Passei a me obrigar a filtrar a informação no caminho entre a minha mesa e a sala de reunião (ou o ícone do Meet/Zoom). Virou um parsing mental de três tópicos, quase um roteiro rígido que eu uso para ter a segurança de que não vou me perder em detalhes. E, o mais importante, para ter a segurança de que vou falar por menos de 60 segundos. O silêncio da minha volta ao meu trabalho depois de falar é o meu prêmio.
O PRIMEIRO PONTO É SEMPRE O O QUÊ EU FECHEI
Não é “O Que Eu Fiz“. É o resultado final. A PR que subiu, o ticket que foi para Done, o deploy que rodou na staging. Tem que ser uma conclusão, um ponto final. Se o meu trabalho de ontem foi só preparar o ambiente de testes, eu não digo “Eu preparei o ambiente”. Eu digo: “O ambiente de testes está pronto para o módulo X. Os testes unitários estão passando.” É a conclusão que importa. E isso tem que ser dito de primeira, para dar a sensação de progresso, de que a roda girou.
Isso ajuda a gente, inclusive, a se sentir melhor. Porque na nossa cabeça, às vezes o progresso não é linear. Mas na comunicação, ele precisa parecer.
O SEGUNDO PONTO É SOBRE O FOCO AGORA
Aqui é onde a gente costuma se enrolar, porque estamos fazendo quinhentas coisas. Mas a daily não quer saber das quinhentas. Ela quer saber da uma coisa que, se parar, afeta o resto do sprint.
Eu forço a barra a escolher o item de maior prioridade. “Estou no feature Y (Ticket #500).” Ponto. Se tiver um detalhe crucial, eu adiciono. “Estou no feature Y, mas dependo do schema de banco de dados do Pedrão.”
A clareza aqui é para evitar as perguntas que nos tiram do prumo. Se você é vago, o PO vai perguntar: “Mas e o ticket #501?” Se você é específico, a chance de te deixarem em paz é maior. E ser específico é mais fácil para quem é analítico. É só dizer o nome exato da branch, do ticket ou do serviço. É menos sobre sentimentos e mais sobre fatos. Fatos a gente domina.
O TERCEIRO TÓPICO, O CRUCIAL, É O BLOQUEIO, O RISCO
E não é sobre não saber. Bloqueio não é incompetência. É dependência.
“Preciso de uma chave de API para avançar, e só o André tem.” É um bloqueio claro.
“A solução que encontrei para o frontend pode conflitar com o trabalho da Maria no backend.” Isso é um risco.
O alívio de falar um bloqueio é transferir a responsabilidade de desbloqueio para o time, não de solução do problema. Isso é essencial para quem tende a segurar as coisas até ter a solução perfeita na mão. A gente tem a tendência de sofrer em silêncio. Ficar horas tentando hackear uma solução só para não ter que falar que está bloqueado. A daily é o timer para parar com essa mania. Se o bloqueio persistiu por mais de quatro horas, ele vira o tópico três. Simples assim.
Esse padrão de comunicação objetiva também é essencial em ambientes assíncronos, como explico em 4 Erros de Comunicação em Slack que Geram Débito Técnico e Como Evitá-los.
No fim, o roteiro (Concluído, Foco, Bloqueio) serve para a gente se proteger. Proteção contra o tempo perdido, contra a ansiedade da exposição, e contra a interpretação errada do nosso silêncio. O colega mais falante pode se dar ao luxo de improvisar. A gente, não. A gente precisa de um protocolo eficiente para voltar para o que realmente importa, que é o código.
Se consigo falar esses três pontos de forma objetiva, em menos de um minuto, eu consegui o que queria. Sincronização e silêncio. E o dia pode finalmente continuar. É uma pequena vitória social, todo dia. E essas pequenas vitórias fazem a gente não desistir desse ambiente de TI que a gente ama, apesar de tudo.
Amanhã tem mais. Mas a fala já está pré-processada. Isso me acalma.
Acabei de fechar o laptop. Essa satisfação da vitória lógica é real, mas a performance de hoje ainda está ecoando. Fico pensando: se comunicar o que se fez é tão difícil, imagine o quão mais complicado é comunicar o que se sente ou o que o colega precisa melhorar. Dar feedback para alguém, ou receber ele de volta, parece ter a mesma armadilha de precisar ser rápido e objetivo, mas com um risco de conflito muito maior.
Continue aprofundando
Se comunicação é um desafio constante para você, talvez estes artigos também ajudem:
• Como o Introvertido Pode Construir Autoridade Técnica Sem Precisar Falar Muito
• Escuta Ativa: A Técnica Simples Para Ser O Mais Inteligente Da Sala
• Introvertido em TI: Demos e Ansiedade
