El riesgo operativo de una aplicación crítica casi nunca está en el código. Está en las cosas de las que solo hay una: una persona que la entiende, una copia que nadie ha restaurado, un camino a producción que solo conoce quien lo recorrió la última vez.
Esto va de cómo un desarrollo a medida, bien contratado, elimina esos puntos únicos. No porque el software nuevo sea mejor —a veces ni hace falta software nuevo—, sino porque un proyecto obliga a reconstruir todo lo que rodea al código. Y el riesgo vive ahí.
Hablamos de empresas de cinco a cincuenta personas donde hay un sistema que, si se para, para la casa: el ERP, la intranet, la web por la que entran los pedidos.
Una sola persona
La aplicación funciona. La entiende una persona: el informático de siempre, el desarrollador que la hizo, la consultora que la mantiene. Mientras esa persona conteste al teléfono, no hay problema. El problema es la palabra «mientras».
No hace falta que se vaya. Bastan unas vacaciones mal puestas o una baja de tres semanas para descubrir cuánta operación vive en una sola cabeza.
Ya escribimos qué hacer cuando esa persona ya no está: la versión corta es que recuperar el control a posteriori cuesta semanas de inventario. Dentro de un proyecto a medida, en cambio, es el punto de partida. El código nace en un repositorio a vuestro nombre. La documentación de despliegue se escribe porque el propio proyecto la necesita para trabajar. Y desde la primera demo hay más de un par de ojos que ha visto el sistema por dentro.
Una sola copia, y sin probar
Todo el mundo tiene copias. Casi nadie ha visto restaurar una.
La pregunta no es si hay backup. Es cuándo se restauró uno entero delante de alguien de vuestra casa, y cuánto tardó. Una copia sin probar no es una copia: es una esperanza con fecha.
En un desarrollo a medida, la restauración se puede exigir como entregable. Antes de la puesta en producción, una restauración completa, cronometrada, con alguien vuestro mirando. Cuesta una mañana. Pedida con el sistema en marcha suena a paranoia; dentro del plan de despliegue es un punto más de la lista.
Un solo camino a producción
Hay aplicaciones que solo sabe actualizar quien las actualizó la última vez, con pasos que viven en su memoria y una carpeta que no se puede tocar. La consecuencia es un círculo que se alimenta solo: como actualizar da miedo, se actualiza poco, y como se actualiza poco, cada actualización es más grande y da más miedo.
Un proyecto a medida no puede permitirse ese círculo ni para sí mismo. Con una demo cada dos semanas, desplegar tiene que ser rutina, no acontecimiento. Ese camino repetible, probado decenas de veces durante el proyecto, se queda en vuestra casa cuando el proyecto termina. Es un efecto secundario del método, y vale más que muchas funcionalidades.
Todo a nombre de otro
El dominio a nombre de la agencia que hizo la web. El servidor en la cuenta personal del desarrollador. Las credenciales que «ya te las paso» y nunca llegan. Nada de esto duele hasta el día que hay que cambiar algo y el que tiene la llave no contesta.
La corrección aquí es una cláusula, no un proyecto: cuentas de infraestructura y repositorios a vuestro nombre desde el kickoff, accesos con el mínimo privilegio y, por escrito, qué es vuestro al terminar. Se firma antes de la primera línea de código. Si un proveedor no quiere firmarlo, ya os ha contado cómo va a acabar la relación.
La ventana en la que arreglar esto no cuesta nada
Este es el argumento entero. Pedir estas cuatro cosas con la aplicación en marcha es un proyecto: presupuesto propio, calendario propio, y nadie lo prioriza porque no añade ninguna funcionalidad. Pedirlas dentro de un desarrollo a medida es una cláusula, porque el repositorio, los accesos, el camino de despliegue y el plan de copias se van a crear igualmente. La única diferencia es a nombre de quién quedan, y con qué prueba.
Por eso un desarrollo a medida reduce el riesgo operativo. No es una propiedad mágica del software hecho a medida: software a medida abandonado hay tanto como software de catálogo abandonado. Es que el proyecto es la única ventana en la que reconstruir lo que rodea a vuestra aplicación sale gratis. Cerrada la ventana, cada una de esas cosas vuelve a ser un proyecto que compite con el día a día. Y pierde siempre.
Lo que no reduce
Dos cosas, por ser honestos con la comparación.
Un desarrollo a medida no os protege de abandonarlo después: sin mantenimiento, el sistema nuevo empieza a envejecer el día de la entrega, y en unos años estáis donde empezasteis. Y añade un riesgo que el catálogo no tiene: el proyecto mismo puede salir mal. Sobre cómo comprarlo con criterio ya escribimos cinco preguntas antes de encargar un desarrollo.
Por dónde empezar
Contad las cosas únicas. De vuestra aplicación crítica: ¿cuántas personas saben desplegarla? ¿Cuándo se restauró la última copia delante de alguien? ¿A nombre de quién está el servidor, el dominio, el código? Cada respuesta que sea «uno», «nunca» o «no lo sé» es un punto del inventario de riesgo. Ese número no baja por suerte: baja por cláusulas.
Si el número os ha salido alto, contadnos qué sistema es en nordicbyte.co.uk/get-started. En 48 horas tenéis una propuesta donde ya está escrito de quién es cada cosa al terminar.