613 lines
16 KiB
Markdown
613 lines
16 KiB
Markdown
# 🗺️ ROADMAP: SISTEMA DE GESTIÓN DE CONTENIDO Y PANEL DE ADMINISTRACIÓN
|
||
|
||
**Versión:** 1.0
|
||
**Fecha:** 2025-01-XX
|
||
**Estado:** Plan de Implementación - Sin Ejecución
|
||
**Autor:** Arquitecto de Software Senior + Arquitecto de Contenido + Diseñador Instruccional Sanitario
|
||
|
||
---
|
||
|
||
## 🎯 PROPÓSITO DEL DOCUMENTO
|
||
|
||
Este documento define **EL PLAN DE IMPLEMENTACIÓN PROGRESIVA** del sistema de gestión de contenido y panel de administración para EMERGES TES. Establece:
|
||
|
||
- ✅ Fases claras de implementación
|
||
- ✅ Dependencias entre fases
|
||
- ✅ Criterios de éxito por fase
|
||
- ✅ Riesgos y mitigaciones
|
||
- ✅ Timeline estimado
|
||
|
||
**Este documento se actualiza según progreso y aprendizajes.**
|
||
|
||
---
|
||
|
||
## 📋 PRINCIPIOS DEL ROADMAP
|
||
|
||
### Principio 1: Progresivo y No Disruptivo
|
||
|
||
**Cada fase:**
|
||
- ✅ No rompe funcionalidad existente
|
||
- ✅ Puede desplegarse independientemente
|
||
- ✅ Permite rollback si hay problemas
|
||
- ✅ Mantiene app funcional en todo momento
|
||
|
||
---
|
||
|
||
### Principio 2: Validación Continua
|
||
|
||
**Cada fase:**
|
||
- ✅ Se valida con usuarios reales (TES)
|
||
- ✅ Se prueba en entorno de producción
|
||
- ✅ Se documenta aprendizajes
|
||
- ✅ Se ajusta plan según feedback
|
||
|
||
---
|
||
|
||
### Principio 3: Priorización por Impacto
|
||
|
||
**Orden de implementación:**
|
||
1. Alto impacto, bajo riesgo
|
||
2. Alto impacto, medio riesgo
|
||
3. Medio impacto, bajo riesgo
|
||
4. Bajo impacto, cualquier riesgo
|
||
|
||
---
|
||
|
||
## 🚀 FASES DE IMPLEMENTACIÓN
|
||
|
||
---
|
||
|
||
## FASE 0: PREPARACIÓN (Sin Impacto en Usuarios)
|
||
|
||
**Duración estimada:** 2-3 semanas
|
||
**Riesgo:** Bajo
|
||
**Impacto en usuarios:** Ninguno
|
||
|
||
### Objetivos
|
||
|
||
1. ✅ Documentar modelo canónico (completado)
|
||
2. ✅ Documentar mapa de relaciones (completado)
|
||
3. ✅ Documentar arquitectura del panel (completado)
|
||
4. ✅ Documentar modelo de datos (completado)
|
||
5. ✅ Crear este roadmap (completado)
|
||
|
||
### Tareas
|
||
|
||
- [x] Crear `MODELO_CANONICO_CONTENIDO_EMERGES_TES.md`
|
||
- [x] Crear `MAPA_RELACIONES_CONTENIDO.md`
|
||
- [x] Crear `ARQUITECTURA_PANEL_ADMIN.md`
|
||
- [x] Crear `MODELO_DATOS_CONTENIDO.md`
|
||
- [x] Crear `ROADMAP_CONTENIDO_Y_ADMIN.md`
|
||
- [ ] Revisar y aprobar documentación con stakeholders
|
||
- [ ] Definir criterios de aceptación por fase
|
||
|
||
### Criterios de Éxito
|
||
|
||
- ✅ Documentación completa y aprobada
|
||
- ✅ Modelo canónico validado
|
||
- ✅ Roadmap consensuado
|
||
- ✅ Sin cambios en código de producción
|
||
|
||
### Riesgos y Mitigaciones
|
||
|
||
**Riesgo:** Documentación incompleta
|
||
**Mitigación:** Revisión iterativa con stakeholders
|
||
|
||
---
|
||
|
||
## FASE 1: EXTRACCIÓN DE CONTENIDO (Preparación)
|
||
|
||
**Duración estimada:** 3-4 semanas
|
||
**Riesgo:** Medio
|
||
**Impacto en usuarios:** Ninguno (paralelo)
|
||
|
||
### Objetivos
|
||
|
||
1. Extraer contenido de código TypeScript a archivos JSON
|
||
2. Crear estructura de archivos para contenido editable
|
||
3. Mantener compatibilidad con app actual
|
||
4. Validar que app sigue funcionando igual
|
||
|
||
### Tareas
|
||
|
||
#### 1.1 Extracción de Protocolos
|
||
|
||
- [ ] Crear script de migración `scripts/migrate-procedures.ts`
|
||
- [ ] Leer `src/data/procedures.ts`
|
||
- [ ] Convertir a formato JSON según `MODELO_DATOS_CONTENIDO.md`
|
||
- [ ] Guardar en `content/protocols/*.json`
|
||
- [ ] Añadir metadatos iniciales (version: 1, validationStatus: 'validated')
|
||
- [ ] Validar JSON con esquema
|
||
|
||
#### 1.2 Extracción de Fármacos
|
||
|
||
- [ ] Crear script de migración `scripts/migrate-drugs.ts`
|
||
- [ ] Leer `src/data/drugs.ts`
|
||
- [ ] Convertir a formato JSON
|
||
- [ ] Guardar en `content/drugs/*.json`
|
||
- [ ] Añadir metadatos iniciales
|
||
- [ ] Validar JSON con esquema
|
||
|
||
#### 1.3 Extracción de Guías
|
||
|
||
- [ ] Crear script de migración `scripts/migrate-guides.ts`
|
||
- [ ] Leer `docs/consolidado/SECCION_XX_*.md`
|
||
- [ ] Convertir a formato JSON (mantener Markdown en campo `content`)
|
||
- [ ] Guardar en `content/guides/{guideId}/section-{num}.json`
|
||
- [ ] Añadir metadatos iniciales
|
||
- [ ] Validar JSON con esquema
|
||
|
||
#### 1.4 Extracción de Manual
|
||
|
||
- [ ] Crear script de migración `scripts/migrate-manual.ts`
|
||
- [ ] Leer `public/manual/BLOQUE_XX_*/*.md`
|
||
- [ ] Convertir a formato JSON
|
||
- [ ] Guardar en `content/manual/bloque-{id}.json`
|
||
- [ ] Añadir metadatos iniciales
|
||
- [ ] Validar JSON con esquema
|
||
|
||
#### 1.5 Validación y Testing
|
||
|
||
- [ ] Comparar contenido extraído vs original
|
||
- [ ] Verificar que no se perdió información
|
||
- [ ] Validar esquemas JSON
|
||
- [ ] Ejecutar tests existentes (deben pasar)
|
||
- [ ] Verificar que app sigue funcionando
|
||
|
||
### Criterios de Éxito
|
||
|
||
- ✅ Todo el contenido extraído a JSON
|
||
- ✅ Estructura de archivos creada
|
||
- ✅ Metadatos iniciales añadidos
|
||
- ✅ App sigue funcionando igual
|
||
- ✅ Tests existentes pasan
|
||
- ✅ Sin regresiones
|
||
|
||
### Riesgos y Mitigaciones
|
||
|
||
**Riesgo:** Pérdida de información en migración
|
||
**Mitigación:** Comparación automática contenido original vs extraído
|
||
|
||
**Riesgo:** App deja de funcionar
|
||
**Mitigación:** Mantener código original hasta validación completa
|
||
|
||
---
|
||
|
||
## FASE 2: CARGA DINÁMICA DE CONTENIDO (MVP)
|
||
|
||
**Duración estimada:** 4-5 semanas
|
||
**Riesgo:** Medio-Alto
|
||
**Impacto en usuarios:** Bajo (mejora transparente)
|
||
|
||
### Objetivos
|
||
|
||
1. Modificar app para cargar contenido desde JSON
|
||
2. Implementar cache local (IndexedDB o localStorage)
|
||
3. Mantener fallback a contenido embebido
|
||
4. Garantizar funcionamiento offline
|
||
|
||
### Tareas
|
||
|
||
#### 2.1 Sistema de Carga de Contenido
|
||
|
||
- [ ] Crear `src/lib/content-loader.ts`
|
||
- [ ] Función `loadProtocols()`: Cargar protocolos desde JSON
|
||
- [ ] Función `loadDrugs()`: Cargar fármacos desde JSON
|
||
- [ ] Función `loadGuideSection()`: Cargar sección de guía
|
||
- [ ] Función `loadManualBlock()`: Cargar bloque de manual
|
||
- [ ] Implementar fallback a contenido embebido si falla carga
|
||
- [ ] Añadir logging de errores
|
||
|
||
#### 2.2 Sistema de Cache Local
|
||
|
||
- [ ] Crear `src/lib/content-cache.ts`
|
||
- [ ] Función `cacheContent()`: Guardar en IndexedDB
|
||
- [ ] Función `getCachedContent()`: Leer de IndexedDB
|
||
- [ ] Función `isStale()`: Verificar si cache está obsoleto
|
||
- [ ] Función `clearCache()`: Limpiar cache
|
||
- [ ] Implementar versionado de cache
|
||
- [ ] Añadir expiración de cache (ej: 7 días)
|
||
|
||
#### 2.3 Integración en App
|
||
|
||
- [ ] Modificar `src/data/procedures.ts`:
|
||
- [ ] Mantener array embebido como fallback
|
||
- [ ] Intentar cargar desde JSON al iniciar
|
||
- [ ] Usar contenido dinámico si disponible, fallback si no
|
||
- [ ] Modificar `src/data/drugs.ts` (mismo patrón)
|
||
- [ ] Modificar cargadores de guías (mismo patrón)
|
||
- [ ] Modificar cargadores de manual (mismo patrón)
|
||
|
||
#### 2.4 Testing y Validación
|
||
|
||
- [ ] Tests unitarios para content-loader
|
||
- [ ] Tests unitarios para content-cache
|
||
- [ ] Tests de integración: App carga contenido dinámico
|
||
- [ ] Tests de fallback: App funciona sin red
|
||
- [ ] Tests de cache: App usa cache cuando corresponde
|
||
- [ ] Testing manual en dispositivos reales
|
||
|
||
### Criterios de Éxito
|
||
|
||
- ✅ App carga contenido desde JSON
|
||
- ✅ Cache local funciona correctamente
|
||
- ✅ Fallback a contenido embebido funciona
|
||
- ✅ App funciona 100% offline
|
||
- ✅ Sin regresiones en funcionalidad
|
||
- ✅ Performance igual o mejor
|
||
|
||
### Riesgos y Mitigaciones
|
||
|
||
**Riesgo:** App deja de funcionar si falla carga
|
||
**Mitigación:** Fallback robusto a contenido embebido
|
||
|
||
**Riesgo:** Performance degradada
|
||
**Mitigación:** Cache agresivo, carga asíncrona
|
||
|
||
**Riesgo:** Cache corrupto
|
||
**Mitigación:** Validación de cache, limpieza automática
|
||
|
||
---
|
||
|
||
## FASE 3: PANEL MÍNIMO VIABLE (MVP)
|
||
|
||
**Duración estimada:** 6-8 semanas
|
||
**Riesgo:** Alto
|
||
**Impacto en usuarios:** Ninguno (panel separado)
|
||
|
||
### Objetivos
|
||
|
||
1. Crear panel de administración básico
|
||
2. Permitir edición de protocolos y fármacos
|
||
3. Implementar validación básica
|
||
4. Guardar cambios en archivos JSON (Git-based)
|
||
|
||
### Tareas
|
||
|
||
#### 3.1 Infraestructura del Panel
|
||
|
||
- [ ] Crear proyecto `admin-panel/` (React + Vite)
|
||
- [ ] Configurar autenticación básica (JWT)
|
||
- [ ] Crear layout del panel
|
||
- [ ] Implementar navegación básica
|
||
|
||
#### 3.2 Editor de Protocolos
|
||
|
||
- [ ] Crear `admin-panel/src/pages/ProtocolsEditor.tsx`
|
||
- [ ] Formulario para editar protocolo:
|
||
- [ ] Título, pasos, advertencias, etc.
|
||
- [ ] Validación de campos (Zod)
|
||
- [ ] Preview del protocolo
|
||
- [ ] Guardar en `content/protocols/*.json`
|
||
|
||
#### 3.3 Editor de Fármacos
|
||
|
||
- [ ] Crear `admin-panel/src/pages/DrugsEditor.tsx`
|
||
- [ ] Formulario para editar fármaco:
|
||
- [ ] Dosis, vías, indicaciones, etc.
|
||
- [ ] Validación de campos
|
||
- [ ] Preview del fármaco
|
||
- [ ] Guardar en `content/drugs/*.json`
|
||
|
||
#### 3.4 Sistema de Guardado
|
||
|
||
- [ ] Crear API básica (Node.js + Express o similar)
|
||
- [ ] Endpoint `PUT /api/content/protocols/:id`
|
||
- [ ] Endpoint `PUT /api/content/drugs/:id`
|
||
- [ ] Guardar en archivos JSON
|
||
- [ ] Incrementar versión automáticamente
|
||
- [ ] Crear entrada en changeLog
|
||
|
||
#### 3.5 Testing del Panel
|
||
|
||
- [ ] Tests unitarios de editores
|
||
- [ ] Tests de integración: Editar y guardar
|
||
- [ ] Validar que cambios se reflejan en app
|
||
- [ ] Testing manual completo
|
||
|
||
### Criterios de Éxito
|
||
|
||
- ✅ Panel permite editar protocolos
|
||
- ✅ Panel permite editar fármacos
|
||
- ✅ Cambios se guardan correctamente
|
||
- ✅ Versiones se incrementan
|
||
- ✅ App consume contenido actualizado
|
||
- ✅ Sin errores en producción
|
||
|
||
### Riesgos y Mitigaciones
|
||
|
||
**Riesgo:** Panel no funciona correctamente
|
||
**Mitigación:** Testing exhaustivo antes de producción
|
||
|
||
**Riesgo:** Cambios corruptos
|
||
**Mitigación:** Validación estricta, backups automáticos
|
||
|
||
**Riesgo:** Conflictos de edición
|
||
**Mitigación:** Sistema de locks o warnings
|
||
|
||
---
|
||
|
||
## FASE 4: VALIDACIÓN CLÍNICA Y ROLES
|
||
|
||
**Duración estimada:** 4-5 semanas
|
||
**Riesgo:** Medio
|
||
**Impacto en usuarios:** Ninguno (solo panel)
|
||
|
||
### Objetivos
|
||
|
||
1. Implementar sistema de roles
|
||
2. Implementar flujo de validación clínica
|
||
3. Añadir campos de metadatos de validación
|
||
4. Permitir aprobar/rechazar cambios
|
||
|
||
### Tareas
|
||
|
||
#### 4.1 Sistema de Roles
|
||
|
||
- [ ] Crear tabla de usuarios y roles
|
||
- [ ] Implementar RBAC (Role-Based Access Control)
|
||
- [ ] Roles: Administrador Clínico, Editor Docente, Editor Clínico, Revisor
|
||
- [ ] Proteger endpoints según roles
|
||
- [ ] UI del panel muestra/oculta según rol
|
||
|
||
#### 4.2 Flujo de Validación
|
||
|
||
- [ ] Añadir campo `validationStatus` a contenido
|
||
- [ ] Estados: 'draft', 'pending', 'validated', 'rejected'
|
||
- [ ] Botón "Solicitar Validación" en panel
|
||
- [ ] Panel de validación para Administrador Clínico
|
||
- [ ] Botones "Aprobar" / "Rechazar"
|
||
- [ ] Notificaciones de cambios de estado
|
||
|
||
#### 4.3 Metadatos de Validación
|
||
|
||
- [ ] Campos: `validatedBy`, `validatedAt`, `clinicalSource`
|
||
- [ ] Formulario para completar metadatos
|
||
- [ ] Validación obligatoria antes de aprobar
|
||
- [ ] Historial de validaciones
|
||
|
||
#### 4.4 Testing
|
||
|
||
- [ ] Tests de roles y permisos
|
||
- [ ] Tests de flujo de validación
|
||
- [ ] Testing manual con usuarios reales
|
||
|
||
### Criterios de Éxito
|
||
|
||
- ✅ Roles funcionan correctamente
|
||
- ✅ Flujo de validación completo
|
||
- ✅ Metadatos se guardan correctamente
|
||
- ✅ Solo contenido validado es público
|
||
- ✅ Historial de validaciones disponible
|
||
|
||
### Riesgos y Mitigaciones
|
||
|
||
**Riesgo:** Roles mal configurados
|
||
**Mitigación:** Testing exhaustivo, documentación clara
|
||
|
||
**Riesgo:** Contenido no validado se publica
|
||
**Mitigación:** Validación estricta en backend
|
||
|
||
---
|
||
|
||
## FASE 5: EDITORES COMPLETOS Y MIGRACIÓN
|
||
|
||
**Duración estimada:** 6-8 semanas
|
||
**Riesgo:** Medio
|
||
**Impacto en usuarios:** Bajo (mejoras transparentes)
|
||
|
||
### Objetivos
|
||
|
||
1. Completar editores de guías y manual
|
||
2. Migrar todo el contenido a sistema nuevo
|
||
3. Desactivar código embebido (solo fallback)
|
||
4. Validar que todo funciona correctamente
|
||
|
||
### Tareas
|
||
|
||
#### 5.1 Editor de Guías
|
||
|
||
- [ ] Crear `admin-panel/src/pages/GuidesEditor.tsx`
|
||
- [ ] Editor Markdown con preview
|
||
- [ ] Navegación entre secciones (1-8)
|
||
- [ ] Validación de estructura (8 secciones)
|
||
- [ ] Guardar en `content/guides/{guideId}/section-{num}.json`
|
||
|
||
#### 5.2 Editor de Manual
|
||
|
||
- [ ] Crear `admin-panel/src/pages/ManualEditor.tsx`
|
||
- [ ] Editor Markdown avanzado
|
||
- [ ] Navegación por bloques
|
||
- [ ] Búsqueda y reemplazo
|
||
- [ ] Guardar en `content/manual/bloque-{id}.json`
|
||
|
||
#### 5.3 Migración Completa
|
||
|
||
- [ ] Migrar todas las guías (10 guías × 8 secciones)
|
||
- [ ] Migrar todo el manual (94 archivos)
|
||
- [ ] Validar que todo el contenido está migrado
|
||
- [ ] Comparar contenido original vs migrado
|
||
|
||
#### 5.4 Desactivación de Código Embebido
|
||
|
||
- [ ] Marcar código embebido como "deprecated"
|
||
- [ ] Mantener solo como fallback de emergencia
|
||
- [ ] Documentar proceso de rollback
|
||
- [ ] Monitorear uso de fallback
|
||
|
||
### Criterios de Éxito
|
||
|
||
- ✅ Todos los editores funcionan
|
||
- ✅ Todo el contenido migrado
|
||
- ✅ Sin pérdida de información
|
||
- ✅ App funciona 100% con contenido dinámico
|
||
- ✅ Fallback solo se usa en emergencias
|
||
|
||
### Riesgos y Mitigaciones
|
||
|
||
**Riesgo:** Pérdida de contenido en migración
|
||
**Mitigación:** Validación exhaustiva, backups
|
||
|
||
**Riesgo:** App deja de funcionar
|
||
**Mitigación:** Fallback robusto, rollback plan
|
||
|
||
---
|
||
|
||
## FASE 6: MEJORAS Y OPTIMIZACIÓN
|
||
|
||
**Duración estimada:** 4-6 semanas
|
||
**Riesgo:** Bajo
|
||
**Impacto en usuarios:** Positivo (mejoras)
|
||
|
||
### Objetivos
|
||
|
||
1. Mejorar UX del panel
|
||
2. Optimizar performance
|
||
3. Añadir funcionalidades avanzadas
|
||
4. Documentar proceso completo
|
||
|
||
### Tareas
|
||
|
||
#### 6.1 Mejoras de UX
|
||
|
||
- [ ] Autoguardado en editores
|
||
- [ ] Indicadores de cambios no guardados
|
||
- [ ] Búsqueda en panel
|
||
- [ ] Filtros y ordenación
|
||
- [ ] Dashboard con estadísticas
|
||
|
||
#### 6.2 Optimización
|
||
|
||
- [ ] Lazy loading de contenido
|
||
- [ ] Compresión de JSON
|
||
- [ ] CDN para contenido estático
|
||
- [ ] Optimización de cache
|
||
|
||
#### 6.3 Funcionalidades Avanzadas
|
||
|
||
- [ ] Comparación de versiones (diff)
|
||
- [ ] Rollback a versiones anteriores
|
||
- [ ] Exportar/importar contenido
|
||
- [ ] Plantillas de contenido
|
||
|
||
#### 6.4 Documentación
|
||
|
||
- [ ] Manual de usuario del panel
|
||
- [ ] Guía de administración
|
||
- [ ] Proceso de validación clínica
|
||
- [ ] Troubleshooting
|
||
|
||
### Criterios de Éxito
|
||
|
||
- ✅ Panel es fácil de usar
|
||
- ✅ Performance mejorada
|
||
- ✅ Funcionalidades avanzadas disponibles
|
||
- ✅ Documentación completa
|
||
|
||
---
|
||
|
||
## 📊 RESUMEN DEL ROADMAP
|
||
|
||
### Timeline Estimado
|
||
|
||
| Fase | Duración | Riesgo | Impacto Usuarios |
|
||
|------|----------|--------|------------------|
|
||
| Fase 0: Preparación | 2-3 semanas | Bajo | Ninguno |
|
||
| Fase 1: Extracción | 3-4 semanas | Medio | Ninguno |
|
||
| Fase 2: Carga Dinámica | 4-5 semanas | Medio-Alto | Bajo |
|
||
| Fase 3: Panel MVP | 6-8 semanas | Alto | Ninguno |
|
||
| Fase 4: Validación | 4-5 semanas | Medio | Ninguno |
|
||
| Fase 5: Editores Completos | 6-8 semanas | Medio | Bajo |
|
||
| Fase 6: Mejoras | 4-6 semanas | Bajo | Positivo |
|
||
| **TOTAL** | **29-39 semanas** | | |
|
||
|
||
**Nota:** Timeline puede variar según recursos y prioridades.
|
||
|
||
---
|
||
|
||
### Dependencias
|
||
|
||
```
|
||
Fase 0 (Preparación)
|
||
↓
|
||
Fase 1 (Extracción)
|
||
↓
|
||
Fase 2 (Carga Dinámica)
|
||
↓
|
||
Fase 3 (Panel MVP) ──┐
|
||
↓ │
|
||
Fase 4 (Validación) │
|
||
↓ │
|
||
Fase 5 (Editores) │
|
||
↓ │
|
||
Fase 6 (Mejoras) ←────┘
|
||
```
|
||
|
||
---
|
||
|
||
### Criterios de Éxito Global
|
||
|
||
- ✅ Contenido editable sin tocar código
|
||
- ✅ Panel funcional y seguro
|
||
- ✅ Validación clínica implementada
|
||
- ✅ App funciona 100% offline
|
||
- ✅ Sin regresiones
|
||
- ✅ Escalable a nivel institucional
|
||
|
||
---
|
||
|
||
## 🚨 RIESGOS GLOBALES Y MITIGACIONES
|
||
|
||
### Riesgo 1: Complejidad Técnica
|
||
|
||
**Descripción:** Sistema más complejo de lo esperado
|
||
**Mitigación:** Fases incrementales, validación continua
|
||
|
||
### Riesgo 2: Resistencia al Cambio
|
||
|
||
**Descripción:** Usuarios no adoptan panel
|
||
**Mitigación:** UX excelente, formación, documentación
|
||
|
||
### Riesgo 3: Contenido Corrupto
|
||
|
||
**Descripción:** Ediciones incorrectas rompen app
|
||
**Mitigación:** Validación estricta, backups, rollback
|
||
|
||
### Riesgo 4: Performance Degradada
|
||
|
||
**Descripción:** Carga dinámica más lenta
|
||
**Mitigación:** Cache agresivo, optimización, monitoreo
|
||
|
||
---
|
||
|
||
## 📝 NOTAS FINALES
|
||
|
||
### Priorización Flexible
|
||
|
||
**Este roadmap es una guía, no un contrato.** Las fases pueden:
|
||
- Reordenarse según necesidades
|
||
- Acelerarse si hay recursos
|
||
- Pausarse si hay problemas
|
||
- Iterarse según feedback
|
||
|
||
### Validación Continua
|
||
|
||
**Cada fase debe validarse con:**
|
||
- Usuarios reales (TES)
|
||
- Stakeholders (médicos, docentes)
|
||
- Testing exhaustivo
|
||
- Monitoreo en producción
|
||
|
||
### Documentación Viva
|
||
|
||
**Este roadmap se actualiza:**
|
||
- Al completar cada fase
|
||
- Al identificar nuevos riesgos
|
||
- Al recibir feedback
|
||
- Al cambiar prioridades
|
||
|
||
---
|
||
|
||
**Este roadmap es el plan de implementación. Se ejecutará de forma progresiva y validada.**
|
||
|