Project Brief

O Brief é o primeiro artefato do projeto. Ele captura o contexto, o problema, o objetivo e as restrições antes de qualquer decisão técnica. Sem brief aprovado, nenhuma outra fase começa.

Fase: 0 — Descoberta
Template: Templates/Full/brief.md ou Templates/Quick/brief.md
Artefato oficial: Docs/brief.md
Próximo artefato: Docs/project.md

Quando criar ou revisar

• Início de projeto
• Início de feature relevante com escopo ainda vago
• Mudança de prioridade, escopo ou restrição
• Mudança externa com impacto no produto
• Sempre que houver conflito de interpretação entre áreas

Full vs Quick

Estrutura — Brief Full

O template Full tem 19 seções. Cada seção deve ser preenchida antes da aprovação.

1. Identificação do projeto

Nome do projeto:
Resumo em 1 frase:
Responsável principal:
Stakeholders envolvidos:
Data de criação:
Versão:

2. Contexto

Qual é o cenário atual? Por que esse projeto está sendo criado agora? Existe histórico anterior relevante?

3. Problema

Qual problema principal o projeto resolve? Quais dores específicas existem hoje? Quem é impactado? O que acontece se não for resolvido?

4. Objetivo

Objetivo principal. Objetivos secundários. Transformação esperada após a entrega.

5. Público-alvo / Usuários

Quem vai usar ou ser impactado? Qual o perfil de cada usuário? Qual problema cada perfil quer resolver?

6. Escopo inicial

O que este projeto deve fazer:
- [item 1]
 
O que é obrigatório no MVP:
- [item obrigatório]
 
O que é desejável, mas não obrigatório agora:
- [item desejável]
 
O que está explicitamente fora de escopo:
- [fora de escopo]

7. Mercado / Nicho

Em qual nicho o projeto se encaixa? Como esse mercado funciona hoje? Existe alguma particularidade que afeta o projeto?

8. Concorrência / Referências

Quais referências ou concorrentes existem? O que fazem bem? O que deixam a desejar? Que experiência queremos seguir, evitar ou superar?

9. Regras de negócio

Regras conhecidas, validações, permissões por perfil, etapas obrigatórias.

10. Requisitos e expectativas

Quais resultados mínimos são esperados? O que definiria este projeto como bem-sucedido? Quais expectativas devem ser respeitadas?

11. Restrições

Técnicas:    [ex.: sem mudança de banco de dados]
Negócio:     [ex.: sem aumento de custo de infra]
Operacionais:[ex.: não pode exigir deploy por demanda]
Legais:      [ex.: LGPD aplicável]
Prazo:       [ex.: entrega até Q3]
Orçamento:   [ex.: sem contratação nova]

12. Plataformas e canais

Onde será usado? Web, mobile, admin, API? Existe plataforma prioritária? Limitações de dispositivo, navegador ou ambiente?

13. Integrações e dependências conhecidas

Serviços externos necessários. Integrações já definidas. Dependências internas entre times, sistemas ou pessoas.

14. Riscos e incertezas

Principais riscos conhecidos. Pontos ainda indefinidos. Decisões que ainda precisam ser tomadas.

15. Critérios de sucesso

Como o sucesso será medido? Indicadores mais importantes. Metas de adoção, conversão, redução de erro, economia de tempo ou receita.

16. Prioridade e deadline

Prioridade do projeto. Urgência. Deadline relevante. Marcos importantes.

17. Resumo executivo

Versão compacta do brief em 5 a 10 linhas: problema central, objetivo central, escopo inicial, restrições mais importantes.

18. Síntese operacional para Dev e AI

O que estamos construindo:
[linguagem direta]
 
O que parece ser mais importante:
- [prioridade 1]
- [prioridade 2]
 
O que não pode ser perdido de vista:
- [restrição crítica]
 
O que ainda está em aberto:
- [ponto indefinido]
 
Próximos documentos que devem nascer deste briefing:
- Docs/project.md
- Docs/stack.md
- Docs/user-stories.md

19. Aprovação

Aprovado por:
Data de aprovação:
Observações finais:

Estrutura — Brief Quick

Para escopo pequeno e contexto já compartilhado. 15 campos em vez de 19 seções:

## Nome do projeto
[preencher]
 
## Resumo
[o que é o projeto em poucas linhas]
 
## Contexto
[qual cenário gerou essa demanda]
 
## Problema
[qual problema principal precisa ser resolvido]
 
## Objetivo
[o que precisa acontecer para ser considerado bem-sucedido]
 
## Público-alvo
- [perfil 1]
 
## Escopo inicial
- [item 1]
 
## MVP
- [item obrigatório]
 
## Fora de escopo
- [item]
 
## Nicho / Mercado
[descreva]
 
## Referências / Concorrentes
- [referência]
 
## Regras de negócio já conhecidas
- [regra]
 
## Restrições
- [restrição]
 
## Riscos / Incertezas
- [risco ou dúvida]
 
## Critérios de sucesso
- [critério mensurável]
 
## Síntese para Dev e AI
O que estamos construindo: [preencher]
O que é mais importante: [item]
O que ainda está indefinido: [ponto]

Exemplo preenchido — seção Escopo

## Escopo inicial
 
O que este projeto deve fazer:
- Permitir que técnicos registrem atendimentos via app mobile
- Gerar relatório de produtividade por técnico
- Integrar com o sistema de agendamento existente
 
O que é obrigatório no MVP:
- Registro de atendimento com foto, localização e assinatura
- Integração com agendamento via API REST
 
O que está fora de escopo agora:
- Aplicativo web para o técnico
- Exportação de relatórios em PDF
- Notificação automática para o cliente

Prompt para gerar com agente

Atue como ScopeAgent.
Objetivo: criar o Docs/brief.md do projeto [nome]
 
Carregue contexto base:
- GUIDE.md
- Skills/user-stories.md
- Templates/Full/brief.md
 
Preencha as 19 seções do template Full com base nas informações fornecidas.
Marque [indefinido] onde houver lacuna — não improvise.
Seção 18 (Síntese para Dev e AI) deve estar em linguagem direta e objetiva.

Definição de pronto

O brief está pronto quando:

1. Problema e objetivo sem ambiguidade — 1 frase cada
2. Escopo e não escopo explícitos
3. Critérios de sucesso mensuráveis — não "ficar melhor"
4. Público impactado descrito por perfil
5. Restrições relevantes listadas
6. Seção 18 (Síntese para Dev e AI) preenchida
7. Aprovação registrada na seção 19

Erros comuns

Documentos que nascem do Brief

Docs/brief.md (aprovado)
    ↓
Docs/project.md    — produto, objetivos e restrições
Docs/stack.md      — escolhas tecnológicas
Docs/user-stories.md — comportamentos esperados por perfil