Fases de un proyecto de software: preguntas clave

Iniciar la digitalización de una empresa implica decisiones que afectan la operatividad, la competitividad y el cumplimiento de normas como la facturación electrónica de SUNAT. En este artículo encontrarás las preguntas que todo gerente, dueño o jefe de operaciones debe formular antes de elegir al proveedor y definir las fases de un proyecto de software.

Las preguntas que hay que hacer

• ¿Cuál es el alcance funcional que entregarán?

  • Respuesta esperada: El proveedor detalla módulos, integraciones y flujos de trabajo, indicando qué procesos de tu empresa quedarán cubiertos y cuáles quedarán fuera.
  • Señal de alerta: Respuestas vagas como “un ERP completo” sin especificar qué áreas (ventas, inventario, contabilidad) estarán incluidas.

• ¿Cómo estructuran el proyecto en fases y qué entregables hay en cada una?

  • Respuesta esperada: Un cronograma dividido en análisis, diseño, desarrollo, pruebas y puesta en producción, con entregables claros (documentación, prototipos, versiones beta).
  • Señal de alerta: No hay desglose o se menciona una única fase de “desarrollo” que se extiende indefinidamente.

• ¿Qué metodología de trabajo utilizan y cómo gestionan cambios de requerimientos?

  • Respuesta esperada: Metodología ágil (Scrum o Kanban) con sprints de 2‑3 semanas, reuniones de revisión y un proceso formal de control de cambios que impacta tiempo y costo.
  • Señal de alerta: Solo se habla de metodología tradicional sin espacio para ajustes, o se ignora el tema de cambios.

• ¿Cuál es el modelo de soporte post‑implementación y quién será el responsable de la propiedad del código?

  • Respuesta esperada: Soporte de 6‑12 meses incluido, con opciones de ampliación, y el código fuente entregado bajo licencia que permite futuras modificaciones.
  • Señal de alerta: El proveedor retiene el código o no menciona un plan de soporte claro.

• ¿Cómo medirán el retorno de la digitalización?

  • Respuesta esperada: Indicadores como reducción de tiempo de facturación electrónica, mejora en la precisión de inventario y ahorro de costos operativos, con metas cuantificables a 12 meses.
  • Señal de alerta: No se proponen métricas o se delega totalmente al cliente sin acompañamiento.

Lo que tiene que estar por escrito

1. Alcance detallado: lista de funcionalidades, integraciones con SUNAT, bancos y sistemas legados. Cada ítem debe tener una descripción breve y el criterio de aceptación.
2. Entregables: documentos de requisitos, diagramas de arquitectura, código fuente, manuales de usuario y de administración, pruebas de aceptación (UAT) firmadas.
3. Plazos: cronograma con hitos en semanas, por ejemplo, análisis 3 sem, diseño 4 sem, desarrollo 12 sem, pruebas 4 sem, puesta en producción 2 sem.
4. Soporte y mantenimiento: nivel de servicio (SLA) para incidencias críticas (respuesta ≤4 h) y menores (≤24 h), duración del soporte incluido y costos de extensión.
5. Propiedad del código: cláusula que establezca la entrega total del código fuente bajo licencia que permita su uso, modificación y hospedaje sin restricciones.

Señales de alarma

• El proveedor evita firmar un contrato detallado. La falta de documentación escrita suele esconder ambigüedades que luego generan costos inesperados.
• Los plazos son demasiado amplios o no están definidos. Un proyecto sin fechas concretas dificulta la planificación de recursos internos.
• No hay referencias de proyectos similares en Perú. La normativa local (SUNAT, normativa de protección de datos) requiere experiencia específica.
• El precio está basado en “horas trabajadas” sin estimación de esfuerzo. Esto abre la puerta a sobrecostos al no haber una base de referencia.

Cómo comparar dos propuestas distintas

Cuando recibas dos ofertas que no cotizan lo mismo, sigue estos pasos:

1. Normaliza los entregables: verifica que ambas incluyan los mismos módulos y documentación. Si una propuesta omite algún entregable, descuenta su valor.
2. Alinea los plazos: convierten los tiempos a semanas y compáralos fase por fase. Una diferencia de más de 20 % en una fase crítica (por ejemplo, pruebas) debe investigarse.
3. Evalúa el modelo de soporte: compara SLA, duración y costos de extensión. Un soporte más corto o con tiempos de respuesta mayores reduce el valor percibido.
4. Revisa la propiedad del código: la propuesta que entrega el código completo bajo licencia abierta gana puntos.
5. Aplica una puntuación ponderada: asigna peso a criterios clave (alcance 30 %, plazos 25 %, soporte 20 %, propiedad 15 %, precio 10 %). Suma los puntajes y elige la opción con mayor total.

Conclusión

Al leer este artículo sabes exactamente qué preguntar antes de decidir y qué elementos deben quedar por escrito para que las fases de un proyecto de software se ejecuten sin sorpresas. Con una lista de preguntas claras, un contrato que cubra alcance, entregables, plazos, soporte y propiedad, y una metodología para comparar propuestas, tu empresa podrá iniciar la digitalización con la confianza de que cada decisión está respaldada por datos concretos y criterios objetivos.