Sobre

Playbook de prontidão de projetos de software. Cobre o intervalo entre a ideia de negócio e o aval que libera o time para desenvolver, dizendo o que precisa existir em cada ponto desse percurso e quem responde por isso.

Por que ele existe

Codar sem alinhamento formal entre negócio e tecnologia sai caro, e a conta chega depois, em retrabalho, em decisões que ninguém assume e em requisitos que ninguém testa. Sempre chega. Três mecanismos respondem a isso:

• Gates objetivos: cada etapa tem critério de entrada (DoR) e de aceite (DoD) verificáveis; aprovação não é subjetiva.
• Segregação de funções: quem produz um artefato nunca é quem o aprova.
• Handoff autossuficiente: o artefato de cada etapa deve bastar para que outro time execute a etapa seguinte sem depender do time anterior. É o que permite alternar times internos, contratados e parceiros ao longo do fluxo.

Vocabulário

Duas numerações convivem no playbook. Capítulos de 1 a 10 são partes do documento; Etapas de 0 a 6 são passos do workflow. Uma referência como “Capítulo 7” aponta para dentro do texto normativo; “Etapa 3”, para um passo do fluxo.

O escopo é a prontidão pré-desenvolvimento. Segurança, deploy, code review, encerramento: tudo isso fica para os companheiros que ainda vêm. Fora daqui.

Versionamento e contribuição

O versionamento é semântico e próprio; o histórico está no CHANGELOG.md. A revisão fica com o Time de Arquitetura, a cada trimestre, alimentada pelas métricas do processo (Capítulo 4.4). Para sugerir mudança, abra uma issue ou procure o time.

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.