Qual é o B.O.? Entender o problema antes do código

1. O pedido não é o problema

Alguém chega e diz: "coloca um botão de exportar para Excel". Dá para fazer o botão em uma tarde. Mas o que a pessoa faz com a planilha depois?

Às vezes ela soma uma coluna que a tela não mostra. Aí o problema é um total que falta, e o botão nem precisa existir. Às vezes ela manda a planilha para outra área toda segunda. Aí o problema é um relatório automático.

O pedido diz o que fazer. A necessidade diz por quê. Quem entende o porquê escolhe a melhor solução, e muitas vezes ela é menor que a pedida.

2. O mesmo pedido, seis cargos

Um pedido que chegou para a Rotina da Zumi, o app de tarefas do Ako: "quero marcar tarefas que não têm dia certo". Veja como cada cargo enxerga o mesmo pedido.

Nenhuma pergunta está errada. Cada uma vê um pedaço. O B.O. completo aparece quando alguém responde as seis. No caso real, a resposta virou grupos de tarefas "Sem data", com emoji, separados da agenda do dia.

Em qualquer cargo, faça também a pergunta do cargo seguinte na tabela.

3. Roteiro de perguntas

Use na primeira conversa sobre qualquer pedido. São perguntas abertas: rendem história, não só "sim" ou "não".

1. Quem sente o problema? Uma pessoa, um grupo, um cliente?
2. Quando ele aparece? "Me conta a última vez que aconteceu."
3. O que acontece hoje, sem a solução? Como a pessoa se vira?
4. Por que isso incomoda? Pergunte de novo a cada resposta, umas três a cinco vezes.
5. Como saber que resolveu? O que muda no dia da pessoa?
6. O que não pode acontecer? Perder dado, ficar lento, mudar o que já funciona.

No fim, repita com suas palavras: "então, se entendi, o problema é...". Se estiver errado, a pessoa corrige na hora.

4. O problema numa frase

Escreva o problema sem a solução dentro. A frase tem três partes: quem sente, em que momento, o que acontece hoje.

[Quem] [em que momento] [o que acontece hoje].

Quem estuda com a Rotina, ao anotar algo que não tem dia certo,
precisa inventar uma data, e a tarefa some da lista no dia seguinte.

Repare: a frase não fala em botão, campo ou banco. Ela deixa a solução em aberto. Mostre a frase para quem pediu antes de seguir.

5. A spec de uma página

Com o problema confirmado, escreva a spec. Ela é o combinado entre você, quem pediu e a IA que vai te ajudar. Uma página basta.

# Spec: tarefas sem data

## Problema
Quem estuda com a Rotina, ao anotar algo sem dia certo,
precisa inventar uma data, e a tarefa some no dia seguinte.

## Resultado esperado
A pessoa guarda tarefas sem data num lugar próprio e acha quando precisar.

## Fora do escopo
Lembrete por notificação. Compartilhar a lista com outra pessoa.

## Critérios de aceite
- [ ] Dado que a tarefa não tem data, quando a pessoa salva,
      então ela aparece no grupo "Sem data".
- [ ] Dado que a pessoa já tinha tarefas, quando abre a versão nova,
      então nada some.

## Como conferir
Abrir no celular e no computador, criar, editar e concluir uma tarefa sem data.

O modelo completo, com a parte de decisões, está em modelo-spec.md, nos Favos.

6. O projeto em sete etapas

Estas sete etapas formam o projeto final da trilha Desenvolvimento. Também serve para qualquer pedido do trabalho.

1. Entender o B.O. Converse com quem pediu usando o roteiro da parte 3 e escreva a frase da parte 4.
2. Spec. Uma página, como na parte 5.
3. Decidir e registrar. Escolha o que é difícil de desfazer, como onde guardar os dados, e escreva um ADR (o registro escrito da decisão).
4. Harness: preparar o projeto para a IA ajudar. Escreva um AGENTS.md: o que é o projeto, onde mexer, como testar, o que nunca fazer.
5. Fatiar com IA. Construa uma fatia por vez. Dê à IA a spec e o AGENTS.md, e leia tudo o que ela escrever.
6. Conferir. Testes passando, prévia no celular e cada critério de aceite marcado.
7. Ensinar de volta. Um post ou um README contando o B.O. e o que você aprendeu.

As etapas 3 e 4 têm modelos na lição Arquitetura para crescer.

7. Missão final