Qué preguntar antes de decidir

En tu empresa, la decisión de quién será dueño del código y cuánto dependerás del proveedor puede marcar la diferencia entre una solución que impulsa el negocio y una que genera costos ocultos y bloqueos operativos. En este artículo encontrarás las preguntas exactas que debes formular, los elementos contractuales que deben quedar por escrito, las señales de alarma que indican que un candidato no es fiable y una guía práctica para comparar dos propuestas que no hablan el mismo idioma.

Las preguntas que hay que hacer

• ¿Quién será el titular legal del código fuente una vez entregado?

  • Respuesta esperada de un proveedor serio: “El código será transferido a tu empresa mediante una cesión de derechos de autor, con licencia plena y sin restricciones de uso.”
  • Respuesta que debe preocuparte: “Mantendremos una licencia de uso, pero la propiedad seguirá siendo nuestra.”

• ¿En qué formato entregaremos el código y la documentación?

  • Respuesta esperada: “Entregaremos el repositorio completo en Git, con historial de commits, ramas de desarrollo y documentación Swagger/OpenAPI para APIs, además de manuales de despliegue y operación.”
  • Respuesta que debe preocuparte: “Solo entregaremos un zip con los binarios y un PDF de arquitectura.”

• ¿Qué nivel de acceso tendrás a los entornos de pruebas y producción durante el proyecto?

  • Respuesta esperada: “Te proporcionaremos credenciales de acceso a los entornos de staging y producción, con roles configurados para que tu equipo pueda revisar logs y ejecutar despliegues.”
  • Respuesta que debe preocuparte: “Solo nuestro equipo gestionará los despliegues y tú no tendrás acceso directo.”

• ¿Cuál es el proceso de gestión de cambios y cuánto tiempo se asigna a cada iteración?

  • Respuesta esperada: “Trabajamos con sprints de 2 semanas, con una reunión de planificación y una de revisión. Cada cambio mayor requiere una estimación de esfuerzo y aprobación antes de iniciar.”
  • Respuesta que debe preocuparte: “Los cambios se hacen bajo demanda y pueden retrasar el proyecto sin aviso previo.”

• ¿Qué garantías ofreces en caso de que el código entregue bugs críticos después de la puesta en marcha?

  • Respuesta esperada: “Incluimos un periodo de garantía de 12 semanas post‑entrega, con corrección de bugs críticos sin costo adicional y un SLA de respuesta de 24 horas.”
  • Respuesta que debe preocuparte: “Los bugs se corregirán bajo un contrato de mantenimiento separado y a precio de hora.”

• ¿Cómo manejas la dependencia de terceros (librerías, servicios SaaS) y qué pasa si alguno deja de estar disponible?

  • Respuesta esperada: “Documentamos todas las dependencias, evaluamos su vida útil y proponemos alternativas. Si alguna deja de estar disponible, nos comprometemos a migrar sin costo extra dentro del plazo de garantía.”
  • Respuesta que debe preocuparte: “No hay plan de contingencia y cualquier sustitución será facturada aparte.”

• ¿Cuál es la política de retención de datos y cumplimiento con la normativa peruana (por ejemplo, SUNAT y la facturación electrónica)?

  • Respuesta esperada: “El sistema cumplirá con los requisitos de SUNAT, generará XML de facturación electrónica y mantendrá los archivos por el tiempo legal (5 años). Además, ofrecemos respaldo en servidores locales o en la nube peruana.”
  • Respuesta que debe preocuparte: “El cumplimiento queda bajo tu responsabilidad y no ofrecemos soporte para actualizaciones de normativa.”

Lo que tiene que estar por escrito

1. Alcance del proyecto: descripción detallada de módulos, funcionalidades y entregables, con criterios de aceptación claros.
2. Entregables técnicos: repositorio Git, diagramas de arquitectura, scripts de despliegue, documentación de API, manuales de usuario y guía de mantenimiento.
3. Plazos: cronograma con hitos en semanas (ej. 4 semanas de análisis, 6 semanas de desarrollo de módulo X, 2 semanas de pruebas, 2 semanas de capacitación). Cada hito debe incluir una fecha de revisión y aceptación.
4. Soporte y mantenimiento: nivel de soporte (N1, N2), horarios de atención, SLA de respuesta y tiempo de resolución, y duración del periodo de garantía post‑entrega.
5. Propiedad del código: cláusula de cesión de derechos de autor, licencia de uso ilimitado, prohibición de sublicenciar el código a terceros sin autorización, y disposición para entregas de código en caso de terminación del contrato.
6. Gestión de cambios: proceso de solicitud, estimación, aprobación y registro de cambios, con impacto en tiempo y costo claramente definido.
7. Confidencialidad y datos: acuerdo de tratamiento de datos personales y cumplimiento con la Ley de Protección de Datos Personales (LPDP) y requisitos de SUNAT.
8. Penalizaciones: multas por incumplimiento de plazos (por ejemplo, 0.5 % del valor total por semana de retraso) y por no entregar la propiedad del código.

Señales de alarma

• El proveedor evita firmar una cláusula de cesión de derechos. Significa que podrías quedarte sin acceso al código si la relación se rompe.
• Entrega solo binarios y no menciona repositorio Git. Indica falta de transparencia y dificulta futuros mantenimientos.
• No define un periodo de garantía ni SLA de soporte. Aumenta el riesgo de costos inesperados por bugs críticos.
• Responde con “todo depende del alcance” sin ofrecer un desglose concreto. Señal de que el proveedor no tiene claridad sobre su propio proceso.
• Propone usar exclusivamente servicios SaaS extranjeros sin alternativas locales. Puede generar problemas de latencia y de cumplimiento con la normativa peruana.

Cómo comparar dos propuestas distintas

1. Normaliza la unidad de medida: convierte todas las estimaciones a semanas de desarrollo y horas de soporte. Si una propuesta habla en “meses” y la otra en “sprints”, tradúcelas a la misma base (ej. 1 mes ≈ 4,3 semanas).
2. Mapea los entregables: crea una tabla donde cada fila sea un entregable (código fuente, documentación, pruebas, capacitación) y cada columna la propuesta. Marca con ✔ los que están incluidos.
3. Evalúa la propiedad del código: asigna 2 puntos si la propuesta incluye cesión total de derechos, 1 punto si solo licencia, 0 puntos si no lo menciona.
4. Compara los SLA: asigna puntuación según tiempo de respuesta (24 h = 2 puntos, 48 h = 1 punto, >48 h = 0).
5. Analiza la gestión de cambios: una propuesta con proceso formal y estimaciones claras recibe 2 puntos; una sin proceso, 0.
6. Sumas y ponderas: da mayor peso (por ejemplo, 40 %) a la propiedad del código, 30 % a los SLA, 20 % a la gestión de cambios y 10 % a los plazos.

Con esta comparativa visual puedes ver rápidamente que, aunque la Propuesta B sea más corta, la Propuesta A protege mejor a tu empresa frente a riesgos de dependencia.

Conclusión

Al terminar la lectura, tendrás una lista concreta de preguntas que todo proveedor debe responder, sabrás exactamente qué cláusulas deben quedar plasmadas en el contrato y reconocerás las señales que indican que un candidato no es confiable. Además, contarás con una metodología práctica para comparar propuestas que hablan en lenguajes diferentes, de modo que la decisión se base en la protección de la propiedad del código y la reducción de la dependencia, no solo en el precio o el tiempo estimado. Con esa claridad, tu empresa podrá avanzar en su transformación digital con la seguridad de que el software será un activo estratégico y no una carga futura.