La risposta onesta su come valutare i progetti di robotica è questa: si valuta il ragionamento che ha prodotto il robot, non i trenta secondi in cui attraversa un tavolo. Una dimostrazione riuscita vi dice che una squadra ci è arrivata, prima o poi. Non vi dice chi ha capito il codice, chi ha copiato da un compagno, o se un cavo sistemato per fortuna abbia salvato un progetto che in realtà non funzionava. Una buona valutazione in classe di robotica guarda alle prove di processo raccolte lungo il percorso e tratta il debugging come una competenza che merita un voto a sé.

Questo conta soprattutto a giugno, quando vanno consegnate le pagelle del secondo trimestre e state cercando di trasformare mesi di lavoro pratico e caotico in un numero difendibile. Se l’unico documento che avete è la prova finale, avete ben poco su cui scrivere. Se avete diari, registri e brevi restituzioni orali, il voto si scrive quasi da solo.

Perché “si è mosso” è un voto debole

La dimostrazione finale è un singolo campione di un sistema rumoroso. Le batterie calano, i pavimenti hanno un’aderenza che il banco di prova non aveva, e un inseguitore di linea tarato con la luce del mattino si comporta diversamente sotto il sole pomeridiano che entra dalla finestra. Due squadre possono arrivare allo stesso risultato visibile per strade molto diverse: una ci è arrivata ragionando, l’altra per forza bruta, cambiando numeri finché qualcosa ha funzionato. Valutare solo il risultato premia entrambe allo stesso modo, e insegna silenziosamente agli studenti migliori che capire è facoltativo.

Inoltre punisce l’ambizione. Una squadra che tenta un meccanismo più difficile e arriva all’80% del percorso può fare una figura peggiore, il giorno della prova, di una squadra che è andata sul sicuro. Se la vostra griglia vede solo il traguardo, gli studenti imparano a scegliere problemi facili. Valutare il processo vi permette di premiare onestamente il tentativo più difficile.

Valutare il processo, non solo il prodotto

Spostate gran parte del peso sulle prove che gli studenti producono mentre lavorano. Tre strumenti fanno quasi tutto il lavoro, e nessuno richiede software particolare.

• Diari di progettazione. Una voce breve e datata a ogni lezione: che cosa abbiamo provato, che cosa ci aspettavamo, che cosa è successo davvero, che cosa cambieremo. Mezza pagina basta e avanza. Il valore sta nello scarto tra atteso e reale, perché è lì che vive l’apprendimento.
• Registri delle iterazioni. Un elenco progressivo delle versioni con una riga di motivazione per ogni modifica. “v3: rallentato il motore sinistro, il robot tirava a destra.” È la finestra più nitida su un punto: lo studente sta ragionando o sta tirando a indovinare? Sul nostro canvas di programmazione a blocchi la cronologia dei salvataggi mostra già questa progressione, quindi il registro può limitarsi ad annotare quali salvataggi contano e perché.
• Restituzioni tra pari. Prima che un progetto si consideri concluso, un membro della squadra spiega a un altro gruppo, in parole semplici, una parte scelta del codice o della costruzione. Voi ascoltate per due minuti. Uno studente che ha scritto la logica sa raccontarla; uno che l’ha copiata si blocca al primo “perché così e non in un altro modo”.

Lo scopo di tutti e tre è rendere visibile il pensiero invisibile, così da avere qualcosa da valutare oltre all’ultima prova.

Una griglia che premia il debugging

Il debugging è il lavoro vero della robotica, quindi dovrebbe pesare davvero invece di essere trattato come un fallimento da nascondere. Una griglia che lo nomina cambia il comportamento degli studenti: iniziano a scrivere che cosa si è rotto invece di tornare in silenzio a un backup fingendo che non sia mai successo.

Una semplice griglia a quattro voci funziona bene per un progetto standard sulla scheda sheenbot o su qualsiasi kit simile. Distribuite i punti in modo che nessuna singola voce possa da sola reggere un progetto debole.

• Comprensione (25%) — lo studente sa spiegare che cosa fa ogni parte della sua soluzione e perché.
• Processo e iterazione (30%) — qualità del diario e del registro; prove di aver testato una modifica rispetto a una previsione invece di ritocchi casuali.
• Debugging (25%) — come un guasto è stato isolato e risolto; un bug documentato con chiarezza, trovato e risolto, dovrebbe valere più di un progetto senza alcun problema registrato.
• Risultato (20%) — la costruzione finale risponde alla consegna? Conta ancora. Semplicemente non domina.

Notate che il risultato è la voce più leggera. È una scelta deliberata. Quando gli studenti vedono che un bug stanato per bene vale più di un progetto sospettosamente pulito e senza storia, smettono di nascondere le difficoltà e cominciano a mostrare il proprio lavoro.

Lavoro di gruppo ed equità

La lamentela più antica in qualsiasi materia pratica è il passeggero: uno studente guida il portatile mentre gli altri guardano. Le prove di processo sono la vostra difesa migliore, perché sono individuali per costruzione. Ogni membro tiene il proprio breve diario, e la restituzione la fa uno studente indicato da voi su una parte scelta da voi, non su una che ha provato prima. Ruotate a ogni lezione un ruolo visibile, così che il pilota, il costruttore e il collaudatore siano persone diverse settimana dopo settimana, e annotate la rotazione.

Tenete individuale una piccola quota del voto e condivisa la parte restante. Una ripartizione diffusa è circa 70% squadra e 30% individuale, dove la quota individuale deriva quasi interamente dal diario dello studente e dalla sua restituzione. Basta a rendere visibile chi si adagia senza trasformare un progetto collaborativo in quattro progetti solitari. I format di gara vanno già in questa direzione: le squadre che puntano alla FTC sono giudicate su un portfolio di ingegneria che documenta l’intera stagione, non solo il robot il giorno della gara: esattamente l’abitudine che state costruendo in classe.

Renderlo sostenibile

Niente di tutto questo sopravvive se raddoppia il vostro carico di correzione. Tenete leggeri gli strumenti. I diari sono mezza pagina e si controllano con un segno di spunta su tre domande, non con un paragrafo di feedback ciascuno. Le restituzioni avvengono dal vivo durante la lezione, quindi vi costano tempo di ascolto, non tempo la sera. I registri delle iterazioni si scorrono, non si leggono riga per riga. Inserite i punti di controllo nella sequenza delle lezioni fin dall’inizio invece di appiccicare la valutazione alla fine, come fa il curriculum della nostra academy, che distribuisce brevi soste riflessive lungo il progetto invece di un unico grande giudizio finale. Una valutazione che vive dentro il lavoro è molto più sostenibile di un evento di correzione a parte.

In sintesi

“Il robot si è mosso” è un punto di partenza, non un voto. Spostate il peso della valutazione sulle prove di processo: diari di progettazione datati, registri di iterazione onesti e brevi restituzioni tra pari. Costruite una griglia che paghi gli studenti per la comprensione e per il debugging, e tenete il risultato finale come voce più leggera invece che come storia intera. Fate così e le pagelle diventeranno più facili da scrivere, i passeggeri silenziosi più difficili da nascondere, e i vostri studenti impareranno la lezione che davvero vale oltre l’aula: nell’ingegneria vera, il prodotto è il ragionamento.