Qué preguntar antes de encargar un software a medida

En resumen: Antes de firmar un desarrollo a medida conviene preguntar mucho más que el precio y el plazo: de quién es el código, dónde estarán los datos, qué pasa si dejas de pagar el mantenimiento, cómo te llevas tus datos y quién hace las copias de seguridad. Esta guía recoge las preguntas y qué respuestas esperar.

¿Por qué preguntar tanto antes de empezar?

Un software a medida no es una compra puntual: es una relación que dura años. El presupuesto y el plazo importan, pero los problemas serios suelen aparecer después, cuando hay que cambiar algo, cuando el proveedor sube precios o cuando la empresa quiere llevarse sus datos a otro sitio. Todo eso se puede dejar resuelto antes de firmar, si se pregunta a tiempo y se pide por escrito.

Estas son las preguntas, agrupadas por tema. No hace falta hacerlas todas en la primera reunión, pero sí tener las respuestas antes de decir que sí.

Preguntas sobre el alcance: ¿qué entra exactamente?

• ¿Qué pantallas y qué funciones incluye el presupuesto? Una lista concreta, no «gestión de clientes». Lo que no está escrito no está incluido.
• ¿Qué queda fuera? Tan importante como lo anterior. Un buen presupuesto dice también lo que no entra.
• ¿Está incluida la migración de los datos que ya tengo? Pasar años de historial desde hojas de cálculo o un programa antiguo es trabajo; conviene saber si está contado.
• ¿Incluye la formación del equipo? ¿Para cuántas personas y en qué formato?

Preguntas sobre el precio: ¿cerrado o abierto?

• ¿El precio es cerrado o por horas? Un precio cerrado traslada el riesgo de desviación al proveedor; uno por horas te lo deja a ti. Ambos pueden ser razonables, pero tienes que saber cuál es.
• ¿Cómo se presupuestan los cambios que surjan? Lo sensato es que cada ampliación se presupueste aparte y la decidas tú, antes de que se haga.
• ¿Hay cuotas recurrentes? Alojamiento, mantenimiento, licencias de terceros. Pide el coste anual total, no solo el del desarrollo.
• ¿Se paga por usuario? En un desarrollo propio no debería haber cuotas por usuario a terceros; si las hay, que te expliquen por qué.

Preguntas sobre plazos: ¿cuándo y cómo lo veré?

• ¿Cuándo estará funcionando? Una fecha, con lo que estará listo en esa fecha.
• ¿Podré probarlo mientras se hace? Ver el programa desde las primeras semanas en una dirección de pruebas evita sorpresas al final.
• ¿Cada cuánto hay entregas? Desaparecer tres meses y volver con todo hecho es la receta para que no sea lo que esperabas.

Como referencia, una aplicación de gestión de tamaño medio suele llevar entre uno y dos meses según los módulos. Si te prometen mucho menos para algo grande, pregunta cómo.

¿De quién es el código?

Es la pregunta que muchos proveedores no sacan si no la haces tú. Las respuestas posibles son varias: el código puede ser tuyo, puede ser del proveedor con una licencia de uso para tu empresa, o puede tratarse de una adaptación sobre una base del proveedor. Ninguna es mala por sí misma; lo malo es no saberlo.

Pregunta también:

• ¿Podría otro programador seguir manteniéndolo si un día lo necesito?
• ¿Hay partes que dependen de servicios o licencias de terceros? ¿Cuáles y cuánto cuestan?
• ¿Está todo esto por escrito en el presupuesto o en el contrato?

¿Dónde estarán mis datos y cómo me los llevo?

• ¿En qué servidores y en qué país? Para muchas empresas es importante que los datos estén en España o en sus propios servidores.
• ¿Quién más tiene acceso? Y si el proveedor trata datos personales por cuenta tuya, debe firmar contigo un contrato de encargado del tratamiento.
• ¿Cómo exporto mis datos? En qué formato, cada cuánto y si tiene coste. Tus datos tienen que poder salir del programa, completos y legibles, sin pedir permiso.

¿Qué pasa si dejo de pagar el mantenimiento?

Otra pregunta incómoda que conviene hacer. Un programa vivo necesita actualizaciones de seguridad, copias de seguridad y pequeños arreglos, y es razonable pagar un mantenimiento por ello. Pero tienes que saber qué ocurre si un día decides no renovarlo:

• ¿El programa sigue funcionando o se apaga?
• ¿Puedo llevarme el programa y los datos a otro alojamiento?
• ¿Qué incluye exactamente el mantenimiento: horas de mejoras, soporte, tiempos de respuesta?

¿Quién hace las copias de seguridad?

• ¿Cada cuánto se hacen y cuántos días se guardan?
• ¿Dónde se guardan? Mejor si no es en el mismo servidor que el programa.
• ¿Se ha probado alguna vez a recuperar una? Una copia que nunca se ha restaurado es una esperanza, no una copia.

¿Quién lo hace y quién me atiende después?

• ¿Lo programa el propio proveedor o lo subcontrata? Ninguna opción es mala, pero tienes que saber con quién tratas.
• ¿Quién responde cuando algo falla? Que conteste quien conoce el programa por dentro ahorra mucho tiempo.
• ¿Tienen proyectos parecidos en producción? Pide verlos funcionando, aunque sea con datos de prueba.

¿Cómo vamos a trabajar juntos durante el proyecto?

Pregunta quién será tu interlocutor, por qué canal se resuelven las dudas y cada cuánto os veréis para revisar avances. Un proyecto a medida necesita decisiones de tu lado: qué campo hace falta, qué informe es prioritario, qué se deja para más adelante. Conviene saber desde el principio cuánto tiempo tendrá que dedicar tu equipo y en qué momentos, para que el proyecto no se pare esperando una respuesta.

Pide también que los acuerdos de cada reunión queden por escrito, aunque sea en un correo breve. Meses después, ese rastro evita discusiones sobre qué se pidió y qué no.

¿Qué respuestas deberían hacerte desconfiar?

• Un precio sin detalle de lo que incluye.
• «Eso ya lo vemos» ante cualquier pregunta sobre código, datos o salida.
• Plazos muy cortos para proyectos grandes sin explicar cómo.
• Ninguna forma de ver el programa hasta el final.
• Dependencias de servicios de terceros que no se mencionan hasta después.

¿Cómo se prueba y cuándo se da por terminado?

Pregunta cómo se va a comprobar que el programa hace lo que se acordó. Lo razonable es que haya una fase de pruebas con datos parecidos a los reales, en la que tu equipo use el programa como lo usará después y apunte lo que no funciona o no se entiende. Pregunta también qué se considera un error que el proveedor corrige sin coste y qué se considera un cambio, que se presupuesta aparte. Esa frontera, escrita de antemano, evita muchas discusiones.

Y pregunta qué pasa después de la entrega: si hay un periodo de garantía, cuánto dura y qué cubre.

¿Cómo se protege el programa y los datos?

• ¿Quién puede entrar y cómo? Usuarios propios para cada persona, contraseñas guardadas cifradas y permisos según el puesto.
• ¿Queda registro de lo que se hace? Saber quién cambió qué y cuándo es útil para detectar errores y abusos.
• ¿Cómo se aplican las actualizaciones de seguridad? Y quién las paga.
• ¿Qué pasa si hay un incidente? Quién avisa, en cuánto tiempo y qué se hace, sobre todo si afecta a datos personales.

En resumen

Pregunta por el alcance, el precio, los plazos y, sobre todo, por lo que pasa después: el código, los datos, el mantenimiento, la exportación y las copias. Pide las respuestas por escrito antes de firmar. Un buen proveedor no se molestará; al contrario, lo agradecerá, porque así ambos sabéis a qué os comprometéis. Si te interesa cómo lo resolvemos nosotros, empieza por el desarrollo de CRM a medida o cuéntanos tu proyecto.