Cuando el conocimiento está concentrado en una persona
Una aplicación puede funcionar durante años y resultar difícil de mantener cuando falta quien conoce sus particularidades. El problema no se resuelve copiando comentarios al código. Hace falta explicar cómo se pone en marcha, qué necesita y cómo se reconoce un resultado incorrecto.
Para una empresa abulense en esta situación, proponemos comenzar por un proceso que se utilice de verdad. Seguimos su entrada, ejecución y salida con la persona responsable y contrastamos lo que explica con los programas disponibles. Las discrepancias se conservan como preguntas por resolver.
Documentación que sirva durante una incidencia
Preparamos instrucciones con nombres de componentes, condiciones previas y comprobaciones concretas. Un manual útil debe permitir distinguir un fichero pendiente de un programa que ha terminado con error. También tiene que indicar a quién corresponde autorizar una repetición.
No incluimos contraseñas en esos documentos. La forma de obtener acceso se describe sin exponer credenciales. Si un paso depende de una herramienta no disponible o de un proveedor, lo dejamos indicado para que no parezca que otra persona puede reproducirlo de inmediato.
Elegir entre estabilizar y modernizar
El inventario puede mostrar que la necesidad principal es ordenar el mantenimiento, no cambiar de lenguaje. En ese caso planteamos correcciones acotadas y pruebas del comportamiento actual. La migración a C# y .NET se valora cuando exista un objetivo que la justifique.
Cuando se decide migrar, la documentación sirve para delimitar el piloto y preparar sus comparaciones. Una regla que todavía no se comprende no desaparece al trasladar el código: pasa a ser una incertidumbre del proyecto nuevo.
Cómo utilizar IA sin convertir suposiciones en documentación
Claude de Anthropic o herramientas de OpenAI pueden apoyar la elaboración de borradores a partir de código autorizado. Les pedimos referencias a programas y campos, pero revisamos esas referencias. El texto generado se etiqueta como pendiente de comprobación hasta contrastarlo.
Una descripción clara puede ser incorrecta si el modelo desconoce un archivo externo o una configuración. Por eso combinamos lectura del código y ejecución controlada. Tampoco completamos con una explicación inventada los pasos que no sea posible observar.
Transferir el trabajo a otra persona
El cierre de esta fase puede incluir una prueba de seguimiento: otro técnico utiliza las instrucciones para preparar una ejecución de ensayo y anota los puntos que no entiende. Esas dudas permiten mejorar la documentación antes de depender de ella durante una incidencia.
Por ejemplo, el objetivo podría ser que un nuevo responsable comprenda un proceso mensual sin necesitar indicaciones verbales en cada paso. Es un escenario de servicio y no una experiencia atribuida a un cliente de Ávila. El alcance se ajusta a la documentación y los permisos disponibles.