Do requisito vago ao plano que se revisa

Laboratório: abrir um requisito do seu backlog

Mão na massa 5 min de leitura 30 min de prática Você leva: Mapa de decisões da feature

Aplicar o método da aula anterior a uma história real sua e sair com o registro de decisões que protege você e o time.

O método da aula anterior só vale alguma coisa aplicado a um requisito que é seu, com gente de verdade para responder as pendências.

Mão na massa30 min

Transformar uma história real do seu backlog em decisões explícitas, separando o que você resolve do que precisa de outra pessoa.

Escolha uma história que ainda não começou e que caiba em até uma semana. Histórias muito grandes geram listas longas demais para o exercício; muito pequenas não têm decisão escondida.

Cole o CONTEXT.md e o texto do requisito exatamente como ele chegou — sem melhorar a redação.
Use o prompt da aula anterior. Exija PENDENTE nas lacunas.
Classifique cada item em: decido eu / decide produto / decide segurança ou compliance.
Para os que você decide, escreva a decisão e o motivo em uma linha cada.
Agrupe o resto em no máximo quatro perguntas objetivas.
Mande as perguntas para quem pediu e registre as respostas no mesmo documento.
Marque no documento qualquer item que continuou sem resposta — esse é o seu risco conhecido.

Deu certo quando

Cada item da lista tem um responsável nomeado.
Nenhuma decisão de produto foi tomada por você em silêncio.
As perguntas enviadas cabem em quatro e são respondíveis com uma frase.
Os itens sem resposta estão visíveis, não esquecidos.

Se travar: Se a lista veio genérica ("validar entradas", "tratar erros"), o requisito provavelmente foi colado resumido. Cole o texto original, com os erros de redação — a ambiguidade que interessa costuma estar justamente na frase mal escrita.

Você leva daquiMapa de decisões da feature

Documento curto que vive junto da história. Serve para três coisas: alinhar antes, revisar durante e explicar depois por que o sistema faz o que faz.

# [Nome da feature] — mapa de decisões
Data: [data] · Autor: [você] · História: [link/ID]

## Requisito como recebido
> [cole o texto original, sem editar]

## Decisões técnicas (tomei eu)
| # | Decisão | Motivo | Reversível? |
|---|---------|--------|-------------|
| 1 | [ex: geração assíncrona com fila] | [timeout acima de 30s] | Sim |

## Decisões de produto (respondidas)
| # | Pergunta | Resposta | Quem respondeu | Quando |
|---|----------|----------|----------------|--------|
| 1 | [pergunta] | [resposta] | [nome] | [data] |

## Pendências assumidas como risco
| # | Item | Impacto se der errado | O que faço enquanto isso |
|---|------|----------------------|--------------------------|
| 1 | [item] | [impacto] | [comportamento provisório] |

## Fora do escopo (explicitamente)
- [o que decidimos NÃO fazer agora e por quê]

Onde guardar: Anexado à história no seu gerenciador de tarefas, ou como docs/decisoes/[feature].md no repositório.

A coluna "Reversível?" faz mais trabalho do que parece

Decisão reversível pode ser tomada rápido e sozinho. Decisão irreversível — formato de dado gravado, contrato de API público, migração destrutiva — merece uma conversa, mesmo que atrase.

Separar as duas evita os dois erros clássicos: travar o time discutindo o que dava para desfazer em dez minutos, e decidir sozinho o que vai doer por dois anos.

Checagem antes de seguir

O requisito original está no documento, sem edição.
Toda decisão técnica tem motivo escrito.
Toda resposta de produto tem nome e data.
Os riscos assumidos estão listados com o comportamento provisório.

Em uma frase

Decisão escrita com responsável e data é o que separa "combinamos" de "achei que estava claro".

← Aula anterior Próxima aula →

Comentários e dúvidas

Inscreva-se grátis para comentar, tirar dúvidas, marcar seu progresso e emitir o certificado ao fim do curso.

Inscrever-se grátis com Google

Ainda não há comentários nesta aula.