Guia prático · Etapa 1 do método
Como fazemos o diagnóstico
Antes de montar um único slide ou exercício, mapeamos o atrito real do squad junto com a liderança. É o documento que sustenta cada escolha depois — e o que evita que a oficina vire conteúdo de prateleira.
Por que o diagnóstico decide tudo depois
A maior parte das oficinas que não engajam não falha na sala — falha antes, na hora de descrever o próprio problema. Quando o pedido é genérico (“melhorar a comunicação do time”), a facilitação acaba adivinhando o que o squad precisa, e o conteúdo sai parecido com qualquer curso pronto.
O diagnóstico é o documento que resolve isso na origem. Ele traduz uma queixa vaga — atrito entre produto e engenharia, decisão que se perde no chat — em situações concretas, critério de sucesso e condições reais do encontro. Uma vez escrito e validado com a liderança, ele vira a régua usada em todas as etapas seguintes: o desenho da oficina, os exercícios escolhidos e o roteiro da condução.
Por isso tratamos o diagnóstico como a primeira etapa do nosso método, não como um formulário de preenchimento rápido. O tempo investido aqui é o que evita retrabalho — e oficina genérica — mais adiante.
As cinco partes de um diagnóstico completo
Situações do dia a dia onde a conversa trava
O que realmente acontece nas dailies, nos code reviews e nas decisões de produto, descrito em momentos concretos — não em qualidade abstrata como “falta comunicação”. Isso também ajuda a distinguir este squad de times parecidos na mesma empresa.
Critério de sucesso depois da oficina
Como o squad vai saber que o combinado pegou. Sem esse critério combinado antes, a avaliação do sprint seguinte tende a virar impressão solta, difícil de justificar para qualquer lado.
Nível de maturidade do time em conversa difícil
Definir se o squad já pratica feedback direto ou está tendo o primeiro contato com isso evita dois erros opostos: uma oficina básica demais para quem já avançou, ou avançada demais para quem ainda está começando.
Comportamentos específicos a trabalhar
Não uma lista genérica de “soft skills”, mas as duas ou três coisas que realmente fazem diferença neste squad — por exemplo, registrar decisão fora do chat, ou dar feedback de code review sem parecer ataque pessoal.
Condições do encontro
Formato remoto ou presencial, duração, tamanho do grupo e quem do squad acompanha depois. Informações práticas que, quando faltam, fazem a oficina perder metade da sala no meio do caminho.
Perguntas que fazemos antes de montar a oficina
Uma conversa curta com o tech lead ou a liderança de produto, guiada por estas perguntas, já resolve boa parte do diagnóstico.
- Por que esse ruído está sendo levado a sério agora — um incidente recente, o crescimento do time ou algo que se repete há tempo?
- O que precisa estar diferente daqui a três sprints para a oficina ser considerada um acerto?
- Quais decisões hoje ficam perdidas no chat e deveriam estar registradas em outro lugar?
- O squad já pratica algum tipo de feedback estruturado, ou este seria o primeiro contato com isso?
- Quem participa do encontro, e quem fora da sala precisa reforçar o combinado depois?
- O que já foi tentado antes para resolver esse ruído, e por que não pegou?