Phase Playbook¶

1. Objetivo¶

Este documento transforma o processo em um playbook simples e executavel.

Ele descreve:

pergunta central de cada fase
entradas
participantes
atividades
saidas
criterio de transicao

2. Visao geral¶

flowchart LR
    S[SOW] --> D[Discovery]
    D --> I[Inception]
    I --> M[Implementation]
    M --> O[Operate and Learn]
    O --> D
    O --> I

3. SOW¶

Pergunta central¶

qual problema ou objetivo de negocio justifica iniciar este trabalho

Participacao dominante¶

Cliente: muito alta
PM: alta
LI: media
ET: baixa

Entradas¶

demanda inicial
contexto institucional
restricoes conhecidas
compromisso ou expectativa de entrega

Atividades principais¶

entender motivacao e objetivo
delimitar problema inicial
explicitar restricoes relevantes
alinhar criterio inicial de sucesso

Saidas esperadas¶

escopo inicial
contexto
premissas
restricoes
objetivo do trabalho

Criterio para seguir¶

O time consegue explicar:

por que isso importa
para quem isso importa
quais limites iniciais ja sao conhecidos

4. Discovery¶

Pergunta central¶

qual problema precisa ser entendido e por que ele importa

Participacao dominante¶

Cliente: alta
PM: muito alta
LI: media
ET: baixa a media

Entradas¶

SOW
entrevistas
materiais institucionais
processos atuais
dores observadas

Atividades principais¶

mapear stakeholders
mapear dores
modelar processo ponta a ponta
identificar dominios do problema
registrar restricoes e excecoes

Saidas esperadas¶

visao do problema
mapa de dominios
glossario
dores por stakeholder
mapa de processo
perguntas em aberto

Criterio para seguir¶

O time consegue explicar:

qual problema esta atacando
quais dominios importam
quais dores e restricoes precisam orientar a solucao

5. Inception¶

Pergunta central¶

qual recorte de solucao vale a pena iniciar agora e com quais limites

Participacao dominante¶

Cliente: media
PM: muito alta
LI: muito alta
ET: media

Entradas¶

saidas do discovery
restricoes de negocio e tecnologia
riscos conhecidos
componentes ou repositorios existentes

Atividades principais¶

propor recorte inicial
definir macro-organizacao da solucao
identificar capacidades prioritarias
avaliar viabilidade
mapear riscos, dependencias e integracoes
preparar handoff para implementacao

Saidas esperadas¶

proposta macro de solucao
racional da proposta
leitura do estado atual e convergencia
handoff para implementacao
ADRs candidatas

Criterio para seguir¶

O time consegue explicar:

o que entra agora
o que fica fora
por que esse recorte e viavel
como transformar isso em backlog

6. Implementation¶

Pergunta central¶

como transformar o recorte aprovado em incremento entregue e validado

Participacao dominante¶

Cliente: baixa a media
PM: media
LI: muito alta
ET: muito alta

Entradas¶

handoff da inception
backlog inicial
ADRs
repositorios de implementacao
guardrails dos agents

Atividades principais¶

transformar o handoff em backlog executavel no planejamento de implementacao
decompor backlog
implementar
testar
documentar
revisar
implantar
observar feedback

Saidas esperadas¶

backlog executavel rastreavel para issues e repositorios canonicos
codigo
testes
evidencias
documentacao atualizada
incremento validado

Criterio para seguir¶

O time consegue demonstrar:

que o backlog foi convertido em issues rastreaveis
o que foi entregue
como foi validado
que riscos permanecem
que ajustes precisam voltar para backlog, inception ou discovery

7. Ritual de revisao por fase¶

Cada fase deve terminar com uma revisao curta orientada por perguntas.

Revisao de SOW¶

o objetivo esta claro
o problema inicial foi bem delimitado
as restricoes mais obvias foram registradas

Revisao de Discovery¶

o problema esta melhor entendido do que no inicio
o dominio foi organizado sem depender de modulos tecnicos
as dores principais estao visiveis

Revisao de Inception¶

existe recorte inicial claro
existe explicacao coerente da solucao
ha base para decompor backlog

Revisao de Implementation¶

o incremento realmente entrega valor
ha evidencias de validacao
o feedback coletado foi transformado em proximo passo

8. Regra de retorno¶

Retornar de fase nao e falha.

Retornar de fase e o mecanismo correto quando surgem evidencias de que:

o problema foi mal entendido
o recorte ficou inviavel
o backlog nao reflete a realidade
a entrega revelou restricoes antes invisiveis