Pense antes de codar, valide antes de sofrer!

Playbook de criação de projetos de software.

Todo projeto percorre o mesmo caminho antes de qualquer linha de código: da concepção do negócio até a autorização formal para desenvolver, no gate Go/No-Go. O playbook diz quais artefatos esse caminho exige. E quem assina embaixo de cada um.

Nem todo projeto paga o mesmo preço. O rigor escala com a criticidade: em criticidade Baixa, BRD e HLD se resolvem juntos num one-pager, pela Trilha Leve; projetos Críticos percorrem o fluxo inteiro, etapa por etapa, com tudo o que ele prevê. Dois nunca são dispensados: BRD e Go/No-Go.

O workflow

   Etapa 0 · Discovery / Spike ................ opcional
        |
        | alimenta
        v
   Etapa 1 · BRD .............................. aprova: PM + Solicitante
        |
        v
   Etapa 2 · HLD (C4 L1/L2) ................... aprova: Tech Lead Aprovador
        |\
        | \__ pode iniciar após HLD aprovado __
        |                                      \
        v                                       v
   Etapa 3 · LLD/TDD (C4 L3)          Etapa 5 · Bootstrap Técnico
        |                                       |
        v                                       |
   Etapa 4 · SAD (consolidação)                 |
        |                                       |
        +-------------------+-------------------+
                            v
                  Etapa 6 · Go / No-Go
                            |
              +-------------+-------------+
              v                           v
      [ NÃO ] Bloqueado          [ SIM ] Início do Desenvolvimento

Reprovar não é vetar. O artefato volta ao produtor com os motivos escritos, e se a mesma etapa reprovar três vezes o caso sobe para o Time de Arquitetura. A especificação completa está no documento normativo.

Três mecanismos

Gates objetivos	Cada etapa carrega critério de entrada (DoR) e de aceite (DoD), ambos verificáveis, o que tira a aprovação do terreno da opinião.
Segregação de funções	Quem produz um artefato nunca é quem o aprova.
Handoff autossuficiente	O artefato de cada etapa precisa bastar para que outro time execute a seguinte sem recorrer ao anterior. Sem isso, não dá para alternar times internos, contratados e parceiros ao longo do fluxo.

Como usar

Se você vai conduzir um projeto novo

Qual trilha o seu projeto segue? Quem responde é o Capítulo 8. O Capítulo 3 diz quem produz e quem aprova cada passo. Comece por eles, dentro do documento principal.
Cada etapa tem seu template. Copie, preencha os campos <...>, apague as instruções em itálico. O exemplo preenchido serve de gabarito.
Avançar exige DoD atendido e aprovação formal registrada, seja no Repositório de Documentação, a ferramenta que as partes combinaram no início do projeto (Confluence, SharePoint, wiki do Git), seja em e-mail com o solicitante.
A Etapa 6, o Go/No-Go, autoriza ou bloqueia o início do desenvolvimento, e para passar por ela todos os itens obrigatórios, mais os condicionais que se aplicarem, precisam estar concluídos. Com evidência.

Se você é aprovador

O Capítulo 4 descreve o seu papel, o SLA de revisão de 3 dias úteis e o fluxo de reprovação. Uma regra não abre exceção: você nunca aprova um artefato que produziu.

Se você quer só entender o espírito da coisa

Abra o exemplo de Go/No-Go. Siga os links de dentro dele: amarram cada peça do caso de referência.

Escopo e roadmap

Escopo	Status
Day Zero Playbook: prontidão pré-desenvolvimento	Publicado (v1.0)
Segurança: configurações obrigatórias	Em elaboração
Desenvolvimento & Code Review · Deploy & Operação · Encerramento & Handover	Roadmap (pós-Day Zero)

Fora do escopo

Branches, issues, code review, QA e encerramento acontecem depois do Go/No-Go, e o Day Zero Playbook não fala sobre eles. Quem define é a convenção da própria equipe; ao playbook basta que ela esteja registrada no Bootstrap Técnico. Segurança é caso à parte: enquanto o companheiro de Segurança não sai, vale o baseline mínimo do Capítulo 7.

Sobre ágil e burocracia

Não nasceu como reação ao ágil. E não existe para acrescentar controle.

Eu trabalho com ágil. O que o Day Zero cobre vem antes da primeira sprint: o alinhamento entre negócio e tecnologia, que, quando falta, não some por isso, e reaparece lá na frente, no meio do desenvolvimento, em forma de retrabalho. Depois disso, o time segue como já seguia. Aqui termina onde o desenvolvimento começa.

Processo novo também não é. BRD, HLD, LLD/TDD, SAD, ADR, Go/No-Go: tudo isso já existe e já se pratica por aí, quase sempre espalhado e sem dono claro. O Day Zero reúne esses recursos num caminho só, nomeia o produtor e o aprovador de cada passo, e ajusta o rigor à criticidade. Num caso de criticidade Baixa, os dois primeiros cabem numa página.

Se em algum projeto isso estiver produzindo papel no lugar de clareza, uma de duas coisas está errada: a trilha pesou demais para a criticidade daquele caso, ou o próprio playbook precisa mudar. Abra uma issue quando acontecer. O que se quer é um caminho saudável, com menos retrabalho e com o desenvolvimento começando a partir de decisões que já foram tomadas e já têm dono.