Un buen reto educativo se diseña, no se improvisa. El artículo usa la tipología de Jonassen y el modelo 3C3R de Hung para mostrar qué hace que un problema enseñe lo que debe enseñar, y por qué en el 40% de los casos el estudiante termina persiguiendo algo distinto de lo que el profesor tenía en mente.
En el primer ensayo de este blog escribí que todo aprendizaje real empieza con un problema que el estudiante todavía no sabe resolver. Desde entonces me han hecho la misma pregunta varias veces, formulada de maneras diferentes pero con el mismo fondo: ¿y cómo se te ocurre el problema?
La pregunta es más importante de lo que parece. Porque la respuesta honesta es que un buen reto educativo no se te ocurre. Se diseña, y diseñarlo es un trabajo tan técnico como diseñar un puente o un circuito. Un problema mal diseñado no solo no enseña: enseña exactamente lo que no querías enseñar. Enseña que la materia es arbitraria, que el esfuerzo no sirve, que el profesor puso algo difícil por ponerlo.
David Jonassen publicó en 2000 lo que se convirtió en la referencia estándar para pensar qué tipo de problema estás poniendo. Propuso una tipología de clases de problemas basada en su grado de estructuración, especificidad de dominio y complejidad, con el objetivo de diferenciar el soporte instruccional necesario para cada tipo. La tipología va desde problemas lógicos y algorítmicos —donde hay una respuesta correcta y un procedimiento claro para llegar a ella— hasta problemas de diseño y dilemas, donde no hay procedimiento, no hay respuesta única, y el contexto importa tanto como el contenido.
Los problemas bien estructurados tienen soluciones convergentes y requieren la aplicación de un número limitado de reglas y principios dentro de parámetros definidos. Los problemas mal estructurados poseen múltiples soluciones, múltiples caminos, menos parámetros manipulables, e incluyen incertidumbre sobre qué conceptos o principios son necesarios.
La distinción parece académica hasta que la pones en un salón de clases. Un profesor de matemáticas que pone un ejercicio de derivadas para practicar el método de la cadena está trabajando con un problema bien estructurado: hay un procedimiento, hay una respuesta, el estudiante lo ejecuta o no. Eso está bien para ciertos objetivos. Pero si lo que quieres es que el estudiante aprenda a decidir qué modelo usar cuando los datos de una empresa no se ajustan a ningún modelo limpio, necesitas un tipo de problema fundamentalmente distinto, uno donde no hay procedimiento predefinido y donde la mitad del trabajo es definir bien el problema antes de resolverlo.
Lo que Jonassen y Woei Hung argumentaron en 2008 en un artículo que debería ser lectura obligada para cualquiera que diseñe cursos es que la comunidad de aprendizaje basado en problemas lleva décadas discutiendo roles del tutor, roles del estudiante, uso de tecnología, y casi nadie discute con rigor qué tipo de problema estás poniendo. La dificultad del problema se define en términos de complejidad —amplitud del conocimiento, nivel de logro requerido, complejidad relacional— y de grado de estructuración —transparencia, heterogeneidad de interpretaciones, interdisciplinariedad, dinamicidad. Todos esos factores importan, y la mayoría de los profesores los mezclan sin saberlo.
Algo que me parece revelador: cuatro estudios distintos mostraron que la correspondencia entre los objetivos que el profesor tenía en mente y los temas de aprendizaje que los estudiantes efectivamente identificaron al trabajar el problema rondaba apenas el 62%. Eso quiere decir que en cuatro de cada diez casos, el estudiante estaba persiguiendo algo diferente de lo que el profesor creía que debía perseguir. No porque el estudiante fuera flojo o el profesor incompetente. Porque el problema no estaba bien diseñado para llevar al estudiante adonde se suponía que debía ir.
Hung propuso en 2006 un modelo para atacar esto de frente: el modelo 3C3R. Tiene seis componentes organizados en dos clases. Tres componentes centrales —contenido, contexto y conexión— sostienen el aprendizaje conceptual. Tres componentes de procesamiento —investigación, razonamiento y reflexión— sostienen los procesos cognitivos y las habilidades de resolución. No es una receta: es un marco para verificar que el problema que diseñaste realmente apunta adonde crees que apunta.
Lo traduzco a cómo lo pienso yo cuando me siento a diseñar una sesión.
Contenido. ¿Qué necesita aprender el estudiante en esta sesión? Si la respuesta es "derivadas por el método de la cadena", entonces el problema tiene que requerir exactamente eso para resolverse, ni más ni menos. Si el problema se puede resolver sin usar el método de la cadena, no sirve. Si requiere tres conceptos que el estudiante todavía no ha visto, tampoco. La precisión aquí es lo más difícil.
Contexto. ¿El problema ocurre en un escenario que el estudiante puede reconocer como real o al menos plausible? Un problema de optimización que dice "una empresa quiere minimizar costos de producción sujeta a las siguientes restricciones" funciona. Uno que dice "calcula el mínimo de la función f" no tiene contexto y el estudiante no sabe para qué lo está haciendo, aunque la matemática sea idéntica.
Conexión. ¿Cómo se relaciona este problema con lo que el estudiante ya sabe y con lo que va a necesitar después? Un reto aislado, que no se conecta con nada anterior ni posterior, produce aprendizaje que se olvida en dos semanas.
Y del lado del procesamiento: ¿el problema obliga al estudiante a investigar algo que no le dieron hecho? ¿Lo obliga a razonar, a tomar decisiones entre alternativas? ¿Lo obliga a preguntarse si su solución tiene sentido, o puede terminar sin haberlo pensado?
Lo que he aprendido a la mala es que fallar en cualquiera de estos ejes produce un tipo diferente de daño. Un problema sin contenido preciso deja al estudiante trabajando mucho y aprendiendo poco. Un problema sin contexto lo deja sin motivación. Un problema sin conexión lo deja con conocimiento suelto. Un problema sin investigación le da todo masticado. Uno sin razonamiento lo deja ejecutando pasos sin pensar. Y uno sin reflexión le permite entregar algo sin saber si lo que entregó está bien.
La tentación permanente del profesor es improvisar el problema. Lo veo en mí mismo: ya sé el tema, ya sé la materia, me siento frente al escritorio y me invento algo que suene interesante. A veces funciona por suerte. Pero la suerte no escala. Cuando tienes que diseñar dieciséis sesiones de un curso, con dieciséis problemas que cubran el contenido completo, conecten entre sí, y lleven al estudiante exactamente adonde tiene que llegar, la improvisación te deja con huecos que solo descubres cuando el estudiante ya se perdió.
Diseñar un buen reto se parece más a escribir un buen problema de ingeniería que a tener una buena idea creativa. Es un proceso con restricciones: estas son las horas, este es el contenido, este es el nivel del estudiante, esta es la evidencia que tiene que producir al final. Dentro de esas restricciones, la creatividad importa —un problema aburrido es un problema que nadie va a querer resolver—. Pero sin restricciones, la creatividad produce actividades entretenidas que no enseñan nada.
No voy a pretender que tenemos esto dominado. Cada vez que diseñamos un curso nuevo, descubrimos retos que parecían buenos en el papel y que en la práctica no funcionaron: demasiado abiertos, demasiado cerrados, con un salto cognitivo que el estudiante no podía dar sin más andamiaje. Lo que sí tenemos es un proceso para diagnosticar por qué falló, y eso vale más que acertar de casualidad. Si puedo explicar qué componente falló, puedo arreglarlo. Si solo sé que "no funcionó", la siguiente versión es otro volado.
Un buen reto educativo parece simple cuando el estudiante lo recibe. Debería poder enunciarse en un párrafo. Pero detrás de ese párrafo hay horas de diseño hacia atrás, verificando que cada pieza esté donde tiene que estar. La elegancia está en que el estudiante nunca vea ese trabajo. Solo vea un problema que quiere resolver.
Referencias
- Jonassen, D. H. (2000). Toward a design theory of problem solving. Educational Technology Research and Development, 48(4), 63–85.
- Jonassen, D. H. (1997). Instructional design models for well-structured and ill-structured problem-solving learning outcomes. Educational Technology Research and Development, 45(1), 65–94.
- Jonassen, D. H., & Hung, W. (2008). All problems are not equal: Implications for problem-based learning. Interdisciplinary Journal of Problem-Based Learning, 2(2), 6–28.
- Hung, W. (2006). The 3C3R model: A conceptual framework for designing problems in PBL. Interdisciplinary Journal of Problem-Based Learning, 1(1), 55–77.