Cuánto tarda en desarrollarse un sistema a la medida

El tiempo para desarrollar un sistema a la medida depende del alcance y de las condiciones para entregarlo. Un portal con un solo proceso y datos listos no requiere el mismo trabajo que una operación con varias sedes, migración de información e integraciones externas.

Para obtener una estimación útil, pide tres cosas: qué estará funcionando, bajo qué supuestos y cómo se validará. Una fecha sin esas condiciones puede ocultar trabajo pendiente.

Qué debe conocerse antes de estimar

Prepara estos datos para la primera conversación:

• Proceso: dónde comienza, dónde termina y qué excepciones tiene.
• Usuarios: quién captura, aprueba, consulta y administra.
• Información: qué datos existen, en qué formato y quién puede corregirlos.
• Integraciones: qué sistemas deben conectarse y si hay documentación, acceso y un entorno de pruebas.
• Restricciones: fecha necesaria, presupuesto, seguridad y horarios de operación.
• Validación: quién tomará decisiones y probará cada entrega.

Si algo sigue desconocido, conviene registrarlo como una dependencia o investigar primero. Suponer que una integración «seguramente es sencilla» no reduce su incertidumbre.

Las fases y el resultado que deberías recibir

Fase	Resultado revisable	Qué puede mover el calendario
Definición	Flujo, alcance inicial y criterios de aceptación	Reglas contradictorias o responsables sin definir
Primera versión utilizable	Un recorrido completo que resuelve la necesidad principal	Cambios en el flujo o accesos pendientes
Ampliación e integración	Funciones adicionales conectadas y probadas	Limitaciones de sistemas externos o datos incompletos
Puesta en operación	Usuarios preparados, información validada y plan de soporte	Migración, correcciones y aprobación de usuarios

Estas fases pueden solaparse. Lo importante es saber qué dependencia impide terminar una entrega y quién puede resolverla.

Un ejemplo de alcance que sí permite conversar sobre fechas

Imagina un sistema de solicitudes de compra. Una primera versión podría incluir captura, aprobación por un responsable y consulta del estado. Inventario, conciliación contable e integración con proveedores quedarían fuera de esa entrega inicial.

Ese ejemplo no implica un plazo estándar. Permite pedir estimaciones comparables porque delimita el recorrido. Si después se agregan aprobaciones por monto y varias empresas, habrá que revisar esfuerzo, pruebas y calendario.

También ayuda separar tiempo de trabajo y tiempo de espera. Tener la integración programada no garantiza poder probarla si aún falta una cuenta del proveedor externo.

Cómo leer una propuesta de calendario

Busca hitos con entregables y revisiones, además de una fecha final. Para cada uno pregunta:

1. ¿Qué podrá hacer el usuario al terminar?
2. ¿Con qué datos y condiciones se probará?
3. ¿Qué necesita el equipo de nuestra parte y para cuándo?
4. ¿Qué riesgos siguen abiertos?
5. ¿Cómo se notificará un cambio en la estimación?

Trabajar por iteraciones permite revisar resultados, pero la duración de una iteración no equivale al plazo de todo el proyecto. La Guía Scrum distingue el trabajo incremental y una definición compartida de cuándo un resultado está terminado.

Qué puedes hacer para reducir esperas

Asigna una persona que resuelva dudas, prepara datos de prueba y solicita accesos desde el inicio. Valida cada entrega con quienes usarán el sistema y registra los cambios antes de incorporarlos.

Priorizar un flujo completo suele ser más útil que comenzar muchos módulos sin terminar ninguno. Si el problema está concentrado en tareas repetitivas, revisa primero qué procesos conviene automatizar: quizá puedas acotar mejor la primera entrega.

Antes de contratar, usa las ocho preguntas para evaluar proveedores. Para preparar una propuesta de desarrollo a medida, lleva un ejemplo real del proceso y una lista de lo que puede esperar.