10 моментов, которые стоит сразу учитывать
1. ваш продюсер должен быть готов к тому, что такое PBL, потому что PBL плохо ложится в логику быстрого конвейерного production pipeline
у производства появляется другая логика: больше итераций, больше сопроектирования, больше зависимостей между ролями и больше мест, где хуже работает передача задачи дальше по цепочке без совместной сборки
расчет и закладывание просадки требуют тут опыта или, во всяком случае, погружения в подход и попытки реалистично обсчитать работы. если этого нет, продакшн будет страдать тем, что все трудности возникают “неожиданно”: внезапно нужно больше встреч с экспертами, внезапно задача не собирается из первого брифа, внезапно один модуль влияет на другой, внезапно нужно пересматривать не только урок, но и всю связку вокруг него
в итоге команде не хватает саппорта, сроки начинают ехать, а давление ложится на все роли
в PBL не получается зажмуриться и затащить. это априори долгий заплыв, и нужна команда не спринтеров
2. более долгий путь до первого выката и тестирования
PBL — это не быстрая модель, потому что в основе лежат комплексные модели проектирования
это не значит, что программу не нужно тестировать. конечно, нужно. но здесь хуже работает стратегия «вот так вот рас рас и готово» или «3 coffees no lunch/ no sleep”
до первого вменяемого тестируемого куска нужно сделать много вполне видимой работы: понять профессиональные задачи, распаковать действия специалиста, собрать уровни сложности, придумать кейсы или симуляции, определить, где нужна теория, какие нужны опоры, как учащийся будет двигаться внутри задачи и как это связано с соседними задачами
то есть путь до тестируемого фрагмента длиннее не потому, что команда “медленно работает”, а потому что сама модель требует более длинной сборки до производства материалов
3. выше требования и отсев авторов-экспертов в разработку
в PBL недостаточно того, что эксперт хорошо знает предмет или давно работает в практике
автору нужно уметь разбирать собственное профессиональное действие: объяснять, как он видит ситуацию, какие признаки считывает, какие гипотезы строит, где видит риск, как принимает решение и по каким основаниям понимает, что решение было качественным
и это не для всех простая задача. многие эксперты прекрасно действуют в практике, но им сложно восстановить собственную логику действия и тем более собрать ее в учебную задачу
поэтому в PBL выше требования к авторам-экспертам и выше отсев
4. больше сопроектирования, меньше работы по т/з
в PBL задача редко рождается из хорошего технического задания и готового материала эксперта
здесь хуже работает логика “напишите нам урок по этой теме, а мы дальше методически упакуем”. чаще приходится вместе собирать саму задачу: что это за профессиональная ситуация, что в ней должен увидеть учащийся, какие решения возможны, какие ошибки вероятны, какие вводные нужны, что будет слишком просто, а что уже перегрузит
в этот раз я зашла в проектирование без программного лида и надо сказать, что это ой как сложно, потому что фактически ты замещаешь куратора программы — в предмете, в котором ты сама разобралась 5 секунд назад
и производственно это важно учитывать: если в разработке нет отдельной роли, которая держит содержательную рамку программы, эта работа никуда не исчезает. она распределяется по другим ролям, чаще всего — падает в методистку
продолжение в комментарии (но не зажимайте ставить лайки! я работаю за дофамин 🙂↕️👍)
