Pular para conteúdo

Product Definition Guidelines

1. Objetivo

Este documento padroniza a construcao dos artefatos em product-definition/.

Ele nao e a referencia completa de SDLC do time.

Para processo, papeis, uso do SOT e treinamento, consulte method/.

O objetivo aqui e evitar tres misturas comuns dentro dos artefatos de produto:

  • problema com solucao
  • estado atual com estado futuro
  • necessidade de negocio com preferencia tecnica

2. Escopo desta area

O diretorio canonico desta disciplina e product-definition/.

Ele cobre:

  • discovery
  • inception
  • handoff para implementacao
  • templates relacionados

Ele nao substitui:

  • method/, que define processo e papeis
  • plan/, que materializa backlog, sprints e ADRs
  • agents/, que define contexto operacional para agentes

3. Regra principal por fase

3.1 Discovery

Pergunta central: qual problema precisa ser entendido e por que ele importa?

O discovery deve documentar:

  • contexto do negocio e do ecossistema
  • stakeholders e seus objetivos
  • dores, gargalos, riscos e variacoes do processo
  • conceitos de negocio, definicoes e dicionario
  • regras, restricoes e excecoes do dominio
  • restricoes institucionais, operacionais e estrategicas que condicionam a solucao
  • processos ponta a ponta no nivel do problema
  • criterios que justificam priorizacao futura

O discovery nao deve documentar como verdade de produto:

  • microservicos, APIs, filas, portais, engines, batches
  • nomes de modulos tecnicos
  • eventos de integracao desenhados como contrato final
  • decisoes de arquitetura fechadas

Excecao: solucoes atuais podem aparecer apenas quando ajudam a explicar dor, dependencia ou limitacao operacional.

Restricoes de implantacao, operacao, sustentacao e estrategia de produto podem aparecer no discovery desde que sejam registradas como contexto e nao como desenho tecnico fechado.

3.2 Inception

Pergunta central: qual recorte de solucao vale a pena iniciar agora e com quais limites?

A inception deve documentar:

  • objetivo do recorte inicial
  • hipoteses de solucao derivadas do discovery
  • escopo e fora de escopo
  • capacidades prioritarias
  • candidatos a modulos, contextos ou fluxos
  • riscos de implementacao
  • dependencias, integracoes e premissas
  • criterios de aceite para iniciar implementacao

3.3 Implementacao

Pergunta central: como transformar o recorte aprovado em backlog executavel e rastreavel?

A implementacao recebe da inception:

  • backlog inicial
  • ADRs necessarias
  • fluxos criticos
  • criterios de validacao
  • riscos e restricoes

4. Entradas e saidas por fase em product-definition

Fase Entradas minimas Saidas obrigatorias
Discovery SOW, contexto institucional, entrevistas, normas, processos atuais visao do problema, contexto e restricoes estruturantes, mapa de dominios do problema, dores por stakeholder, mapa de processo, glossario, perguntas em aberto
Inception saidas do discovery priorizadas proposta de recorte, macro-solucao, riscos, convergencia com estado atual, handoff para implementacao
Implementacao handoff da inception backlog de execucao, sprints, ADRs aprovadas, evidencias de entrega e operacao

5. Estrutura canonica

5.1 Discovery

Arquivos minimos:

  • discovery/problem-overview.md
  • discovery/context-and-strategy.md
  • discovery/stakeholder-pains.md
  • discovery/problem-domain-map.md
  • discovery/process-map.md
  • discovery/glossary.md

Quando necessario:

  • discovery/problem-domains/*.md
  • benchmarks, pesquisa de mercado e referencias regulatórias em arquivos proprios

5.2 Inception

Arquivos minimos:

  • inception/README.md
  • inception/inputs-from-discovery.md
  • inception/macro-domain-proposal.md
  • inception/handoff-to-implementation.md

6. Regras de escrita

  • Use linguagem de negocio antes de linguagem de software.
  • Nomeie dominios pelo problema, nao pelo portal ou pelo time.
  • Separe fatos observados de hipoteses.
  • Registre tensoes e tradeoffs explicitamente.
  • Diferencie ator, papel, responsabilidade, processo e capacidade.
  • Se um conteudo depender de escolha tecnica futura, ele pertence a inception, nao a discovery.

7. Checklist de revisao do discovery

  • O artefato explica dor real e nao apenas funcionalidade desejada.
  • O texto evita assumir estrutura de sistema como se fosse estrutura do problema.
  • Stakeholders tem objetivos, dores e restricoes explicitados.
  • O processo ponta a ponta identifica friccoes e excecoes.
  • Conceitos centrais do dominio estao definidos no glossario.
  • Perguntas em aberto foram registradas.

8. Checklist de revisao da inception

  • Cada hipotese de solucao referencia uma dor ou restricao do discovery.
  • Existe um recorte inicial claro.
  • O fora de escopo foi declarado.
  • Riscos de implementacao estao visiveis.
  • Handoff para implementacao contem criterios de pronto.