O documento normativo

Artefatos, Documentação e Workflow de Aprovação · v1.0

Como ler este documento. O Day Zero Playbook se divide internamente em Capítulos (1 a 10) e descreve as Etapas (0 a 6) do workflow: tudo o que um projeto resolve antes da primeira linha de código. Referências do tipo “Capítulo 7” apontam para dentro deste documento; “Etapa 3” aponta para uma etapa do workflow. Temas posteriores (segurança, deploy, code review, encerramento) são companheiros no roadmap, tratados fora deste playbook.

Capítulo 1: Visão Geral

Este playbook define os artefatos obrigatórios e o workflow que todo projeto deve seguir antes de qualquer linha de código ser escrita. O objetivo é simples de enunciar e difícil de sustentar: negócio e tecnologia alinhados, cada decisão com rastro, e menos retrabalho nascido de projeto começado às pressas.

As etapas a seguir podem ser executadas por times diferentes (interno, contratado ou time parceiro). Por isso, este playbook adota duas garantias inegociáveis:

• Pacote de handoff autossuficiente: o artefato de cada etapa deve ser completo o bastante para que o time da etapa seguinte continue sem depender do time anterior.
• Segregação de funções: quem produz um artefato nunca é quem o aprova.

1.1 Índice deste documento

1.2 Roadmap (companheiros futuros)

1.3 Fronteira deste documento

Este documento cobre da concepção do negócio até a autorização de início do desenvolvimento (gate Go/No-Go). O que vem depois (padrões de código, fluxo de branches, code review, encerramento) fica fora do escopo do Day Zero Playbook e é governado pelas convenções da própria equipe. No Bootstrap Técnico, registre qual convenção o projeto adota para cada tema:

• Estratégia de branches: a estratégia adotada pela equipe (ex.: Gitflow, trunk-based, GitHub Flow).
• Padrão de issues: o formato adotado pela equipe (ex.: HU/Task/Bug).
• Verificação e encerramento de bugs: o processo de QA e fechamento de bugs adotado pela equipe.
• Segurança (configurações obrigatórias): companheiro de Segurança, em elaboração. Até ele existir, vale o baseline mínimo do Capítulo 7 deste documento.

1.4 O Workflow em um diagrama

   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

Capítulo 2: Princípios do Playbook

Capítulo 3: Papéis e Responsabilidades

3.1 Glossário de papéis

3.2 Matriz RACI por etapa

R = Responsável (produz) · A = Aprova · C = Consultado · I = Informado

Capítulo 4: Workflow Geral

O processo é composto por 6 etapas obrigatórias (1 a 6) e 1 etapa opcional (a Etapa 0, de Discovery). Cada etapa depende da aprovação da anterior. Etapas não podem ser puladas; paralelização só é permitida quando explicitamente autorizada nesta tabela.

4.1 Fluxo de Aprovação, Reprovação e Rework

Toda etapa termina em uma decisão formal do aprovador. O caminho de reprovação é parte do processo:

• Aprovado: registrado no Repositório de Documentação ou por e-mail; libera a etapa seguinte.
• Reprovado: o aprovador registra motivos objetivos (referenciando o critério de aceite da etapa). O produtor corrige e ressubmete.
• SLA de revisão: o aprovador tem 3 dias úteis para revisar cada submissão. Cada aprovador deve ter um suplente designado para não bloquear o fluxo.
• Limite de iterações: após 3 ciclos de reprovação na mesma etapa, o caso é escalado ao Time de Arquitetura para decisão (replanejar escopo, trocar abordagem ou cancelar).

4.2 Política de Estimativa Progressiva

A estimativa de custo/prazo não é um número único. Ela é registrada no BRD (ordem de grandeza) e reestimada obrigatoriamente em dois pontos: após o HLD (estimativa de arquitetura/infra) e após o LLD (estimativa de esforço de desenvolvimento). Variações acima de ±25% entre estimativas exigem ciência formal do Solicitante.

4.3 Gestão de Mudanças

Alterações de escopo após qualquer aprovação exigem: (a) atualização dos artefatos afetados, (b) reavaliação de risco e estimativa, e (c) re-aprovação pelos mesmos aprovadores das etapas impactadas.

4.4 Métricas do Processo

Um playbook que não se mede não evolui. O Time de Arquitetura acompanha, por trimestre:

Os resultados alimentam a revisão trimestral deste documento (ver cabeçalho).

Etapa 0: Discovery / Spike (opcional)

Etapa de redução de incerteza antes de comprometer o BRD/arquitetura. É timeboxed e gera aprendizado, não código de produção.

Quando é exigida: tecnologia nova/não dominada pelo time; viabilidade técnica incerta; integração externa sem contrato conhecido; ou risco técnico classificado como Alto no levantamento inicial. Para projetos sem esses fatores, a Etapa 0 é dispensada.

Entrada (DoR): oportunidade/ideia registrada e uma pergunta de viabilidade clara a responder (“é possível X dentro de Y?”).

Conteúdo do Spike / PoC Report

Etapa 1: Business Requirements Document (BRD)

O BRD é o ponto de partida. Documenta o problema de negócio, objetivos, escopo e stakeholders. Deve ser escrito e aprovado pelo solicitante antes de qualquer atividade técnica.

Entrada (DoR): problema de negócio identificado e patrocinador (Solicitante) definido. Se houve Etapa 0, os achados do spike estão disponíveis.

Conteúdo Obrigatório do BRD

Definições Obrigatórias no BRD

Etapa 2: High-Level Design (HLD)

O HLD traduz os requisitos de negócio em uma visão técnica de alto nível: arquitetura macro, componentes principais, integrações e decisões tecnológicas.

Entrada (DoR): BRD aprovado (DoD da Etapa 1 atendido).

Conteúdo Obrigatório do HLD

Modelo C4: Níveis Exigidos no HLD

O Modelo C4 (Context, Containers, Components, Code) é o padrão de diagramação adotado neste playbook. No HLD são obrigatórios os níveis 1 e 2.

Etapa 3: Low-Level Design (LLD) e Technical Design Document (TDD)

O LLD/TDD detalha como cada componente será implementado. É a referência dos desenvolvedores durante a codificação.

Entrada (DoR): HLD aprovado; stack e integrações definidas. Se o projeto possui interface de usuário, protótipo/wireframes aprovados pelo Solicitante.

Conteúdo Obrigatório do LLD/TDD

Diagramas Obrigatórios no LLD

Etapa 4: Solution Architecture Document (SAD)

O SAD é o documento vivo que consolida as decisões de HLD e LLD num registro único de referência. É mantido ao longo das Etapas 2 a 4 e finalizado nesta etapa; não é produção nova. A aprovação aqui é revisão de consistência e completude, não reescrita.

Entrada (DoR): HLD e LLD aprovados.

Estrutura do SAD

Architecture Decision Records (ADR)

Cada decisão arquitetural relevante é registrada como ADR no momento em que é tomada (Etapa 2 em diante). O ADR é curto e imutável: decisões não são deletadas, apenas supercedidas por novos ADRs.

Etapa 5: Bootstrap Técnico

Esta etapa transforma a arquitetura aprovada em um ambiente pronto para desenvolver. Pode iniciar assim que o HLD (Etapa 2) for aprovado, em paralelo às Etapas 3 e 4. Resolve os itens de prontidão que antes não tinham etapa de origem.

Entrada (DoR): HLD aprovado (stack definida).

Conteúdo Obrigatório

Etapa 6: Checklist de Go / No-Go

Entrada (DoR): Etapas 1 a 5 concluídas. Antes de iniciar o desenvolvimento, PM, Tech Lead Aprovador e Segurança validam o checklist. Todos os itens obrigatórios devem estar “Concluído”. Itens pendentes bloqueiam o início. Itens Condicionais são obrigatórios quando a dimensão correspondente do BRD se aplica (UI, IA); caso contrário, marcam-se “N/A”.

Capítulo 5: Registro de Riscos

O Registro de Riscos é iniciado no BRD (riscos de negócio), enriquecido no HLD/LLD (riscos técnicos) e consolidado no SAD. É um artefato vivo.

Capítulo 6: Matriz de Rastreabilidade

Garante que todo requisito foi desenhado e será testado (P3). Preenchida ao longo do HLD/LLD e validada no Go/No-Go (item 11).

Capítulo 7: Baseline Mínimo de Segurança

Vigente até o companheiro de Segurança ser publicado. Quando ele existir, prevalece e este baseline torna-se o piso.

A atestação de cada controle é registrada em Templates/template-baseline-seguranca.md, produzida pelo Arquiteto/TL e aprovada pelo Segurança/DPO. Exemplo preenchido em Examples/exemplo-baseline-seguranca-preenchido.md.

Capítulo 8: Tailoring por Criticidade

O rigor do processo escala com a criticidade (P8). BRD e Go/No-Go nunca são dispensados. Simplificações exigem registro da decisão pelo Tech Lead Aprovador.

Trilha Leve (criticidade Baixa): o BRD e o HLD simplificado podem ser combinados em um documento único (estilo one-pager / design doc), desde que preserve: problema, objetivo mensurável, escopo, RF/RNF, dimensões obrigatórias do BRD, C4 L1 e stack com justificativa. As demais regras (produtor ≠ aprovador, registro formal, Go/No-Go) permanecem integrais.

Capítulo 9: Resumo de Artefatos e Onde Armazenar

Na coluna Armazenamento, Repositório de Documentação é a ferramenta acordada entre as partes no início do projeto e registrada no BRD (ex: Confluence, SharePoint, wiki do Git).

Capítulo 10: Glossário e Acrônimos

Observações Finais

• Todos os artefatos devem estar formalizados no Repositório de Documentação (ferramenta acordada entre as partes e registrada no BRD) ou por e-mail com o solicitante antes do início do desenvolvimento.
• Alterações de escopo após a aprovação seguem o Capítulo 4 (Gestão de Mudanças).
• O Tech Lead Aprovador é o guardião deste processo e pode exigir revisão de qualquer artefato a qualquer momento, respeitando sempre a segregação produtor ≠ aprovador.
• O tailoring por criticidade (Capítulo 8) permite simplificar artefatos; o BRD e o Go/No-Go nunca são dispensados.
• Dúvidas sobre a aplicação deste processo devem ser direcionadas ao Time de Arquitetura.

Day Zero Playbook · v1.0 · Pense antes de codar, valide antes de sofrer!