Честный ответ на вопрос, как оценивать проекты по робототехнике, звучит так: оценивайте мышление, которое породило робота, а не те тридцать секунд, когда он едет по столу. Работающая демонстрация говорит вам, что команда в конце концов до этого дошла. Она не говорит, кто понял код, кто списал у друга и не спас ли удачно подоткнутый провод конструкцию, которая на самом деле была сломана. Хорошее оценивание на уроке робототехники смотрит на свидетельства процесса, собранные по ходу дела, и относится к отладке как к навыку, который сам по себе заслуживает баллов.

Особенно остро это встаёт в июне, когда подходит срок отчётов за второй триместр и вы пытаетесь превратить целую четверть шумной практической работы в защитимую цифру. Если единственный ваш артефакт — финальный заезд, писать почти не о чем. Если у вас есть дневники, журналы и короткие устные объяснения, отметка выставляется почти сама.

Почему «поехал» — слабая отметка

Финальная демонстрация — это одна-единственная выборка из шумной системы. Батареи проседают, сцепление пола отличается от испытательного стенда, а следующий по линии робот, настроенный при утреннем свете, ведёт себя иначе под послеполуденным солнцем из окна. Две команды могут прийти к одному и тому же видимому результату совершенно разными путями: одна дошла рассуждением, вторая перебором меняла числа, пока что-то не заработало. Оценивая только результат, вы уравниваете их, а тем самым тихо внушаете самым сильным ученикам, что понимание необязательно.

Это ещё и наказывает амбиции. Команда, которая берётся за более сложный механизм и проходит 80% пути, в день демонстрации может выглядеть хуже команды, сыгравшей наверняка. Если ваши критерии видят только финишную черту, ученики учатся выбирать простые задачи. Оценивание процесса позволяет честно вознаградить более трудную попытку.

Оценивайте процесс, а не только продукт

Перенесите основной вес на свидетельства, которые ученики порождают по ходу работы. Три артефакта делают почти всю тяжёлую работу, и ни один из них не требует специального софта.

• Проектные дневники. Короткая запись с датой на каждом занятии: что пробовали, чего ожидали, что получилось на самом деле, что изменим дальше. Половины страницы вполне достаточно. Ценность — в разрыве между ожидаемым и фактическим, потому что именно в этом разрыве живёт обучение.
• Журналы итераций. Текущий список версий с однострочной причиной каждого изменения. «v3: замедлил левый мотор, робота уводило вправо». Это самое ясное окно в то, рассуждает ученик или гадает. На нашем полотне для блочного программирования история сохранений уже показывает эту динамику, так что журнал может сводиться к пометкам, какие сохранения были важны и почему.
• Взаимные объяснения. Прежде чем проект считается сделанным, один участник команды объясняет выбранный фрагмент кода или конструкции другой группе простыми словами. Вы слушаете две минуты. Ученик, который написал логику, может её пересказать; ученик, который её скопировал, спотыкается на первом же «почему так, а не иначе».

Смысл всех трёх — сделать невидимое мышление видимым, чтобы вам было что оценивать, кроме последнего заезда.

Критерии, которые поощряют отладку

Отладка — это и есть настоящая работа в робототехнике, поэтому она должна иметь реальный вес, а не считаться провалом, который надо спрятать. Критерии, где она названа явно, меняют поведение учеников: они начинают записывать, что сломалось, вместо того чтобы тихо откатиться к резервной копии и сделать вид, что ничего не было.

Для стандартного проекта на плате sheenbot или любом похожем наборе хорошо работают простые критерии из четырёх линий. Разделите баллы так, чтобы ни одна линия не вытянула слабый проект в одиночку.

• Понимание (25%) — может ли ученик объяснить, что делает каждая часть его решения и зачем.
• Процесс и итерации (30%) — качество дневника и журнала; свидетельства того, что изменение проверялось против предсказания, а не подкручивалось наугад.
• Отладка (25%) — как неисправность была локализована и устранена; чётко задокументированная найденная и решённая проблема должна оцениваться выше, чем проект вообще без записанных проблем.
• Результат (20%) — соответствует ли итоговая сборка заданию. Он по-прежнему учитывается. Просто не доминирует.

Обратите внимание: результат — самая маленькая линия. Это сделано намеренно. Когда ученики видят, что хорошо выслеженная ошибка приносит больше, чем подозрительно чистый проект без истории, они перестают прятать свои трудности и начинают показывать ход работы.

Групповая работа и справедливость

Самая старая жалоба в любом практическом предмете — «пассажир»: один ученик управляет ноутбуком, остальные смотрят. Свидетельства процесса — ваша лучшая защита, потому что они индивидуальны по своей природе. Каждый участник ведёт собственный короткий дневник, а объяснение делает названный вами ученик по выбранному вами фрагменту, а не по отрепетированному. Меняйте видимую роль каждое занятие, чтобы оператор, сборщик и испытатель от недели к неделе были разными людьми, и фиксируйте эту ротацию.

Оставьте небольшую часть отметки индивидуальной, а остальное — общей. Обычное разделение — примерно 70% команде и 30% лично, где индивидуальная часть почти целиком складывается из собственного дневника ученика и его объяснения. Этого хватает, чтобы безделье стало заметным, но совместный проект не превратился в четыре сольных. Соревновательные форматы и так устроены похоже: команды, идущие к FTC, оцениваются по инженерному портфолио, документирующему весь сезон, а не только по роботу в день матча — ровно та привычка, которую вы формируете на уроке.

Как сделать это устойчивым

Всё это не выживет, если удвоит вашу нагрузку по проверке. Держите инструменты лёгкими. Дневник — половина страницы, проверяется галочками по трём вопросам, а не абзацем отзыва на каждый. Объяснения происходят вживую на занятии, так что стоят вам времени слушания, а не вечера. Журналы итераций вы просматриваете по диагонали, а не читаете построчно. Встраивайте контрольные точки в последовательность занятий с самого начала, а не привинчивайте оценивание в конце — так, как наша учебная программа академии распределяет короткие рефлексивные остановки по всему проекту вместо одного большого суда на финише. Оценивание, живущее внутри работы, куда устойчивее, чем отдельное проверочное мероприятие.

Главное

«Робот поехал» — это отправная точка, а не отметка. Перенесите вес оценивания на свидетельства процесса: датированные проектные дневники, честные журналы итераций и короткие взаимные объяснения. Постройте критерии, которые платят ученикам за понимание и за отладку, и оставьте итоговый результат самой маленькой линией, а не всей историей. Сделайте так — и отчёты станет легче писать, тихим «пассажирам» станет труднее прятаться, а ваши ученики усвоят урок, который действительно переносится за пределы класса: в настоящей инженерии продукт — это мышление.