📐 Planejamento e arquitetura
Os comandos da família 06: transformar um objetivo em plano com etapas verificáveis, mapear o que depende do quê, desenhar a estrutura e fechar tudo em procedimento repetível.
🏗️ /blueprint — do objetivo ao plano executável
O comando-mãe da família 06. Ele recebe um objetivo e devolve etapas, dependências, recursos, responsáveis, métricas, riscos e a próxima ação — os sete campos que separam um plano de uma lista de desejos.
🧱 Os 7 campos de um blueprint
- •Etapas: cada uma com entregável nomeado — "landing publicada", não "trabalhar na landing".
- •Dependências e recursos: o que precisa existir antes e quem/o quê é consumido.
- •Métricas e riscos: como saber que deu certo e o que pode derrubar.
- •Próxima ação: a única coisa que dá para fazer hoje — sem ela o plano é decorativo.
Novo aqui? Entregável é um artefato que existe ou não existe: arquivo, página no ar, contrato assinado, número atingido. Se não dá para apontar e dizer "está aqui", não é entregável, é atividade.
🎯 Copie e rode
/blueprint para <objetivo em uma frase, com prazo>; etapas com entregável, dependências, recursos, responsável, métrica de sucesso, 3 riscos e a próxima ação de hoje
Como verificar: cada etapa tem um substantivo (o entregável), e a "próxima ação" cabe em uma tarde — se cabe em um mês, é etapa disfarçada.
✓ Blueprint executável
- ✓"Etapa 2: formulário de inscrição no ar, testado com 5 pessoas — depende da etapa 1, dona: Ana, até 12/09."
- ✓Próxima ação: "criar o formulário no Tally e mandar o link pro grupo".
✗ Lista de desejos
- ✗"Fase 2: engajar a comunidade" — sem entregável, sem dono, sem data.
- ✗Próxima ação: "alinhar com o time" — reunião não é ação, é adiamento com agenda.
🗺️ /roadmap + /milestones — sequência verificável
/roadmap organiza o plano no tempo — horizontes, marcos e entregas em sequência. /milestones define os marcos com critério de conclusão: um ponto onde é possível dizer "chegamos" sem discussão.
Horizontes, não datas exatas
Agora (2 semanas) · Em seguida (1-2 meses) · Depois (trimestre). Quanto mais longe, mais grosso o traço.
Marcos com critério binário
"Marco 1: 10 clientes pagantes" — atingiu ou não atingiu. "Marco 1: produto maduro" não é marco, é opinião.
Entregas encaixadas nos marcos
Cada marco puxa 2-4 entregas que o tornam possível. Entrega solta, sem marco acima, é candidata a corte.
🎯 Copie e rode
/roadmap /milestones para <projeto>; horizontes agora/em seguida/depois, 3-5 marcos com critério binário de conclusão e as entregas que cada marco exige
Como verificar: você consegue riscar um marco sem convocar reunião para decidir se foi atingido.
💡 Dica prática
Peça o roadmap com a pergunta "o que precisa ser verdade em 30 dias para o marco de 90 ser possível?". Isso obriga o modelo a encadear de trás para frente — e expõe marcos otimistas.
🔗 /dependencies — mapeie pré-requisitos
Identifica pré-requisitos, bloqueios, ordem de execução e dependências externas — as que não estão sob seu controle e por isso mandam no cronograma inteiro.
Novo aqui? Caminho crítico é a sequência de tarefas dependentes mais longa do projeto. Qualquer atraso nela atrasa o fim; atraso fora dela pode não mudar nada. Saber onde ele passa é saber onde vale gastar atenção.
| Tipo | Exemplo | O que fazer |
|---|---|---|
| Interna, sob controle | Landing depende do texto da oferta | Ordenar; começar pelo bloqueador |
| Externa, previsível | Aprovação do gateway de pagamento (5-7 dias) | Disparar no dia 1, em paralelo com o resto |
| Externa, imprevisível | Resposta de parceiro / liberação de API | Plano B declarado antes de precisar dele |
Exemplo didático: a dependência externa imprevisível é a que decide se o prazo é real.
🎯 Copie e rode
/dependencies para <plano ou lista de etapas>; classifique cada dependência como interna, externa previsível ou externa imprevisível, marque o caminho crítico e sugira o que disparar hoje
Como verificar: as externas aparecem no topo da lista de "disparar hoje" — se estão no fim, o mapa está de cabeça para baixo.
👥 /resources — estime pessoas, dados, orçamento
Estima pessoas, ferramentas, dados, orçamento, infraestrutura e conhecimento necessários. A última categoria é a que todo mundo esquece — e a que mais atrasa.
🧰 Seis categorias, uma pergunta cada
- •Pessoas: quantas horas de quem, em que semana?
- •Ferramentas e infra: o que já temos, o que precisa de assinatura ou setup?
- •Dados: existem, estão limpos, alguém pode acessá-los?
- •Orçamento: quanto sai do caixa antes do primeiro retorno?
- •Conhecimento: o que ninguém aqui sabe fazer ainda — e quanto tempo leva aprender ou contratar?
🎯 Copie e rode
/resources para <plano>; estime por categoria (pessoas, ferramentas, dados, orçamento, infra, conhecimento), marque o que já existe vs. o que falta e o gap mais caro
Como verificar: a coluna "conhecimento" não está vazia. Se está, o modelo assumiu que seu time sabe tudo — e não sabe.
📊 Regra dos 40%
Estimativas iniciais de esforço em projetos de software e conteúdo costumam estourar entre 30% e 50% — mesmo em times experientes. Não é falha moral, é assimetria: o que a gente não sabe que não sabe não entra na conta. Peça a estimativa e depois pergunte "o que faria isso custar o dobro?".
🧱 /architecture — desenhe componentes e interfaces
Define componentes, interfaces, fluxos, responsabilidades e decisões estruturais. Vale para software, mas também para uma operação, um curso ou um negócio: tudo que tem partes que conversam tem arquitetura.
Ilustrativo: a família 06 é uma linha de montagem — o objetivo entra vago e sai como rotina verificável.
Novo aqui? Interface é o contrato entre duas partes: o que uma entrega e o que a outra espera receber. Componente sem interface definida vira "depois a gente vê" — e "depois" é onde os projetos morrem.
🎯 Copie e rode
/architecture para <sistema, produto ou operação>; liste componentes com responsabilidade única, as interfaces entre eles (o que entra, o que sai), os fluxos principais e as 3 decisões estruturais mais difíceis de reverter
Como verificar: cada componente tem UMA responsabilidade descrita em uma frase. Se precisa de "e também", são dois componentes.
💡 Dica prática
Peça as "decisões difíceis de reverter" separadas das demais. Banco de dados, linguagem, plataforma de pagamento e modelo de cobrança merecem red team (Trilha 3); o nome do botão, não.
🔄 /workflow — processo em estados e fluxos
Transforma o processo em estados, entradas, ações, decisões, saídas e exceções. A diferença para um fluxograma bonito está na última palavra: exceções. Processo sem exceções mapeadas quebra na primeira terça-feira.
✓ Workflow operante
- ✓Cada estado tem nome ("aguardando pagamento") e uma condição de saída clara.
- ✓Exceções previstas: "pagamento recusado → notificar em 1h, repetir em 24h, cancelar em 72h".
✗ Fluxograma decorativo
- ✗Caixas com verbos vagos ("processar", "analisar") e setas sem condição.
- ✗Caminho feliz apenas — o erro descobre sozinho para onde ir, geralmente para a caixa de entrada do dono.
🎯 Copie e rode
/workflow para <processo recorrente>; estados nomeados, entrada e saída de cada um, decisões com condição explícita e as 5 exceções mais prováveis com o que acontece em cada uma
Como verificar: dá para desenhar o fluxo sem perguntar nada a quem opera — e as exceções cobrem o que já deu errado nos últimos 30 dias.
📋 /SOP — procedimento padrão repetível
Converte um processo recorrente em passos repetíveis, controles e critérios de qualidade. SOP (Standard Operating Procedure) é o que permite que outra pessoa — ou um agente — faça a tarefa igual a você, sem você.
Novo aqui? SOP (Standard Operating Procedure, procedimento operacional padrão) é a receita completa de uma tarefa recorrente: passos numerados, o que verificar em cada um, e como saber que o resultado está bom. É o documento que você entrega quando vai delegar de verdade.
Gatilho e pré-condições
Quando este SOP roda ("toda segunda às 9h", "ao receber um pedido") e o que precisa estar pronto antes.
Passos numerados com controle
Cada passo termina com uma verificação de 5 segundos: "confirme que o e-mail chegou na caixa de teste".
Critério de qualidade e escalonamento
Como saber que ficou bom — e para quem mandar quando algo sair do previsto.
🎯 Copie e rode
/SOP para <tarefa recorrente>; gatilho, pré-condições, passos numerados com controle em cada um, critério de qualidade do resultado e regra de escalonamento
Como verificar: entregue o SOP a alguém que nunca fez a tarefa e saia da sala. Se voltarem com pergunta, o passo correspondente está incompleto.
⚠️ SOP que ninguém abre
Um SOP de 12 páginas é um SOP de zero páginas. Se o procedimento não cabe numa tela por execução, quebre em dois — ou automatize a parte mecânica (Módulo 4.2, /automate).
✅ /checklist + /sequence — verifique e otimize a ordem
/checklist gera itens objetivos para evitar omissões antes, durante ou depois da execução. /sequence encontra a menor sequência de passos que desbloqueia resultado ou aprendizado real — o antídoto contra planos que começam pelo logotipo.
🎯 Checklist boa vs. lista de tarefas
- •Item binário: "DNS propagado (dig responde o IP novo)" — sim ou não, sem "em andamento".
- •Momento certo: pré-voo (antes), em voo (durante), pós-voo (depois). Misturar os três derruba a adesão.
- •Curta: 5 a 12 itens. Acima disso, vira formulário e ninguém lê.
🎯 Copie e rode
/checklist /sequence para <lançamento ou entrega>; checklist pré/durante/pós com itens binários, e a menor sequência de passos que gera o primeiro resultado ou aprendizado verificável
Como verificar: o primeiro passo da sequência produz algo que você consegue mostrar a alguém hoje — não "configurar ambiente".
💡 Receita composta
Combine com a Trilha 3: /chain(/blueprint -> /premortem -> /checklist). O premortem descobre como o plano falha; a checklist transforma cada modo de falha em item de verificação.
Auto-verificação rápida (opcional): o que torna uma etapa de plano "executável" segundo o /blueprint?
🎓 Resumo do Módulo
Próximo Módulo:
4.2 - Execução e operações — o plano está pronto; agora ele precisa virar ação de hoje, dono, prioridade e monitoramento.