Retrospectiva de projeto: perguntas, pauta e modelo

O que é uma retrospectiva de projeto?

A retrospectiva é uma reunião para revisar a experiência da equipe em um período e decidir o que mudar. Pode acontecer depois de um projeto, etapa ou ciclo de trabalho. O foco é a colaboração, os processos e as condições, sem procurar culpados.

Uma reunião de acompanhamento trata do que terminou ou está atrasado. Na retrospectiva, pergunte por que o trabalho ocorreu assim e qual pequeno passo ajudaria da próxima vez. Listar dificuldades é só o começo. Combine um resultado verificável.

Evite transformar a reunião em defesa de relatório diante da liderança. Se as pessoas temem punição por falar abertamente, podem omitir detalhes úteis. Explique o objetivo e as regras com antecedência.

Como preparar a equipe

Delimite o tema: “preparação e lançamento do webinar de treinamento”, por exemplo, em vez de “tudo que funciona mal”. Convide participantes do processo com perspectivas diferentes.

Peça a cada pessoa um caso concreto: o que aconteceu, quando, qual foi o efeito e o que ajudou. Reúna anotações antes e dê alguns minutos para reflexão silenciosa, para a conversa não começar só pela opinião de quem mais fala.

Tenha à mão plano, histórico de tarefas, versões aprovadas ou mensagens para conferir fatos. A falta de registro não mostra que nada aconteceu. Um comentário não salvo não prova que ninguém agiu.

Pauta e perguntas da retrospectiva

A distribuição de tempo é um exemplo para uma equipe pequena. Adapte se necessário. Um assunto complexo pode pedir uma reunião separada.

Se começarem a discutir quem costuma errar, volte ao caso concreto. Em vez de “Nunca recebemos material decente”, pergunte “O que faltou dessa vez e quando percebemos?”.

Não tente resolver tudo em uma reunião. Escolha um problema que afete o trabalho e tenha um próximo passo viável. Registre os outros assuntos à parte para que não se percam nem virem promessas sem responsável.

Da reclamação a uma mudança verificável

A equipe preparava um webinar. Um dia antes do lançamento, descobriu que algumas alterações aprovadas não estavam na apresentação. Na retrospectiva, alguém disse: “Tivemos que refazer tudo de última hora outra vez.” A frustração não indicava uma solução.

As pessoas abriram os materiais e reconstruíram o caso. Comentários chegaram em dois chats, algumas alterações foram feitas, mas faltava um status compartilhado. A equipe supôs que uma lista única revelaria omissões antes da aprovação final.

Combinaram testar no próximo webinar de treinamento. Marina, a coordenadora, cria a lista antes da preparação. Cada comentário recebe “aceito”, “em andamento”, “verificado” ou um motivo para a recusa. Um dia antes do lançamento, a edição compara a lista com a apresentação final.

Na próxima retrospectiva, a equipe verifica se houve alterações aprovadas e esquecidas e se foi fácil manter a lista. Se a falha se repetir, investigue outras causas, como instruções pouco claras ou mudanças tardias, antes de culpar a ferramenta.

Modelo de resultado da retrospectiva

Projeto e período:
Participantes:
O que ajudou e queremos manter:

Problema escolhido:
Observações e exemplos concretos:
Causa possível:
O que ainda não sabemos:

Experimento:
Responsável:
Prazo de preparação:
Onde registrar o progresso:
Como avaliar o resultado:
Quando discutir o resultado:
Decisão após a verificação: [manter / mudar / parar]

Outros assuntos para a próxima conversa:

Envie o resumo aos participantes e deixe que corrijam imprecisões. Se faltar uma decisão de quem não estava presente, registre essa dependência. Obtenha o acordo da pessoa antes de atribuir a tarefa ou registrar uma promessa em seu nome.

• O escopo está claro.
• Os fatos estão separados das suposições.
• A equipe sabe o que quer manter.
• Foi escolhida uma mudança viável.
• A pessoa responsável aceitou a tarefa.
• Há uma data para verificar o resultado.