Um guia prático do Day Zero Playbook
As sete etapas que todo projeto percorre antes de codar, do BRD ao Go/No-Go: os gates, os papéis, o tailoring, o baseline de segurança e os templates que mantêm negócio e tecnologia no mesmo trilho.
As vantagens de preparar o projeto antes de codar
Já vi projeto morrer de repositório cheio. Commit todo dia, board se mexendo, todo mundo ocupado pra valer. E morto mesmo assim, porque ninguém combinou o que ia ser construído antes da primeira linha entrar. Pro negócio, “pronto” queria dizer uma coisa. Pra quem codava, outra. Essa diferença ficou enterrada por meses, até estourar num go-live que virou madrugada.
O Day Zero Playbook, o DZP, nasceu pra impedir esse fim. Ele lista os documentos obrigatórios e o fluxo de aprovação que um projeto cruza antes de existir código, do primeiro aperto de mão com o negócio até o gate que libera (ou trava) o desenvolvimento. São sete etapas, do BRD ao Go/No-Go. Não vou percorrer uma por uma aqui, isso fica pra outro texto. Minha pergunta é outra: por que raios adotar mais processo num mundo que já vive reclamando de processo?
Porque processo certo, na hora certa, sai mais barato que o caos. Confesso que demorei pra engolir isso. Por muito tempo, documento antes de código me cheirava a burocracia de quem gosta mais de reunião do que de editor. Mudei de ideia no susto, depois de pagar a conta do jeito caro umas boas vezes (mais do que eu queria admitir). Deixa eu mostrar onde ela fecha.
O retrabalho que nem chega a nascer
A vantagem mais óbvia também é a mais subestimada. Quando negócio e tecnologia botam a assinatura no mesmo papel antes do código, o desencontro aparece numa reunião de uma hora. Não num sprint inteiro no lixo.
Pensa no custo de descobrir tarde. Um requisito mal entendido vira código; o código vira teste; o teste passa, porque testa a coisa errada; e aquilo desliza pra produção com cara de saudável. Seis semanas depois o usuário abre a tela: “não era isso”. Aí você já não corrige um parágrafo. Você desfaz seis semanas de trabalho de um monte de gente.
O DZP não faz mágica. Só empurra a descoberta do erro pro ponto mais barato da linha do tempo: o papel.
Decisão com dono e com rastro
Tem uma pergunta que assombra todo sistema com idade: “quem decidiu isso, e por quê?”. Você tromba com uma escolha estranha no código, um banco que não faz sentido, uma integração torta, e não há ninguém pra responder. A pessoa saiu. A conversa aconteceu num corredor qualquer. O motivo evaporou.
O playbook mata isso com duas peças simples. A rastreabilidade prende cada requisito a um pedaço do design e a um caso de teste, então nada fica solto. E o ADR, o registro de decisão de arquitetura, grava a escolha no instante em que é tomada, com contexto e as alternativas que ficaram pra trás. Um ano depois, quando alguém for questionar, a resposta já está escrita. Decisão com dono. Com data. Com motivo.
O conhecimento fica no artefato, não na pessoa
Essa, arrisco dizer, é a que menos gente valoriza e mais vira o jogo. O DZP cobra que o documento de cada fase seja completo o suficiente pra outro time tocar a fase seguinte sem depender de quem escreveu a de antes. Handoff autossuficiente, é o nome que dão.
Parece detalhe. Não é. É isso que te dá liberdade pra trocar de time no meio do caminho. O desenho sai de um time interno, uma consultoria escreve o código, um parceiro assume a operação, e nada disso apaga a memória do projeto, porque o saber vive no artefato, não na cabeça de um dev que pode pedir as contas numa sexta.
Quem já herdou sistema sem documentação sabe o tamanho desse alívio. Peguei um, faz uns anos, cujo acervo inteiro era um README de três linhas e um autor que já tinha ido embora fazia tempo. Passei quase um mês só pra entender por que uma rotina disparava às 3 da manhã. O caminhão da desgraça, aquele que atropela seu único especialista, deixa de ser risco.
Aprovar deixa de ser política
Como se aprova um documento hoje? No geral, alguém graúdo lê na diagonal, gosta ou não gosta, e libera. Aprovação por simpatia. Por hierarquia. Por cansaço (esse costuma vencer).
O playbook troca esse jogo por gates objetivos. Toda etapa carrega um critério de entrada e um de aceite, escritos, checáveis. Ou cumpre a lista, ou não cumpre. E existe uma regra que eu queria ver em mais lugar: quem produz um artefato jamais é quem aprova. Segregação de funções, que nem na contabilidade. O autor não carimba o próprio serviço.
O efeito colateral é político, no bom sentido. A briga sai do “não gostei” e vai pro “o critério tal não foi atendido”. Dá pra discordar de um critério. Já de um achismo, difícil.
O incêndio que você apaga antes de ele começar
Segurança, plano de recuperação de desastre, observabilidade. Sabe quando esse trio costuma entrar na conversa? Na véspera do go-live. Ou pior: depois do primeiro incidente. Tarde, no susto, remendando uma arquitetura que já endureceu.
O DZP puxa essas decisões pra cima da mesa de desenho, lá no HLD e no LLD. Onde os logs vão parar, como o sistema levanta depois de cair, qual a ameaça óbvia que precisa ser fechada antes de ontem. Pensado no design, isso custa umas horas de conversa. Pensado em produção, cobra um plantão, a confiança do cliente e, vez ou outra, um vazamento de dados estampado no jornal.
Operabilidade não é enfeite pra pendurar no fim. É estrutura. E estrutura entra na fundação.
Rigor não é a mesma coisa que peso
Aí vem a objeção que todo mundo levanta, com razão: “isso não vai transformar um projeto de duas semanas num inferno de papelada?”.
Não. E foi exatamente isso que me fez respeitar o playbook. Ele ajusta o rigor à criticidade do que está em jogo. Coisa pequena, de baixo risco, corre numa trilha leve: BRD e desenho espremidos num documento de uma página. Já um sistema crítico, que mexe com dinheiro ou com gente, encara o fluxo inteiro. O peso do processo acompanha o tamanho do estrago possível.
Duas peças nunca saem de cena, não importa o tamanho: o requisito de negócio e o Go/No-Go. Faz sentido. São as que respondem “o que a gente quer” e “dá pra começar”.
O direito de dizer não
O Go/No-Go é a etapa que eu mais defendo, porque devolve uma decisão que quase sempre roda no automático: a de começar.
Na prática, um tanto de projeto começa por inércia pura. Foi aprovado lá atrás, tem orçamento, então vai. Ninguém freia no último instante pra perguntar se ainda faz sentido, se os riscos estão cobertos, se o time está de pé. O gate força essa pergunta. E concede, no papel, o direito de dizer “não” ou “ainda não”.
Dizer não a tempo é barato. Fazer isso com metade do orçamento já queimado é caríssimo. O DZP transforma o pontapé do desenvolvimento naquilo que ele sempre devia ter sido: uma escolha consciente, não um piloto automático.
Pago adiantado
Não vou te empurrar facilidade. Preparar um projeto desse jeito dá trabalho, e o trabalho pinta logo no início, bem quando geral está doido pra ver a coisa andar. É a parte desconfortável.
Só que trabalho de software não some quando você faz vista grossa. Muda de lugar e cobra juros. Compostos, pra ser exato. Ou você paga adiantado, escrevendo e alinhando enquanto ainda é barato mexer, ou paga lá na frente, refazendo código, correndo atrás de incêndio e caçando quem foi que decidiu o quê. Já paguei das duas formas. Adiantado dói bem menos.
Se você toca projetos e vive apagando os mesmos incêndios, abre o playbook e olha com honestidade: quais dessas contas você anda pagando com juros? Provavelmente mais de uma.
