Ciao a tutti e benvenuti nel podcast! Sono Giordano. Allora, provate a immaginare questa scena: siamo in un'aula di scuola, ci sono quattro ragazzi chinati su un tavolo, circondati da cavetti, mattoncini di plastica e un piccolo robot programmato per seguire una linea nera sul pavimento. Il robot parte, fa due centimetri, scatta a sinistra, urta un astuccio e si ribalta tristemente su un fianco. Fine della corsa. Ora, se fossimo dei valutatori tradizionali, daremmo un bel due a quel robot, giusto? Non funziona. Compito fallito. Ma qui sta l'inghippo che mi fa letteralmente impazzire da quando studio Digital Education: valutare la robotica educativa guardando solo se il robot si muove o meno è come giudicare un intero romanzo solo dalla copertina. Ci perdiamo tutta la parte migliore. Questo è quello che in didattica chiamiamo la trappola del prodotto finale. Se un gruppo di studenti più furbi scarica un codice già pronto da internet, lo carica sul robot e questo funziona perfettamente al primo colpo, che cosa hanno imparato davvero? Praticamente nulla. Hanno solo eseguito un copia-incolla efficiente. Un altro gruppo, invece, potrebbe aver passato tre ore a litigare con un ciclo condizionale, a capire perché un sensore di luce leggeva male la luminosità della stanza, facendo decine di tentativi ed errori. Il loro robot alla fine magari fa cilecca, ma il loro bagaglio di apprendimento è infinitamente più ricco. Ecco perché dobbiamo assolutamente valorizzare il fallimento costruttivo. Nella robotica, l'errore non è un voto rosso sul registro; è un dato. È il robot che ti dice: "Ehi, guarda che questa riga di codice non produce l'effetto che pensavi". Il debugging, cioè la ricerca e la correzione dell'errore, è il vero cuore del pensiero computazionale. E poi ci sono quelle che io chiamo le competenze invisibili. Come si misura con un classico test a crocette la capacità di un ragazzo di mediare durante un conflitto nel team? O la perseveranza di fronte a un motore che non risponde ai comandi? Spoiler: non si può. Queste competenze, la collaborazione e il problem solving concreto, richiedono uno sguardo diverso da parte del docente. Un cambio di paradigma totale. Ma allora, concretamente, un insegnante come fa a valutare tutto questo senza impazzire? Non possiamo certo basarci solo sull'intuito o sulla simpatia. Fortunatamente la ricerca in tecnologie educative ci dà dei binari molto solidi su cui muoverci. Possiamo appoggiarci a tre pilastri pratici. Il primo pilastro sono le rubriche valutative con criteri espliciti. Non parliamo di generici "bravo" o "sufficiente", ma di griglie dove andiamo a spacchettare il lavoro. Ad esempio, creiamo una voce per l'accuratezza del codice, una per la creatività del design del robot e, soprattutto, una per la gestione del lavoro di gruppo. Il secondo pilastro è l'osservazione sistematica. Il docente non sta alla cattedra a correggere i compiti, ma gira tra i banchi con una griglia osservativa in mano, annotando come gli studenti interagiscono, chi prende l'iniziativa, come reagiscono quando il robot si schianta contro il muro per la decima volta. E infine, il terzo pilastro: il portfolio di robotica, concepito come un vero e proprio diario di bordo. I ragazzi documentano il loro viaggio, caricano foto dei prototipi intermedi, registrano brevi video in cui spiegano: "Oggi volevamo fare questo, abbiamo fallito per questo motivo e abbiamo risolto così". Ma andiamo ancora più a fondo, perché qui c'è una chicca accademica che adoro. Nel 2015, il ricercatore Marcos Román-González ha sviluppato uno strumento pazzesco chiamato Computational Thinking Test. Questo test serve proprio a misurare il pensiero computazionale in modo diagnostico, cioè scollegato dalla specifica sintassi di un linguaggio di programmazione. Valuta la capacità di gestire sequenze, cicli, decisioni e orientamento spaziale. Usarlo all'inizio e alla fine di un percorso di robotica permette di capire, con dati scientifici alla mano, se i ragazzi hanno davvero sviluppato flessibilità mentale e capacità di astrazione, al di là dell'hardware che hanno usato. E per chiudere il cerchio della valutazione, non possiamo dimenticare il potere del peer assessment, la valutazione tra pari. Far valutare i progetti ai ragazzi stessi non significa far fare il lavoro sporco al posto del docente, tutt'altro! Quando chiedi a un gruppo di analizzare il robot di un altro team e dare un feedback strutturato -- spiegando cosa funziona, cosa si potrebbe migliorare e perché -- li costringi a fare uno sforzo di astrazione enorme. Devono comprendere la logica altrui e formularla a parole. È un esercizio di empatia tecnologica e comunicazione formidabile. Quindi, la prossima volta che vedete un robot educativo muoversi in classe, provate a ignorare per un attimo il traguardo. Guardate invece i volti dei ragazzi, le loro discussioni, i fogli pieni di appunti scarabocchiati e cancellati. È lì dentro, in quel caos creativo, che si nasconde il vero apprendimento. Voi cosa ne pensate? Siete pronti a valorizzare i robot che sbagliano? Alla prossima!
Audio Coursesby Jellypod