Qué preguntar a una empresa de desarrollo antes de contratar

La causa más habitual de conflictos no es la técnica, sino un alcance que cada parte imaginaba distinto. Estas preguntas sirven para detectarlo antes de empezar.

• ¿Puedes resumir con tus palabras qué problema vamos a resolver y para quién? Si el resumen no coincide con lo que tienes en la cabeza, para ahí.
• ¿Qué queda explícitamente fuera de la propuesta? Una propuesta sin exclusiones suele tenerlas implícitas.
• ¿Qué supuestos has hecho para estimar? Por ejemplo, número de integraciones, volumen de datos o disponibilidad de una API del ERP.
• ¿Cómo se gestiona un cambio de alcance? Quién lo valora, cómo se aprueba y cómo afecta al precio y al plazo.
• ¿Propones una fase de análisis antes de cerrar el precio? Para proyectos con incertidumbre, es una señal de rigor, no de indecisión.

Un ejemplo ilustrativo: pides una aplicación para gestionar reservas de salas. Un proveedor presupuesta solo la reserva desde la web; otro incluye también la sincronización con los calendarios corporativos, los avisos por correo y un informe de ocupación. Ambos han leído el mismo correo, pero han imaginado sistemas distintos. Preguntar por las exclusiones y los supuestos es lo que hace aflorar esa diferencia antes de comparar importes, y suele ahorrar discusiones a mitad de proyecto sobre si algo «estaba incluido».

En un desarrollo a medida, que el código te pertenezca, o que al menos tengas derechos suficientes para usarlo, modificarlo y encargar su mantenimiento a otro, no es automático: depende de lo que diga el contrato. Conviene dejarlo por escrito y revisarlo con asesoramiento jurídico si el proyecto es importante.

• ¿Quién será titular del código desarrollado específicamente para nosotros, o qué licencia de uso tendremos?
• ¿Qué partes del sistema son componentes previos del proveedor (librerías propias, plantillas) y con qué licencia se ceden?
• ¿Qué componentes de código abierto o de terceros se usarán y qué obligaciones imponen sus licencias?
• ¿Tendremos acceso al repositorio durante el proyecto, o solo al final?
• ¿Qué se entrega al terminar? Código fuente, scripts de despliegue, documentación, credenciales de todos los servicios y cuentas a nombre de la empresa.

Todo proveedor dirá que prueba su trabajo. La diferencia está en qué se prueba, cuándo y cómo puedes comprobarlo tú.

Nadie puede prometer seguridad total, y desconfía de quien lo haga. Lo que sí puede explicarse es qué prácticas se aplican de forma sistemática y cómo se tratarán tus datos durante el proyecto.

• ¿Cómo gestionáis contraseñas, claves de API y otros secretos? No deberían estar en el código ni circular por correo.
• ¿Cómo se controlan las dependencias de terceros y sus vulnerabilidades conocidas a lo largo del tiempo?
• ¿Con qué datos se trabaja en desarrollo y pruebas? Si son datos reales, ¿se anonimizan?
• ¿Dónde se alojarán el sistema y sus copias de seguridad, y quién tendrá acceso?
• Si el sistema trata datos personales, ¿cómo se regulará la relación de encargo del tratamiento?
• ¿Usáis herramientas de inteligencia artificial para programar? Si es así, ¿con qué condiciones respecto a nuestro código y nuestros datos?
• ¿Qué registros de actividad tendrá el sistema para investigar un incidente?

Un proyecto que solo se enseña al final concentra todo el riesgo en el último mes. Pregunta por el ritmo de entregas y por lo que ocurre cuando el sistema ya está en producción.

• ¿Cada cuánto veremos avances funcionando, no capturas ni presentaciones?
• ¿Habrá un entorno de pruebas al que podamos acceder durante todo el proyecto?
• ¿Quién será nuestra persona de contacto y quién hará el trabajo técnico? ¿Cambiará durante el proyecto?
• ¿Cómo se hace la puesta en producción y cómo se vuelve atrás si algo sale mal?
• ¿Qué incluye el mantenimiento, con qué tiempos de respuesta y en qué horario?
• ¿Cómo sería el traspaso si en el futuro decidimos cambiar de proveedor?

Después de las conversaciones, revisa las notas con estas preguntas. No hay un proveedor perfecto, pero sí diferencias claras en cómo gestionan el riesgo.

1. ¿El proveedor demostró haber entendido el problema, o solo repitió tus palabras?
2. ¿Las exclusiones y los supuestos están por escrito?
3. ¿Está claro qué será tuyo al terminar y qué recibirás?
4. ¿Las respuestas sobre calidad y seguridad describían procedimientos concretos?
5. ¿Verás avances funcionando con regularidad, con posibilidad de corregir el rumbo?
6. ¿Sabes cuánto costará mantenerlo y cómo cambiarías de proveedor si hiciera falta?

Puedes hacernos estas mismas preguntas. Preferimos contestarlas antes de empezar que descubrir a mitad de proyecto que esperabas otra cosa, y si alguna respuesta no te convence, es mejor saberlo pronto.