Doze documentos canônicos do ciclo inicial de qualquer projeto sério — discovery, design, requirements, operações. Cada um com quando usar, estrutura típica, e template copiável. Pensado para evitar a página em branco que paralisa o início.
O início de projeto é onde mais se ganha ou perde tempo. Documentos bem estruturados nos primeiros dias evitam retrabalho, alinham stakeholders, e deixam rastros para quem chega depois. Esta página reúne doze templates do que se vê em times maduros — cada um pronto para copiar, adaptar, e usar. Não são doze documentos obrigatórios em todo projeto: são doze ferramentas que valem conhecer para escolher quais aplicar em cada situação.
Documentos da fase inicial — antes de design técnico, antes de código. Alinhar problema, usuários e stakeholders.
Síntese do projeto em uma página: problema, solução, métricas. Forçar a clareza antes de investir em detalhe.
Documento canônico de produto: o quê está sendo construído, para quem, e por quê. Source of truth para PM/Eng/Design.
Mapeamento de stakeholders e matriz RACI (Responsible/Accountable/Consulted/Informed). Evita "esqueci de avisar o time X".
Depois do "o quê", antes do código. Onde trade-offs viram explícitos e decisões ficam rastreáveis.
Proposta técnica antes de mudança não-trivial. Articula alternativas, trade-offs, e plano de implementação.
Registro de decisão arquitetural. Diferente do RFC (proposta), ADR é a decisão tomada — para que daqui a 2 anos alguém entenda o porquê.
Primeira coisa a desenhar em sistema novo. Mostra o sistema como caixa única, atores, e sistemas externos. Simon Brown.
Análise sistemática de ameaças via STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation). Microsoft + Adam Shostack.
Tradução de PRD em itens acionáveis. Onde o time concorda no detalhe do que "pronto" significa.
Formato canônico "As a... I want... So that..." + acceptance criteria em Given/When/Then. Mike Cohn + BDD.
Requisitos não-funcionais sistematizados: performance, disponibilidade, segurança, observabilidade, compliance. ISO/IEC 25010.
Acordo do time sobre o que é "pronto para entrar em sprint" e "pronto para fechar". Evita "achei que estava pronto".
Pensados antes de incidentes (não durante). Onde sistema vive de verdade.
Estes templates não são para serem usados todos em todo projeto. São ferramentas. Use o critério da ocasião: projeto pequeno pode bastar one-pager + ADR + runbook minimalista; projeto grande pede a coleção completa. A regra geral é copiar o template, deletar o que não se aplica, preencher o resto. Documento perfeito não existe; documento útil é o que evita conversa repetida e captura decisões para quem vier depois. Quando em dúvida, escreva.
Cada template usa formatos do mercado (Markdown, Gherkin,
Mermaid) — copie, adapte, e versione no seu repo
(docs/templates/ é convenção comum).