Software libre o propietario: plazos y obstáculos

En tu empresa ya sabes que la propiedad del código y la dependencia del proveedor son decisiones estratégicas. Lo que ahora necesitas es entender cuánto tiempo lleva cerrar el proyecto y qué suele alargar esos plazos. En este artículo te explicamos, fase por fase, los tiempos reales y los obstáculos más frecuentes.

Las fases y su duración

Fase	Duración (semanas)	Entregable revisable
1. Análisis de requisitos y alineación legal	3‑4	Documento de requisitos + matriz de riesgos legales (incluye cláusulas de propiedad del código)
2. Arquitectura y diseño técnico	2‑3	Diagramas de arquitectura y prototipo de UI/UX
3. Desarrollo de módulos críticos	6‑8	Código fuente de los módulos críticos con pruebas unitarias
4. Integración y pruebas de sistema	4‑5	Suite de pruebas integradas + informe de cobertura
5. Validación de cumplimiento (SUNAT, facturación electrónica)	2‑3	Reporte de validación contra requisitos de SUNAT
6. Capacitación y transferencia de conocimiento	2‑3	Manuales de usuario y guía de despliegue del código
7. Cierre contractual y entrega definitiva	1‑2	Repositorio con código completo, documentación y certificado de propiedad

En total, un proyecto típico de software a medida en Perú se sitúa entre 20 y 28 semanas. Cada fase tiene un entregable que permite a tu equipo revisar avances y detectar desvíos a tiempo.

Qué hace que un plazo se rompa

• Requisitos poco claros o cambiantes: Cada cambio de alcance implica volver a la fase 1 o 2, añadiendo 1‑2 semanas por iteración. En promedio, los proyectos que experimentan al menos tres cambios de alcance pierden 4‑6 semanas.
• Falta de datos de entrada: Cuando la empresa no entrega bases de datos, APIs de terceros o documentación de procesos internos, el desarrollador debe invertir tiempo de investigación (aprox. 0.5‑1 semana por fuente de datos).
• Aprobaciones internas lentas: En empresas peruanas, la validación de la documentación de SUNAT y la firma de contratos pueden tardar 1‑2 semanas extra por cada ronda de revisión.
• Dependencia de terceros: Si el proyecto integra servicios externos (por ejemplo, pasarelas de pago o APIs de la Superintendencia Nacional de Aduanas), los tiempos de respuesta del proveedor externo añaden entre 1 y 3 semanas.
• Recursos internos limitados: Cuando el cliente asigna a un único responsable de negocio en lugar de un comité, la toma de decisiones se alarga 0.5‑1 semana por decisión.
• Problemas de infraestructura: Falta de ambientes de pruebas o servidores configurados retrasa la fase de integración en 1‑2 semanas.

Qué te van a pedir a ti

• Definición definitiva de requisitos: Un documento firmado que detalle funcionalidades, flujos y criterios de aceptación. Sin él, el proveedor no puede cerrar la fase de análisis.
• Acceso a sistemas críticos: Credenciales, endpoints de APIs y documentación de procesos (por ejemplo, cómo se genera la factura electrónica para SUNAT).
• Participación de usuarios clave: Al menos dos usuarios de cada área (finanzas, operaciones, TI) para validar prototipos y pruebas de aceptación.
• Aprobación de cláusulas de propiedad del código: Decidir si el código será software libre o software propietario y firmar la cláusula correspondiente. Esta decisión influye en la licencia y en la forma de entrega del repositorio.
• Plan de pruebas interno: Casos de prueba que tu equipo ejecutará durante la fase de validación, para no depender exclusivamente del proveedor.
• Calendario de revisiones: Fechas fijas para revisiones de entregables (por ejemplo, cada 2 semanas) y para la firma de actas de entrega.

Cómo saber si va bien

• Hitos de control:
  • Fin de la fase 1: Verifica que el documento de requisitos esté aprobado por todas las áreas y que incluya la cláusula de propiedad del código.
  • Fin de la fase 3: El código de los módulos críticos debe pasar al menos el 80 % de cobertura de pruebas unitarias.
  • Fin de la fase 5: El reporte de validación SUNAT debe estar libre de errores críticos.
• Señales de desvío:
  • Retrasos repetidos en la entrega de datos por parte del cliente (más de 3 días hábiles).
  • Cambios de alcance que superan el 10 % del total de requisitos originales.
  • Falta de participación de usuarios clave en pruebas de aceptación (menos del 50 % de los convocados).
  • Comentarios del equipo de desarrollo sobre bloqueos de infraestructura (ambientes no disponibles).

Si observas cualquiera de estas señales, convoca una reunión de seguimiento y renegocia el cronograma antes de que el retraso se acumule.

Conclusión

Al cerrar la lectura, sabes que la entrega del código no es un evento aislado; depende de fases bien definidas, de la claridad de los requisitos y de la participación activa de tu empresa. Un proyecto típico lleva entre 20 y 28 semanas, pero cada cambio de alcance, cada dato faltante y cada aprobación tardía pueden añadir semanas al calendario. La clave está en planificar con antelación, asignar responsables claros y establecer hitos de control que permitan detectar a tiempo cualquier desviación. Con esa disciplina, la software libre o software propietario que elijas será una ventaja estratégica, no una fuente de incertidumbre.