Conocí a Charles en mayo de 2013. Se integró al equipo de consultores de learning(capacitación y desarrollo) del que yo era parte en aquellos días, para hacerse cargo de un proyecto nuevo con un cliente trasnacional de la industria del retail, el cual quería desarrollar una experiencia de aprendizaje presencial que ayudara a generar mayor engagement entre sus miembros.
Durante algunos meses analizamos información, diseñamos la solución y desarrollamos las herramientas para la experiencia de aprendizaje. Finalmente, en agosto todo estaba listo (según Charles) para la implementación del material. Y es aquí cuando las lecciones aparecieron.
Como parte de la metodología de trabajo que teníamos (ADDPIE), antes de la implementación corríamos lo que se conoce como un piloto o proof of concept (la P en ADDPIE). Esto no es otra cosa que poner a prueba el curso antes de implementarlo.
La metodología ADDIE. De hecho, nosotros le agregamos la P (ADDPIE) de Piloto.
El piloto no es una simulación, porque se hace todo tal y como se haría en la fase de implementación. Es decir, en este caso por ser presencial se reservaron salones o espacios, se imprimieron y manufacturaron los materiales, los facilitadores se prepararon de manera previa para la sesión y se invitó a la audiencia potencial.
La idea es que dependiendo de cómo resulte el piloto, se llevarán a cabo las modificaciones necesarias para mejorar el material para la implementación.
El piloto de la experiencia de aprendizaje de Charles ocupó dos días: dos mañanas y una tarde. Como Líder de Proyecto, lo acompañé a la sesión. El resultado: catastrófico. Eso dijo Charles, así lo sintió (para mí, era lo esperado; una “catástrofe” calculada).
El piloto sacó a la luz varios detalles que debían corregirse, tanto técnicos como de fondo y forma. Al finalizar el segundo día, Charles terminó abrumado, lleno de dudas, algunas preocupaciones y un poco desanimado debido a lo que él consideraba eran “errores” graves.
Lo que él no sabía en ese momento, es que lo que le sucedió era, de algún modo, lo mejor que podía pasarle a él y al cliente. Al final, la función del piloto es la misma que tienen las fases de prototyping y testing en metodologías muy populares hoy, como el Design Thinking (DT) o el Design Sprint (DS): localizar aquello que puede (debe) mejorarse, saber las sensaciones del usuario final, detectar necesidades ocultas (hidden needs) y así entregar un producto final probado (nosotros no trabajábamos con ninguna de estas metodologías).
Si te interesa indagar más en el Design Thinking, este libro es básico.
En el DT y el DS, el Prototyping y el Testing son la última barrera de contención antes de lanzar un producto o servicio final. El PILOTO en el ADDPIE, tiene la misma lógica y su función es entregar “algo” probado. Por supuesto, todo es perfectible, pero con esta etapa se reduce al mínimo el riesgo en la implementación. De hecho, tanto el DT como el DS proponen que tanto el Prototyping como el testing se lleven a cabo de manera periódica y sistemática entre fase y fase del desarrollo de un proyecto. Dicho de otro modo, llevan a cabo pequeños pilotos una y otra vez. El objetivo es detectar de manera continua detalles y mejoras (pero profundizar en esas metodologías es cosa de otra nota).
Una vez que le explicamos esto a Charles (y luego de levantarle el ánimo), se enfocó en sus notas, en las mías, en las del cliente y se dedicó a mejorar lo mejorable. El producto final se entregó y al cabo de un par de meses nos llegó un email del cliente comunicándonos su satisfacción con nuestro trabajo y que el curso se había implementado ya en varios países con gran éxito. Happy ending
Charles y yo dejamos de ser parte de ese equipo de consultores (extraordinario equipo, por cierto) hace un tiempo ya. Sin embargo, puedo decir que el piloto se convirtió no sólo en una etapa en una metodología de trabajo, sino en una parte esencial en nuestra cultura de trabajo.
Hoy en día, en cada proyecto personal y profesional trato de incluir una fase de piloto, prototyping y testing, de alguna manera u otra. Cada día es (o debería) ser más común esta práctica. Sin embargo, me he dado cuenta que muchas veces pasamos del diseño y desarrollo de una solución, directo a la implementación y es en ese momento que salen a relucir detalles que deberían haberse detectado antes (justamente en el piloto) y que resultan ser costosos en muchos sentidos, entre otros:
- Tiempo. Corregir sobre la marcha, demanda tiempo extra por parte del cliente y el proveedor del servicio.
- Dinero. Se ponen recursos monetarios en forma de hrs de trabajo extra por parte de ambos lados.
- Relación con el cliente o socio de trabajo. La falta de una prueba previa al lanzamiento, puede afectar la relación debido a que no se comprueba la efectividad o eficiencia del producto o servicio entregado.
- Estrés. Mucho.
La gran lección que se llevó Charles fue que el piloto es una fase seria, pero también una fase amiga. Es la etapa o el paso donde todo puede salir mal, pero que bien calculado permitirá que cuando se entregue el trabajo y se implemente, todo salga bien.
No importa que metodología sigas, integra una fase de prueba, un piloto, prototipo y testing, antes de implementar o lanzar una solución de learning, capacitación, desarrollo o educación continua.
Que todo salga mal en esa etapa, podría ser lo mejor que te podría pasar para que todo salga bien después.
Algunas cosas que yo hago cuando llevo a cabo un piloto para aprovechar al máximo la sesión, son:
Antes de la sesión
- Calendarizar desde el inicio del proyecto una fase de piloto
- Entregar los materiales “finales” versión prototipo de antemano al cliente (pon atención al fondo, no a la forma)
- Tener una sesión de pre-piloto con el equipo de facilitadores del curso
- Invitar a la sesión a gente que potencialmente podrían ser los receptores del curso
Durante la sesión
- Tomar en serio esa sesión (cómo si fuera la implementación final)
- Invitar a un colega del equipo para tener una opinión fresca
- Invita a tu equipo de diseño multimedia (gráfico, programador, editorial)
- Tomar notas (muchas)
- Grabar la sesión
- Encuesta a los asistentes
Después
- Ten una sesión postpiloto con el cliente
- Genera un checklist (o to improve list) de los detalles a corregir
Este breve checklist me ayuda a obtener del piloto la mayor información posible.
Por supuesto, la idea es que el trabajo realizado no tenga muchas fallas, pero si existe alguna, el piloto te ayudará a corregirla.
Integra esta etapa en tus procesos de desarrollo de soluciones y experiencias de learning o en tus estrategias, seguramente te ahorraras muchos costos innecesarios y tendrás un producto exitoso.
Si te interesa indagar más en metodologías que ya integran este tipo de pasos, lee este artículo sobre Design Thinking, este sobre Sprint Design, este sobre ADDIE y este sobre SAM.
Comparte tus experiencias y comparte esta nota a quien pienses que le puede resultar útil. Siempre hay alguien que la puede encontrar útil.
PS: esta nota es precisamente un piloto, pues es el primer artículo que escribo para Dare To Learn en español. Toda opinión es bienvenida.
Actualmente me desempeño como Learning Advisor. Tras más de 7 años en el mundo del learning, hoy en día soy trainer certificado y consultor en Design Thinking.
Si te interesa conversar o profundizar más en algún tema, no dudes en contactarme. Siempre estoy disponible para una charla o un café.
Twitter: @diegolainez
