Qué preguntar antes de contratar software a medida

El riesgo no es el precio

Cuando una empresa compara presupuestos de software a medida, casi siempre mira el número de abajo. Y casi nunca es ahí donde está el riesgo.

El riesgo está en firmar algo que funciona bien durante un año y que después te deja sin salida: sin acceso al código, sin poder cambiar de proveedor, sin saber dónde están tus datos y con un mantenimiento que sube porque no tienes alternativa.

Estas son las preguntas que conviene hacer antes de firmar. Las escribimos sabiendo que somos parte interesada: nosotros también vendemos desarrollo a medida. Precisamente por eso sabemos cuáles son incómodas.

1. ¿De quién es el código?

La pregunta más importante y la que menos se hace.

Hay tres respuestas posibles y las tres son legítimas si se dicen claras: el código es tuyo, es del proveedor y tú tienes licencia de uso, o es un producto del proveedor que tú alquilas.

Lo que no es aceptable es que no esté escrito. Si el contrato no dice de quién es el código, la respuesta por defecto no te va a gustar el día que quieras cambiar de proveedor.

Pregunta complementaria: si el código es mío, ¿me lo entregas en un repositorio al que tengo acceso desde el primer día, o al final del proyecto?

La respuesta correcta es desde el primer día. Un proveedor que trabaja en un repositorio al que tú tienes acceso desde el minuto uno es un proveedor que no tiene nada que esconder.

2. ¿Dónde están mis datos y cómo los saco?

Tus datos son tuyos siempre, pero eso no significa que puedas recuperarlos con facilidad.

Preguntas concretas:

• ¿En qué proveedor y en qué país está alojada la base de datos?
• ¿Puedo obtener una copia completa y utilizable cuando quiera, sin pedir permiso?
• Si nos separamos, ¿en qué formato y en cuánto tiempo recibo todo?
• ¿Quién tiene acceso administrativo?

Para una empresa andorrana hay una capa adicional: el alojamiento fuera del país tiene implicaciones de protección de datos que conviene tener resueltas, y lo tratamos en el artículo sobre lo que exige la APDA.

3. ¿Qué incluye exactamente el mantenimiento?

"Mantenimiento" significa cosas muy distintas según quién lo diga. Conviene desglosarlo:

• Corrección de errores de lo entregado: debería estar incluido y sin plazo corto de garantía
• Actualizaciones de seguridad del framework y las dependencias: imprescindible, y es donde más proyectos se abandonan
• Cambios pequeños: ¿hay una bolsa de horas, se factura aparte, hay un mínimo?
• Soporte: en qué horario, por qué canal y con qué tiempo de respuesta
• Copias de seguridad: frecuencia, retención y, sobre todo, si se prueba que se pueden restaurar

Esa última es la que separa a los profesionales. Una copia de seguridad que nunca se ha restaurado no es una copia de seguridad, es una carpeta.

4. ¿Qué pasa si desaparecéis?

Pregunta incómoda y completamente razonable, sobre todo con proveedores pequeños. En Andorra, donde muchos equipos son de dos o tres personas, es especialmente pertinente.

Lo que quieres oír: que el código está en un repositorio al que tienes acceso, que la infraestructura está a nombre de tu empresa o es transferible, que la documentación técnica existe, y que la tecnología usada es estándar y no una invención propia.

Señal de alarma: un proveedor que ha construido tu sistema sobre un framework propio no documentado. Aunque sea bueno, te ata de por vida.

5. ¿Con qué tecnología y por qué esa?

No necesitas entender la respuesta técnica, necesitas comprobar que hay una razón.

Una respuesta buena suena a: "Laravel, porque tu proyecto es sobre todo lógica de negocio y formularios, hay muchos desarrolladores que lo conocen y podrás encontrar quien lo mantenga sin nosotros".

Una respuesta preocupante suena a: "nuestra plataforma propia", "es lo que usamos siempre" o una lista de tecnologías de moda sin conexión con tu problema.

El criterio de fondo es simple: ¿podría otro equipo coger esto y seguir? Si la respuesta es no, el precio del proyecto no incluye el coste real.

6. ¿Cómo se gestionan los cambios de alcance?

Todo proyecto cambia sobre la marcha. Lo que distingue a un proveedor serio no es que no haya cambios, es que exista un procedimiento acordado antes de que aparezcan.

Preguntas: ¿cómo se valora un cambio?, ¿quién decide si es cambio o estaba incluido?, ¿se para el resto mientras tanto?

Si la respuesta es "ya lo iremos viendo", lo que vas a ver es una discusión en el peor momento.

7. ¿Puedo hablar con dos clientes vuestros?

La pregunta más simple y la que más información da. No pidas referencias por escrito, pide hablar con alguien.

Y cuando hables, pregunta lo que de verdad importa: qué salió mal, cómo lo resolvieron, si cumplieron plazos y si volverían a contratarlos. Un cliente satisfecho te contará los problemas con naturalidad. Es justo eso lo que quieres oír, porque significa que hubo problemas y se resolvieron.

8. ¿Qué NO vais a hacer?

Un proveedor que dice que sí a todo es una señal de alarma, no de flexibilidad.

Un equipo serio te dirá que hay cosas que no tienen sentido, funcionalidades que no vas a usar, o que una parte de lo que pides se resuelve mejor con una herramienta existente que desarrollando desde cero. Si nadie te ha dicho que no a nada en toda la conversación comercial, es que te están vendiendo, no asesorando.

Y una que deberías hacerte a ti mismo

Antes de contratar nada: ¿qué problema concreto quiero resolver y cómo sabré que se ha resuelto?

Si la respuesta es "modernizarnos" o "digitalizarnos", todavía no estás listo para pedir presupuestos. Si es "quiero dejar de dedicar cuatro horas semanales a copiar datos entre el presupuesto y la factura", ya tienes un proyecto y una forma de medirlo.

Sobre ese punto de partida hablamos en el artículo sobre migrar de Excel a un sistema de gestión.

En AndorraDev respondemos a estas ocho preguntas por escrito antes de firmar nada, y el código va a un repositorio al que el cliente tiene acceso desde el primer día. Si estás evaluando proveedores y quieres una segunda opinión sobre lo que te han propuesto, escríbenos.