Análisis-Diseño-Desarrollo-Implementación-Evaluación es una cantinela que todos los que diseñamos formación nos hemos aprendido en algún momento. Es un método directo y sin complejos de gestión de proyectos de e-learning, posiblemente el más extendido, pero se le pueden hacer críticas muy válidas. La mía se basa sobre todo en que es un modelo de fases en el que faltan procesos.

¿Cuál es el problema de ADDIE?

A nadie se le escapa que comprobar si estás avanzando en la dirección correcta mientras trabajas es importante. Medir resultados al final y ver qué tal lo has hecho es fundamental, pero es francamente un mal momento para descubrir que tu idea no era buena desde el principio. Incluso si haces esa evaluación al final de cada fase, como sugieren las últimas variaciones de la secuencia A-D-D-I-E, sigue habiendo un riesgo muy alto de que sea demasiado tarde para hacer todas las correcciones necesarias, no digamos ya para cambiar de enfoque. Por eso la mayoría incluimos pequeños ciclos de diseño, desarrollo y evolución dentro de cada una de las fases, probablemente incluso para cada entregable de cada fase. No es exactamente una novedad: los métodos ágiles de gestión de proyectos van por ahí. Pero en este campo por algún motivo lo hacemos escondiendo esos ciclos dentro de ADDIE y sin documentarlo, como si romper la ortodoxia del modelo no mereciera figurar en nuestros informes. Puede que me equivoque generalizando, pero creo que casi nadie aplica ADDIE en su forma más pura, sino que proliferan los apaños caseros.

El título de esta entrada no es, por tanto, exacto: nunca he aplicado ADDIE tal cual, así que no puedo abandonarlo. En algún proyecto de largo recorrido ni siquiera he estado cerca, y he trabajado con un modelo ad hoc, pero ese es un lujo viable únicamente cuando tienes muchos meses para pulirlo.

El modelo de aproximaciones sucesivas (SAM).

Una metodología fiable permite empezar con paso firme, sabiendo que no te vas a dejar nada por el camino. Y buscando algo que no fuera un nuevo parche dí con SAM, desarrollado por Michael Allen. Allen es un habitual en los círculos de debate del e-learning y la formación corporativa, y tiene un discurso sensato, así que parecía una buena apuesta. Lo es en términos generales, porque pone negro sobre blanco lo que describía al principio de la entrada: cómo incluir pequeños ciclos de trabajo en las distintas etapas de un proyecto, para generar y validar entregables que permitan ver si vas por buen camino o no. Allen se pasa medio libro diciendo que su modelo no es un ADDIE con iteraciones, pero la verdad es que no me ha convencido de ello, y creo que los paralelismos son fáciles de encontrar:

Tampoco es raro, porque las fases de ADDIE son tan obvias, quizá tan naturales, que no creo que haya que romperlas necesariamente: simplemente hacía falta que alguien describiera lo que todos hacemos.

No llego tan lejos como el autor, achacando a un mal modelo de gestión el origen de los males de la formación corporativa. De hecho creo que la mayor parte de la responsabilidad cae sobre el diseño didáctico. Pero sí le doy la razón en que una mala gestión de los riesgos y poca flexibilidad, especialmente en la producción, tienden a generar resultados muy poco adaptados a las necesidades de los alumnos. Me gusta especialmente el énfasis que pone en la exploración de diseños alternativos, y en el análisis de necesidades continuado (que obviamente van de la mano).

Las bases de una buena gestión.

Allen considera que hay cuatro criterios fundamentales en los que debe basarse cualquier proceso de gestión de proyectos:

1. Debe ser iterativo, para hacer las correcciones que toquen cuando suponen menos coste
2. Debe facilitar la colaboración, no tanto para mejorar el resultado final sino para acortar los tiempos.
3. Debe ser eficiente y efectivo (menuda sorpresa), lo que implica tanto evitar el perfeccionismo como detectar cuándo vale la pena invertir un esfuerzo extra para mejorar el resultado final.
4. Debe ser manejable, en el sentido de que deje claro quién hace cada cosa y permita predecir el impacto de los cambios hechos sobre la marcha.

Son criterios de sentido común y bastante amplios; posiblemente, sobre el papel, cualquier modelo de gestión cumple con ellos. Sin embargo, me parece interesante cómo SAM logra convertirlo en acciones concretas con sencillez. Como estos objetivos no dependen de las mismas variables en proyectos grandes y pequeños, SAM tiene dos variantes: un nivel uno (SAM1) apropiado para proyectos o equipos pequeños y sin demasiadas complicaciones tecnológicas, y un nivel dos (SAM2) para los que tienen más miga.

En una próxima entrada repasaré SAM1, que está ya en mi vida en plan no-sé-cómo-no-lo-he-hecho-así-siempre-porque-es-de-cajón. SAM2 son palabras mayores y no he tenido ocasión para probarlo en condiciones, así que dejaré su revisión para más adelante.