Die ehrliche Antwort auf die Frage, wie man Robotikprojekte bewertet, lautet: Benoten Sie das Denken, aus dem der Roboter entstanden ist, und nicht die dreißig Sekunden, in denen er über einen Tisch fährt. Eine funktionierende Vorführung sagt Ihnen, dass ein Team irgendwann ans Ziel gekommen ist. Sie sagt Ihnen nicht, wer den Code verstanden hat, wer bei einer Freundin abgeschrieben hat oder ob ein glücklich verlegtes Kabel eine eigentlich fehlerhafte Konstruktion gerettet hat. Gute Bewertung im Robotikunterricht schaut auf Prozessbelege, die unterwegs entstehen, und behandelt Debugging als eine Fähigkeit, die eigene Punkte verdient.

Am wichtigsten wird das im Juni, wenn die Zeugnisse für das zweite Trimester fällig sind und Sie ein ganzes Trimester lauter, praktischer Arbeit in eine begründbare Zahl übersetzen müssen. Wenn Ihr einziges Artefakt der Abschlusslauf ist, haben Sie sehr wenig, worüber Sie schreiben können. Wenn Sie Journale, Protokolle und kurze Erklärrunden haben, schreibt sich die Note fast von selbst.

Warum „er ist gefahren“ eine schwache Note ist

Eine Abschlussvorführung ist eine einzige Stichprobe aus einem verrauschten System. Akkus brechen ein, Böden haben eine Griffigkeit, die der Teststand nicht hatte, und ein Linienfolger, der im Morgenlicht eingestellt wurde, verhält sich unter der Nachmittagssonne durchs Fenster anders. Zwei Teams können auf sehr unterschiedlichen Wegen zum selben sichtbaren Ergebnis kommen: Das eine hat sich dorthin gedacht, das andere hat sich mit roher Gewalt durchprobiert, bis irgendetwas funktionierte. Wer nur das Ergebnis bewertet, belohnt beide gleich – und lehrt damit still und leise die stärksten Schülerinnen und Schüler, dass Verstehen optional ist.

Es bestraft außerdem Ehrgeiz. Ein Team, das sich an einen schwierigeren Mechanismus wagt und 80 % des Weges schafft, kann am Vorführtag schlechter dastehen als ein Team, das auf Nummer sicher gegangen ist. Sieht Ihr Bewertungsraster nur die Ziellinie, lernen die Lernenden, sich einfache Probleme auszusuchen. Den Prozess zu bewerten erlaubt Ihnen, den schwierigeren Versuch ehrlich zu honorieren.

Den Prozess bewerten, nicht nur das Produkt

Verlagern Sie den Großteil der Gewichtung auf Belege, die die Lernenden während der Arbeit selbst erzeugen. Drei Artefakte erledigen fast die gesamte Arbeit, und keines davon braucht spezielle Software.

• Konstruktionsjournale. Ein kurzer, datierter Eintrag pro Stunde: Was haben wir versucht, was haben wir erwartet, was ist tatsächlich passiert, was ändern wir als Nächstes. Eine halbe Seite reicht völlig. Der Wert liegt in der Lücke zwischen Erwartung und Wirklichkeit, denn in dieser Lücke steckt das Lernen.
• Iterationsprotokolle. Eine fortlaufende Liste der Versionen mit einer einzeiligen Begründung für jede Änderung. „v3: linken Motor verlangsamt, Roboter zog nach rechts.“ Das ist das klarste Fenster darauf, ob jemand argumentiert oder rät. Auf unserem Canvas für blockbasiertes Programmieren zeigt der Speicherverlauf diese Entwicklung ohnehin, das Protokoll kann also so schlicht sein wie eine Notiz dazu, welche Speicherstände wichtig waren und warum.
• Erklärrunden unter Gleichaltrigen. Bevor ein Projekt als fertig gilt, erklärt ein Teammitglied einer anderen Gruppe einen ausgewählten Abschnitt des Codes oder des Aufbaus in einfacher Sprache. Sie hören zwei Minuten zu. Wer die Logik selbst geschrieben hat, kann sie erzählen; wer sie kopiert hat, stockt beim ersten „Warum so und nicht anders?“.

Der Sinn aller drei Instrumente ist, unsichtbares Denken sichtbar zu machen, damit Sie etwas anderes zu bewerten haben als den letzten Lauf.

Ein Raster, das Debugging belohnt

Debugging ist die eigentliche Arbeit in der Robotik, also sollte es echtes Gewicht tragen, statt als zu verbergendes Scheitern zu gelten. Ein Raster, das es benennt, verändert das Verhalten der Lernenden: Sie fangen an aufzuschreiben, was kaputtgegangen ist, statt still zu einem Backup zurückzukehren und so zu tun, als sei nie etwas gewesen.

Ein einfaches Raster mit vier Strängen funktioniert gut für ein Standardprojekt auf dem sheenbot-Board oder einem vergleichbaren Kit. Verteilen Sie die Punkte so, dass kein einzelner Strang ein schwaches Projekt allein tragen kann.

• Verstehen (25 %) – kann die Person erklären, was jeder Teil ihrer Lösung tut und warum.
• Prozess und Iteration (30 %) – Qualität von Journal und Protokoll; Belege dafür, dass eine Änderung gegen eine Vorhersage getestet wurde statt willkürlich herumzuschrauben.
• Debugging (25 %) – wie ein Fehler eingegrenzt und behoben wurde; ein sauber dokumentierter Bug, der gefunden und gelöst wurde, sollte höher bewertet werden als ein Projekt ganz ohne festgehaltene Probleme.
• Ergebnis (20 %) – erfüllt der fertige Aufbau die Aufgabenstellung. Es zählt weiterhin. Es dominiert nur nicht mehr.

Beachten Sie, dass das Ergebnis der kleinste Strang ist. Das ist Absicht. Wenn Lernende sehen, dass ein gut aufgespürter Fehler mehr einbringt als ein verdächtig sauberes Projekt ohne Historie, verstecken sie ihre Mühen nicht mehr, sondern zeigen ihren Rechenweg.

Gruppenarbeit und Fairness

Die älteste Klage in jedem praktischen Fach ist der Mitfahrer: Eine Person bedient den Laptop, die anderen schauen zu. Prozessbelege sind Ihre beste Absicherung, denn sie sind von vornherein individuell. Jedes Mitglied führt sein eigenes kurzes Journal, und die Erklärrunde übernimmt eine namentlich benannte Person zu einem Abschnitt, den Sie auswählen, nicht zu einem einstudierten. Rotieren Sie in jeder Stunde eine sichtbare Rolle, sodass Fahrer, Konstrukteurin und Testerin von Woche zu Woche wechseln, und halten Sie diese Rotation fest.

Halten Sie einen kleinen Teil der Note individuell und den Rest gemeinsam. Eine gängige Aufteilung liegt bei rund 70 % Team und 30 % Einzelleistung, wobei der individuelle Anteil fast vollständig aus dem eigenen Journal und der Erklärrunde stammt. Das reicht, um Trittbrettfahren sichtbar zu machen, ohne aus einem gemeinsamen Projekt vier Einzelarbeiten zu machen. Wettbewerbsformate gehen ohnehin in diese Richtung: Teams auf dem Weg zur FTC werden nach einem Engineering-Portfolio bewertet, das die ganze Saison dokumentiert, und nicht nur nach dem Roboter am Wettkampftag – genau die Gewohnheit, die Sie im Unterricht aufbauen.

So bleibt es tragfähig

Nichts davon überlebt, wenn es Ihre Korrekturlast verdoppelt. Halten Sie die Instrumente leicht. Journale umfassen eine halbe Seite und werden mit einem Häkchen gegen drei Fragen abgeglichen, nicht mit einem Absatz Rückmeldung je Eintrag. Erklärrunden finden live im Unterricht statt, sie kosten also Zuhörzeit, nicht Abendzeit. Iterationsprotokolle überfliegen Sie, statt sie Zeile für Zeile zu lesen. Bauen Sie die Kontrollpunkte von Anfang an in die Stundenfolge ein, statt die Bewertung am Ende anzuflanschen – so, wie unser Academy-Lehrplan kurze Reflexionsstopps über ein Projekt verteilt, statt am Schluss ein großes Urteil zu fällen. Bewertung, die in der Arbeit selbst steckt, ist weit tragfähiger als ein separates Prüfungsereignis.

Fazit

„Der Roboter ist gefahren“ ist ein Ausgangspunkt, keine Note. Verlagern Sie das Gewicht Ihrer Bewertung auf Prozessbelege: datierte Konstruktionsjournale, ehrliche Iterationsprotokolle und kurze Erklärrunden unter Gleichaltrigen. Bauen Sie ein Raster, das Verstehen und Debugging honoriert, und lassen Sie das Endergebnis den kleinsten Strang sein statt die ganze Geschichte. Tun Sie das, und Ihre Zeugnisse lassen sich leichter schreiben, stille Mitfahrer können sich schlechter verstecken, und Ihre Lernenden lernen die Lektion, die tatsächlich über das Klassenzimmer hinaus trägt: Im echten Ingenieurwesen ist das Denken das Produkt.