Pular para o conteúdo
Moldapé Docs

Plano de ação, DoR e DoD

Fases

Seção intitulada “Fases”

  1. Fase 0 · Pré-requisitos (≈ 1 sprint)

    • Corrigir R-01 (webhook sem verificação, PAYMENT_BYPASS_TOKEN), R-13 (cookies em log) e R-14 (rotacionar credenciais).
    • Automatizar as migrations no deploy (R-07) e corrigir o CI (R-06).
    • Saída: webhook InfinitePay verificado em produção; CI verde.

  2. Fase 1 · Descoberta (≈ 1–2 sprints, em paralelo com a Fase 0)

    • 3 a 5 entrevistas com prescritores (validar personas, parâmetros, disposição a pagar).
    • Entrevista com a fábrica: formatos aceitos (STL, 3MF, PDF), tolerâncias, maquinário.
    • Mágico de Oz: ortesista produz propostas para ≥ 30 briefings reais → conjunto de avaliação.
    • Validar preços e pacotes com os sócios.
    • Saída: personas validadas, faixas de parâmetros por região, conjunto de avaliação, tabela de preços aprovada.

  3. Fase 2 · Spikes técnicos (≈ 1 sprint, timeboxed)

    • S-1 Preview R3F com malha-base deformável: medir FPS em celular de referência.
    • S-2 Serviço Python: gerar par estanque a partir de parâmetros; exportar STL e 3MF com zonas; abrir no PrusaSlicer/OrcaSlicer.
    • S-3 Agente IA: rodar o conjunto de avaliação; medir acerto de faixas, latência e custo.
    • S-4 Teste de ouro preview × Python em 5 casos.
    • Saída: ADRs 0011–0013 aceitos ou revistos; go/no-go do MVP.

  4. Fase 3 · Fundação (≈ 2 sprints)

    • Pacote insole-contract (schema + geração TS/Python).
    • Contexto Créditos (planos, lotes, livro-razão, direitos, concessão manual pelo admin).
    • Contexto Editor3D (projeto, revisão, proposta IA, auditoria) + Draft.mode.
    • Serviço apps/geometry no Coolify; fila BullMQ.
    • Saída: API completa testada; admin concede créditos manualmente.

  5. Fase 4 · MVP fechado — Essencial (≈ 3 sprints)

    • UC-01 a UC-06, UC-09, UC-12, UC-14, UC-16, UC-17, UC-18.
    • Beta com 5 a 10 prescritores, créditos concedidos manualmente (sem cobrança).
    • Saída: SUS ≥ 70; ≥ 50% dos projetos do beta viram pedido; zero divergência acima da tolerância nos pedidos fabricados.

  6. Fase 5 · Monetização (≈ 1–2 sprints)

    • UC-11 (compra pela InfinitePay), UC-19 (expiração e avisos), tela de planos, termos de uso.
    • Saída: primeira venda real conciliada; abertura para toda a base.

  7. Fase 6 · Profissional e Clínica (≈ 3–4 sprints)

    • UC-07, UC-08, UC-10, UC-13, UC-15; exportação STL/3MF.
    • Saída: primeiros pacotes Profissional e Clínica vendidos.

  8. Fase 7 · Evolução

    • Importar plantigrafia do estúdio clássico como contorno; importar scan 3D; copiloto conversacional; pacote avulso de 1 crédito.

Métricas de acompanhamento

Seção intitulada “Métricas de acompanhamento”
Métrica Fonte Meta inicial (hipótese)
Conversão preview grátis → primeira compra Eventos + livro-razão ≥ 8% em 90 dias
Projetos 3D que viram pedido Pedidos com mode = EDITOR_3D ≥ 50%
Aceitação da proposta IA sem ajuste por parâmetro Auditoria Acompanhar (não é meta: aceitação alta demais pode indicar viés de automação)
Revisões por projeto Revisões 2–4
Retrabalho/devolução 3D vs clássico Pedidos Menor que o clássico
Custo de IA por projeto Logs do adaptador Abaixo do teto aprovado

Definition of Ready (DoR)

Seção intitulada “Definition of Ready (DoR)”

Uma história do Editor 3D só entra na sprint quando:

  • Está escrita como história com valor para um ator e liga-se a um caso de uso (UC-xx) e a requisitos (RF/RNF-3D-xx).
  • Tem critérios de aceitação verificáveis (Dado/Quando/Então), incluindo pelo menos um cenário de erro.
  • O plano mínimo e o comportamento para planos sem direito estão definidos.
  • Se mexe em créditos: o lançamento do livro-razão e a chave de idempotência estão especificados.
  • Se mexe em parâmetros: a mudança no contrato de geometria (campo, unidade, faixa, plano) está descrita e a versão do schema definida.
  • Se envolve a IA: o caso está no conjunto de avaliação ou há casos novos propostos.
  • Protótipo/tela de referência aprovado (ou dispensado justificadamente).
  • Dependências identificadas e desbloqueadas (outras histórias, fábrica, sócios, InfinitePay).
  • Estimada pelo time e cabe em uma sprint.
  • Dados pessoais envolvidos mapeados (o que vai para a IA, o que fica em log).

Definition of Done (DoD)

Seção intitulada “Definition of Done (DoD)”

Uma história está pronta quando:

Código e qualidade

  • Revisado e aprovado em PR; o revisor de PRs (regras determinísticas) sem bloqueios.
  • Lint, tipos e build verdes no CI.
  • Testes de unidade e integração; cobertura ≥ 70% nos módulos de créditos, validador e geometria.
  • Testes de ouro preview × Python passando quando a história altera geometria.
  • Direitos do plano verificados no backend com teste para usuário sem direito.
  • Operações de crédito idempotentes, com teste de dupla submissão.

Experiência

  • Critérios de aceitação demonstrados ao responsável de produto.
  • Funciona no celular de referência com ≥ 30 FPS (quando há 3D) e nas 2 últimas versões dos navegadores-alvo.
  • Controles acessíveis por teclado, com rótulo e valor numérico editável.
  • Textos em português revisados; avisos clínicos presentes onde exigido.

Segurança, dados e operação

  • Nenhum dado identificável do paciente enviado à IA nem gravado em log.
  • Logs estruturados com ids de projeto/revisão/job; erros observáveis.
  • Migrations criadas com prisma migrate (nunca migrate dev em produção) e reversíveis.
  • Feature flag configurada se a história não deve aparecer para todos.

Documentação

  • Docs-as-code atualizadas (apps/docs): requisitos, casos de uso, API e, se houver decisão, ADR.
  • Mudanças no contrato de geometria registradas com nova schemaVersion e nota de compatibilidade.
  • CHANGELOG atualizado.
Desenvolvido e documentado por
Nós Tecnologia · Desenvolvimento Criativo