Lecciones aprendidas: qué son, cómo documentarlas y plantilla

Al cerrar un proyecto, el equipo se reúne, llena una pared de notas adhesivas y coincide: la próxima vez hablaremos antes con informática. Seis meses después empieza el siguiente proyecto y nadie recuerda la nota. Esta guía explica el concepto, muestra cinco pasos para que de verdad se usen y le da preguntas y una plantilla para copiar.

¿Qué son las lecciones aprendidas?

Lecciones aprendidas es la traducción habitual del inglés lessons learned: experiencias extraídas de actividades pasadas que deben tenerse en cuenta en acciones futuras. El Project Management Institute las define como el conocimiento adquirido durante un proyecto que muestra cómo se abordaron o deberían abordarse sus eventos en el futuro, con el fin de mejorar el desempeño.

Las agencias espaciales NASA, ESA y JAXA usan una definición más exigente: una lección aprendida es conocimiento o comprensión obtenidos por la experiencia, tanto de un éxito como de un fracaso. Para contar, debe cumplir tres condiciones:

• Significativa: tiene un impacto real o previsible en el trabajo.
• Válida: es correcta en los hechos y en lo técnico.
• Aplicable: señala un diseño, un proceso o una decisión concretos que reducen el riesgo de fallar o refuerzan un buen resultado.

Estas tres pruebas ayudan después al analizar lo recopilado. Y marcan la diferencia con la documentación del proyecto: la documentación describe lo que pasó, la lección aprendida dice qué hará distinto la próxima vez. Por eso es uno de los métodos más sencillos de la gestión del conocimiento: va ligado a una fecha que ya existe, el cierre del proyecto.

Lecciones aprendidas, retrospectiva, revisión después de la acción y post mortem

Muchos equipos las hacen con otro nombre. Cambian el momento y el objetivo.

Retrospectiva: la Guía Scrum la describe como el evento que cierra cada sprint. El equipo revisa cómo fue el sprint en cuanto a personas, interacciones, procesos y herramientas, qué salió bien, qué problemas encontró y cómo se resolvieron o no. En un sprint de un mes dura como máximo tres horas, y las mejoras de mayor impacto se abordan lo antes posible.

Revisión después de la acción: la desarrolló el Ejército de Estados Unidos y parte de comparar el resultado previsto con el real. Buscar culpables contradice su propósito; cada participante mira su propia actuación.

Post mortem: busca las causas de un fracaso o de una caída, mientras que la retrospectiva repasa lo positivo y lo negativo.

La diferencia clave: la retrospectiva mejora el trabajo del mismo equipo en el siguiente sprint. Las lecciones aprendidas deben servir también a personas que no participaron en el proyecto. Por eso es tan importante escribirlas y guardarlas.

Cuándo recoger las lecciones aprendidas

• Al cierre del proyecto: el momento clásico, a menudo dentro del informe final.
• Después de fases e hitos: en proyectos largos. Asana recomienda enviar la encuesta justo al terminar el proyecto o al final de una fase importante, mientras el recuerdo está fresco.
• Al empezar un proyecto nuevo: aquí las lecciones se usan, no se recogen. Incluya en cada arranque la lectura de las lecciones de proyectos parecidos.
• Antes de que una persona clave deje el proyecto: el momento que más se olvida. Quien se va a mitad del proyecto se lleva su visión, y en la reunión de cierre falta.

Cómo documentar las lecciones aprendidas en 5 pasos

Los pasos siguen el ciclo que también describe Asana: identificación, documentación, análisis, almacenamiento y recuperación.

1. Recopilar experiencias

Funciona bien combinar una encuesta breve con una reunión. Asana aconseja que no la modere el gerente del proyecto, para que todos hablen con libertad. Para planificarla, la guía de Atlassian sobre retrospectivas da una referencia útil: unos 15 minutos de preparación, 60 minutos de reunión y de 4 a 8 personas.

2. Redactarlas de forma concreta

«Mejorar la comunicación» no es una lección, es un deseo. Una lección útil describe la situación, qué pasó, por qué y qué será distinto la próxima vez. Por ejemplo: «En proyectos con software nuevo, involucrar a informática en la primera semana, porque si no la aprobación de accesos retrasa el arranque». Anote también lo que salió bien: según la definición de NASA, ESA y JAXA, los éxitos cuentan tanto como los fallos.

3. Analizar y condensar

Una los puntos repetidos y pase cada uno por las tres pruebas: ¿significativa, válida, aplicable? Atlassian aconseja no centrarse en errores o aciertos puntuales que no afectarán al trabajo futuro. Pocas lecciones que cambien algo son el objetivo.

4. Guardarlas donde otros buscan

Una lección en una carpeta personal se pierde para el siguiente equipo. Guarde las lecciones aprendidas en un lugar fijo, como una base de datos de proyectos o una unidad compartida, y etiquételas por tipo de proyecto, tema y área.

5. Aplicarlas en el siguiente proyecto

Es el paso que más se salta. Cada lección necesita un responsable y un lugar donde cambie algo: una lista de verificación, una plantilla de proyecto, el manual de procedimientos o la documentación de procesos.

Preguntas para la reunión de lecciones aprendidas

El núcleo son tres preguntas que también propone Asana: ¿qué salió bien?, ¿qué salió mal? y ¿qué se puede mejorar? Una variante de las retrospectivas es el método 4L, que Atlassian llama en español AAOE: qué le encantó al equipo, qué odió, qué aprendió y qué anheló. Para un proyecto completo conviene ir más allá:

• ¿Alcanzamos el objetivo? ¿Dónde se aparta el resultado del plan y por qué?
• ¿Qué decisión tomaríamos hoy de otra manera?
• ¿Qué conocimiento tenía una sola persona y dónde está escrito ahora?
• ¿Qué debería saber primero el próximo equipo?
• ¿Qué pasamos a plantillas, listas o procesos, y quién se encarga?

Plantilla de lecciones aprendidas

Copie la tabla en su documento u hoja de cálculo. Encima, anote nombre del proyecto, periodo, participantes, fecha y moderación. Las dos filas son ejemplos inventados que muestran lo concreta que debe ser cada entrada.

La última columna es la más importante. Si queda vacía, la lección está escrita, pero todavía no aprendida.

Errores frecuentes

• Buscar culpables: en cuanto aparece la culpa, la gente dice solo lo imprescindible. En la revisión después de la acción, culpar contradice expresamente su propósito.
• Quedarse en lo general: «planificar mejor» no cambia nada. Cada lección necesita una recomendación concreta.
• Guardar sin aplicar: sin el paso 5, el archivo es un cementerio de buenas intenciones.
• Faltan las personas clave: quien dejó el proyecto antes no está en la sala, y con ella falta la experiencia de las fases más difíciles.

Cuando la experiencia se va con la persona

Las lecciones aprendidas recogen lo que un equipo aprendió en conjunto. No recogen cómo hace su trabajo una persona concreta: el truco del cierre de facturación, qué proveedor responde por qué canal, qué excepciones hay. Ese saber suele ser conocimiento tácito y rara vez sale solo en una reunión.

Cuando una persona clave deja la empresa, una reunión de lecciones aprendidas no basta. Hace falta una transferencia de conocimiento ordenada y un acta de entrega de cargo para quien la sustituya. Si alguien se va a mitad del proyecto, añada antes de su último día una conversación breve a solas: ¿qué le aconsejaría a quien le sucede en el proyecto?, ¿qué decisiones quedan abiertas?, ¿a quién hay que conocer? Es distinto de la entrevista de salida, que trata de los motivos de la marcha.

Conclusión

Las lecciones aprendidas se recogen rápido y se olvidan igual de rápido. Para que funcionen necesitan una redacción concreta, un lugar fijo y, sobre todo, el paso 5: alguien que lleve cada lección allí donde ocurre el trabajo. Programe la reunión mientras todos siguen en el equipo, pregunte por lo bueno y lo malo, y no olvide a quienes dejaron el proyecto antes.