Programar o no programar, ésa es la cuestión.

Realmente, el título tiene un poco de trampa. Programar sí o sí, claro, es necesario, y obligatorio, con lo que no hay mucha más opción. 

Pongamos las cartas boca arriba: programar es un rollo. Así, como suena. El rollo supremo. Pero es una herramienta necesaria, así que hay que hacerlo, me guste o no me guste (que no me gusta, no sé si lo había dejado suficientemente claro).

Así que mentalizaos, hoy voy a quejarme, ya os lo advierto. Podéis abandonar ahora, no os lo tendré en cuenta. Yo también me iría.

Cuando digo que la programación didáctica de un módulo es una herramienta necesaria, me refiero a que es obvio que necesitamos planificar lo que vamos a hacer durante el curso, y necesitamos distribuir los contenidos en el tiempo. Y ya si nos lo curramos y vamos incluyendo las actividades que podemos desarrollar en las diferentes unidades didácticas, la verdad es que nos ayuda mucho para los cursos siguientes, si repetimos módulo. Y reseñar la bibliografía y los recursos lo mismo, sobre todo ahora que la mayoría de ellos los encontramos por medio de la red. Hasta ahí de acuerdo.

Otra parte que hay que tener en cuenta es la protección de los derechos de los alumnos. Para que puedan ejercer su derecho a reclamar calificaciones, la forma en que los evaluamos debe estar muy bien explicadita. Y eso también lo hacemos en la programación, incluyendo con qué herramientas les vamos a evaluar, y cómo vamos a reflejar, calcular y obtener sus calificaciones. El alumno puede reclamar tanto si las pruebas no se ajustan a los contenidos de la programación, como si las calificaciones se han obtenido de forma diferente a como hemos dicho que se haría, lo que tiene su lógica. Hasta ahí, también de acuerdo.

La cuestión es cómo programamos, y por qué programamos como programamos. Ésa es la cuestión.

Si la programación se limitase a lo necesario (contenidos, temporalización, metodología y evaluación), yo le veo la lógica.

Pero cuando empezamos a convertir la programación en un documento eterno, que en gran parte es un corta y pega de la normativa, un galimatías de nomenclatura, y un corsé rígido a la hora de trabajar con ella, pues ya empiezo a no verle la lógica por ninguna parte. 

Y yo necesito verle la lógica a las cosas, qué le vamos a hacer. Si no, no estoy convencida.

Para empezar, entre objetivos, criterios de realización, unidades de competencia, etc., para cuando he terminado una programación es muy posible que haya cortado y pegado casi un tercio de la norma. ¿Y para qué, si ya está en la norma?

Por otro lado, por favor, si hay alguien que se aclare con el párrafo anterior, que venga y que me lo explique. Tenemos objetivos del ciclo, del módulo, capacidades terminales, unidades de competencia, criterios de realización, de evaluación... ¿en serio? ¿en serio es necesario hablar un lenguaje que necesita ser explicado para que alguien lo entienda? Además añadidle que cada x tiempo nos cambian la terminología, no vaya a ser que nos aburramos o sonemos anticuados. Me vais a perdonar, pero lo que sonamos es pedantes.
Al final, pones el titulito de turno, aunque no consigas ver la diferencia, y a la marcha. Al menos yo hago eso. Y no me da ninguna vergüenza admitirlo.

Y hay quien te mira raro cuando dices eso, ¿eh? Gente muy puesta en la terminología de turno, a la que le parece increíble que no distingas una capacidad terminal (que se las traía, el nombrecito, muy alegre no suena) de un criterio de realización. Por poner un ejemplo. El caso es que a mí me da igual. O mejor dicho, me da igual cómo le llamemos, mientras sepamos de lo que estamos hablando.

Pero bueno, hasta aquí lo que he mencionado son minucias. Te adaptas, y punto. Nosotros tenemos un modelo aprobado por la comisión de calidad del centro (sí, tenemos de eso), te pliegas a ella, y haces camino.

 A mí lo que me asfixia de verdad es dejar por escrito instrucciones o normas que luego se convierten en medidas inflexibles a la hora de trabajar.

Ya he comentado que en mi centro tenemos un modelo común de programación, para todas las familias profesionales. No está mal tener uno, ya digo que a mí me ayuda a la hora de redactar la programación. Pero luego ya viene cuando tendemos a estandarizarlo todo, y a forzar la uniformidad cuando en educación (al menos en Formación Profesional) eso es prácticamente inviable.

Por ejemplo: este curso nos piden que adoptemos acuerdos en los departamentos sobre aspectos generales de la metodología, lo que incluye una recomendación para los módulos teóricos y los prácticos. Pero vamos a ver, si cada módulo es de su madre y de su padre, incluso dentro de los teóricos, ¿qué necesidad tenemos de forzar a que todos los módulos teóricos funcionen de una manera determinada, cuando el enfoque de trabajo en el aula puede ser radicalmente distinto? ¿Y qué pasa si esa metodología que a mí me parece fantástica no sirve para un grupo determinado? O ¿por qué voy a atar por escrito hasta el mínimo detalle una metodología concreta, si a lo mejor a mitad de curso se me ocurre o encuentro una estrategia nueva que me encanta? ¿No puedo implantarla hasta que cambie la programación, el curso siguiente?

Por esta razón, yo suelo preferir dejar algunas cosas lo más abiertas posible, porque prefiero poder maniobrar e improvisar sobre la marcha en ocasiones. Ojo, que no hablo de trabajar de forma errática, sino de dejarme un margen para reaccionar en caso de que lo necesite, o piense que va a ser mejor que lo que había pensado de inicio. O encuentre una idea fantástica, que quiera poner en marcha para ya.

A veces, en los momentos más alejados de cuando estás planificando las actividades para el grupo (qué sé yo, en la ducha o en el coche), se te ocurren ideas que funcionan muy bien en el aula, aunque parezca raro.

Solución: nuestro acuerdo de departamento sobre metodología es precisamente no llegar a ningún acuerdo, sino dar libertad al profesor para elegir la metodología que crea más conveniente en cada caso. Y mientras el equipo directivo o inspección educativa no nos digan lo contrario, así se va a quedar.

Y por último, hay otro factor que a mí no me gusta nada, que interviene en cómo programamos. De vez en cuando, tu equipo directivo te insiste en la importancia de atar hasta el último detalle todo lo que tiene que ver con la evaluación (criterios, la forma en que obtienes la calificación, los instrumentos que vas a utilizar para reflejar tus observaciones, etc.). Y lo hacen para proteger al profesor en caso de reclamaciones de los alumnos. Normalmente, porque así se lo ha indicado algún inspector, después de que haya habido algún problema en el que haya tenido que intervenir.

A ver, a nadie le gusta que le pongan una reclamación, supongo (yo no he tenido ninguna de momento, pero nunca se está libre de que te pueda pasar). No me gustaría, porque supondría, primero, que no he podido llegar a un acuerdo con un alumno en algo tan importante como la forma de evaluarlo, y ese alumno se sentirá agraviado por mí de alguna manera. Y eso no me gusta. Y segundo, por el lío administrativo en que te metes, que acaba implicando a compañeros, jefatura de estudios, y en última instancia, a inspección educativa. Y cuando tratas con inspección educativa, sabes positivamente dos cosas: que van a ir a beneficiar al alumno, y que van a aplicar la norma hasta la última coma, para no pillarse los dedos. Ninguna de las dos cosas me parece mal, pero eso suele tener como consecuencia lo que comentaba antes, que el equipo directivo de turno insistirá en atar las programaciones cada vez más, para que no vuelva a ocurrir. Y eso tampoco me gusta.

Al fin y al cabo, ¿qué es lo peor que puede pasar ante una reclamación de un alumno? Que tus compañeros revisen la calificación y decidan que tienes que modificarla. Y ante eso, lo tengo súper claro: se modifica la nota y punto. O que tus compañeros ratifiquen tu calificación, y que en última instancia un inspector decida que pese a eso el alumno tiene razón, y hay que modificar la calificación. Y ahí tampoco tengo dudas: se modifica la calificación, y punto. Pero queda claro que la ha modificado inspección, y no yo, con lo que mi criterio queda claro. Ya está, problema finalizado.

En resumen, que me gustaría dejar mis programaciones más abiertas en muchos aspectos, pero parece que la tendencia es la contraria. Y eso hace de las programaciones un documento eterno e infumable completamente, en lugar de ser una herramienta motivadora (al menos para mí), que es lo que deberían ser, en mi opinión.

Pues eso, que ya os he soltado el rollo de esta semana (si no habíais huido antes). La culpa la tienen las programaciones de los cinco módulos que imparto, y que he estado revisando este mes. Ahora ya están, hasta el curso que viene.