🧭 Direcciones Estratégicas — ¿Qué Construir Primero?¶
Fecha: 1 de abril de 2026 Rol: Product Strategist + Project Manager Propósito: Evaluar las opciones de priorización y recomendar una dirección
1. El Dilema¶
Hay más trabajo que tiempo. Las piezas del ecosistema están parcialmente construidas. La pregunta es: ¿por dónde muerdes el elefante?
Restricciones conocidas¶
| Restricción | Detalle |
|---|---|
| Equipo | 1 desarrollador principal (tú) |
| Cliente | DKV espera ver valor tangible (el flujo de encuesta funciona) |
| Riesgo Netcomp | Go-live de PET Cloud vs Netcomp previsto julio 2026, no tocar piezas Erlang |
| IP propia | Jaraxa es IP de Jaraxa Software, reutilizable en otros proyectos (IEO) |
| Dependencia PET | El webhook de colas ya existe, solo hay que configurar la URL |
2. Las 3 Direcciones¶
Dirección A — MVP Backlog-First (Backend Vertical) 🏗️¶
Filosofía: "Construye solo lo que necesita el flujo de encuesta, de arriba a abajo, nada más."
Semana: 1 2 3 4
┌──────────────────────────┐
│ TODO lo del MVP Backlog: │
│ Webhook ingress │
│ Dapr Workflow engine │
│ Wait/Timer │
│ Condition evaluator │
│ Gorush push activity │
│ Apps DKV en selector │
│ Trigger config panel │
│ Push config panel │
└──────────────────────────┘
| Dimensión | Evaluación |
|---|---|
| Reach | 1 flujo funcional end-to-end → demo a DKV |
| Impact | DKV ve el producto funcionando → confianza |
| Confidence | Alto — el webhook existe, Gorush existe, Jaraxa canvas funciona |
| Effort | ~51 SP, 4 semanas |
| RICE Score | (9 × 9 × 0.8) / 4 = 16.2 |
Pro: Demo funcional rápida. DKV puede testear el flujo real. Contra: Jaraxa no avanza. El código del MVP Backlog puede no ser reutilizable si Jaraxa cambia.
Dirección B — Librería-First (Horizontal) 📚¶
Filosofía: "Completa Jaraxa como librería sólida. Después, construir el MVP Backlog es trivial."
Semana: 1 2 3 4 5 6
┌──────────────────────────────────┐
│ Jaraxa completa: │
│ AppRegistry extensible │
│ Trigger config framework │
│ SchedulingConfig │
│ AudienceFilter │
│ ChannelConfig │
│ FlowLifecycle │
│ Iterator/Aggregator │
└──────────────────────────────────┘
┌──────┐
│ MVP Backlog │
│ BE │
└──────┘
| Dimensión | Evaluación |
|---|---|
| Reach | La librería sirve para DKV + IEO + futuros |
| Impact | Medio — el cliente no ve nada funcional hasta semana 7+ |
| Confidence | Medio — hay riesgo de diseñar en abstracto sin validar con PET real |
| Effort | ~80 SP, 6 semanas (Jaraxa) + 4 semanas (MVP Backlog) |
| RICE Score | (7 × 5 × 0.6) / 10 = 2.1 |
Pro: Arquitectura limpia. Librería reutilizable validada. Contra: Mucho tiempo sin valor visible. Riesgo de "ivory tower architecture".
Dirección C — Híbrida (Recomendada) ⚡¶
Filosofía: "Capa fina de backend que desbloquea el MVP Backlog. Mientras, Jaraxa evoluciona. Las dos vías convergen."
Semana: 1 2 3 4 5
┌──────────────────────┐
Jaraxa │ AppRegistry extensible │
│ Trigger config panel │
│ Apps DKV estáticas │ + │ Engagement Layer types │
└──────────────────────┘ └──────────────────────────┘
┌──────────────────────┐
Backend │ Webhook ingress │
│ Dapr MVP Backlog workflow │
│ Gorush activity │
└──────────────────────┘
┌──────────┐
Integración │ Wire MVP Backlog │
│ FE ↔ BE │
└──────────┘
| Dimensión | Evaluación |
|---|---|
| Reach | MVP Backlog funcional + librería mejorada |
| Impact | DKV ve demo + arquitectura limpia para escalar |
| Confidence | Alto — validado contra PET real durante construcción |
| Effort | ~55 SP, 5 semanas |
| RICE Score | (9 × 8 × 0.8) / 5 = 11.5 |
Pro: Equilibrio entre valor inmediato e inversión arquitectónica. Contra: Requiere disciplina de separar lo genérico (Jaraxa) de lo específico (DKV).
3. Comparativa Visual¶
| Criterio | A: MVP Backlog-First | B: Librería-First | C: Híbrida ⭐ |
|---|---|---|---|
| Tiempo a demo funcional | 4 semanas ✅ | 10 semanas ❌ | 5 semanas ✅ |
| Jaraxa avanza | ❌ No | ✅ Mucho | 🟡 Lo justo |
| Reutilizable IEO | ❌ No | ✅ Sí | 🟡 Parcial |
| Riesgo de ivory tower | ✅ Ninguno | 🔴 Alto | ✅ Bajo |
| Riesgo de tech debt | 🔴 Alto | ✅ Bajo | 🟡 Medio |
| DKV ve valor | ✅ Rápido | ❌ Tarde | ✅ Rápido |
| RICE Score | 16.2 | 2.1 | 11.5 |
4. Recomendación: Dirección C — Híbrida¶
[!IMPORTANT] RICE Score más alto: Dirección A (16.2), pero con riesgo alto de tech debt. Recomendación: Dirección C (11.5) — mejor balance entre velocidad y calidad arquitectónica.
¿Por qué no A pura?¶
Porque el código que escribas para el MVP Backlog será la base de todo lo que viene después. Si lo haces sin pensar en Jaraxa, en 2 meses tendrás que reescribir. El coste de la reescritura es mayor que la semana extra de la Dirección C.
¿Por qué no B pura?¶
Porque no puedes diseñar la Engagement Layer en abstracto. Necesitas el payload real de PET, la estructura real de las colas, el comportamiento real de Gorush. Construir bottom-up (desde el MVP Backlog) te da esas señales. Top-down (desde la librería) es adivinar.
¿Por qué C es mejor?¶
Porque construyes la librería MIENTRAS resuelves el MVP Backlog. Cada decisión se valida contra la realidad: - "¿Cómo debe ser el AppRegistry?" → Lo diseñas mientras implementas las 5 apps DKV - "¿Cómo debe ser el TriggerConfig?" → Lo diseñas mientras configuras el trigger de cola - "¿Cómo serializa el flow JSON?" → Lo diseñas mientras el backend lo interpreta
5. Sprint Plan — Dirección C¶
Sprint 1 (Semana 1-2): Fundaciones Paralelas¶
Goal: Base sólida en ambos lados que converja en semana 3.
| # | Story | Capa | SP | Prioridad |
|---|---|---|---|---|
| 1.1 | Hacer AppSelectorDialog extensible (prop apps en vez de hardcoded) |
Jaraxa | 3 | Must |
| 1.2 | Crear constante DKV_APPS con las 5 apps del doc 03 |
Flows FE | 2 | Must |
| 1.3 | Crear TriggerConfigPanel genérico en Jaraxa |
Jaraxa | 5 | Must |
| 1.4 | Webhook ingress POST /api/webhooks/pet en Quarkus |
Flows BE | 3 | Must |
| 1.5 | PostgreSQL schema: flow_definition (JSONB), flow_execution |
Flows BE | 5 | Must |
| 1.6 | Quarkus REST: CRUD /api/flows básico |
Flows BE | 5 | Must |
| Total | 23 SP |
Sprint 2 (Semana 3-4): Motor + Integración¶
Goal: El flujo MVP Backlog se ejecuta end-to-end.
| # | Story | Capa | SP | Prioridad |
|---|---|---|---|---|
| 2.1 | Dapr Workflow MVP Backlog: interpreta flow → trigger → wait → condition → action | Flows BE | 13 | Must |
| 2.2 | Gorush push activity con rich content y deep link | Flows BE | 5 | Must |
| 2.3 | Push config panel (título, body, deep link con variables {{}}) |
Flows FE | 5 | Must |
| 2.4 | Sleep config panel (duración + unidad) | Flows FE | 2 | Must |
| 2.5 | Configurar webhook_new_message_recipients en cola Telemedicina de PET |
Integración | 1 | Must |
| 2.6 | Wire FE ↔ BE: TanStack Query hooks para save/load flow | Flows FE | 3 | Should |
| Total | 29 SP |
Sprint 3 (Semana 5): Polish + Demo¶
Goal: MVP Backlog pulido y demostrable a DKV.
| # | Story | Capa | SP | Prioridad |
|---|---|---|---|---|
| 3.1 | Test end-to-end: crear flow en UI → save → trigger webhook → wait → push | Full stack | 3 | Must |
| 3.2 | Execution monitor básico (SSE) | Flows BE + FE | 5 | Should |
| 3.3 | Email fallback activity (Dapr Binding SMTP) | Flows BE | 3 | Should |
| 3.4 | Documentar tipos TriggerMode, SchedulingConfig en Jaraxa types.ts |
Jaraxa | 2 | Should |
| Total | 13 SP |
TOTAL: 65 SP ≈ 5 semanas¶
6. Análisis de Riesgos por Dirección¶
| Riesgo | Dir. A | Dir. B | Dir. C ⭐ |
|---|---|---|---|
| DKV pierde paciencia | ✅ Bajo | 🔴 Alto | ✅ Bajo |
| Tech debt acumulada | 🔴 Alto | ✅ Bajo | 🟡 Medio |
| Jaraxa no avanza | 🔴 Alto | ✅ N/A | 🟡 Avanza lo justo |
| Ivory tower (diseño sin validar) | ✅ N/A | 🔴 Alto | ✅ Bajo |
| Webhook PET no funciona como esperamos | 🟡 Medio | 🔴 Alto (se descubre tarde) | 🟡 Medio (se descubre pronto) |
| Dapr Workflow learning curve | 🟡 Medio | 🟡 Medio | 🟡 Medio |
| Gorush certificados APNs | 🟡 Medio | 🟡 Medio | 🟡 Medio |
7. Más Allá del MVP Backlog — Horizonte a 3 Meses¶
Independientemente de la dirección elegida, después del MVP Backlog el roadmap es:
MVP Backlog (5 sem) → Canales completos (3 sem) → IA (2 sem) → Segmentación (2 sem) → Analytics (2 sem)
Email, SMS, In-App LangChain4j Constructor visual Dashboard métricas
de segmentos
| Horizonte | Entregable | Valor para DKV |
|---|---|---|
| MVP Backlog (Mes 1) | Flujo encuesta satisfacción end-to-end | "Esto funciona, podemos empezar a usarlo" |
| Mes 2 | Email, SMS, flujo SLA colas, tags dinámicos | "Ya no necesitamos Notificare para lo básico" |
| Mes 3 | IA generativa, segmentación visual, analytics | "Esto es mejor que lo que teníamos" |
8. Decisión Requerida¶
[!CAUTION] Antes de empezar a ejecutar, necesito tu decisión sobre:
- ¿Dirección A, B, o C? (Recomiendo C)
- ¿El flujo de SLA de colas (segundo MVP Backlog) se incluye en el primer sprint o se difiere?
- ¿Tienes acceso a un entorno PET donde puedas configurar el webhook de la cola de Telemedicina?
- ¿Los certificados APNs de Gorush están vigentes o necesitamos FCM-only para dev?
Documentos Relacionados¶
| Documento | Propósito |
|---|---|
| 01 — Mapa de Piezas | Vista general del ecosistema |
| 02 — Tensión Conceptual | Make.com vs Customer Engagement |
| 03 — PET como App | Las 5 apps reales del selector |
| 04 — Anatomía del MVP Backlog | Flujo de encuesta nodo a nodo |