do kick-off ao workshop tático: um guia para aterrissar iniciativas para implementação
muitas vezes há uma lacuna entre a definição de uma solução e o momento em que um time efetivamente começa a trabalhar nela. é um espaço cheio de ambiguidades, onde o alinhamento se perde e apropriação fica difícil.
para navegar nesse terreno, tenho definido uma etapa com duas partes sequenciais: um kick-off focado em alinhamento e um workshop tático para detalhamento, ambos desenhados para gerar clareza e dar autonomia ao time. este texto é uma tentativa de organizar e compartilhar esse modelo, para que sirva de guia para outros times e facilitadores.
essas dinâmicas se integram ao processo foco & fôlego, que é uma variação do processo shape up. e fucionam seguindo o modelo de processo explicitado em meu site ops.timeproduto.com.br, justamente na etapa “mapear e sequenciar escopos técnicos”.
índice
aqui está uma proposta de sumário (toc) para o texto:
parte 1: o kick-off da iniciativa (a preparação do terreno)
preparação (antes do kick-off)
a reunião de kick-off
leitura silenciosa da proposta
apresentação do contexto
discussão e entendimento
parte 2: o workshop tático (caindo na real)
a diferença para sprint planning e refinamento
o que são "escopos"?
roteiro do workshop
alinhamento e contexto
geração e refinamento de insumos
processamento com a i.a.
análise crítica e ajuste do plano
usando uma ferramenta para a inspeção focada
fechamento e próximos passos
parte 1: o kick-off da iniciativa (a preparação do terreno)
o objetivo do kick-off não é detalhar tarefas, mas garantir que todos compartilhem do mesmo entendimento sobre o problema, os objetivos e as fronteiras da solução. é aqui que o time pode confirmar se tem clareza suficiente para iniciar os trabalhos.
preparação (antes do kick-off)
responsáveis:
product manager, product designer e tech lead (esses papéis podem estar entre 1 a 3 pessoas).
o que fazer:
o trabalho aqui é preparar o terreno para uma boa conversa. isso significa chegar com uma proposta de iniciativa clara que cubra o problema a ser resolvido, o contexto, o conceito de solução e restrições intencionais. o foco não é trazer uma solução técnica, mas sim uma solução bem formulada. a tríade (pm, pd, tl) se prepara para ser uma fonte de consulta para o time.
veja as etapas da trilha de definição de solução no site ops.timeproduto.com.br para descobrir prompts e ferramentas para ajudar com isso.
a reunião de kick-off (90-120 minutos)
responsáveis:
product manager com apoio de product designer e tech lead (esses papéis podem estar em uma pessoa)
participantes:
time de implementação
1. leitura silenciosa da proposta (30 min)
para o time: todos leem, individualmente e em silêncio, a proposta da iniciativa. o objetivo é absorver o contexto sem a influência da opinião dos outros, permitindo que cada um formule suas próprias perguntas.
uma nota para quem facilita: proteja o silêncio. essa fase é essencial para que todos, especialmente os mais introspectivos, possam formular suas próprias perguntas e reflexões.
2. apresentação do contexto (20-30 min)
para o time: pm e pd lideram a apresentação, focando na história por trás da iniciativa: o problema delimitado e o conceito da solução. a tech lead complementa com o contexto técnico de alto nível que for relevante, mas sem prescrever uma solução. o objetivo é dar ao time o máximo de contexto para que possam fazer boas perguntas.
uma nota para quem facilita: seu papel é garantir que a apresentação seja um ponto de partida para a conversa. a ênfase é no "porquê" e no "o quê", não no "como". a tríade de papéis está ali para servir ao time com informações, não para entregar um plano.
3. discussão e entendimento (30-45 min)
para o time: agora, o diálogo é aberto e liderado pelas perguntas do time. o objetivo é que vocês saiam daqui sentindo que entendem a iniciativa e estão prontos para começar.
uma nota para quem facilita: guie a conversa para que o time seja o protagonista. as perguntas deles são o insumo mais valioso. o papel da tríade é responder, clarificar e, o mais importante, ouvir. use estas perguntas-guia para o time:
"qual o principal problema que estamos resolvendo com isso?"
"quais são os 2 ou 3 resultados ou entregáveis mais importantes desta iniciativa?"
"quais os maiores riscos, ambiguidades ou preocupações que vocês antecipam?"
"qual é o núcleo essencial da solução para ser 'boa o suficiente'? o que não pode faltar de jeito nenhum?"
ao final, pergunte diretamente: "vocês sentem que têm clareza sobre o problema, a solução, o escopo e o que significa 'bom o suficiente' para podermos avançar?"
o kick-off termina quando o time se sente confiante para pegar o bastão. o artefato de saída é um time alinhado e pronto para o próximo passo: o workshop tático, onde eles mesmos irão detalhar o plano de ataque.
parte 2: o workshop tático (caindo na real)
com o "o quê" e o "porquê" alinhados no kick-off, o workshop tático foca no "como". é aqui que o time de implementação se apropria da iniciativa e a transforma em um mapa de escopos.
antes de entrar no roteiro, vale a pena explicar dois conceitos.
a diferença para sprint planning e refinamento
minha impressão é que rituais como a “sprint planning” focavam em selecionar quantas pequenas tarefas de uma lista o time faria em um ciclo. o "refinement" preparava itens futuros dessa mesma lista.
no workshop tático, a dinâmica é outra. o time não chega com uma lista de tarefas pronta, nem recebe um plano pré-definido. eles chegam com o contexto da iniciativa, alinhado no kick-off. o workshop é o momento em que o time, como especialista do domínio, gera os insumos (as tarefas e riscos) e, em colaboração com a ia, produz o primeiro rascunho dos escopos e da sequência de implementação. a apropriação acontece na criação, não no recebimento do plano.
o que são "escopos"?
pense em escopos como fatias integradas do projeto (incluindo front-end, back-end, etc.) que podem ser trabalhadas de forma relativamente independente.
eles representam partes significativas do problema, finalizáveis em poucos dias.
são maiores que tarefas, mas muito menores que o projeto inteiro.
eles emergem do entendimento das interdependências reais, não de um agrupamento arbitrário.
eles se tornam a linguagem macro para comunicar o progresso.
workshop (90 minutos)
responsáveis:
tech lead
participantes:
time de implementação
1. alinhamento e contexto (5 min)
para o time: o facilitador dará as boas-vindas, explicando a nova dinâmica. "nosso tempo é curto e nosso objetivo é focado. hoje, nosso papel é duplo: primeiro, vocês são os especialistas técnicos e gerarão a lista de tarefas e identificando os riscos. depois, seremos um conselho técnico sênior, revisando e ajustando um plano de ataque que será proposto por uma ia. nosso foco é na validação e na decisão, não no agrupamento manual."
uma nota para quem facilita: defina a expectativa corretamente. o time não vai fazer o trabalho braçal de organização, mas o trabalho intelectual de análise crítica, que é ainda mais importante. a ia é uma ferramenta para alavancar a expertise do time, não para substituí-la.
2. geração e refinamento de insumos (25 min)
para o time: esta fase é a mais crucial, pois a qualidade do plano da ia depende diretamente da qualidade dos nossos insumos.
sprint de tarefas (15 min): em um quadro branco digital, cada um irá listar as tarefas que imagina serem necessárias. importante: se uma tarefa parecer particularmente incerta, complexa ou com dependências desconhecidas, adicione a marcação [arriscada] ao final dela.
refinamento rápido (10 min): agora, em grupo, vamos revisar a lista completa. o objetivo não é agrupar, mas sim clarificar, remover duplicatas e, principalmente, confirmar se as tarefas marcadas como [arriscada] fazem sentido para todos.
uma nota para quem facilita: proteja esta fase. uma lista de tarefas bem definida e com riscos bem sinalizados é 80% do caminho para um bom resultado. guie a conversa no refinamento para garantir que as tarefas estejam claras o suficiente para a ia entender.
3. processamento com a i.a. (10 min)
para o time: agora, vamos alimentar a ia com nosso trabalho. o facilitador irá copiar toda a lista de tarefas, pedir para o líder técnico definir a estratégia de sequenciamento (o padrão será riskiest-first) e usar o prompt para gerar um mapeamento inicial: prompt llm de mapeamento e sequenciamento.
uma nota para quem facilita:
seja transparente: compartilhe a tela. copie a lista de tarefas do quadro branco. cole-a no campo {tarefas} do prompt. pergunte ao time se a estratégia deve ser riskiest-first ou ui-first.
defina os inputs:
estrategia_sequenciamento:
`riskiest-first` (padrão): escopos e tarefas arriscas vêm primeiro.
ou `ui-first`: escopos que permitem entrega de UI mais rápido para validação
modo_analise:
`estrito`: i.a. usará informação que o time enviou do que é arriscado e não fará nova sugestões do que parece arriscado.
ou, `sugestivo` (padrão): além de usar a informação de input do time do que é arriscado, mas também fará sugestões do que parece arriscado.
execute o prompt: cole o prompt completo em um llm de reasoning avançada e execute-o. o tempo de geração da resposta pode ser usado para uma pequena pausa.
apresente o resultado: cole a resposta da llm de volta no quadro branco, em uma área dedicada, para que todos possam ver e analisar.
4. análise crítica e ajuste do plano (40 min)
para o time: este é o nosso principal trabalho hoje. com o mapeamento e sequenciamento gerado pela ia à nossa frente, vamos atuar como julgadores sênior. as perguntas que nos guiam são:
os escopos fazem sentido? a ia agrupou as tarefas como escopos significativos?
a sequência proposta é realista? esquecemos de alguma dependência crítica?
a forma como a ia tratou as tarefas [arriscada] está correta?
se uma parte do mapeamento parecer estranha ou gerar dúvidas dos riscos, podemos fazer uma inspeção focada de 5 minutos no código para validar nossas suspeitas e corrigir o plano da ia.
uma nota para quem facilita: guie a análise. comece pelos escopos, depois pela sequência de alto nível, e só então mergulhe nos detalhes de um ou dois escopos iniciais. use a "inspeção focada" como um recurso cirúrgico para resolver as divergências mais importantes. o objetivo não é reescrever o plano, mas fazer ajustes pontuais e validar as premissas.
usando uma ferramenta para a inspeção focada:
para tech lead e time quando a necessidade de uma "inspeção focada" surgir, este é o momento de usar uma ferramenta como deepwiki para questões arquiteturais ou copilot de i.a. para vasculhar código específico, como cursor, gemini code assist, augment, cline ou roocode.
uma nota para quem facilita:
enquadre a ferramenta: apresente-a como um "sonar". ela nos ajuda a ver a complexidade do terreno, mas não nos diz para onde navegar. o objetivo é diagnosticar o risco, não gerar a solução.
a dinâmica: um dev compartilha a tela e formula, em voz alta, uma pergunta para a ia da ferramenta.
bons prompts (diagnóstico): "explique as responsabilidades desta classe." ou "se eu alterar este método, que outros arquivos são impactados?".
maus prompts (solução): "me dê o código para refatorar esta classe.".
seu papel: mantenha o timebox de 5 minutos e, após a resposta da ia, pergunte ao dev: "isso faz sentido para você? o que a ia pode não estar vendo?". a análise humana é sempre a palavra final.
5. fechamento e próximos passos (10 min)
para o time: vamos revisar o mapeamento e sequenciamento, agora ajustados e validados por nós. saímos daqui com uma clareza sobre o primeiro escopo a ser implementado e suas tarefas iniciais. este artefato será nosso guia para começar o trabalho.
uma nota para quem facilita: termine com uma ação concreta. "pessoa xyz, com base no mapeamento que refinamos, você pode criar as primeiras tarefas dentro do escopo 'x' em nosso board?". salve o plano finalizado em nossa ferramenta. ele é o resultado da colaboração entre a inteligência do time e a capacidade de processamento da máquina.