¿Cuánto tiempo toma desarrollar software empresarial?
La respuesta corta: entre seis y doce semanas para la mayoría de los proyectos de empresa mediana, y de tres a cinco meses cuando hay integraciones serias de por medio.
La respuesta larga importa más, porque explica dónde se va el tiempo — y por qué los proyectos que se atrasan casi nunca se atrasan por la programación.
Cómo se ve un proyecto de diez semanas
Semanas 1 y 2 — Entender. Conversaciones con quien va a usar el sistema, no solo con quien lo aprueba. Mapear el proceso como sucede de verdad, incluyendo las excepciones que nadie menciona en la primera junta. Al final de esta etapa debe existir un documento con el alcance escrito, los casos raros identificados y un presupuesto que ya no se mueve.
Es la etapa que más se quiere brincar y la que más caro sale brincarse.
Semanas 3 y 4 — Lo primero que se puede tocar. No un diseño en una presentación: algo que abre en un navegador. Suele ser el flujo principal, con datos falsos y la mitad de las funciones. Sirve para que digas “así no” mientras cambiar cuesta poco.
Semanas 5 a 8 — Construir en serio. Aquí sí se escribe el grueso del sistema. Debe haber una entrega funcional cada semana o cada dos. Si pasa un mes sin que veas nada nuevo, algo va mal, independientemente de lo que te digan en el reporte de avance.
Semana 9 — Datos reales y gente real. Se migra la información histórica y se le da acceso a un grupo pequeño. Aquí siempre aparecen sorpresas: registros duplicados, casos que nadie contempló, y una función que todos daban por obvia y nadie pidió.
Semana 10 — Salida y acompañamiento. El sistema entra en operación. Las dos semanas siguientes se van en ajustes finos y en resolver lo que solo aparece con uso real.
Los tres retrasos de siempre
Después de bastantes proyectos, los retrasos casi nunca son técnicos. Son estos tres:
1. Decisiones que no llegan
El equipo pregunta qué debe pasar cuando un pedido se cancela después de facturado. La respuesta requiere que hablen tres áreas. Nadie convoca la junta. Pasan nueve días.
Esa es la causa número uno de atraso en proyectos de software, y no aparece en ninguna metodología. La solución es aburrida y efectiva: una sola persona de tu lado con autoridad para decidir, disponible unas horas a la semana. No un comité. Una persona.
2. Sistemas de terceros
La integración con el ERP tarda porque el proveedor del ERP no contesta. La conexión con el banco requiere un trámite que nadie sabía que existía. Las credenciales del ambiente de pruebas llegan tres semanas tarde.
Nada de esto está bajo control de quien desarrolla, y es la razón por la que un proyecto con integraciones se cotiza distinto a uno sin ellas. Si tu proyecto depende de sistemas de terceros, empieza a pedir accesos el día uno — antes de que exista una sola línea de código.
3. El alcance que crece de a poquito
Nunca llega como “cambiemos el proyecto”. Llega como “ya que estamos, ¿podríamos agregar…?”. Cada petición es razonable y pequeña. Doce peticiones razonables y pequeñas son un mes.
No es que no deban agregarse. Es que deben agregarse conscientemente, con su costo y su efecto en la fecha sobre la mesa. Un proyecto sano tiene un mecanismo explícito para esto. Uno enfermo dice que sí a todo y avisa del retraso al final.
Los proyectos de software no se atrasan semanas de golpe. Se atrasan un día a la vez, y cada día tiene una buena explicación.
Por qué hoy se puede más rápido que hace cinco años
Es cierto que las herramientas de inteligencia artificial cambiaron los tiempos, pero no como se suele contar.
Lo que se aceleró es la parte mecánica: el código repetitivo, la primera versión de una pantalla, las pruebas, la documentación. Eso que antes tomaba días ahora toma horas, y es real.
Lo que no se aceleró es entender el problema, decidir qué construir, y descubrir que el proceso que te describieron no es el proceso que sucede. Esa parte sigue tomando exactamente lo que tomaba, porque depende de conversaciones con personas.
Por eso un proyecto que hace cinco años tomaba cinco meses hoy toma dos y medio, pero no toma dos semanas. La parte que se comprimió era la mitad del trabajo, no todo.
Desconfía de quien te prometa un sistema empresarial completo en quince días. O el alcance es mucho menor de lo que entendiste, o el descubrimiento no se hizo y lo van a pagar los dos más adelante.
Qué puedes hacer tú para que sea más rápido
Sorprendentemente, mucho:
Nombra a un dueño. Una persona, con calendario disponible, con autoridad. Vale más que cualquier metodología.
Consigue los accesos antes de empezar. Credenciales, ambientes de prueba, contactos técnicos de tus proveedores. Es trámite puro y bloquea semanas.
Junta a quien usa el sistema, no solo a quien lo autoriza. La persona que captura los pedidos sabe cosas que el director no sabe que no sabe.
Di que no a la mitad de tus buenas ideas. Las buenas ideas que no salgan en la primera versión no se pierden: se hacen después, cuando ya sabes cuáles importaban de verdad.
Acepta salir con menos. Un sistema que resuelve el 80% funcionando desde el mes tres vale más que uno perfecto en el mes ocho, porque durante cinco meses el primero ya está trabajando.
La única fecha que importa
No es la de entrega. Es la primera fecha en que el sistema le ahorra tiempo real a alguien.
Un proyecto bien planteado alcanza esa fecha bastante antes de estar terminado. Si tu plan no tiene ningún momento así hasta el final, el plan está mal armado — y vale más discutirlo ahora que en la semana ocho.
Si quieres saber cuánto tomaría tu caso, cuéntanoslo en veinte minutos y te decimos un rango honesto: hablemos.