Casi toda pyme tiene una aplicación hecha a medida. La encargó hace ocho o diez años, resolvió un problema real y sigue funcionando. La hizo una empresa pequeña que cambió de dueño, o un informático que se estableció por su cuenta, o un empleado que ya no está. Nadie la ha tocado desde entonces porque no ha hecho falta, y ese es exactamente el problema.
Conviene decirlo sin dramatismo. Una aplicación antigua que hace su trabajo no es un fallo de gestión, es una inversión que salió bien. Lo que falla no es el programa, es que la relación que lo mantenía vivo se terminó sin que nadie lo formalizara. El día que haya que cambiar algo, integrarlo con otra cosa o corregir un fallo de seguridad, la empresa descubrirá que no tiene ni el código, ni la documentación, ni a quién llamar.
El riesgo no es teórico y tiene tres formas concretas. La primera es la parálisis, cuando un cambio en la ley o en un banco obliga a tocar el programa y no hay quien lo toque. La segunda es la seguridad, porque toda aplicación se apoya en componentes de terceros que envejecen y acumulan fallos conocidos que nadie está corrigiendo. La tercera es la del cliente que pregunta, cada vez más a menudo, quién mantiene el software con el que tratáis sus datos.
El software a medida no se rompe. Se queda huérfano, y eso solo se nota el día que hay que cambiarlo.
Lo que se firma antes de encargar
Estas cláusulas no encarecen un desarrollo, pero hay que pedirlas antes de la primera factura. Después ya no se negocian.
- Propiedad y entrega del código. Que el código fuente es de tu empresa y que se entrega en cada versión, no solo al final. Sin esto, todo lo demás sobra.
- Depósito del código. Una copia en un repositorio al que tú tengas acceso desde el primer día, con tu propia cuenta, no la del proveedor.
- Lista de componentes de terceros. Qué librerías y servicios externos lleva dentro y en qué versión. Es lo que permite saber, años después, si un fallo publicado te afecta.
- Quién parchea y en cuánto tiempo. Un compromiso escrito de corregir fallos de seguridad con un plazo, distinto del plazo de las mejoras.
- Durante cuánto tiempo. Los años de mantenimiento incluidos y el precio de renovarlos, para que la renovación no sea una negociación desde cero.
- Documentación mínima. Cómo se instala, dónde se configura y qué hace falta para levantarlo en una máquina nueva. Una página bien hecha vale más que un manual de cien.
- Salida ordenada. Qué entrega el proveedor si la relación termina y en qué plazo, incluyendo los datos en un formato que se pueda leer sin su programa.
- A quién llamar. Una persona con nombre y un canal, y el compromiso de avisar si esa persona cambia.
Y con la que ya tienes
La aplicación que lleva diez años ahí no admite cláusulas retroactivas, pero sí cuatro preguntas que se contestan en una tarde.
- Quién la hizo y si sigue existiendo. Busca la factura. Si la empresa ya no está, la respuesta a todo lo demás es que estás solo.
- Dónde está el código. Si nadie sabe contestar, esa es la primera compra pendiente, porque recuperarlo más tarde cuesta mucho más que pedirlo ahora.
- Sobre qué está montada. La versión del sistema operativo, de la base de datos y del entorno en que corre. Si alguna está fuera de soporte, la aplicación hereda ese problema entero.
- Qué pasaría si mañana no arranca. Cuánto tiempo aguanta el negocio sin ella y si existe una copia desde la que reconstruirla.
Ninguna de esas preguntas es técnica en el fondo. Todas son preguntas de dependencia, del mismo tipo que las que hay que hacerse sobre cualquier sistema que sostiene el negocio, y ese trabajo empieza por la lista que describimos en El inventario que no tienes.
El próximo desarrollo a medida lo vas a encargar igual, porque a menudo es la decisión correcta. La diferencia entre encargarlo bien y encargarlo mal no está en el precio ni en el plazo, está en ocho líneas del contrato que se escriben una vez. Lo que queda hecho para la próxima vez es un anexo reutilizable, y la aplicación que salga de ahí seguirá siendo tuya el día que el proveedor deje de existir.
