julian
17c08e6392
- Nx 22.7 monorepo (pnpm 11.1, TypeScript 5.9, Node 24) - apps/api: NestJS 11 (CJS conforme CODING-RULES.md PGD-DB-004) - apps/web: React 19 + Vite 8 (ESM) - libs/shared/api-interface: Zod contract base - Docker Compose dev: Postgres 18, Valkey 8, MinIO, Mailpit - WDS artifacts: - design-artifacts/A-Product-Brief/ (5 docs canônicos + 16 dialogs) - design-artifacts/B-Trigger-Map/ (hub + 4 personas + feature impact) - Stack canon: STACK.md v2.2 + CODING-RULES.md v2.0 + brand.md - AGENTS.md + README.md como entrada para devs/agentes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
9.5 KiB
9.5 KiB
Feature Impact Analysis — SAR
Phase 2 — Trigger Mapping · Workshop 5 Created: 2026-05-27
Matriz Features × Driving Forces × Personas que prioriza o MVP. Resolve a tensão "concept ambicioso + solo founder + 3-4 meses" do Constraints (Step 10).
Princípios de priorização
- Feature de alto impacto = atende driving forces de alta score (Freq × Int × Fit) de múltiplas personas.
- Feature de unfair advantage (Step 9) = atende força que só o SAR resolve bem no mercado.
- Feature P0 = atende medo absoluto (ex: R-3 "Perder pedido por bug ou sem sinal" do Rafael). Falhar aqui é morte instantânea do produto.
- Feature pós-MVP = atende força importante mas não bloqueia validação do PMF (north star MVP é renovação, não cobertura completa).
Mapa de features pilares do MVP
🔴 P0 (absoluto — produto não roda sem)
| Feature | Personas atendidas | Forças (top hits) | Por quê P0 |
|---|---|---|---|
| Lançamento de pedido offline com sync (PWA + IndexedDB queue) | Rafael | R-3 (5/5×5/5) · R+4 · R-5 | Perder pedido = perda de confiança catastrófica do Rafael. North star MVP impossível sem isso. |
| Multi-tenancy BD-por-workspace (ADR 0006) | Todos (arquitetural) | Habilita BG-4 (coexistência ERPs) | Fundacional. Não pode ser retrofit. |
| Auth via master-login + RBAC por cockpit | Todos | Pre-req de todas as personas | Sem segmentação por papel, não existe "4 cockpits". |
| Real-time entre cockpits (Socket.IO + Valkey) | Sandra · Daniel · Rafael | S-1 · S+2 · D-1 | Sem real-time, promessa-mãe "visibilidade em tempo real" quebra. |
| Idempotency-Key em todos POST críticos | Rafael · Sandra | R-3 · S-1 | Pedido duplicado é falha de produção. |
🟢 MVP core (Rafael + Sandra completos)
| Feature | Personas | Forças (top hits) | Score impacto |
|---|---|---|---|
| Visão 360° do cliente (timeline, histórico, contatos, pedidos, comissão) | Rafael · Sandra · Daniel | R+2 · S-4 · D-4 | ALTO — 3 personas, todas com score alto |
| Lançamento de pedido < 60s mobile | Rafael · Sandra (vê em tempo real) | R+2 · R+4 · R+5 · S+2 | ALTO — central pro PMF |
| Comissão visível em tempo real (rep + FLEX rateio) | Rafael | R-4 (5/5×4/5×5/5) | ALTO — força com freq máxima |
| Funil de propostas (kanban pessoal) | Rafael | R+2 · R+5 | MÉDIO-ALTO — diferencial vs concorrentes |
| Lista de inativos com alerta proativo (>60d) | Rafael · Sandra · Daniel | R-1 · S-4 · D-4 | ALTO — promessa-mãe materializada |
| Agenda + check-in GPS | Rafael · Sandra (visão consolidada) | R-2 · R+4 · S+2 · S+6 | MÉDIO-ALTO |
| WhatsApp nativo (envio de notificações ao cliente final) | Rafael · Sandra · cliente final | R+5 · R-6 · S-2 | ALTO — diferencial declarado |
| Share API (compartilhar pedido via WhatsApp do celular) | Rafael | R+5 · R-6 | MÉDIO |
| Push notifications (Sandra: aprovação; Rafael: pedido aprovado) | Rafael · Sandra | S-1 · S-2 · R-2 | ALTO — substitui WhatsApp informal |
| Fila de aprovações com contexto | Sandra | S-2 · S+3 | ALTO — diferencial declarado |
| Mapa de calor da equipe (privado, só pra Sandra) | Sandra | S+6 · S+1 · S-5 | MÉDIO — cuidado com R-7 (não punitivo) |
| Watchlist de clientes-chave com alerta automático | Sandra · Daniel | S-4 · D-4 | ALTO |
| Dashboard "tela do dia" (Sandra) | Sandra | S+2 · S+4 · S-1 | ALTO — UX central da Sandra |
| Dashboard executivo (Daniel) simplificado | Daniel | D+1 · D+2 · D-1 | ALTO — mas simplificado no MVP |
🔵 MVP suporte (Alice e Daniel simplificados)
| Feature | Personas | Forças | Score impacto |
|---|---|---|---|
| Cadastro completo de produto (form denso) | Alice | A+1 · A-2 | ALTO — produto não roda sem catálogo |
| Cadastro completo de cliente | Alice · Rafael (também cria no campo) | A+1 · R+2 | ALTO |
| Cadastro de rep (permissões, região, comissão) | Alice | A+1 | MÉDIO-ALTO |
| Pauta de preço com versionamento | Alice | A+4 · A-2 · A-4 | ALTO — auditoria habilita confiança |
| ICMS-ST manual por UF (sem assistente IA) | Alice | A-3 | MÉDIO — viabiliza operação, mas não brilha |
| Auditoria em entidade (histórico de mudanças) | Alice · Daniel · Sandra | A+4 · A-4 · D-7 · S+3 | ALTO — transversal |
| Timeline 360° do cliente (versão Daniel: estratégico) | Daniel | D+1 · D-4 · D+6 | MÉDIO-ALTO |
| Faturamento mês×mês com tendência (Chart.js) | Daniel | D+6 · D-1 | MÉDIO-ALTO |
| Limite de crédito automático + bloqueio cliente | Sandra · Alice · Rafael | S-1 · A-2 · R-2 | ALTO — central no fluxo de pedido |
🟡 MVP-light (existe mas sem brilho) — completar pós-MVP
| Feature MVP-light | Pós-MVP (versão rica) |
|---|---|
| Dashboard Daniel sem IA estratégica | IA explicável proativa (D+4 · D-6) — DIFERENCIAL DECLARADO |
| Tela direta de promoção (1 a 1) | Editor visual de campanhas no-code (A+5 · A-1) — DIFERENCIAL DECLARADO |
| ICMS-ST manual | Assistente IA por NCM+UF (A-3) |
| WhatsApp apenas notificação outbound | Conversa bidirecional + aquecimento de lead (R+5 · S-2) — promessa de positioning |
| Bulk operations básico (CSV import) | Bulk edit em massa + edição inline (A+2 · A-5) |
⚪ Pós-MVP (entram conforme tração)
| Feature | Personas | Forças | Quando |
|---|---|---|---|
| Comparativo período (mês×mês, ano×ano) | Daniel | D+6 · D+5 | Y1 conforme dado acumular |
| Análise de concentração de carteira (D+5) | Daniel | D+5 · D-4 | Y1 |
| Benchmarking setorial (cross-tenant anonimizado) | Daniel | D+3 · D-2 | Y2 |
| Onboarding white-glove com tour interativo | Cliente novo | D-3 | NÃO (excluído Step 17a — brand Apple) |
| Chat-com-cliente in-app | — | — | NÃO (excluído Step 17a) |
| App nativo iOS/Android (sobre backend SAR) | Rafael | R+3 · R-5 | Y1-Y2 conforme PWA validar limites |
| Adaptação app Android legado para backend SAR | Reps Android atuais | Continuidade | Pós-MVP (Step 10a) |
| Programa de indicação (referral) | Daniel buyer | BG-2 | Y1 quando 5+ clientes |
| Marketplace de templates WhatsApp | Alice | A+5 · A-1 | Y1+ |
Score por Business Goal × Features
| Business Goal | Features que mais contribuem |
|---|---|
| BG-1 PMF MVP | Lançamento offline · Real-time · Visão 360° · Comissão tempo real · Dashboard Sandra "tela do dia" · WhatsApp notif |
| BG-2 Referenciabilidade | Mesma lista do BG-1 (sem PMF não há referenciabilidade) + Alertas inativos (cumprir promessa-mãe) |
| BG-3 Modernidade visual | Visual DNA do Block C aplicado em todo cockpit · PWA polido · Dark mode |
| BG-4 Coexistência ERPs | Multi-tenancy BD/workspace · API REST + OpenAPI · Adapter por ERP (pós-MVP por demanda) |
| BG-5 Fundação para escala | OTel + Pino + Sentry · Test coverage · ADRs documentados · Vault rotação · Backup Proxmox |
Tensões e trade-offs do MVP
Tensão A: IA estratégica não entra no MVP, mas é diferencial de venda
- Problema: D+4 (IA segundo cérebro) é argumento de venda forte, mas solo founder + 3-4 meses não comporta IA explicável bem feita
- Resolução: MVP entrega Dashboard Daniel sem IA; demo de venda mostra roadmap IA com data prevista (pós-renovação 1º cliente)
- Risco: Daniel comprou esperando IA, MVP entrega menos
- Mitigação: 1º cliente é parceiro próximo — aceita roadmap, recebe condição especial
Tensão B: Editor no-code de campanhas é diferencial Alice, mas pós-MVP
- Problema: A+5 (campanhas sem dev) é o que deveria liberar Alice — mas exige UI complexa que solo founder não entrega no MVP
- Resolução: MVP entrega tela direta de promoção (Alice mexe 1 a 1) + cadastro/pauta robustos. Editor visual entra pós-renovação.
- Risco: Alice fica achando o produto "só OK"
- Mitigação: Alice não pesa na decisão de compra (Step 6). Risco aceitável.
Tensão C: WhatsApp conversa bidirecional vs notificação outbound
- Problema: "WhatsApp nativo" no positioning sugere conversa completa, mas MVP entrega só notificação outbound
- Resolução: Linguagem de marketing deixa explícito "notificações via WhatsApp Business API" + roadmap "conversa bidirecional Y1"
- Risco: Cliente comprou esperando chatbot completo
- Mitigação: Demo + proposta especificam escopo
Tensão D: Sandra vs Rafael — visibilidade não pode virar vigia
- Problema: S+6 (Sandra quer ver quem produz) ↔ R-7 (Rafael teme ser substituível/vigiado)
- Resolução: SAR mostra outputs (pedidos, faturamento, % meta) — NÃO inputs punitivos (tempo logado, geolocation contínua, % tela ativa)
- Risco: Rep boicota produto se sentir vigiado
- Mitigação: UI design explicitamente alinhada com tom canônico "consultor sênior, não Big Brother"
Tensão E: Daniel vs Sandra — dashboards sobrepostos
- Problema: Os dois precisam ver dados de equipe e clientes
- Resolução: Sandra vê operacional do dia · Daniel vê estratégico do período. Mesma fonte, camadas distintas.
- Risco: Ambos veem mesma tela e dashboards ficam confusos
- Mitigação: Cockpits separados desde dia 1 — RBAC por papel
Próximos passos
- Phase 3 (PRD): este Feature Impact vira backlog priorizado
- Phase 4 (UX Specs): features de alta score viram pages específicas
- Phase 6 (Design System): componentes emergem das features pilares