Знание должно зачем-то понадобиться
предыдущий кусок.
Диаграма на второй день мне не понравилась, поэтому я её перерисовал
Некоторые мои коллеги и друзья знают, что я ярый противник идеи обучния "впрок": когда досматривают ролики, получают какой-то навык или дочитывают книги не для удовольствия, а на будущее, по сути только потому что купили курс или собственно книгу, а "рабочей" задачи под это нет. И разумная критика что хорошо, конечно, так рассуждать, но на переходе из области в область такой задачи может просто и не быть? Что же делать? Рассмотрим близкий мне пример из области обучения технарей.
Вот допустим мы учим дата-инженеров. Можно подойти к этому так:
- рассказать студенту пять принципов проектирования пайплайна на пяти лекциях и отпустить с зачётом
- показать красивую архитектурную схему и поискать в ней спорные узлы
- дать тест, в котором надо узнать правильный термин
Обычно так оно и происходит. Те же квизы например, для меня стали маркером провального методического процесса, потому что в одной образовательной платформе с которой я работал их в какой-то момент старались воткнуть буквально в каждый модуль просто потому что "ну должны же быть тесты на знание в модуле". Конечно, можно возразить что с квизами лучше чем вообще без заданий, но когда у команды нет возможности сделать нормальные проверки студенту эти квизы по факту только мозолят глаза. Проверка знаний тут скорее отсутствует, особенно когда тесты составлены ради тестов и наспех.
Что делать? Ну, конечно первое это пожертвовать полнотой ради закрепления. Можно найти время на разработку более сложных проверок, если порезать материал. Я пришёл в своих проектах к тому что надо тесты в виде лаб, и охватывать сразу большой кусок материала, тем самым как раз создавая контекст к пройденному материалу. Придумать модельную приближённую к реальности ситуацию, в случае DE-специалистов это не просто копипаст "выполни вот эти команды и получи виртуальную печеньку" а кривые данные, конфликтующие требования, погуглить почему какая-то часть не работает, споткнуться о какие-то нюансы, которые утаили в описании. Всё как в жизни.
Условно на примере навыка "выберитать тип хранилища", по сути нам важен контекст:
- для кого мы строим хранилище
- какие запросы будут частыми
- сколько у нас данных
- сколько у нас денег
- что изменится через полгода
- какой ошибкой мы готовы рискнуть
И наша образовательная цель это знание в контексте как инструмент внутри модельной ситуации, а не как правильный ответ на вопрос, которого студент возможно даже не задавал.
Кстати, конечно же у каких-то студентов будет жёстко гореть жопа с того что они отдали деньги, но им приходится думать и напрягаться. Тут всегда нужен индивидумальный подход к тушению такого пожара, но это хорошо подсвечивает что важная часть дополнительного обучения это как раз фильтрация на входе. Чем больше ты уточнишь ожидания "на входе" тем меньше шансов что студент в какой-то момент придёт к выводу что купил билет не на тот (иммерсивный) спектакль.
Если говоритиь афоризматически, то понимание детали зависит от целого, а понимание целого постоянно перестраивается из-за деталей. Герменевтический круг передаёт привет, так сказать 👋
То есть, контекст в задании нужен чтобы объяснить, зачем это знание понадобилось именно сейчас. Но одной правдоподобной декорации ("вы разрабатываете пайплайн обработки данных для соцсети") мало: внутри этой декорации ещё должно появиться продуктивное напряжение, иначе мы рискуем попасть в ту самую ситуацию увлекательного развлечения без обучения. Об этом дальше.