Empezar por lo que no puede quedarse sin responsable
No todas las partes de una aplicación tienen la misma urgencia. Un proceso que se ejecuta una vez al año puede concentrar más riesgo que una pantalla de uso diario si nadie sabe cómo prepararlo. En el diagnóstico preguntamos qué tareas dependen de indicaciones personales y qué ocurre cuando esa persona no está.
Para empresas leonesas proponemos una lista priorizada de operaciones que necesitan conocimiento transferible. Esa lista sirve para organizar el trabajo sin exigir que toda la documentación esté disponible antes de comenzar.
Separar instrucciones de decisiones
Un procedimiento puede explicar qué botón pulsar y seguir sin aclarar cuándo conviene hacerlo. Documentamos las condiciones para ejecutar, repetir o detener una operación. También identificamos las decisiones que necesitan autorización del responsable del negocio.
Las soluciones manuales merecen una revisión específica. Si alguien corrige habitualmente un fichero antes de procesarlo, interesa saber qué detecta y por qué modifica esos campos. No convertimos esa práctica en una automatización sin comprobar su intención y sus consecuencias.
Mantenimiento que deje conocimiento aprovechable
Cuando corregimos una incidencia COBOL, procuramos asociarla a un ejemplo de reproducción y a una explicación del cambio. Esa evidencia facilita que el siguiente técnico entienda el problema y compruebe que no reaparece.
Una migración a C# y .NET puede apoyarse en esas mismas pruebas. Antes de presupuestarla de forma amplia, se selecciona un componente cuyo comportamiento esté suficientemente descrito. La transferencia de conocimiento puede avanzar aunque todavía no se haya decidido la arquitectura de destino.
IA con preguntas abiertas visibles
Las herramientas de OpenAI o Claude de Anthropic pueden preparar un primer mapa de programas. Pedimos que indiquen las dependencias que no pueden resolver con el material disponible. Es preferible una duda bien identificada a una descripción aparentemente completa que invente un paso.
Los resúmenes se revisan con el equipo y con ejecuciones autorizadas. No utilizamos la IA para atribuir una intención histórica a un autor que no ha explicado el código. La documentación distingue lo demostrado, lo confirmado por el cliente y lo que sigue pendiente.
Ensayar el relevo antes de necesitarlo
Una entrega útil puede incluir ejercicios sobre un entorno de pruebas: preparar una ejecución, interpretar un error y localizar el registro afectado. El objetivo es descubrir lagunas mientras todavía se puede pedir aclaración.
Como ejemplo, un proceso periódico podría quedar documentado junto con una muestra de entrada y una salida de referencia. Otro técnico lo repetiría y registraría diferencias. Es una propuesta metodológica, no un caso de cliente en León ni una garantía de independencia inmediata.