La idea clave
Como orientación, una primera fase o MVP sencillo puede tardar entre 4 y 8 semanas, un software empresarial medio entre 2 y 4 meses, y una plataforma compleja con varios módulos o integraciones puede requerir 4 a 9 meses o más. Son rangos orientativos, no fechas contractuales.
En esta guía
Plazos orientativos por complejidad
El plazo depende de alcance, reglas, integraciones, usuarios, validaciones y velocidad de feedback interno.
Una estimación sana separa discovery, diseño funcional, construcción, QA, despliegue y ajustes posteriores.
| Tipo de proyecto | Plazo orientativo | Lectura correcta |
|---|---|---|
| MVP o primera fase sencilla | 4-8 semanas | Un flujo principal, pocas integraciones y decisiones rápidas. |
| Software empresarial medio | 2-4 meses | Varios flujos, permisos, reporting e integración con operación real. |
| Plataforma compleja | 4-9 meses o más | Múltiples módulos, dependencias externas, seguridad, QA e implantación gradual. |
Primera fase o MVP
La primera fase debe concentrarse en el tramo que más valor entrega y que permite aprender con usuarios reales.
Intentar incluir todo el roadmap en el primer lanzamiento suele alargar tiempos sin mejorar la decisión de negocio.
- Flujo principal
- Usuarios clave
- Datos imprescindibles
- Validación operativa
Qué bloquea un proyecto
Los bloqueos más habituales son alcance difuso, decisiones pendientes, integraciones sin responsable, cambios de prioridad, datos desordenados y ciclos de feedback demasiado lentos.
Muchos retrasos no nacen del desarrollo, sino de dependencias externas o de no haber definido reglas y excepciones a tiempo.
- Alcance cambiante
- Dependencias externas
- Integraciones
- Feedback lento
- Datos inconsistentes
Cómo discovery reduce incertidumbre
Un discovery bien planteado reduce incertidumbre porque convierte una idea amplia en flujos, usuarios, estados, permisos, integraciones y entregables.
No elimina todo el riesgo, pero evita estimar sobre una descripción demasiado abstracta.
- Mapa de proceso
- Priorización
- Riesgos visibles
- Calendario por fases
Diseño, arquitectura y mantenimiento también consumen calendario
El plazo no se compone solo de desarrollo visible. Antes hay decisiones de diseño funcional, arquitectura, modelo de datos, permisos, integraciones y criterios de despliegue.
Después de la primera entrega también suele existir una fase de mantenimiento, ajustes de uso real, soporte y evolución. Ignorarla hace que el calendario inicial parezca más corto, pero el proyecto sea menos fiable.
- Diseño funcional
- Arquitectura
- Modelo de datos
- Seguridad
- QA
- Despliegue
- Mantenimiento
Integraciones, QA y despliegue
Las integraciones con CRM, ERP, APIs, correo, formularios o sistemas heredados pueden condicionar el calendario más que la interfaz.
QA y despliegue tampoco deberían comprimirse hasta desaparecer: son la parte que evita lanzar una herramienta frágil para operación real.
- APIs externas
- Permisos
- Pruebas
- Migración de datos
- Despliegue controlado
Qué ocurre después de la primera entrega
La salida inicial suele abrir una etapa de ajustes, soporte, aprendizaje y evolución. Esto no significa que la primera fase esté incompleta; significa que el sistema entra en contacto con uso real.
Planificar esa continuidad evita convertir cada mejora posterior en una urgencia improvisada.
- Ajustes de uso real
- Nuevos módulos
- Automatizaciones
- Mantenimiento
- Reporting mejorado
