El sistema funciona. Los pedidos entran, los datos llegan al ERP, el equipo comercial consulta el CRM y las incidencias se resuelven. Las pruebas pasaron, el proyecto se entregó y nadie tiene una razón evidente para considerarlo problemático.
Hasta que hay que cambiar algo.
La persona que desarrolló una integración está de vacaciones. El proveedor anterior creó la cuenta de infraestructura con su propio correo. Nadie sabe por qué determinados registros se excluyen de la sincronización. Hay copias de seguridad, pero no consta que se haya probado una restauración. El código está en un repositorio, aunque publicar una nueva versión requiere seguir unos pasos que nunca se escribieron.
Ninguno de esos problemas significa necesariamente que el desarrollo sea malo. Significa que la empresa depende de información, accesos o decisiones que no puede gestionar con seguridad. El riesgo se hace visible cuando llega una incidencia, una evolución del producto o un cambio de proveedor.
Por eso, al evaluar la calidad de un proyecto tecnológico, la pregunta no debería limitarse a «¿funciona?». También hay que preguntarse quién puede operarlo, mantenerlo, modificarlo y asumir su responsabilidad mañana.
El código es solo una parte del sistema que sostiene la operación
Una aplicación rara vez funciona de forma aislada. Incluso un desarrollo aparentemente sencillo puede depender de una base de datos, un servicio de correo, una pasarela de pago, varias API, una infraestructura en la nube, un dominio, un sistema de analítica y procesos internos que no aparecen en ninguna pantalla.
Cuando el proyecto se entrega, todas esas piezas siguen necesitando gestión. Hay que renovar servicios, revisar permisos, detectar errores, aplicar cambios, responder a incidencias y entender qué efecto puede tener una modificación en otros procesos.
Pensemos en una plataforma que recibe solicitudes de clientes y las envía a un sistema interno. La funcionalidad principal puede estar perfectamente desarrollada. Sin embargo, si nadie sabe qué ocurre cuando el sistema interno rechaza una solicitud, quién recibe el aviso o cómo se reenvía sin duplicarla, la empresa tendrá que resolver la excepción manualmente. El problema operativo existe aunque la pantalla y el código hagan exactamente lo que se les pidió.
La continuidad depende de que el sistema conserve su contexto: qué hace, de qué depende, quién responde por cada parte y cómo se actúa cuando las condiciones previstas dejan de cumplirse.
Primer riesgo: los accesos existen, pero la empresa no los controla
Durante un proyecto se crean cuentas con rapidez. Alguien registra el alojamiento, conecta una API, configura el correo transaccional o contrata una herramienta necesaria para hacer pruebas. Si no se acuerda desde el principio quién debe ser titular de cada activo, es fácil que servicios esenciales terminen ligados al correo o a la tarjeta de una persona concreta.
Mientras esa persona trabaja en el proyecto, el problema puede pasar inadvertido. Aparece cuando hay que renovar un servicio, cambiar permisos, consultar la facturación, responder a una alerta de seguridad o incorporar a otro proveedor.
Controlar los accesos no significa que todo el mundo deba conocer una contraseña compartida. De hecho, conviene evitar ese modelo. Significa que la empresa dispone de una cuenta administradora bajo su control, puede conceder permisos adecuados a cada participante y tiene capacidad para revocarlos cuando termina su intervención.
En un proyecto que sostiene la operación, merece la pena identificar al menos quién controla:
- Los dominios, DNS y certificados.
- La infraestructura, los entornos y las cuentas de facturación.
- Los repositorios de código y los procesos de despliegue.
- Las bases de datos, las copias de seguridad y las herramientas de monitorización.
- Las cuentas y credenciales de servicios externos, como pasarelas de pago, correo o API.
Si un activo es esencial, la empresa debe saber dónde está, quién puede administrarlo y qué procedimiento permite transferir su gestión. También debe distinguir qué le pertenece, qué se utiliza bajo licencia y qué condiciones contractuales afectan a cada componente.
Segundo riesgo: se conocen las decisiones, pero solo mientras alguien las recuerda
Muchos proyectos acumulan decisiones que no son evidentes al leer el código. Una integración puede esperar antes de reintentar una operación para evitar duplicados. Una pantalla puede ocultar un campo porque los datos de origen no son fiables. Un proceso puede ejecutarse de noche porque durante el día bloquearía otra tarea.
Quien tomó esas decisiones suele recordar el contexto. Quien llega seis meses después ve una regla extraña y puede concluir que sobra. Al eliminarla, reaparece el problema que aquella regla resolvía.
Documentar decisiones no consiste en escribir una crónica de cada reunión. Conviene registrar las que condicionan el mantenimiento y la evolución: el problema observado, la solución elegida, las alternativas relevantes, las dependencias y las circunstancias en las que habría que revisar la decisión.
Esto es especialmente importante cuando el software incorpora lógica de negocio. Un comentario técnico puede explicar cómo se calcula una cifra; quizá no explique por qué una categoría de clientes debe tratarse de otra manera, quién aprobó esa excepción o qué sucedería si se eliminara.
La documentación útil permite que una persona nueva entienda qué puede cambiar con seguridad y qué debe verificar antes de hacerlo.
Tercer riesgo: una sola persona sostiene la respuesta ante incidencias
Es normal que haya personas con más conocimiento que otras. La dependencia se vuelve problemática cuando una incidencia no puede diagnosticarse ni contenerse sin localizar a alguien en particular.
Imaginemos que una integración deja de enviar pedidos. Si solo una persona sabe dónde consultar los errores, cómo distinguir un fallo temporal de un dato incorrecto y qué pedidos pueden reprocesarse, la capacidad de respuesta de la empresa depende de su disponibilidad. Incorporar más desarrolladores no resuelve por sí mismo esa situación: necesitan acceso, contexto y un procedimiento que puedan seguir.
Una primera respuesta razonable debería poder contestar preguntas concretas: qué proceso está afectado, desde cuándo, cuántas operaciones podrían estar pendientes, dónde queda registrado el error, quién debe recibir el aviso y qué acciones son seguras antes de investigar la causa definitiva.
Ese conocimiento puede recogerse en instrucciones breves para las incidencias previsibles, acompañadas de responsables y criterios de escalado. No garantiza que cualquier problema vaya a resolverse de inmediato. Sí evita perder las primeras horas averiguando dónde mirar o a quién llamar.
Cuarto riesgo: hay copias y despliegues, pero nadie ha comprobado la recuperación
«Hacemos copias de seguridad» y «podemos recuperar el servicio» son afirmaciones distintas. Una copia puede existir y estar incompleta. Puede incluir la base de datos y excluir archivos necesarios. Puede almacenarse correctamente y requerir una restauración que nunca se ha probado.
Algo parecido ocurre con los despliegues. Publicar cambios con facilidad no implica que sea sencillo volver atrás. Si una actualización modifica datos o cambia el esquema de una base de datos, recuperar la versión anterior de la aplicación quizá no baste para restaurar el funcionamiento.
La continuidad exige conocer qué se necesita para recuperar un proceso concreto y comprobar que los pasos funcionan. Según la criticidad del sistema, eso puede incluir pruebas de restauración, una forma de revertir cambios, instrucciones para reconstruir un entorno y decisiones previas sobre quién autoriza una intervención.
El nivel de preparación debe ser proporcional al impacto de una caída. Una herramienta interna de uso ocasional y una plataforma de la que dependen pedidos o servicios a clientes no necesitan exactamente el mismo procedimiento. Ambas requieren que sus responsables sepan qué ocurriría si dejan de estar disponibles.
La continuidad debe formar parte del delivery desde el principio
Intentar resolver todos estos puntos en el momento de la entrega suele llegar tarde. Puede que las cuentas ya se hayan creado bajo la titularidad equivocada, que las decisiones nunca se registraran o que una integración lleve meses funcionando sin trazabilidad suficiente para investigar sus errores.
El trabajo empieza al definir el proyecto. Hay que acordar qué activos utilizará, quién será su titular, qué procesos son críticos, qué responsabilidades tendrá cada parte y qué nivel de soporte necesitará después del lanzamiento. Esas decisiones permiten diseñar accesos, entornos y procedimientos coherentes con la realidad de la empresa.
Durante el desarrollo, la continuidad se mantiene con hábitos concretos: decisiones registradas cuando se toman, accesos gestionados por roles, cambios identificables, dependencias conocidas y errores que dejan una señal útil para investigarlos. Antes de la puesta en producción, conviene comprobar el despliegue, la supervisión, las copias y las acciones disponibles ante una incidencia.
Finalmente, la entrega debe incluir una transferencia real. Una lista de documentos puede formar parte de ella, pero resulta más revelador pedir a otra persona autorizada que localice un error, publique un cambio controlado o explique cómo recuperaría un servicio. Si no puede hacerlo con la información y los permisos disponibles, todavía queda trabajo de entrega.
Cómo comprobarlo sin convertirlo en una auditoría interminable
Una revisión inicial puede centrarse en cinco preguntas:
- Propiedad: ¿sabemos a nombre de quién están los activos esenciales y quién puede administrarlos?
- Operación: ¿sabemos cómo se supervisa el sistema y quién responde cuando aparece un problema?
- Cambio: ¿puede otra persona autorizada entender, probar y publicar una modificación?
- Recuperación: ¿sabemos qué datos y servicios hay que restaurar y hemos comprobado el procedimiento?
- Conocimiento: ¿están registradas las decisiones y excepciones que una persona nueva necesitaría entender?
No todas las respuestas negativas tienen la misma urgencia. Conviene priorizarlas según el impacto empresarial: qué proceso se detendría, cuántas personas dependerían de él, cuánto tiempo podría pasar antes de detectar el problema y qué alternativas existirían mientras se resuelve.
El resultado de esa revisión debería ser una lista de decisiones y acciones con responsables. Por ejemplo: trasladar una cuenta al control del cliente, documentar el reprocesamiento de pedidos, configurar una alerta útil o probar la restauración de una copia. La continuidad mejora cuando cada riesgo identificado tiene una forma concreta de reducirse.
Una entrega sólida permite elegir el futuro del sistema
Una empresa puede mantener una relación duradera con el proveedor que construyó su tecnología. Esa relación funciona mejor cuando el cliente conoce sus activos, dispone de información suficiente y sabe qué responsabilidad asume cada parte. Así puede pedir mejoras, incorporar especialistas, cambiar prioridades o preparar un traspaso sin que cada decisión se convierta en una negociación sobre accesos o conocimiento.
En Pibeca abordamos la propiedad, la documentación y la capacidad de evolución como parte de la construcción de plataformas y productos digitales. Cuando un sistema ya existe, el primer paso es entender sus dependencias antes de prometer cambios o fechas.
Si estás preparando un proyecto o necesitas recuperar el control de uno del que depende tu empresa, cuéntanos qué sistema necesitas construir o revisar.
Y hazte una última pregunta: si otra persona tuviera que asumir el sistema mañana, ¿podría hacerlo sin reconstruir su historia?
Preguntas frecuentes sobre la continuidad de un proyecto tecnológico
¿Un proyecto puede estar bien desarrollado y seguir siendo un riesgo?
Sí. El código puede funcionar según lo previsto y, aun así, la empresa puede depender de cuentas ajenas, procesos de despliegue desconocidos, decisiones no documentadas o una única persona capaz de resolver incidencias. La calidad del desarrollo también debe evaluarse por su capacidad de operación, mantenimiento y transferencia.
¿Es suficiente con entregar el código fuente y la documentación?
No siempre. El código y la documentación son necesarios, pero otra persona también necesita accesos adecuados, conocimiento de la infraestructura y de las integraciones, procedimientos para publicar cambios y una forma de diagnosticar errores. La prueba útil es comprobar si alguien autorizado puede realizar esas tareas con lo entregado.
¿La infraestructura y las cuentas deben estar siempre a nombre del cliente?
Los activos esenciales deben quedar bajo el control efectivo de la empresa. La forma concreta dependerá del contrato y de los servicios utilizados, pero el cliente debería poder identificar a sus titulares, administrar permisos, mantener el servicio y organizar un traspaso. Conviene aclararlo antes de crear las cuentas, no cuando termina la relación con un proveedor.
¿Cada cuánto hay que probar las copias de seguridad?
No hay una frecuencia única para todos los sistemas. Depende de cuánto dato puede perder la empresa, cuánto tiempo puede estar detenido el proceso y con qué frecuencia cambian la aplicación y su infraestructura. Lo imprescindible es definir un criterio, asignar un responsable y comprobar periódicamente que la restauración produce un sistema utilizable.
¿Cómo reducir la dependencia de una persona sin perder su conocimiento?
Hay que convertir la información que utiliza para trabajar en conocimiento accesible para otras personas autorizadas: decisiones relevantes, pasos de despliegue, ubicación de errores, procedimientos de recuperación y contactos de escalado. Después, conviene validar ese material mediante tareas reales o simuladas realizadas por alguien que no haya construido el sistema.
¿La continuidad implica contratar soporte permanente?
No necesariamente. Implica decidir qué respuesta necesita cada proceso y preparar los medios para proporcionarla. Algunos sistemas requieren supervisión y tiempos de respuesta acordados; otros pueden funcionar con revisiones y soporte en horario definido. La decisión debe basarse en el impacto de una interrupción y quedar clara para la empresa y su proveedor.
