# Gobierno360 — Plataforma SaaS de Ciudad Inteligente
## Matriz de Funcionalidades y Roadmap a 12 Meses

## 1. Visión del producto

Gobierno360 es una plataforma SaaS **multi-tenant** que permite a gobiernos municipales y regionales **recibir, gestionar y resolver incidencias ciudadanas** de forma trazable, con inteligencia geoespacial y analítica de gestión. El valor central es cerrar el ciclo: *reporte ciudadano → asignación → resolución → transparencia*.

**Diferenciadores objetivo:**
- Time-to-value bajo: municipio operativo en menos de 2 semanas.
- Transparencia ciudadana por defecto (portal público de estado de incidencias).
- Multi-tenant real con aislamiento de datos por entidad.
- Precio accesible para municipios pequeños y medianos (modelo por tramos de población).

---

## 2. Módulos core

| # | Módulo | Propósito | Usuario principal |
|---|--------|-----------|-------------------|
| 1 | **Reporte Ciudadano** | Captar incidencias con foto, geolocalización y categoría | Ciudadano |
| 2 | **Despacho** (Dispatch) | Asignar, enrutar y dar seguimiento a cuadrillas/áreas | Operador / Supervisor |
| 3 | **GIS** | Visualizar incidencias sobre mapa; capas territoriales | Operador / Analista |
| 4 | **Analítica** | KPIs de gestión, SLAs, mapas de calor, reportes ejecutivos | Directivo / Alcalde |
| 5 | **Administración** | Tenants, usuarios, roles, catálogos, configuración | Admin de entidad / Super-admin |

---

## 3. Matriz de funcionalidades (MoSCoW)

**M** = Must (MVP) · **S** = Should (importante, no bloquea lanzamiento) · **C** = Could (deseable) · **W** = Won't *ahora* (backlog).

### 3.1 Reporte Ciudadano
| Funcionalidad | MoSCoW | Notas |
|---|:---:|---|
| Reporte web responsive (PWA) con foto + geo + categoría | **M** | Sin app; baja fricción |
| Catálogo de categorías configurable por municipio | **M** | Baches, alumbrado, basura, agua… |
| Seguimiento por folio (consulta pública sin login) | **M** | Pilar de transparencia |
| Reporte anónimo vs. identificado | **M** | Anónimo baja fricción; identificado permite notificar |
| Notificaciones de avance (email / SMS) | **S** | SMS encarece; email primero |
| Detección de duplicados por proximidad | **S** | Evita saturar despacho |
| App móvil nativa (iOS/Android) | **C** | PWA cubre el MVP |
| Reporte por WhatsApp / chatbot | **C** | Alta demanda LATAM; fase tardía |
| Encuesta de satisfacción (CSAT) post-resolución | **S** | Alimenta analítica |
| Gamificación / reputación ciudadana | **W** | Riesgo de mal uso |

### 3.2 Despacho
| Funcionalidad | MoSCoW | Notas |
|---|:---:|---|
| Bandeja de incidencias con filtros y estados | **M** | Núcleo operativo |
| Asignación manual a área/cuadrilla | **M** | |
| Estados configurables (workflow) | **M** | Recibido→Asignado→En proceso→Resuelto→Cerrado |
| SLA por categoría + alertas de vencimiento | **S** | Diferenciador de gestión |
| Asignación automática por reglas (categoría/zona) | **S** | Reduce carga del operador |
| Comentarios internos + evidencia (foto antes/después) | **M** | Auditoría |
| Reasignación y escalamiento | **S** | |
| App de campo para cuadrillas (cierre en sitio) | **C** | Depende de app móvil |
| Optimización de rutas | **W** | Complejo; backlog |

### 3.3 GIS
| Funcionalidad | MoSCoW | Notas |
|---|:---:|---|
| Mapa base con pines en (casi) tiempo real | **M** | Leaflet/MapLibre + tiles |
| Filtrado en mapa por categoría/estado/fecha | **M** | |
| Mapa de calor de densidad | **S** | Alto impacto en demos |
| Capas territoriales (colonias/distritos, GeoJSON) | **S** | Habilita analítica por zona |
| Clustering de pines a baja escala | **S** | Rendimiento con muchos puntos |
| Geocerca / asignación automática por zona | **C** | Liga con despacho automático |
| Edición de capas dentro de la plataforma | **W** | Usar GeoJSON importado |

### 3.4 Analítica
| Funcionalidad | MoSCoW | Notas |
|---|:---:|---|
| Dashboard de KPIs (volumen, % resuelto, tiempo medio) | **M** | |
| Cumplimiento de SLA por categoría/área | **S** | |
| Tendencias temporales (series por periodo) | **S** | |
| Ranking de categorías y zonas más reportadas | **S** | |
| Exportación CSV/Excel | **M** | Requisito frecuente de gobierno |
| Reportes ejecutivos PDF programados | **C** | Para alcaldía |
| Analítica predictiva / patrones con IA | **W** | Requiere volumen de datos |
| Benchmarking entre municipios | **W** | Sensible políticamente |

### 3.5 Administración
| Funcionalidad | MoSCoW | Notas |
|---|:---:|---|
| Multi-tenant con aislamiento de datos | **M** | Decisión arquitectónica base |
| Gestión de usuarios y roles (RBAC) | **M** | Admin, Operador, Supervisor, Directivo |
| Configuración de catálogos (categorías, áreas, SLAs) | **M** | Autoservicio por entidad |
| Branding por entidad (logo, colores, dominio) | **S** | Sensación de "su" plataforma |
| Bitácora de auditoría (quién hizo qué) | **M** | Exigencia de transparencia |
| Panel super-admin (alta de tenants, métricas de uso) | **M** | Operación interna |
| SSO / integración con directorio del gobierno | **C** | Entidades grandes |
| Gestión de planes y facturación in-app | **S** | Liga con modelo comercial |

---

## 4. Roadmap a 12 meses (4 fases ≈ 3 meses c/u)

Equipo pequeño (2–4 ingenieros + producto/diseño). Cada fase deja un producto **demostrable y vendible**.

### Fase 1 — MVP Fundacional (Meses 1–3)
*Objetivo: plataforma operable end-to-end para municipio piloto.*
- **Arquitectura:** multi-tenant, modelo de datos core, RBAC, super-admin básico.
- **Reporte:** PWA foto+geo+categoría; folio público; anónimo/identificado.
- **Despacho:** bandeja, asignación manual, estados, evidencia de resolución.
- **GIS:** mapa con pines + filtros básicos.
- **Admin:** usuarios/roles, catálogos, bitácora de auditoría.
- **Hito:** 1 municipio piloto en producción.

### Fase 2 — Gestión Profesional (Meses 4–6)
*Objetivo: pasar de "registro" a herramienta de gestión con SLAs.*
- **Despacho:** SLAs con alertas; reasignación/escalamiento; asignación automática por reglas.
- **Analítica:** dashboard KPIs + cumplimiento SLA + exportación CSV/Excel.
- **GIS:** mapa de calor, capas territoriales (GeoJSON), clustering.
- **Reporte:** notificaciones email; detección de duplicados; CSAT.
- **Admin:** branding por entidad; planes/facturación.
- **Hito:** 3–5 municipios de pago; caso de éxito documentado.

### Fase 3 — Escala y Canales (Meses 7–9)
*Objetivo: ampliar captación y robustez multi-tenant.*
- **Reporte:** WhatsApp/chatbot; SMS opcional.
- **GIS:** geocercas con asignación automática por zona.
- **Analítica:** tendencias, rankings, reportes PDF programados.
- **Plataforma:** rendimiento, observabilidad, backups, hardening de seguridad.
- **Admin:** SSO para entidades grandes.
- **Hito:** 10+ municipios; primer cliente regional.

### Fase 4 — Diferenciación e Inteligencia (Meses 10–12)
*Objetivo: consolidar diferenciadores y abrir ecosistema.*
- **Móvil:** app ciudadana nativa + app de campo (cierre en sitio).
- **IA:** clasificación automática de reportes por imagen/texto; detección de patrones.
- **Integraciones:** API pública / webhooks para sistemas municipales.
- **Optimización:** rutas de cuadrillas (piloto), reportes predictivos.
- **Hito:** plataforma de referencia regional.

### Cronograma visual
```
Mes →          1   2   3 | 4   5   6 | 7   8   9 | 10  11  12
─────────────────────────────────────────────────────────────
F1 MVP        ███████████|           |           |
F2 Gestión               |███████████|           |
F3 Escala                |           |███████████|
F4 Inteligencia          |           |           |███████████
─────────────────────────────────────────────────────────────
Clientes      Piloto(1)  →  Pago(3-5) →   10+     →  Regional
```

---

## 5. Consideraciones técnicas

**Arquitectura**
- **Multi-tenancy:** preferir *shared DB tenant-aware* (`tenant_id` + Row-Level Security) por costo y simplicidad; aislar por esquema solo para clientes grandes. **Decidir temprano: es difícil de revertir.**
- **Modelo de datos:** la incidencia es la entidad central. Diseñar el historial de estados como **log inmutable** desde el día 1 (alimenta auditoría y analítica).

**Stack recomendado**
- *Frontend:* Next.js (SSR) + PWA, sistema de diseño propio (UI premium consistente).
- *Backend:* API tipada (Node/TS o Python) + cola de trabajos asíncronos.
- *Base de datos:* **PostgreSQL + PostGIS** — clave para proximidad, dentro-de-zona y densidad sin servicios externos.
- *Mapas:* MapLibre GL / Leaflet con tiles de OSM o proveedor económico (evitar dependencia cara de Google Maps en MVP).
- *Fotos:* object storage S3-compatible + CDN; comprimir en cliente.
- *IA (Fase 4):* clasificación con modelo de bajo costo (p. ej. Gemini Flash) en **batch**, no en tiempo real, para controlar gasto.

**Geoespacial:** PostGIS resuelve ~90% sin servidor GIS dedicado; capas como GeoJSON importado; índices GiST; clustering del lado servidor.

**Seguridad y cumplimiento:** RBAC estricto + aislamiento verificado por pruebas (el peor incidente es fuga entre municipios); bitácora inmutable; protección de datos según país (LFPDPPP/MX, LGPD/BR, GDPR si aplica); backups y DRP desde Fase 3.

**Riesgos principales**
| Riesgo | Mitigación |
|---|---|
| Multi-tenancy difícil de revertir | Definir y probar aislamiento en Fase 1 |
| Costos de mapas/SMS/IA al escalar | Proveedores económicos; IA en batch; SMS opcional |
| Volumen geoespacial degrada rendimiento | PostGIS + índices + clustering desde Fase 2 |
| Ciclo de venta a gobierno largo | Piloto gratuito/bajo costo → caso de éxito |

---

## 6. Métricas de éxito por fase
- **F1:** piloto activo; >50 incidencias reales end-to-end.
- **F2:** % resueltas dentro de SLA > 70%; 3–5 clientes de pago.
- **F3:** 10+ municipios; ≥1 canal alternativo (WhatsApp) con tracción.
- **F4:** ≥1 cliente regional; clasificación automática útil (>80% precisión).

---

**Próximos pasos sugeridos:** (1) validar modelo de multi-tenancy y modelo de datos de incidencia; (2) confirmar municipio piloto; (3) cerrar el alcance exacto del MVP de Fase 1 con el equipo.

---