“¿En cuánto tiempo lo tienen listo?” es la segunda pregunta de toda reunión de software, justo después del precio. Y la respuesta honesta incomoda: depende. Pero depende de cosas concretas que se pueden explicar, y saber cuáles te permite distinguir un plazo realista de uno que se va a incumplir.
Esta guía desglosa el tiempo por fase y explica qué lo alarga.
Las fases y cuánto pesa cada una
Un sistema empresarial no se construye de corrido. Estas son las fases y su peso relativo dentro del proyecto:
| Fase | Peso del proyecto | Qué ocurre |
|---|---|---|
| Discovery y definición | 10 a 15% | Levantamiento, requerimientos, arquitectura |
| Diseño de interfaz | 10 a 15% | Flujos y pantallas antes de programar |
| Desarrollo | 40 a 50% | Construcción de los módulos |
| Integraciones | 10 a 20% | Conexión con sistemas externos |
| Pruebas y correcciones | 15 a 25% | Control de calidad y ajustes |
| Migración de datos | 5 a 15% | Traer y limpiar la información existente |
| Capacitación y puesta en marcha | 5 a 10% | Entrenamiento y salida a producción |
Fíjate que desarrollar es menos de la mitad. Cuando alguien cotiza “tres meses de desarrollo”, suele estar contando solo esa franja y omitiendo el resto.
Órdenes de magnitud realistas
Sin entrar en tu caso concreto, estos son rangos que se sostienen en la práctica:
| Tipo de proyecto | Plazo típico |
|---|---|
| Módulo puntual sobre un sistema existente | 3 a 6 semanas |
| Sistema acotado, un área, sin integraciones | 2 a 4 meses |
| Sistema de gestión con 3 o 4 módulos e integraciones | 4 a 8 meses |
| Plataforma que sustituye la operación completa | 8 a 18 meses |
| Migración de un sistema legacy por fases | 12 meses en adelante |
Si alguien te ofrece un sistema de gestión completo en seis semanas, o está vendiendo un producto ya hecho —que puede ser perfectamente válido, pero no es a medida— o va a incumplir.
Lo que más alarga un proyecto (y casi nunca es programar)
1. Decisiones que no llegan
Es la causa número uno de retraso, y no depende del proveedor. El equipo entrega una pantalla para validar y pasan tres semanas sin respuesta porque el gerente está de viaje y nadie más decide. Multiplicado por veinte validaciones, son meses.
Cómo evitarlo: designa un dueño del proyecto con autoridad para decidir, y un plazo comprometido de respuesta para las validaciones.
2. Requerimientos que aparecen tarde
“Ah, y también necesitamos que emita la retención” dicho en el mes cinco es un módulo nuevo, no un ajuste. Cada requerimiento tardío reordena lo que ya se construyó.
3. Integraciones con terceros
Aquí el proveedor deja de controlar el tiempo. Depende de que el otro sistema tenga API, de que la documenten bien, de que te den credenciales de prueba y de que su soporte responda. Es el punto donde más proyectos se atascan.
4. Datos sucios
La migración se estima asumiendo que los datos están razonablemente ordenados. Cuando se abre la base y hay clientes duplicados, campos con formatos distintos y registros incompletos de diez años, la limpieza se vuelve un proyecto aparte.
5. Disponibilidad de tu equipo
Un sistema se construye con quienes conocen el proceso. Si la persona que sabe cómo funciona realmente el inventario solo tiene dos horas al mes, el proyecto avanza a ese ritmo.
Cómo se puede acelerar de verdad
| Palanca | Efecto | Costo |
|---|---|---|
| Reducir alcance de la primera versión | Alto | Ninguno: se pospone, no se pierde |
| Dedicar una persona interna al proyecto | Alto | Tiempo de tu equipo |
| Tener los datos limpios antes de migrar | Medio-alto | Trabajo previo tuyo |
| Decisiones rápidas y con autoridad | Alto | Ninguno |
| Agregar más programadores | Bajo, a veces negativo | Alto |
Esa última fila sorprende a mucha gente. Sumar desarrolladores a un proyecto atrasado suele retrasarlo más: hay que capacitarlos, coordinarlos y se multiplican los puntos de fricción. Nueve mujeres no tienen un bebé en un mes.
La palanca que de verdad funciona es recortar el alcance de la primera entrega. Sale antes, empiezas a usarlo, y lo demás se construye encima con la experiencia real de uso.
Por qué conviene una primera versión mínima
Lanzar en el mes cuatro con lo indispensable y evolucionar tiene tres ventajas sobre esperar al mes diez con todo:
- Empiezas a capturar valor antes. El sistema trabaja para ti mientras se construye el resto.
- Descubres lo que realmente necesitas. La mitad de lo que se pide al inicio cambia cuando la gente usa el sistema de verdad.
- Reduces el riesgo. Si algo está mal enfocado, lo detectas con cuatro meses invertidos, no con diez.
Señales de un plazo que no se va a cumplir
- Es un número único sin fases. “Cuatro meses” sin desglose no se puede verificar.
- No incluye pruebas ni migración. Van a aparecer después como tiempo extra.
- No menciona qué depende de ti. Ningún proyecto de software depende solo del proveedor.
- Coincide sospechosamente con tu fecha deseada. Te están diciendo lo que quieres oír.
- No hay entregas parciales. Sin hitos verificables, te enteras del atraso al final.
- No contempla qué pasa si cambia el alcance. Va a cambiar.
Preguntas frecuentes
¿Por qué dos proveedores dan plazos tan distintos para lo mismo?
Casi siempre porque entendieron alcances distintos. Uno incluyó pruebas, migración y capacitación; el otro contó solo programación. Antes de comparar plazos, verifica que ambos estén cotizando las mismas fases. Es el mismo problema que con los precios.
¿Puedo poner una fecha límite y que se ajusten?
Puedes, pero el ajuste tiene que salir del alcance, no del esfuerzo. Si la fecha es firme por una razón de negocio, dilo desde el inicio: un proveedor serio va a proponer qué entra en la primera versión para cumplirla, en vez de comprometer todo y fallar.
¿Qué pasa si el proyecto se atrasa?
Debería estar previsto en el contrato: cómo se comunica, cómo se replanifica y qué consecuencias tiene según la causa. Lo importante es distinguir atrasos por el proveedor de atrasos por decisiones pendientes del cliente o por terceros, porque se manejan distinto.
¿Cuánto tiempo debo dedicarle yo?
Más de lo que la mayoría espera. En las fases de definición y validación, cuenta con varias horas semanales de la persona que conoce el proceso. Un proyecto donde el cliente no participa termina siendo un sistema que no refleja cómo trabaja la empresa.
Artículos relacionados
- Cómo se cotiza un proyecto de software: qué es el discovery
- Ágil o cascada: qué metodología conviene a tu proyecto de software
- Deuda técnica: por qué tu sistema ya no aguanta y cuándo rehacerlo
Desarrollo de software a medida
¿Tienes un proyecto de sistema en mente?
Hacemos el diagnóstico sin costo: levantamos el problema, te decimos qué se necesita de verdad y entregamos una propuesta escrita con alcance y precio cerrados en 3 a 5 días hábiles.
Conversemos tu proyecto
Ver portafolio
64 clientes en 14 verticales · proyectos@bluenova.com.ec · +593 96 949 8704
Sigue leyendo
Comentarios y opiniones
0 comentarios · Moderación previa
Cuéntanos tu experiencia, dudas o casos similares. Revisamos cada comentario antes de publicarlo para mantener conversaciones de calidad. También puedes suscribirte para recibir nuevos artículos.