Что нужно для диагностики методистов

Как мы собирали оценивание по пед.технологиям и проектированию образовательных программ. И что важно не забыть при проектировании оценивания.

Выяснить, что на самом деле знают студенты по пед.технологиям и разработке образовательных программ. Нам было важно собрать структуру, по которой мы могли бы оценить методиста / студента, окончившего бакалавриат по педагогическому направлению, в рамках 2х дисциплин: Технологии обучения и Проектирование образовательных программ.

По ТЗ задача казалось бы простая: составить 250 заданий по каждому направлению по всем правилам тестдева. К заданиям были определенные требования (классические, чтобы задания действительно работали, и несколько дополнительных – определенный % заданий на разные уровни таксономии по каждой дисциплине). И ещё 3 круга внутренних QA, включая команду психометриков проекта + 2 внешних круга QA от заказчика.

Обожаю, когда люди относятся к задачам с отвественностью.

Конечно, мы могли бы пойти по простому сценарию: согласовать кодификатор (который в некоторой степени дублирует тем план), и на основе кодификатора (управляя покрытием) собрать это 250 вопросов. ТЗ простое, понятное, и, к сожалению, как большое количество таких решений – не работающее.

Но то, что это не будет работать знают только психометрики. И вот почему:

Здесь вы можете возразить – судя по ТЗ это самматив, а значит, Марина, идите с вашей точной ОС в форматив.

Но нет, самматив тоже так не работает.

Даже если вы хотите получить итоговый балл и сравнивать только результат студентов, вам необходимо отследить, как именно формируется этот балл. Причем вне зависимости от того, что мы хотим определить что ЗНАЕТ студент или что он УМЕЕТ / может реализовать. В обоих случаях вы столкнётесь со следующими проблемами:

1) Если при разработке вы не построили верно рамку оценивания, то ваше оценивание «расползётся». Т.е. вы не будете видеть в структуре теста связей заданий с ОР и тем, как они объединяются в компетенции. Это особенно важно, если у вас часть ОР могут более комплексными, а часть простыми, т.е. если вы работаете на разные уровни таксономии, особенно DOK.

2) Покрытие по кодификатору не всегда, а часто вообще не равно покрытию по компетенциям. И вам нужно выбирать, какое покрытие приоритетнее. Мы выбираем всё же не темы.

3) И не учитывая это, вам будет сложнее отбирать задания в тест, если количество вопросов в нём не 250) Т.е. ваш тест не будет валиден. Про надежность ничего сказать не могу)

Итак, 500 вопросов за 3 недели небольшой командой из 4х человек: 3 сеньора и джуниор. При этом я собрала рамку, которая позволила контролировать количество вопросов по каждой компетенции (а не только теме кодификатора) и по уровню сложности).

При этом мне нужно было управляли покрытием кодификатора, т.к. в ТЗ было важно распределить верно. Но равномерное покрытие по кодификатору не позволяло корректно отрабатывать компетенции, поэтому мы определяли наиболее приоритетные ОР и соотносили с кодификатором.

Что ещё уникального в этом продукте, чего обычно вы не увидите в разработке:

То, как разрабатывались задания. Скажу честно, у нас было несколько собеседований, и нам пришлось отказаться от помощи нескольких классных методистов, но без бекграунда в разработке заданий, так как мы в несколько итераций корректуры не могли добиться понимания. Всё же, наши курсы тестдев (теперь это часть «Оценивания в образовании») и «ECD в образовании» делают что-то очень важное с мышлением.

Фрейм разработки заданий является критичным, потому что мы при разработке, а далее я при проверке вопросов ориентировались в первую очередь на ОР, что позволяло максимально точно собирать дистракторы к заданиям, корректировать формулировки или сами задания.

Этот подход тоже не очевиден. Обычно, при разработке тестов так не собирают, поскольку цена ошибки – минимальна. Собственно это и делает обычное оценивание скорее формальной, чем диагностической процедурой.

Конечно, оно не везде нужно. Но есть несколько критичных точек, когда вы или продакт принимают решение, подходят ли студенты в программу, или их желательно перенаправить на другой курс. А ведь менеджеры продаж ошибаются, а этот процесс можно автоматизировать (если вы ещё не).

Этап 1. Внутренний QA команды

Кросс-ревью. Задания, которые требовали доработки (и мои задания) были отсмотрены командой.

Финальная приёмка команды. Все (абсолютно все) 500 заданий были мной прочитаны, соотнесены с ОР, проверены дистракторы. На этом этапе % доработок сильно зависел от уровня методиста и итерации. Все знают базовый тестдев, некоторые хорошо понимают ECD. От 90% на первой итерации с совместной проработкой и до 5% на совместно подумать на последних итерациях.

Этап 2. QA руководителем проекта

Здесь доработок было не очень много. Нам повезло и руководители не просто были в теме, имели здравый смысл (часто можно выехать на этом), они профи в теме. И это тот ещё челлендж.

Содержательный комментарий по выбранному кейсу, тому как он может быть прочитан, какие могут быть варианты - это ещё один взгляд, которые сделали наши задания на порядок лучше.

Этап 3. QA команды психометриков

Нам повезло, а такой проект нельзя в принципе было собирать без психометриков, команда психометриков работала на проекте как отдельный сервис, обеспечивающий логику разработки. В прошлом году на анлогичный проект мы нанимали одного мега-специлиста международного уровня и нашего психометрика.

Здесь я не могу не написать про мою любовь среди психометриков (хоть и не единственную))): Ирину Брун. Это были лучшие, самые лучшие комментарии. От того, как написаны комментарии зависит, насколько точно мы доработаем задание, и его психометрические характеристика (дискриминативность - насколько оно верно разделяет респондентов на тех, кто знает/умеет и тех, кто нет).

Этап 4-5-6. Финальная проверка
Да, у нас была ещё 1 проверка) и 2 от экспертов со стороны заказчика.

Я думаю, что это всё помогло взглянуть на задания под взглядом разных экспертов. Надо сказать, что доработок было не много. И это, конечно, меня радовало.

После проведения оценивания мы получили обратную связь, статистику и кроме того, теперь еще лучше делаем оценивание и диагностики.

Это было невероятное, крутое приключение для команды!

Марина, ну зачем так сложно? И, главное, дорого ведь.

Иногда лучше заплатить 1 раз. чем платить несколько раз и в итоге всё равно придётся собирать так. Потому что в некоторых случаях, когда диагностика - это база для разработки, то как она будет собрана очень сильно повлияет на дальнейший продукт. А если это инструмент использует очень много людей - то масштаб ошибки будет уже не человеческих размеров. Не надо так)

🎁 Не уверена, что кто-то дочитает, поэтому моим героям
пример разбора написанного задания (которое не вошло и поэтому мы не нарушаем NDA) в моём очень маленьком чатике для самых упоротых оценивании и ECD в обучении.