No existe un plazo único para desarrollar software a medida. Un registro sencillo y una plataforma con múltiples permisos pueden mostrar una cantidad parecida de pantallas, pero exigir trabajos muy diferentes. Una estimación responsable parte del alcance y explica qué falta confirmar.

Qué ocupa tiempo en un proyecto

Primero se entiende el problema, el proceso actual y las personas involucradas. Después se acuerdan flujos, información, diseño y prioridades. La construcción incluye programar, integrar, probar y corregir; la puesta en marcha requiere comprobar que el equipo puede operar, y a veces migrar datos o preparar capacitación.

Estas actividades pueden solaparse. Lo importante es saber qué entregables se esperan y qué decisiones deben ocurrir antes de avanzar. Un calendario con una sola fecha final oculta dependencias que pueden cambiar el resultado.

Dependencias que suelen cambiar una estimación

  • Reglas y excepciones: una aprobación con condiciones especiales necesita definición y pruebas adicionales.
  • Información existente: trasladar archivos requiere examinar calidad, duplicados y criterios de validación.
  • Conexiones: una integración depende de documentación, credenciales y límites del proveedor externo.
  • Revisiones: el equipo del cliente necesita tiempo para probar y responder dudas.
  • Operación: seguridad, respaldos, disponibilidad y salida a producción deben planearse según el proyecto.

Cómo pedir una fecha útil

Solicita que la propuesta indique alcance, hitos, supuestos y margen de incertidumbre, además de las tareas a cargo de cada parte. Pregunta qué ocurre si una integración no está disponible o si una aprobación se retrasa. Una fecha orientativa con condiciones visibles es más útil para decidir que una promesa cerrada sin trabajo definido.

También conviene distinguir la fecha en que se puede revisar una versión de la fecha en que estará lista para uso operativo. Una demostración puede carecer todavía de controles de acceso, datos revisados o procedimientos de respaldo.

Observa el calendario de ambas partes

Reserva tiempo para las actividades de tu equipo: responder preguntas, entregar una muestra de datos, revisar prototipos y probar una versión. Identifica quién puede aprobar decisiones y quién lo reemplaza si no está disponible. Si la revisión se posterga, el desarrollo de funciones dependientes también puede detenerse. Conversar sobre estas dependencias desde el principio ayuda a interpretar las fechas y a actualizar el plan cuando cambian las condiciones.

Ejemplo: dividir una solicitud empresarial

Una empresa hipotética quiere gestionar solicitudes internas. Su primera etapa podría permitir crear una solicitud, asignar un responsable y consultar su estado. Más adelante podría evaluar reportes avanzados e integración con otro sistema. Cada etapa necesita criterios de aceptación; el ejemplo no implica que sea adecuada para toda operación.

Si el problema aún no está definido, una breve fase de descubrimiento puede servir para identificar dudas antes de estimar el desarrollo. Consulta también cómo definir una primera versión útil.

Durante la ejecución

Revisa avances con ejemplos reales, registra decisiones y mantén visibles los cambios de alcance. Si se solicita una función nueva, pregunta por su efecto en costo y plazo antes de incorporarla. Mide el progreso por resultados que pueden probarse, no solo por pantallas mostradas o tareas marcadas como completas.

Atlassian describe el MVP como una versión limitada que permite aprender con usuarios. Esa idea ayuda a priorizar, pero no convierte un calendario genérico en garantía para tu empresa.

Fuentes consultadas

Planifiquemos una primera entrega

Cuéntanos el problema y las dependencias que conoces para revisar un punto de partida.

Hablar sobre mi calendario