Anotaciones sobre la divulgación de Drupal en el aula
En este momento mientras preparo una nueva iteración más de las slides que uso en los diferentes cursos/talleres y sesiones formativas sobre Drupal, me voy encontrando con diferentes notas que he ido dejando a lo largo de las distintas ediciones y veo que mientras algunas han perdido cualquier utilidad y no han requerido prácticamente confirmación alguna, otras asunciones y observaciones se han ido reiterando a lo largo de las iteraciones.
He decidido unificarlas en un artículo central y dejarlas recogidas de una vez por todas (siempre se queda pendiente), aprovechando el arranque del grupo de divulgación de la comunidad Drupal — (AED) donde estamos compartiendo ideas y recursos desde Dropbox-paper:
Así que allá van mis notas internas acerca de enseñar y promover Drupal en el aula. ¡Salud!
Contexto: Como mínimo una vez al año, suele ocurrir que una organización (centro formativo, Universidad, empresa consultora, etc) me solicita “ir a contar” que es Drupal (a modo de introducción) o bien que exponga mi visión acerca de como deberían enfocarse proyectos basados en Drupal por parte de un equipo de trabajo.
Los escenarios suelen estar poblados por público cualificado: bien personas interesadas por la tecnología o grupos de profesionales del desarrollo de software con los que alguna empresa quiere empezar a hacer proyectos basados en Drupal. Normalmente todo empieza con una premisa aparente sencilla y sobre-simplificada: “Queremos aprender como se hace un proyecto en Drupal”, y ahí arranca LA AVENTURA TOTAL-MIX 9.
Como decía, me debía a mi mismo recopilar las notas majaretas que había ido dejando por ahí: borradores de correo, notas en postits, hojas de cuaderno y hasta extraños SMS enviados a mi mismo para recordar tal o cual detalle. Por cohesionar un poco las experiencias y extraer algunos mensajes comunes. Ojalá que alguien les encuentre alguna utilidad.
Si quieres evitarte esta chapa, aquí en Speaker Deck está la última iteración (febrero 2018) de las slides. Son unas 125 diapositivas preparadas para 30 horas de trabajo mediante sesiones teorico-prácticas que contienen unos 22 ejercicios progresivos para conocer y practicar Drupal:
https://speakerdeck.com/davidjguru/team-building-around-drupal
Observación 1: No, no hay que dar nada por supuesto
En primer lugar he ido aprendiendo iteración tras iteración que quiere decir eso de “Gestión de las Expectativas”, pero el caso es que cada cual tiene sus propios objetivos para estar en el aula, es cierto. Pero aún hay más.
Existen tres zonas de interés que más vale saber identificar, relacionar y tejer adecuadamente para asegurar la calidad de la experiencia. Tú acudes a una convocatoria realizada por una organización (normalmente una empresa) que tiene sus propios objetivos. A partir de ahí montas los tuyos y solo en el día a día del aula descubres que en realidad, las personas que asisten tienen otros que no tienen que coincidir -necesariamente- con los fines determinados por la organización.
Triangularizar objetivos: Docente — Organización — Asistentes
Parte del trabajo inicial es identificar todo esto y hacerlo que cuadre.
Esto hace que las sesiones estén vivas y por deteminar: a pesar de haber cerrado un esqueleto, es necesario editarlo y volver a editar para adaptar los contenidos a las necesidades del grupo. Más vale tomar en consideración las necesidades de los asistentes para determinar el alcance y el enfoque.
Y al igual que en el caso de las expectativas, las necesidades y los objetivos, tampoco podemos dar por hecho nada acerca del Stack tecnológico. No, por mucho que nos resulte cotidiano y habitual, todavía quedan muchos equipos trabajando con svn en su día a día, o haciendo programación procedimental sin necesidad de construir ningún objeto. Tampoco tienen porque haber oído hablar de Software Libre, ni de las cuatro libertades, ni tener cuenta en Github o lanzar comandos por consola ni nada de esto. Y son caminos que debes integrar de alguna manera u otra en el relato principal. ¿La clave? auscultar cuanto antes el estado de estos factores dentro del grupo. Cuanto antes. ASAP.
Observación 2: Todo es más intuitivo cuando se conecta desde la experiencia directa
Sí, puede parecer una perogrullada PERO en un entorno real es más importante y más complejo de lo que parece en un principio. Y además está directamente vinculado a la consecución del “éxito” de la formación a impartir (entrecomillado, ya que habría que identificar primero que consideraríamos un éxito).
Necesitamos aproximarnos a nuevas vivencias desde las experiencias ya acumuladas por parte de los equipos.
Ejemplo 1: Si la people te está contando que en su día a día solo usa svn y para dos operaciones básicas (checkout, commit y poco más)…¿Para qué vas a contarles historias abstractas de repositorios distribuidos? ¿Para qué les vas a reventar el cerebro hablándoles de ramas, de pull-request, de push? ¿Para que se pierdan antes y sientan que el plan formativo es un pastelazo? NO-WAY.
Empieza hablando de las operaciones de checkout y commit en Git, para que vean las similitudes. Que operen con ello. Y poco a poco que se vaya abriendo el campo de la experiencia con casos más complejos.
Ejemplo 2: Si la people está acostumbrada a trabajar desarrollando con Java, ese es el vector ideal de entrada para hablar de objetos, clases, métodos y en general POO. Es la base de partida perfecta ¿Para que rodear esto e intentar entrar desde otra dirección? no tiene sentido no aprovecharlo.
Todo el relato debe estar conectado directamente a la experiencia diaria.
Investigación-Acción Participativa (IAP): Evaluar la experiencia de partida y alinear la narración con ella.
Observación 3: Los procesos son más importantes que los detalles
Porque los detalles podrán conocerlos por si mismos, investigando y filtrando; pero los procesos -en cierta manera- son más extraños y a menudo, más contra-intuitivos.
En realidad, he ido observando poco a poco, paso a paso, que mis hipótesis iniciales no eran correctas en cuanto a las necesidades más urgentes o inmediatas en cuanto al aprendizaje de Drupal: las personas -en un primer acercamiento- no desean conocer de manera explícita los detalles, ni los ejemplos, ni los métodos estáticos, ni los parches de uno y otro módulo…
La peña quiere saber:
1- Dónde está cada cosa
2- Dónde está la ayuda
3- Cómo se pide ayuda
Y cualquier otro procedimiento que les evite la lluvia de mierda que cae en cascada en la consultoría tecnológica clásica. O que les sirva para reducir la angustia existencial de ser depositados en un proyecto para el que no tienen base de conocimiento alguna con todo-para-ayer. Que hacer cuando las fechas se vayan aproximando y los jefes culpen al equipo de los retrasos y estos tengan que echar horas extra y madrugadas enteras buscando soluciones para preparar una entrega. Esto quiere saber la gente. El resto es tomar los deseos por realidades, o inferir de manera errónea que el universo laboral se rige por las mismas leyes que el de tus amigos y amigas más guays.
Y el resto de cosas adquiere carácter de valor en cuanto pueden ser relacionables con las necesidades “primarias” o demuestran tener una conexión útil a estas.
Ejemplo: Un parche de software y como aplicarlo parece tener escaso interés por si mismo de cara a la audiencia -HASTA- que se convierte en una solución rápida y efectiva para corregir el funcionamiento defectuoso de un módulo. Ahí de repente cobra todo el interés del mundo saber donde se encuentran los parches (Issues de Drupal) y como se aplican al código (git apply).
Observación 4: Pulir una metodología globalizada, integrada y progresiva
A lo que anotaba antes acerca de vincular experiencias nuevas con las ya previas del día a día (en torno a la observación #2), se suman varios arcos complementarios para depurar esto que nos piden infinitamente más: concatenar de manera progresiva las actividades y los conceptos, para ir de menos a más, con un sentido de avance parecido al del aprendizaje de las matemáticas en la escuela pública: cada pieza tiene una utilidad pero además, sirve para construir la siguiente pieza (conocimiento anidado).
Observación 5: Sensación de trayectoria, percepción de destino
Una de las cosas que más tarde he comprendido es que realmente no hay un viaje si no existe un sentido de trayectoria, es decir, si los asistentes no tienen una percepción de destino al que llegar en conjunción con una sensación de trayectoria no hay movimiento. Así de simple y así de complicado a la vez.
¿De dónde partimos? seamos honestos. Cuando arrancamos en un aula, la peña ya tiene un punto de partida. Así que mejor hacerlo explícito. Sin secretos, directos al mito, a las leyendas (que según Regis Debray son las únicas cosas serias).
La peña se ubica mejor cuando sabe (sabemos) a dónde vamos o dónde pretendemos llegar. Que no sea por no compartir información: abrir cada sesión describiendo los objetivos de esta, como se relacionan esos objetivos parciales con los globales, y en que momento exacto del mapa nos encontramos. Fundamental.
P.S- (Esto no sé exactamente dónde ubicarlo, lo dejo aquí): La terminología. La peña se lía (y con razón) si la terminología no está suficientemente anclada y clara desde el principio. Conceptos como “plugin”, “widget”, “servicio”, “clase”, “módulo” y demás, tienen otros significados -en otros contextos- que las personas intentan mantener en este y solo hace aumentar el conflicto. Anclar los términos es controlar el espacio comunicativo.
