La respuesta sincera a cómo evaluar los proyectos de robótica es esta: hay que calificar el razonamiento que ha producido el robot, no los treinta segundos en los que atraviesa una mesa. Una demostración que funciona te dice que un equipo acabó llegando. No te dice quién entendió el código, quién copió a un compañero ni si un cable bien remetido salvó de milagro un diseño que en realidad estaba roto. La buena evaluación en una clase de robótica mira las evidencias de proceso recogidas sobre la marcha, y trata la depuración como una destreza que merece nota por sí misma.

Esto importa sobre todo en junio, cuando hay que entregar los informes del segundo trimestre y toca convertir un trimestre de trabajo ruidoso y manual en una nota defendible. Si tu único artefacto es la ejecución final, tienes muy poco sobre lo que escribir. Si tienes diarios, registros y explicaciones breves, la nota casi se escribe sola.

Por qué “se ha movido” es una nota endeble

Una demostración final es una única muestra de un sistema ruidoso. Las pilas se agotan, los suelos tienen un agarre que el banco de pruebas no tenía y un siguelíneas ajustado con la luz de la mañana se comporta de otro modo con el sol de la tarde entrando por la ventana. Dos equipos pueden llegar al mismo resultado visible por caminos muy distintos: uno ha razonado hasta ahí y el otro lo ha forzado a base de cambiar números hasta que algo funcionó. Calificar solo el resultado premia a ambos por igual, lo que enseña calladamente a tus mejores alumnos que entender es opcional.

También castiga la ambición. Un equipo que intenta un mecanismo más difícil y se queda al 80 % del camino puede parecer peor el día de la demostración que otro que ha ido a lo seguro. Si tu rúbrica solo ve la línea de meta, los alumnos aprenden a elegir problemas fáciles. Evaluar el proceso te permite premiar el intento más difícil con honestidad.

Evalúa el proceso, no solo el producto

Traslada la mayor parte del peso a las evidencias que los alumnos generan mientras trabajan. Tres artefactos hacen casi todo el trabajo pesado y ninguno necesita software especial.

• Diarios de diseño. Una entrada breve y fechada en cada sesión: qué hemos probado, qué esperábamos, qué ha pasado en realidad, qué vamos a cambiar. Con media página basta. El valor está en la distancia entre lo esperado y lo real, porque en esa distancia es donde vive el aprendizaje.
• Registros de iteración. Una lista corrida de versiones con una línea de motivo por cada cambio. “v3: he bajado la velocidad del motor izquierdo, el robot se desviaba a la derecha”. Es la ventana más clara para saber si un alumno razona o adivina. En nuestro lienzo de programación por bloques el historial de guardado ya muestra esa progresión, así que el registro puede ser tan simple como anotar qué guardados importaron y por qué.
• Explicaciones entre iguales. Antes de dar un proyecto por terminado, un miembro del equipo explica a otro grupo, en lenguaje llano, una parte del código o del montaje elegida por ti. Tú escuchas dos minutos. Un alumno que ha escrito la lógica sabe narrarla; uno que la ha copiado se atasca en el primer “por qué esto y no aquello”.

El sentido de los tres es hacer visible el pensamiento invisible para que tengas algo que calificar además de la última ejecución.

Una rúbrica que premia la depuración

Depurar es el trabajo real de la robótica, así que debería pesar de verdad en lugar de tratarse como un fracaso que hay que esconder. Una rúbrica que la nombra cambia el comportamiento de los alumnos: empiezan a anotar qué se ha roto en vez de volver en silencio a una copia de seguridad y fingir que nunca pasó.

Una rúbrica sencilla de cuatro ejes funciona bien para un proyecto estándar con la placa sheenbot o cualquier kit similar. Reparte la nota de modo que ningún eje pueda sostener por sí solo un proyecto flojo.

• Comprensión (25 %): si el alumno sabe explicar qué hace cada parte de su solución y por qué.
• Proceso e iteración (30 %): calidad del diario y del registro; evidencia de haber probado un cambio contra una predicción en lugar de tocar al azar.
• Depuración (25 %): cómo se aisló y se corrigió un fallo; un error bien documentado que se encontró y se resolvió debería puntuar más que un proyecto sin ningún problema registrado.
• Resultado (20 %): si el montaje final cumple el encargo. Sigue contando. Solo que no domina.

Fíjate en que el resultado es el eje más pequeño. Es deliberado. Cuando los alumnos ven que un error bien cazado vale más que un proyecto sospechosamente limpio y sin historial, dejan de esconder sus dificultades y empiezan a mostrar su trabajo.

Trabajo en grupo y equidad

La queja más antigua en cualquier asignatura práctica es la del pasajero: un alumno maneja el portátil mientras los demás miran. Las evidencias de proceso son tu mejor defensa, porque son individuales por diseño. Cada miembro lleva su propio diario breve, y la explicación la hace un alumno concreto sobre una parte que eliges tú, no una que haya ensayado. Rota un rol visible en cada sesión para que el que maneja, el que monta y el que prueba cambien de semana en semana, y deja constancia de esa rotación.

Reserva una parte pequeña de la nota como individual y el resto como compartida. Un reparto habitual ronda el 70 % de equipo y el 30 % individual, donde la parte individual sale casi por completo del diario del propio alumno y de su explicación. Basta para que escaquearse se note, sin convertir un proyecto colaborativo en cuatro proyectos en solitario. Los formatos de competición ya van en esta línea: los equipos que se preparan para la FTC son juzgados por un porfolio de ingeniería que documenta toda la temporada, no solo por el robot el día del combate, que es justo el hábito que estás construyendo en clase.

Hacerlo sostenible

Nada de esto sobrevive si te duplica la carga de corrección. Mantén los instrumentos ligeros. Los diarios ocupan media página y se corrigen con un visto rápido contra tres preguntas, no con un párrafo de comentarios en cada uno. Las explicaciones ocurren en directo durante la clase, así que te cuestan tiempo de escucha, no tiempo de tarde. Los registros de iteración se ojean, no se leen línea a línea. Integra los puntos de control en la secuencia de la unidad desde el principio en vez de añadir la evaluación al final, tal como nuestro currículo de la academia reparte paradas reflexivas breves a lo largo de un proyecto en lugar de un único juicio al terminar. Una evaluación que vive dentro del trabajo es mucho más sostenible que un acto de corrección aparte.

Para quedarse con esto

“El robot se ha movido” es un punto de partida, no una nota. Traslada el peso de tu evaluación a las evidencias de proceso: diarios de diseño fechados, registros de iteración honestos y explicaciones breves entre iguales. Construye una rúbrica que pague a los alumnos por comprender y por depurar, y deja el resultado final como el eje más pequeño en lugar de como la historia entera. Hazlo y tus informes serán más fáciles de escribir, tus pasajeros silenciosos lo tendrán más difícil para esconderse y tus alumnos aprenderán la lección que de verdad se transfiere fuera del aula: en la ingeniería real, el producto es el razonamiento.