Claude e a Análise de Retrospectivas: Aprendizados e Ações

Há uma coisa que os PMs fazem que ninguém coloca em uma descrição de trabalho. A cada duas semanas, após uma retro, você sinaliza três ou quatro itens na sua cabeça como coisas a observar. Então, um sprint passa. Depois outro. Três meses depois, você está em uma revisão de liderança, alguém pergunta "X está melhorando ou piorando?", e você responde com base na intuição porque não há tempo para ler 12 retros antes da reunião.

As retros estão lá. Os dados estão bons. O trabalho de lê-los não está.

Eu trabalho na Kollabe, então leve isso com a devida cautela. Os padrões se generalizam; se sua ferramenta de retro expõe uma API ou um servidor MCP, o fluxo de trabalho abaixo funciona contra o que você tiver. Vou manter os prompts moldados para o fornecedor para que sejam fáceis de trocar.

O que eu mudei

Nos últimos dois meses, tenho conduzido a maior parte do meu trabalho adjacente a retros através do Claude com três servidores MCP conectados: Kollabe (para a superfície de retro e itens de ação), Atlassian (para Jira) e GitHub. O MCP do Kollabe expõe cerca de 50 ferramentas que mapeiam 1:1 para a API REST pública, então qualquer coisa que eu possa fazer na interface, Claude pode fazer como eu. Isso inclui ler cada retro e item de ação nos espaços aos quais tenho acesso.

O fluxo de trabalho da segunda-feira de manhã é um prompt. Ele faz quatro coisas em ordem, depois para e espera por mim.

1. Lê as últimas 26 semanas de retros nos espaços que possuo.
2. Puxa todos os itens de ação abertos, incluindo aqueles que estão silenciosamente mais velhos do que as pessoas que os criaram.
3. Lê os standups do último sprint para sinal adicional.
4. Escreve um resumo estruturado: o que está melhorando, o que está piorando, quais itens de ação estão obsoletos e uma linha "aqui está o que eu perguntaria à equipe sobre isso esta semana."

Então ele fica em silêncio e me deixa pensar.

A metade do item de ação: a parte que falha silenciosamente

Aqui está a coisa embaraçosa que ninguém diz em voz alta sobre retros: a maioria dos itens de ação não é concluída porque sai da memória de trabalho. A retro acontece, alguém escreve "investigar CI instável", isso é atribuído, dois sprints passam, a pessoa que o possuía mudou de equipe, e o item está tecnicamente aberto na ferramenta para sempre. Leia um painel limpo de "itens de ação abertos" na maioria das equipes e você encontrará que a idade mediana é algo como 47 dias.

A solução não é um rastreador melhor. A solução é alguém ler cada item de ação aberto uma vez por semana e fazer três perguntas: ainda é relevante, foi realmente feito silenciosamente, quem realmente o possui agora.

Eu faço Claude fazer isso. O prompt é curto:

Para cada espaço que possuo, use `action_item_list` (status = PENDING).
Para cada item mais velho que 21 dias:
1. Use `search` (Kollabe MCP) para procurar atividade nas palavras-chave do item em retros, standups e Jira via o MCP Atlassian — últimos 30 dias.
2. Se o item aparecer resolvido ou substituído, proponha marcá-lo como CONCLUÍDO com uma nota de uma linha explicando o que o fechou.
3. Se o responsável mudou de espaço ou não esteve ativo em standups por >14 dias, sinalize para reatribuição.
4. Caso contrário, proponha um comentário de lembrete de uma frase de mim, via `action_item_create_comment`.
Mostre-me uma tabela. Espere eu aprovar cada linha antes de qualquer gravação.

Ele produz uma tabela. Na maioria das semanas, eu aprovo cerca de 80% dela e rejeito o resto. Os rejeitados são os mais interessantes. Eles são itens que a IA achou que estavam resolvidos, mas eu sei que não estão, o que geralmente significa que temos uma decisão não documentada que deveria se tornar uma documentada.

Dois meses depois, a idade mediana dos itens de ação em nossos espaços é de 14 dias, não 47. Ninguém teve que incomodar ninguém. Ninguém teve que construir um painel.

A diferença de seis meses: a parte que é nova

Esta é a parte que subestimei quando a conectei. O MCP do Kollabe tem uma ferramenta de search que executa busca semântica em cada retro, standup, item de ação e rodada em seus espaços, apoiada por embeddings pgvector. Mais rápido do que rolar não é realmente o ponto. O ponto são as perguntas que você nunca teria feito porque o trabalho não valia a pena.

O que eu pergunto, toda segunda-feira, no mesmo prompt:

Usando o MCP do Kollabe `search` e `retro_list` + `retro_get`, escaneie as últimas 26 semanas de retros em meus espaços. Produza:

1. Os cinco temas que apareceram nos primeiros 3 meses, mas NÃO apareceram nas últimas 6 semanas. (Coisas que foram silenciosamente consertadas.)
2. Os cinco temas que apareceram em 3+ retros nas últimas 6 semanas e não eram um problema há 6 meses. (Coisas que silenciosamente pioraram.)
3. Qualquer tema que apareceu, foi resolvido e voltou.
4. Duas perguntas que valem a pena perguntar à equipe esta semana, dado (1) - (3).

Na primeira vez que executei, a IA destacou três coisas que realmente me surpreenderam. Uma foi uma correção que eu havia esquecido que a equipe havia feito silenciosamente. O fluxo de implantação tinha sido uma reclamação crônica durante o primeiro trimestre e simplesmente parou de ser uma reclamação, o que significava que o trabalho de janeiro de alguém havia valido a pena e eu não havia agradecido a eles. Uma foi uma lenta deriva nos tempos de espera da revisão de código, muito silenciosa para parecer um problema em qualquer retro, obviamente um problema quando você viu três retros seguidas mencioná-lo sem escalonamento. A terceira foi uma frustração recorrente sobre a sobrecarga de reuniões que havia sido resolvida uma vez e estava voltando.

Foi desconfortável. Também foi o ponto de dados mais útil que recebi sobre minha equipe em um ano. Eu enviei um reconhecimento público ao desenvolvedor que consertou as implantações naquela tarde.

Por que MCP e não "eu apenas construo um script"

Eu trabalho com essas coisas para viver e, de fato, construí a versão do script. Funciona. Também é rígido: toda vez que quero fazer uma pergunta ligeiramente diferente, eu edito o código. A versão MCP me permite escrever a pergunta em inglês na segunda-feira de manhã e fazê-la rodar contra a mesma superfície de API que meu script Python teria usado.

A coisa que torna isso real, não um truque de salão, é que a API pública e o servidor MCP são a mesma superfície. Cada ferramenta MCP está registrada contra um /api/v1/* manipulador, com os mesmos esquemas Zod e as mesmas verificações de acesso. Então, quando eu prototipo algo no chat que acaba sendo útil semanalmente, posso transferir as mesmas chamadas para um Worker agendado, executá-lo na sexta-feira às 16h, e enviar um e-mail para mim com o resumo. O prompt e o script compartilham uma interface.

Isso importa para PMs técnicos especificamente. Você vai querer graduar as coisas que funcionaram em algo que funcione sem você. Com um MCP que espelha uma verdadeira API REST, você pode —