Las listas de verificación son una herramienta práctica para implementar las lecciones aprendidas, garantizando que los conocimientos clave y las mejores prácticas se apliquen de forma coherente en actividades futuras.
Al crear un nuevo elemento en KF (como un proyecto, una tarea o un producto) y especificar "esto se basa en" otro elemento (su tipo), KF crea automáticamente una lista de verificación. Esta lista le ayuda a asegurarse de no olvidar ningún paso importante ni aprendizaje previo.
Entre otras cosas, trae del tipo:
Es como si KF dijera:
"Oye, la última vez que hiciste algo así, esto es lo que tenías que hacer, lo que tenías que entregar y lo que salió mal; quizás deberías revisar esto de nuevo".
La lista de verificación de un elemento es una tabla de dos columnas.
| Columna izquierda | el elemento y sus componentes — reales y posibles, de forma recursiva |
| Columna derecha | para cada entrada de la izquierda, sus tareas — reales y posibles |
Real significa presente en la estructura del propio elemento. Posible significa declarado por uno de sus tipos, en cualquier nivel de la jerarquía de tipos, y no presente en el elemento.
Todo aparece listado, esté presente o no. Una lista de verificación es la declaración completa de lo que un elemento es y de lo que debe — no una lista de puntos abiertos. Por eso cada entrada de la izquierda tiene su fila aunque no deba nada: una celda derecha vacía es la respuesta "este componente no tiene comprobaciones", que es información, no un motivo para ocultar el componente.
Una tarea es todo aquello a lo que el elemento está obligado: una acción a realizar, o un objeto o un documento a producir. Lo que la convierte en tarea es el vínculo, no el tipo de elemento que sea. Las tareas llegan a un elemento de dos maneras — directamente, o a través de un evento (un fallo, una incidencia o un riesgo). Ambas cuentan igual; el evento es la procedencia, indica por qué se debe ese trabajo. Una lección aprendida es exactamente eso: una tarea que proviene de un evento.
Tomemos una bicicleta cuyo cuadro es de un tipo que exige una inspección de pintura, y cuyos frenos deben una tarea registrada tras un fallo en campo:
| Elemento | Tareas |
|---|---|
| Bicicleta Modelo A | Expediente de homologación [pending] 2/3 |
| Cuadro | Inspección de pintura [missing] ← Tipo cuadro |
| Frenos | Reapretar los tornillos de la pinza [done] ← Pérdida de frenada |
| Ruedas y neumáticos | |
| Batería (faltante) ← Tipo bicicleta | Informe de cualificación de celdas [missing] |
Cada componente es una fila — incluido el que no debe nada (Ruedas y neumáticos) y el que la bicicleta ni siquiera tiene todavía (Batería, exigida por su tipo: tanto ella como todo lo que debe están faltantes). La inspección de pintura es posible, no real. El reapriete es real y llegó a través de un evento, que se muestra como su procedencia.
Esta asimetría es lo que impide que las dos columnas se confundan entre sí.
La columna izquierda es descomposición: un elemento se divide en sus componentes, y cada uno de ellos en los suyos, tan profundo como llegue la estructura. La columna derecha no. Una tarea es una sola celda. Nunca se abre en sus subtareas, y si tiene un desglose propio — una acción con los pasos o las herramientas que necesita — ese desglose no sube a la columna izquierda. De lo contrario, una llave dinamométrica acabaría junto a componentes reales, como si la bicicleta estuviera hecha de ella.
No se pierde nada, porque una tarea es a su vez un elemento, y todo elemento tiene su lista de verificación. El desglose de una tarea está a un clic: abre la tarea y lee su lista. A la profundidad se llega navegando, no aplanando.
Una tarea que nunca se divide podría esconder una cantidad arbitraria de trabajo tras una línea inocua. Una cláusula ISO listada como una sola fila puede descomponerse en cuatro obligaciones concretas, y quien la lea no tendría motivo para hacer clic.
Por eso cada celda lleva un recuento acumulado de todo lo que hay debajo: Parte 10
(Mejora) [missing] 0/4. El número de la celda es exactamente lo que informa la página que
hay detrás de ella. Una tarea pendiente cuyo subárbol está enteramente realizado o no
aplicable cuenta como realizada — aunque un juicio explícito siempre prevalece: una tarea
marcada como realizada con 1/2 debajo sigue diciendo done y sigue mostrando el
recuento, poniendo la contradicción en la página en lugar de ocultarla.
Cada tarea tiene uno de cinco estados:
El not applicable de un tipo se hereda literalmente: si un tipo declara una tarea y la marca como no aplicable, sus instancias no la deben — muestran not applicable, no missing. Basta marcarlo una vez en el tipo y queda resuelto para todas las instancias, presentes y futuras.
El resolved de un tipo se hereda igual, y es la otra mitad de esa idea. Resolved significa que el tipo ha cumplido la obligación él mismo, para todas sus instancias a la vez — una homologación obtenida una sola vez para toda la línea de producto, un análisis realizado de forma centralizada. Una instancia que no tiene la tarea muestra resolved, no missing: el trabajo existe, simplemente no le toca repetirlo.
El done de un tipo no se hereda, y ahí está la diferencia: done dice que el trabajo se
terminó para ese ítem y no dice nada de nadie más, mientras que resolved dice «terminado,
y cuenta también para mis instancias». En todo lo demás se comportan igual — resolved
cierra su celda y cuenta como realizada. La excepción se aplica nodo a nodo: una tarea
resolved cuya subtarea sigue pendiente llega como resolved con 0/1 debajo, porque el
tipo respondió por lo que respondió.
Los componentes se cuentan de forma distinta a las tareas, por presencia y no por avance: un componente que el elemento tiene está realizado, y uno que su tipo declara y él no tiene está faltante. Un componente nunca está pendiente — "tenemos una batería" no es media respuesta.
La lista de conformidad es la misma tabla restringida a un único tipo: solo lo que ese tipo aporta y el elemento todavía no tiene.
Responde a "¿cumple este elemento con esa norma?", mientras que la lista de verificación normal responde a "¿qué debe este elemento, sumando todos sus tipos a la vez?"
Todo lo anterior propaga las lecciones hacia abajo, del tipo a sus elementos. Eso solo funciona con las lecciones que ya están en un tipo. Volvamos a la bicicleta: la tarea de reapriete en los frenos del Modelo A proviene de un fallo real en campo, y está únicamente en el Modelo A. Los frenos del Modelo B nunca sabrán de ella. Ninguna lista de verificación la mencionará jamás. Una lección que se queda en un solo elemento es una lección perdida.
La lista de verificación invertida recorre la misma relación en sentido contrario:
| Sentido | Pregunta | |
|---|---|---|
| Lista de verificación | tipo → elemento | ¿Tiene este elemento lo que sus tipos exigen? |
| Lista invertida | elemento → tipo | ¿Está lo que este elemento tiene reflejado en sus tipos? |
Para cada tarea del elemento la respuesta es sí o no:
No hay una tercera respuesta — en particular, no existe la lección generalizada al tipo equivocado. Nada en KF ordena los tipos de un elemento entre sí.
Las celdas se comportan igual que en cualquier lista: una tarea es una sola celda, nunca se divide, y por eso lleva el recuento acumulado de todo lo que hay debajo. Cuando una tarea no está generalizada, tampoco lo está nada de lo que hay debajo de ella.
Sobre un elemento — puede responder cualquier tipo del elemento. La pregunta es "¿está recogido en algún sitio lo que este proyecto ha aprendido?" Es la vista que se usa mientras el trabajo está vivo y las lecciones aún se están aprendiendo.
Sobre un tipo — lista las tareas de todos los elementos de ese tipo, y solo puede responder la jerarquía de ese tipo: lo que él declara, lo que hereda de sus propios tipos y lo que declaran sus componentes. La pregunta es la de los hermanos: los frenos del Modelo A han aprendido algo, ¿lo reciben los frenos del Modelo B, que son del mismo tipo? Solo si la lección llegó al tipo compartido, porque es todo lo que ambas bicicletas tienen en común.
Así, una lección generalizada a algún otro tipo que el Modelo A tenga es real, y la vista del elemento se lo reconoce — pero no llega al Modelo B, y la vista del tipo la señala como la carencia que es. Es el reflejo de la lista de conformidad: ambas se restringen al único tipo por el que se pregunta.
Algunas lecciones son realmente irrepetibles — un proveedor concreto, una situación que no volverá a darse. Hay una forma limpia de resolverlo: generalizarla igualmente al tipo que corresponda y marcarla allí como not applicable. La carencia queda cerrada para todos los elementos a la vez, porque el not applicable de un tipo se hereda literalmente. El juicio queda documentado y la lección sigue visible en el historial del tipo sin imponer trabajo a nadie.
Marcarla como resolved cuando la lección sí se aplica a todas las instancias pero el trabajo que la resuelve se hace una sola vez en el tipo, en lugar de repetirlo en cada una: las instancias heredan esa respuesta en lugar de una carencia. Los dos estados no son intercambiables — not applicable dice que nadie la debe, resolved dice que se debe y ya está cumplida — de modo que una auditoría puede distinguir un requisito exceptuado de uno satisfecho de forma centralizada.
Una pregunta recurrente en las auditorías de ASPICE e ISO 9001 es "¿cómo aseguran que todas las lecciones aprendidas quedan cubiertas por el proceso de diseño?" La respuesta habitual es un registro, una revisión, un procedimiento — mecanismos que dependen de que alguien se acuerde de consultarlos.
Las dos listas responden desde la propia estructura. La lista de verificación muestra que las lecciones conocidas se están aplicando al trabajo actual; sus carencias son acciones a realizar. La lista invertida muestra que lo que el trabajo actual está aprendiendo vuelve al sistema de tipos; sus carencias son lecciones que hay que promover a un tipo, o marcar como no aplicables. Juntas cierran el ciclo — de los tipos a los elementos, y de vuelta de los elementos a los tipos.