Plazos del software a medida: semanas frente a meses

Una herramienta interna pequeña con requisitos estables suele mostrar un build usable en 6–10 semanas. Sistemas multi-organización con histórico y API, 3–6 meses. El alcance inestable alarga el calendario.

Rangos que podemos decir en público

Herramientas pequeñas (cuentas, un flujo principal, unos informes): a menudo 6–10 semanas. Sistemas con aprobaciones, muchos roles y API externas: de forma habitual 3–6 meses. Son magnitudes con alcance más o menos estable, no un eslogan contractual.

Rara vez es el código lo que mueve la fecha

  • Los usuarios clave solo pueden confirmar una hora a la semana.
  • El otro ERP no tiene notas de interfaz, así que el mapeo es adivinanza.
  • Los maestros siguen en tres esquemas de código.
  • El go-live espera a un consejo o a una ventana de cumplimiento.

No reutilicéis el calendario de una app o un WMS

Las apps añaden revisión de tienda. El WMS añade un recorrido de planta y un bucle de prueba. Software, móvil y almacén son tres caminos críticos que casualmente comparten proveedor.

Acelerar tiene techo

Podéis añadir ingenieros en módulos independientes. No podéis añadir personas a un socio que entrega el libro de prueba el jueves. Escribid esa espera en el plan.

Preguntas frecuentes

¿Se puede cortar el calendario a la mitad pagando más?

El trabajo en paralelo ayuda. El descubrimiento y las interfaces de la otra parte no se comprimen igual. Esperar el libro de prueba de finanzas sigue siendo esperar.

¿Por qué explota la semana de pruebas?

Suele ser que el alcance no se congeló, o que la aceptación es "dirección echará otro vistazo". Poned la aceptación en el memo o la semana de pruebas no puede terminar.

¿Qué enviamos para un primer calendario?

Tres funciones imprescindibles y un no-objetivo explícito. Basta para esbozar una primera fase.

Listad lo que debe entrar en vivo y lo que puede esperar. Pondremos un calendario de primera fase sobre esa lista en /es/contacto/.

Ver el servicio Contacto