La documentación técnica es probablemente el entregable más subestimado en proyectos TI. No el plan previo al proyecto, que suele estar bien desarrollado. Lo que se subestima es la documentación de lo que realmente quedó implementado: la arquitectura resultante, las decisiones que se tomaron en el camino, y los procedimientos que el equipo del cliente necesita para operar el sistema de forma autónoma.
En Aleph Server, documentar el resultado de cada proyecto es parte del trabajo, no un extra. Esta es la razón.
El costo que no aparece en el proyecto
El escenario es más frecuente de lo que parece: seis meses después de una implementación, alguien del equipo técnico del cliente cambia de rol o deja la empresa. El sistema funciona. Pero nadie sabe exactamente cómo está configurado, qué decisiones de diseño se tomaron ni por qué.
El día que hay que hacer un cambio, agregar una integración nueva o resolver un problema fuera de lo habitual, el tiempo de diagnóstico se multiplica porque no hay referencia. Si el proveedor original también tiene rotación de personal, el problema es mayor todavía.
Ese costo no aparece en el presupuesto del proyecto original. Aparece meses después, en forma de horas de trabajo no planificadas, decisiones tomadas sin contexto, y riesgo operacional acumulado.
Qué documentamos y por qué esas tres cosas
En todo proyecto, Aleph Server entrega tres tipos de documentación.
Arquitectura resultante: descripción de qué existe en el entorno, cómo se conecta, dónde está físicamente o lógicamente, y cuáles son los puntos críticos. No como diagrama decorativo: como referencia operacional que permite a cualquier persona técnica entender el entorno en menos de una hora.
Registro de decisiones técnicas: qué se eligió y por qué. Por qué Proxmox y no VMware en ese caso específico. Por qué ese diseño de red y no otro. Por qué esa configuración de almacenamiento. Las decisiones técnicas tienen contexto que no es obvio seis meses después. Documentar ese contexto evita que el equipo del cliente tenga que reconstruirlo bajo presión.
Procedimientos operacionales básicos: los pasos que el equipo del cliente necesita para operar el sistema en el día a día. Cómo verificar el estado de los backups. Cómo agregar una VM nueva al clúster. Cómo interpretar una alerta del sistema de monitoreo. Esa documentación tiene que ser legible para el equipo del cliente, no solo para quien la escribió.
La autonomía como criterio de éxito del proyecto
La definición que usamos internamente para un proyecto bien ejecutado incluye que el cliente pueda operar el resultado de forma autónoma en el día a día. Para situaciones complejas, cambios de mayor alcance o problemas fuera de lo esperado, estamos disponibles. Pero el soporte no debería ser necesario para lo cotidiano.
Si un cliente necesita llamarnos para cada ajuste menor, hay dos posibles razones: el sistema es más frágil de lo que debería, o la documentación y transferencia de conocimiento no fueron suficientes. Cualquiera de las dos es un problema que debemos resolver.
Esto implica que la documentación tiene que estar escrita para el equipo que la va a usar, no para el equipo que la escribe. Un documento técnico que solo entiende quien lo redactó no cumple su función.
La relación entre documentación y confianza
Un cliente que recibe un sistema bien documentado puede auditarlo, entenderlo, y si en algún momento decide trabajar con otro proveedor, puede hacerlo sin quedar atrapado en una dependencia que nadie acordó explícitamente.
Eso no es una amenaza para la relación comercial. Es la señal más clara de que la relación se construyó sobre valor real. Un cliente que se queda porque el trabajo fue bueno tiene más valor en el tiempo que un cliente que se queda porque no puede irse.
En TI, la dependencia forzada es uno de los indicadores más claros de que alguien no está actuando como partner. La documentación completa es una de las formas más directas de demostrar lo contrario.
Lo que esto implica en la práctica
Documentar bien toma tiempo. En proyectos con fechas ajustadas, es lo que siempre parece que puede esperar. En Aleph Server, no espera: está incluida en el plan del proyecto y en el tiempo estimado desde el principio.
Cuando un cliente nos pide recortar tiempo del proyecto, podemos discutir el alcance técnico. No discutimos la documentación. Esa conversación la hacemos antes de empezar, no después.
