Как же я ждал такого комментария на этот пост: «Проблема скрывается в непонимании разработчиков как, когда и зачем выбирать подходы/модели проектирования обучения, а в некоторых случаях и сочетать разные модели в одной учебной программе».
После разбора сотен учебных программ я понял:
большинство ошибок мы делаем ещё на старте, когда выбираем подход к проектированию.
Вот что часто происходит 👇🏼
Мы берём модель просто потому, что привыкли — как к тёплым тапочкам.
Удобно, но не всегда уместно.
Потом оказывается, что выбранный подход не учитывает, например, кто у нас учится — новички или опытные специалисты.
Или мы планируем быструю разработку, но забываем, что эксперты доступны раз в неделю, контент нужно согласовывать с тремя отделами, а мы планируем сделать учебную программу за 2 недели.
Подменяем логику проектирования попыткой угодить всем.
Заказчик хочет цифры, обучающиеся — образовательные результаты, руководитель — отчёт. Вместо выбора приоритетов пытаемся вместить всё сразу. Результат: программа теряет фокус, а её эффективность стремится к нулю.
А ещё бывает, делаем программу из отдельных кусочков: тут теория, тут практика, тут проверка знаний. А связать их в единую логическую цепочку забываем. Студенты чувствуют этот разрыв и их вовлеченность снижается.
Иногда вообще вижу, как разработчики превращаются в «заядлых оптимистов», которые считают, что все сложности решатся сами собой. Не продумывают как будут оценивать результат, хватит ли ресурсов, что делать, если что-то пойдёт не так.
Сам через это проходил на самом начальном профессиональном этапе, пока не понял: модель проектирования — это фундамент любого курса.
Без неё даже самый крутой контент развалится на части.
Всё это — следствие одного: мы сначала делаем, а потом думаем о методологии.
А должно быть наоборот!
❓ Друзья, если бы вам сейчас пришлось объяснять новичку, как НЕ надо выбирать подходы к проектированию учебных программ, что бы вы назвали первым пунктом?