Tu sistema funciona de maravilla. Hasta que trabaja la persona que sabe por qué.
Imagina una empresa que tiene un sistema funcionando desde hace siete años. Se creó por etapas. Primero lo hizo una software house. Luego una parte la asumió un freelancer. Después otro equipo añadió un módulo B2B. La siguiente agencia conectó el CRM. Alguien más integró los pagos.
El sistema funciona.
La empresa gana dinero gracias a él.
Los empleados lo usan a diario.
Los clientes ni siquiera saben cuántos procesos ocurren en segundo plano.
Solo hay un problema.
Ya nadie sabe exactamente cómo funciona todo esto.
La documentación está parcialmente en Confluence. Algo quedó en Google Drive. Unas cuantas informaciones están en los tickets. Una integración se describió en un correo de hace cuatro años.
Y lo más importante, "seguro que se acordaba Łukasz".
Solo que Łukasz se fue hace tres años.
Y durante tres años no pasó nada.
Hasta una mañana de martes.
El sistema funciona. ¿Entonces todo está en orden?
Es uno de los estados más engañosos en los que puede encontrarse un sistema de empresa.
Funciona.
No hay averías.
Los usuarios están satisfechos.
Ventas usa la aplicación.
Los pedidos se tramitan.
Los datos llegan al CRM.
Los informes se generan.
Así que la reacción natural es: No toquemos nada. ¿Para qué meter mano en algo que funciona?
Y, de hecho, no hay motivo para cambiar un sistema que funciona solo porque se pueda.
El problema es que un sistema puede ser estable técnicamente y, al mismo tiempo, muy inestable organizativamente.
Puede funcionar hoy, pero nadie sabe qué pasará cuando haya que cambiar el servidor, el proveedor de API, el dominio, la biblioteca, el método de autenticación o una parte del proceso de negocio.
Puede ser eficiente, pero depender de una sola persona.
Puede ser seguro, pero nadie saber dónde están todas las claves de acceso.
Puede seguir desarrollándose, pero solo por la persona que conoce la historia de todas las decisiones.
Y precisamente aquí aparece el concepto de bus factor.
¿Cuántas personas pueden desaparecer antes de que el proyecto empiece a tener problemas?
El bus factor es un concepto muy simple, aunque brutal.
Preguntamos: ¿Cuántas personas deben dejar de estar disponibles para que el proyecto deje de poder mantenerse con normalidad?
Si la respuesta es: "Una", tenemos un problema.
Si la respuesta es: "Dos, pero ambas trabajan en otra empresa", tenemos un problema aún mayor.
No se trata, por supuesto, de la "desaparición" literal de las personas.
Un programador puede dejar la empresa.
Un freelancer puede terminar la colaboración.
Una software house puede dejar de atender al cliente.
Un administrador puede cambiar de trabajo.
La persona responsable de una integración concreta puede pasar a otro departamento.
El titular del conocimiento puede simplemente enfermar o no estar disponible durante varias semanas.
Si con él desaparece la posibilidad de entender el sistema, la empresa no tiene un problema de personal.
Tiene un problema de negocio.
El código no siempre dice por qué algo funciona
Se puede decir: "Pero si tenemos el código fuente. En caso de necesidad, un nuevo programador lo leerá."
Teóricamente sí.
En la práctica, el código responde sobre todo a la pregunta: cómo hace el sistema algo.
No siempre responde a la pregunta: por qué lo hace precisamente de esa manera.
Y eso es una diferencia enorme.
En el código puede haber una condición: "Si el cliente tiene un tipo de cuenta determinado, ejecuta la operación X."
Un nuevo desarrollador puede encontrarla.
Pero, ¿cómo va a saber por qué?
Puede ser un requisito de negocio.
Puede ser un resto de una integración antigua.
Puede ser una protección frente a un error de una API externa.
Puede ser una solución de contorno a un problema que existía hace cinco años.
Puede ser la solución a un caso inusual de uno de los clientes más grandes.
Puede estar ahí por una muy buena razón.
O por ninguna.
Sin contexto es difícil evaluarlo.
Por eso la documentación del sistema no debería limitarse a instrucciones:
"haz clic aquí, luego aquí".
La documentación más valiosa suele describir decisiones y dependencias, y no solo el uso de las funciones.
El conocimiento más peligroso es el que existe solo en la cabeza de alguien
Las empresas suelen tener documentación. Pero la documentación no siempre es lo mismo que el conocimiento.
Podemos tener la descripción de una API, pero no la información de por qué usamos precisamente esa API.
Podemos tener una guía de despliegue, pero no una lista de todos los lugares en los que hay que cambiar la configuración.
Podemos tener la descripción de una integración, pero no saber qué ocurrirá cuando el proveedor externo cambie el método de autorización.
Podemos tener una lista de servidores, pero no saber cuál es crítico para un proceso concreto.
Podemos tener acceso al repositorio, pero no tener acceso a la cuenta en la que se encuentra la infraestructura de producción.
Esos son precisamente los elementos que pueden convertir un cambio aparentemente sencillo en una investigación de varios días.
La integración que funciona desde hace cinco años sigue siendo una dependencia
Una de las áreas que más se ignoran son los servicios externos;
- Pagos.
- SMS.
- Correo electrónico.
- CRM.
- ERP.
- Mapas.
- Sistemas de mensajería.
- Plataformas de marketing.
- Sistemas contables.
- Servicios en la nube.
- API externas.
- Bibliotecas de código abierto.
Cada una de estas cosas forma parte de un ecosistema mayor.
Si el sistema usa diez servicios externos, no tenemos un solo sistema. Tenemos un sistema más diez dependencias. Y cada una de ellas puede cambiar.
El proveedor puede cambiar la API.
Puede cerrar el servicio.
Puede cambiar el modelo de precios.
Puede retirar la versión antigua.
Puede introducir nuevos requisitos de seguridad.
Puede ser adquirida por otra empresa.
Por eso también cobra cada vez más importancia el conocimiento sobre el origen de los componentes y las dependencias del software. El NIST señala, entre otras cosas, la importancia del SBOM, es decir, Software Bill of Materials: un listado formal de los componentes utilizados para construir el software. Ese inventario ayuda a entender de qué está hecho el sistema y a evaluar más rápido el impacto de vulnerabilidades o cambios en la cadena de suministro.
Para el negocio, esto se puede reducir a una pregunta muy simple:
¿Sabes de qué depende tu sistema?
Y ahora imagina un cambio de software house
Es uno de esos momentos en los que todas las carencias salen a la luz.
La empresa trabajó durante años con un solo proveedor. De repente, la colaboración termina. Las razones pueden ser muchas; cambio de estrategia. cambio de presupuesto. adquisición de la agencia. problemas organizativos. falta de competencias para seguir desarrollándose. O simplemente la empresa quiere trabajar con otro socio.
La nueva software house pregunta:
"¿Dónde está el repositorio?" - Está.
"¿Dónde está la infraestructura?" - Está.
"¿Cómo desplegamos a producción?" - "No lo sabemos, lo hizo el equipo anterior."
"¿Cómo funciona la integración con ERP?" - "Creo que a través de ese servidor."
"¿Qué claves API tenemos?" - "Deberían estar en el correo."
"¿Qué API son de producción?" - "No lo sabemos."
"¿Qué procesos son críticos?" - "Hay que preguntarle a Łukasz."
Łukasz ya no trabaja allí...
Y precisamente por eso la transferencia de un proyecto no es solo la transferencia del código. También hay que transferir el conocimiento.
La documentación no es un coste. Es una póliza
En muchas empresas, la documentación se trata como algo que se hace "cuando haya tiempo".
Es decir, normalmente nunca.
O al final del proyecto.
O cuando alguien pregunte.
Eso es un error.
La documentación es uno de los mecanismos que limitan el riesgo operativo. No genera ventas directamente. No mejora la conversión. No luce espectacular en una presentación.
Pero en una situación de crisis puede ser la diferencia entre: "lo arreglamos hoy"
y: "primero tenemos que encontrar a la persona que recuerda cómo funcionaba".
En las nuevas directrices del NIST sobre planes de seguridad, privacidad y gestión del riesgo de la cadena de suministro de software, documentar el propósito del sistema, su estado, los controles y la responsabilidad y comportamiento de las personas que lo gestionan se trata como un elemento de gestión ordenada del sistema.
Eso muestra muy bien el cambio de mentalidad.
La documentación no es solo una herramienta para el desarrollador.
Es un elemento de continuidad operativa de la organización.
¿Qué debería documentarse?
No se trata de crear una documentación de 800 páginas que nadie abrirá nunca.
Una buena documentación debería responder sobre todo a las preguntas que aparecerán cuando algo cambie o deje de funcionar.
- ¿Quién es el propietario del sistema?
- ¿Dónde está el código?
- ¿Dónde está la producción?
- ¿Cómo es el proceso de despliegue?
- ¿Qué entornos hay?
- ¿Cuáles son las integraciones críticas?
- ¿Qué servicios externos utilizamos?
- ¿Quién es su proveedor?
- ¿Qué contratos y cuentas tenemos?
- ¿Dónde están las claves y los datos de acceso?
- ¿Quién tiene permisos?
- ¿Cómo es el backup?
- ¿Cómo es la recuperación del sistema?
- ¿Qué componentes de código abierto se utilizan?
- ¿Qué bibliotecas están obsoletas?
- ¿Cuáles son las decisiones arquitectónicas más importantes?
- ¿Qué elementos son críticos para el negocio?
- ¿Qué ocurrirá si un servicio externo concreto deja de funcionar?
Esto no es documentación "para programadores".
Es un mapa de la dependencia del negocio respecto a la tecnología.
"Funciona, así que no lo toquemos" puede ser una estrategia. Pero hay que conocer su precio
No todas las empresas necesitan rehacer un sistema antiguo.
No todo sistema legacy es malo.
No todo código antiguo hay que reescribirlo.
Al contrario: a veces un sistema estable y antiguo es una solución mucho mejor que una migración costosa realizada sin un motivo concreto.
El problema no es la antigüedad del sistema.
El problema es la falta de conocimiento sobre su estado.
Si sabemos cómo funciona el sistema, qué dependencias tiene, dónde están los riesgos y quién puede mantenerlo, podemos decidir conscientemente:
- lo dejamos,
- lo modernizamos,
- reescribimos un fragmento,
- lo migramos,
- o no tocamos nada.
Si no lo sabemos, la decisión de "no tocarlo" no es una estrategia.
Es una apuesta.
¿Cómo es una auditoría de un sistema heredado?
Cuando un sistema existente llega a una software house, el primer paso no debería ser: "Reescribámoslo." - Primero hay que entenderlo.
Una buena auditoría debería abarcar, entre otras cosas, la arquitectura de la aplicación, el código fuente, la base de datos, la infraestructura, el proceso de despliegue, las dependencias, las integraciones, la seguridad, el acceso a los servicios y la documentación.
Pero igual de importante es entender el negocio;
- ¿Qué procesos son críticos?
- ¿Qué funciones se utilizan a diario?
- ¿Qué módulos generan ingresos?
- ¿Qué elementos pueden desactivarse sin consecuencias?
- ¿Qué ocurre cuando una integración concreta deja de funcionar?
- ¿Qué elementos son los más arriesgados?
Solo después de combinar la perspectiva técnica y la empresarial se puede decir qué necesita realmente un cambio.
La auditoría no tiene por qué acabar en una revolución
A veces el resultado de la auditoría es sorprendentemente simple.
El sistema está bien, solo hay que:
- Completar la documentación.
- Ordenar los accesos.
- Actualizar algunas bibliotecas.
- Transferir la propiedad de las cuentas.
- Describir el proceso de despliegue.
- Añadir monitorización.
- Establecer backups.
- Incorporar a una segunda persona en las áreas que solo conocía un desarrollador.
Y de repente el bus factor cambia de 1 a 3.
No hace falta reescribir toda la aplicación.
No hace falta tirar siete años de trabajo.
No hace falta construir todo desde cero.
A veces el mayor problema no es la tecnología.
Es la falta de un mapa.
El sistema debería sobrevivir a las personas que lo crearon
Esa es probablemente la regla más importante: un buen sistema debería poder sobrevivir a la marcha de un desarrollador.
Debería sobrevivir al cambio de administrador.
Debería sobrevivir al cambio de software house.
Debería sobrevivir a la reorganización de la empresa.
Debería sobrevivir a varios años de desarrollo.
Eso no significa que cada programador deba entender cada línea de código. Significa que el conocimiento crítico para el funcionamiento del negocio no puede existir únicamente en la cabeza de una sola persona.
Porque un empleado puede irse.
Un freelancer puede terminar la colaboración.
Una agencia puede desaparecer.
El proveedor puede cambiar el servicio.
Y la empresa sigue teniendo que funcionar.
La tecnología debería ser propiedad de la organización, no de la memoria de una sola persona
Eso es especialmente importante en el caso de sistemas construidos durante muchos años.
Si la empresa paga por el software, debería saber no solo dónde está el código.
Debería saber:
- qué posee,
- de qué depende,
- quién tiene acceso,
- quién puede modificarlo,
- cómo se puede desplegar,
- cómo se puede recuperar,
- cómo se puede entregar a otro equipo.
NIST, en los materiales actuales sobre la debida diligencia de proveedores, señala entre otras cosas el origen, la resiliencia, las prácticas de ciberseguridad y las dependencias en la cadena de suministro. Esto muestra una dirección más amplia: las organizaciones cada vez más deben saber no solo quién entregó el sistema, sino también de qué está compuesto el sistema y qué riesgos se asocian con su mantenimiento.
Esto ya no es solo un tema para el departamento de TI.
Es un tema de gestión del riesgo empresarial.
El peor momento para conocer tu sistema es una caída.
Se puede dedicar unos días a una auditoría.
Se puede ordenar la documentación.
Se pueden revisar las dependencias.
Se puede describir la arquitectura.
Se pueden verificar los accesos.
Se puede determinar quién es realmente responsable de las distintas áreas.
Se puede reducir el bus factor.
O se puede esperar.
Hasta que el sistema deje de funcionar.
Entonces las preguntas serán exactamente las mismas.
Solo que la presión será mayor, los usuarios esperarán, las ventas pueden detenerse y cada hora costará dinero.
Por eso vale la pena hacerse una pregunta antes de que aparezca el problema: Si mañana desapareciera la persona que mejor conoce tu sistema, ¿seguiríamos sabiendo cómo mantenerlo?
Si la respuesta es "no", eso todavía no significa que el sistema sea malo.
Significa que la empresa tiene un riesgo oculto que hasta ahora no tuvo que activar.
En Web24 no solo asumimos el código.
Tomar un proyecto existente es un trabajo completamente distinto a empezar un sistema nuevo desde cero.
Primero hay que entender qué ya existe.
Qué funciona.
Qué es crítico.
Qué es una dependencia.
Qué es un problema.
Qué es solo un resto de decisiones anteriores.
Y, sobre todo, dónde está el conocimiento sin el cual el sistema no puede desarrollarse de forma segura.
Solo entonces se pueden planificar los siguientes pasos.
A veces será modernización.
A veces desarrollo.
A veces ordenar la infraestructura.
A veces asumir el mantenimiento.
Y a veces simplemente crear un buen mapa del sistema, que durante años nadie tuvo tiempo de preparar.
Porque una software house responsable no debería construir una tecnología que solo funciona cuando la persona adecuada está sentada frente al ordenador.
El sistema debe ser más grande que la memoria de una sola persona.
Y el negocio debería tener la certeza de que, cuando alguien se vaya, la tecnología no se irá con él.
