Это подход, инструмент, чтобы структурировать контент. Он — часть группы моделей педдизайна, в которых программу проектируют от задач/проблем, а не целей (от задач — 4C/ID, Pebble in the Pond, от целей — UbD, Dick and Carey). Такие модели ставят в центр цельные реальные задачи, которые выполняют профессионалы в теме.
Важно на берегу понять, что здесь слово «задача» отличается о том, что мы часто привыкли под ним понимать. Задача в таких моделях — это только та целиковая штуку, которую могут дать специалисту; то, у чего на старте нет придуманного решения; и то, что требует сочетать одновременно много знаний и навыков в процессе решения.
Посмотрим на примере из работы методиста, чтобы лучше понять:
- Подходящие задачи — спроектировать курс, занятие, образовательную модель; проверить методревью.
- Неподходящие задачи — выбрать методику для занятия; дать фидбек студенту; создать квиз или задание (все фокусируются на отдельных шагах или маленьких артефактах, а не цельных задачах).
Как по этим моделям проектировать?
Каждый модуль/урок учит решать конкретную задачу, причём с теми вводными (ограничения, сроки, данные на старте, формат сдачи), с которыми получают специалисты. Для целей обучения эти задачи упрощают на старте программы, чтобы студентам было проще «войти».
В основе подхода два принципа:
- найти простейшую версию задачи, которая всё ещё представляет целую задачу (epitomizing в оригинале)
- выстраивать обучающие задачи в возрастающую по сложности прогрессию — чтобы они при этом были упрощёнными или равными по вводным версиями реальной задачи (elaborating).
Простейший процесс в таком подходе
Этап 1. Подготовиться к анализу и дизайну
Шаг 1. Установить отношения с SME — в этой методике педдизайнеру нужно много-много-много-много интервьюировать эксперта: вытаскивать то, как выглядит реальность, работа; сверять своё понимание и дизайн → хорошие отношения важны
Шаг 2. Определить характеристики задачи в целом — по каким параметрам одна задача в реальной работе специалиста может отличаться от другой, а в курсе — быть упрощённой по ним + какие «значения» могут принимать эти параметры. Это и есть те самые simplifying conditions — условия, по которым можно уменьшить или увеличить сложность задачи. Например, параметры задачи
Шаг 3. Определить характеристики студентов в целом — здесь стандартный список: что знают и не очень, чего хотят + сталкивались ли уже в любом виде с задачами, которым будем учить
Шаг 4. Определить ограничения
Этап 2. Определить стартовую задачу — самую простую задачи
Шаг 5. Определить простейшую версию задачи — какую задачу даёт сочетание наиболее простых значений параметров
Шаг 6. Проанализировать задачу и определить, как можно прийти к решению — через заранее известную последовательность шагов или через самостоятельный поиск.
Шаг 7. Проанализировать задачу и понять, что нужно (у)знать, чтобы решить её и какая поддержка может пригодится
Шаг 8. Определить масштаб задачи — сколько времени, сил и других ресурсов займёт решение и обучение. Нужно, чтобы задача была ни слишком простой, ни слишком сложной, в зоне ближайшего развития.
Шаг 9. Упорядочить контент внутри учебной сущности, которая учит решать эту задачу.
Этап 3. Определить следующие задачи
Шаг 10. Определить и упорядочить все остальные упрощающие условия, которые различают простейшие версии.
Шаг 11. Определить следующую простейшую и наиболее репрезентативную версию задачи (чтобы была довольно похожа на ту, с которой профессионал в работе сталкивается.
Шаг 12. Снова упорядочить.
Падам, вот и конец. Не так всё и сложно.
Вот так всё просто. Ладно, на первый взгляд (и даже на второй) не очень, но на самом деле просто, если попробовать. Если попробуете, расскажите, что вышло (или нет).