Lecciones aprendidas que se consultan, no que se archivan

01 El punto de partida

Las lecciones existían. Encontrarlas era el problema.

Cada proyecto dejaba su registro de lecciones aprendidas en una planilla propia. El contenido era bueno —análisis técnicos serios, escritos por gente que había estado en la obra— pero vivía en archivos sueltos, con criterios distintos en cada uno.

Al revisarlas aparecía siempre lo mismo: el mismo sector escrito de tres formas, fases del ciclo de vida con el nombre tipeado a mano, acciones sin identificador, columnas que cambiaban de lugar entre planilla y planilla. Nada de eso es negligencia: es lo que pasa inevitablemente cuando el vocabulario no está definido en ningún lado.

La consecuencia práctica es que el conocimiento no se podía consultar. Para saber qué había pasado antes con permisos ambientales en una estación de bombeo había que acordarse de en qué proyecto fue y abrir la planilla correcta.

03 La decisión que sostiene todo

Vocabulario cerrado donde importa, libre donde no

El trabajo técnico que más rinde en una implementación así no se ve en la pantalla: es decidir qué campos llevan una lista de valores y cuáles no.

Sector, proyecto, fase, origen y estado quedaron con vocabulario controlado. Son los ejes por los que alguien va a querer filtrar o agrupar, y sin una lista cerrada cada variante de escritura parte el conjunto en pedazos. El tema y la descripción quedaron libres, porque ahí forzar un vocabulario sería pelearse con quien escribe.

Las listas viven en el administrador de modelos de Alfresco, no en el código. Agregar un sector nuevo es editar el modelo desde la consola: no hace falta tocar la aplicación ni volver a desplegar nada.

El importador valida contra esas mismas listas. Si una planilla trae un valor que no existe, la fila se rechaza con el campo y el valor señalados. Es más molesto al cargar y es exactamente lo que evita que el repositorio se vuelva, otra vez, un conjunto de archivos sueltos.