Como usar estes documentos
Comece pelo problema, escolha o tamanho certo do registro e mantenha o documento atualizado enquanto o trabalho acontece.
Qual documento escolher
Mostra as prioridades e os resultados que a bLOw busca em um período. Revise todo mês. Revisão a cada 30 dias.
Use quando o trabalho envolve várias entregas, pessoas ou dependências. Explica o problema, o limite e o resultado esperado. Revisão a cada 30 dias.
Descreve uma nova capacidade visível ao usuário e os critérios que provam que ela funciona. Revisão a cada 60 dias.
Use para uma mudança com decisões de arquitetura, dados, segurança ou operação. Complementa o escopo; não o substitui. Revisão a cada 90 dias.
Registra uma falha, seu impacto, como reproduzi-la e como comprovar a correção.
Retrato sempre atual de um sistema: visão, andamento, código, plataformas, decisões, uso de IA e sustentação. Deve ter dono e revisão frequente. Revisão a cada 7 dias.
Quem escreve e quem aprova
Cada item tem uma pessoa responsável por mantê-lo claro e atualizado. Chamamos essa pessoa de DRI. Não é um cargo: pode ser quem lidera o trabalho naquele momento. Em mudanças de risco médio ou alto, outra pessoa revisa o resultado.
Quando começar e quando terminar
Pronto para começar: problema, público, prioridade, escopo, responsável e forma de validar estão claros. Concluído: o resultado esperado foi testado, a entrega foi verificada no ambiente final e existe uma data para medir o efeito.
Princípios de escrita
- Linguagem simples, em português do Brasil. Termo técnico só quando necessário, e explicado.
- Comece pelo problema e pelo resultado mensurável: de X para Y até uma data absoluta (“31 de dezembro de 2026”), com a fonte do número.
- Sempre diga o que fica fora, quem é responsável, como saberemos que deu certo e o que ainda está em aberto.
Como escrever no editor
Cada seção tem um editor com barra de ferramentas e uma dica de preenchimento. A pré-visualização ao lado mostra o documento como ele vai ficar.
| Recurso | Como usar |
|---|---|
| Negrito, itálico, listas e subtítulo | Botões da barra ou atalhos (⌘B, ⌘I). Digitar “- ” ou “1. ” também inicia listas. |
| Tabela | Botão de tabela. Com o cursor dentro dela aparecem os botões para adicionar ou remover linhas e colunas. |
| Nota destacada | Botão de citação. Aparece com a borda laranja do playbook. |
| Métricas | Uma por linha, no formato 62% | Ponto de partida. |
| Bloco de fluxo e código | Para fluxos técnicos (RFC) e contratos de API. |
| Selos NEXT e LATER | Botões “Next” e “Later”, ou digite [NEXT] e [LATER]. |
| Link para outro documento | Botão de link com o código, por exemplo PRJ-001. |
O rascunho é guardado automaticamente neste navegador. A versão só é gravada, e fica no histórico, quando você clica em Salvar.
Termos em linguagem simples
- Baseline: o número atual, antes de mudar algo.
- Meta: o número que queremos alcançar.
- Escopo: o que faz parte do trabalho e o que fica de fora.
- Critério de aceite: condição observável que mostra que a entrega funciona.
- Rollback: plano para voltar à versão anterior se houver problema.
- Severidade: tamanho do dano causado por um bug.
- Prioridade: quão cedo vamos agir.
Levar para Word, Confluence ou PDF
Abra o documento e clique em Copiar formatado para colar no Confluence ou no Word com títulos, listas e tabelas. Baixar para Word gera um arquivo .doc, e Imprimir ou salvar em PDF imprime só o papel.
De onde veio o padrão
Esta adaptação usa práticas publicadas pelo Scrum Guide, pelo GitLab, pela Atlassian, pelo Google e pelo Google SRE.