> For the complete documentation index, see [llms.txt](https://urd.gitbook.io/compass/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://urd.gitbook.io/compass/home/espanol/aprendizaje-y-adaptacion/aprender-de-la-experiencia-y-compartir-conocimientos/procesos-estructurados-de-aprendizaje-de-lecciones.md).

# Procesos estructurados de aprendizaje de lecciones

### <mark style="color:naranja;">Cuando una experiencia merece más que una sesión de cierre</mark>

Un **proceso estructurado de aprendizaje de lecciones** es lo que conviene usar cuando una revisión posterior a la acción no es suficiente. La experiencia abarca varios equipos o fases, involucra a partes interesadas más allá del equipo del proyecto, o se considera lo bastante importante como para que dedicar tiempo a convertirla en un conocimiento real y transferible valga la pena.

A diferencia de la revisión inmediata, no ocurre espontáneamente. Se **debe planificar**: alguien decide hacerlo, define para qué sirve y lo lleva hasta que quede algo escrito y compartido.

***

### <mark style="color:naranja;">**Los cuatro pasos**</mark>

<details>

<summary><strong>1. Delimitación</strong></summary>

¿De qué experiencia, exactamente, van a extraer lecciones? ¿Qué pregunta se supone que debe responder? ¿Para quién es (es decir, para el propio equipo, la organización en general, los socios, el sector)? Omitir este paso es, con diferencia, la razón más común por la que estos procesos se desvían y nunca llegan a terminarse.

</details>

<details>

<summary><strong>2. Recopilación</strong></summary>

Entrevistas individuales o grupales, talleres de restitución con los equipos implicados y, cuando sea posible, con las comunidades concernidas, además de una revisión de la documentación existente (es decir, datos de seguimiento, notas de AAR ya elaboradas, informes).

</details>

<details>

<summary><strong>3. Análisis</strong></summary>

Separe lo que es específico de este contexto de lo que podría aplicarse en otro lugar. Identifique qué funcionó y qué no, sin suavizar los fracasos. Un proceso que solo se centra en los éxitos probablemente pasa por alto elementos importantes de aprendizaje.

</details>

<details>

<summary><strong>4. Formalización y restitución</strong></summary>

Produzca un resultado breve y utilizable (véase [Documentación y difusión: formatos, divulgación y salvaguardias](/compass/home/espanol/aprendizaje-y-adaptacion/aprender-de-la-experiencia-y-compartir-conocimientos/documentacion-y-difusion-formatos-divulgacion-y-salvaguardias.md)), y compártalo de nuevo con las personas que contribuyeron antes de difundirlo más ampliamente.

</details>

> Omitir el paso de delimitación para pasar directamente a recopilar información es la razón más común por la que estos procesos se atascan. Sin una pregunta y un público claros, el ejercicio se expande indefinidamente y nunca llega al paso 4.

***

### <mark style="color:naranja;">**Realización de un taller de aprendizaje**</mark>

**Dos versiones, según el tiempo y los recursos disponibles.**

| Versión ligera                                             | Versión completa                                                                         |
| ---------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Un taller de medio día con el equipo del proyecto          | Varias sesiones repartidas a lo largo de unas semanas                                    |
| Facilitado internamente                                    | Facilitación externa o dedicada, especialmente para temas sensibles                      |
| El resultado podría ser una ficha informativa de 2 páginas | El resultado podría ser un estudio de caso, una nota orientativa o material de formación |
| Compartido internamente                                    | Compartido interna y externamente (socios, plataformas de coordinación)                  |

Empiece por defecto con la versión ligera. Pase a la versión completa solo cuando la fase de delimitación haya confirmado que la experiencia realmente lo merece, no porque un proceso más grande parezca más legítimo.

{% file src="/files/33335e549fc10480275fc06c7126981b954d169b" %}

***

### <mark style="color:naranja;">**En qué se diferencia de una evaluación**</mark>

Un proceso estructurado de aprendizaje de lecciones no necesita ser dirigido por alguien externo, y **no juzga el desempeño con respecto a criterios predefinidos** (como los criterios del CAD de la OCDE usados en las evaluaciones). Parte de la **experiencia vivida del equipo** y pregunta qué significado puede extraerse de ella, de forma descriptiva y reflexiva más que valorativa. Sin embargo, puede apoyarse en los datos y hallazgos de una evaluación existente como uno de sus insumos.

***

### <mark style="color:naranja;">**Puntos clave**</mark>

* Reserve este método para experiencias a las que una AAR no hace justicia, no como el ejercicio estándar de fin de proyecto.
* Delimite antes de recopilar: sin una pregunta y un público claros, el proceso se desvía.
* Opte por defecto por la versión ligera; amplíe solo cuando la delimitación confirme que está justificado.
* Documente los fracasos con la misma honestidad que los éxitos; ahí reside gran parte del valor transferible.
* Complementa la evaluación; no la sustituye.