Учительский долг/teaching debt я ввожу по аналогии с technical debt в разработке софта. Этот технический долг накапливается, накапливается, а потом почему-то не даёт быстро продвигаться в проекте -- из-за накапливающихся недоделок любые маленькие изменения приводят к катастрофам, авралам и сбоям, ибо оказывается, что слишком много всего сразу нужно переделывать). Вот роли образовательного проекта: методолог, разработчик курса, преподаватель, тьюто/коуч, организатор образования.
Учительский долг/teaching debt я ввожу по аналогии с technical debt в разработке софта. Этот технический долг накапливается, накапливается, а потом почему-то не даёт быстро продвигаться в проекте -- из-за накапливающихся недоделок любые маленькие изменения приводят к катастрофам, авралам и сбоям, ибо оказывается, что слишком много всего сразу нужно переделывать).
Вот частые варианты учительского долга, в разбросе по ролям образовательного проекта:
1. Методолог -- документирование учебного стандарта. Часто методолог (отвечает за содержание образования) и instructional designer (отвечает за методику обучения и содержание курса) -- это две роли в одном лице. Поэтому различие между стандартом образования и собственно курсом (curriculum, объяснения, задачи) не делается. А потом тебе нужно делать много разных курсов для одного и того же содержания -- и всё, не работает машинка. "Чему учить" и "как учить" оказывается склееным, а необходимая расклейка как раз и будет -- teaching debt. Ещё тут teaching debt появляется, когда SoTA разбегается с тем, чему учат -- учат старому стандарту, а производственники работают по-новому, а руки поправить стандарт не доходят. Ещё методолог должен делать валидацию того, что instructional designer делает курсы именно те, по которым выучивается содержание стандарта, а не что-то совсем другое.
2. Разработчик курса/instructional designer -- он обеспечивает разработку курса с понятным (документированным!) соответствием учебным стандартам для тех или иных учебных ситуаций (дети, взрослые, короткие или длинные курсы, разные уровни компетенций на выходе). Он готовит учебный план/curriculum, методику обучения, содержание курса, метод проверки достижения компетенций (ибо тренинг и экзаменование мало отличаются -- всё это части одного курса, надо ведь "учить до готовности"). И тут debt часто в неучёте возможностей соверменных IT для поддержки blended learning, дистантного образования и всего подобного -- ожидается, что курс преподователь всё будет делать "из головы" по ходу занятия, ибо никаких материалов курса при его начале ещё нет, "не успели" (вот он, учебный долг!). Разработчик курса/instructional designer и преподаватель часто в одном лице, поэтому весь долг по разработке курса и его масштабированию никому не виден: всё потребное изобретается прямо по ходу обучения, а шанса подготовки каких-то учебных материалов (объяснений, упражнений и всего того, что делается учениками без преподавателя) тогда нет, после "пилотного курса" (так это обычно называется) история повторяется снова и снова. И появление второго преподавателя, или резкое увеличение людей, которые обучаются одним преподавателем с помощью компьютера -- вот это всё принципиально задерживается из-за того самого долга по переходу к blended learning.
3. Преподаватель -- тут две его подроли:
-- лидер, его главная задача обеспечить мотивацию учеников выполнять задания. Он также может давать обратную связь по непонимаемому материалу (но и тут может выкрутиться: организовать старших учеников учить младших, а самому делать ту самую мотивационную/лидерскую супервизию). Да, он может побыть и магнитофоном, воспроизводя методику, полученную от instructional designer -- но с этим справится и сам instructional designer, и компьютер. Объяснение материала проходит без участия преподавателя, это современная ситуация. И упражнения тоже. Преподаватель нужен только для того, чтобы уговорить ученика знакомиться с объяснениями и далее упражняться в пройденном -- занять личность ученика эту позицию (подробней см. https://ailev.livejournal.com/1316601.html). Не уговорил, не хватает "часов налёта" -- нарастает лидерский долг, недоработка лидера.
-- консультант, его главная задача провести ученика через множество проектных ситуаций, чтобы связать знания из учебника-задачника с жизнью (тренинг в постановке задач, это отличается от тренинга в решении задач, третий пункт из https://ailev.livejournal.com/1282190.html). Если не была обеспечена генерализация компетенции в решении задач на жизненные ситуации -- это долг консультанта. И тут ещё валидация работы instructional designer и лидера (и тут бросается в глаза конфликт интересов лидера и консультанта, но сразу возникает много нюансов) -- если недоученный ученик работает в проекте, то бесполезно: пустая голова не может в жизни увидеть объекты из учебника и применить способы мышления из задачника. Собственно, консультант должен "доварить до готовности", в какой-то мере у него и роль "экзаменатора" (справился с проектом -- ОК, сдал экзамен. Ибо экзамен на знание текста учебника или решение стандартных задач -- бесполезен. Нужно уметь использовать освоенную компетенцию в жизни, проверять интеллект).
4. Тьютор/коуч занимается общим образовательным маршрутом ученика, помогает ему выйти на бесконечное развитие (мои предварительные заметки про тьюторство и его автоматизацию -- https://ailev.livejournal.com/1145422.html). Для него все учебные курсы и проекты -- кирпичики из life long learning. Мы тут сознательно не разделяем тьютора и коуча, посколько далеки от концепции резкого окончания обучения (где ответственность тьютора) и перехода к бесконечному развитию (где ответственность коуча). Условно мы можем говорить, что тьютор должен вывести ученика на тот уровень владения трансдисциплинами (фундаментальные и кругозорные), где он сможет дальше бесконечно развиваться самостоятельно, самостоятельно формулировать свой учебно/рабочий план (curriculum) в рамках life-long learning. Ученик плавно переходит от обучения не только и даже не столько на учебных курсах, сколько в каких-то рабочих проектах -- которые ученик или инициирует сам, или к которым принимает решение присоединиться сам. Тьюторский долг накапливается в том случае, если образование получается однобоким, кругозор узким, выход на уровень самостоятельного развития не получается. Это происходит, если ученика недоучили личному стратегированию и не дали ему полного курса трансдисциплинарных предметов. После окончания обучения ученик не может самостоятельно двигаться по жизни, это будет огромной проблемой.
5. Организатор образования с подролями (обычно эти подроли исполняет много людей-исполнителей):
-- стратег (чему и кого учим)
-- системный менеджер учебного процесса (операционная деятельность в образовательной программе)
-- архитектор обучающей организации со всеми вышеупомянутыми ролями (и обычный долг тут -- недокументированная архитектура)
-- управление оргизменениями и лидерство (и обычные долги тут -- развал управления конфигурацией, все работают с разными версиями материалов и полно коллизий, а также развал коммуникации в команде вышеописанных ролей, плохая работа исполнителей ролей, необученные исполнители)
Как бороться с этим учительским долгом? Если всё делать в рамках какой-нибудь heavyweight методологии из этих ваших академических университетов, то ни один курс, ни одна учебная программа из множества курсов (помним о тьюторстве) не взлетит -- так и умрут на стадии разработки, а на выходе будут не ученики, а те самые "учебные материалы" и "методики. Если делать всё agile/lightweight (что часто читается как "на коленке"), то долг будет нарастать с каждым шагом по проекту -- и это тоже не выход.
Выход в повышении производительности труда за счёт организации труда и использования IT, поднятии квалификации исполнителей всех этих ролей (их тоже нужно учить!), и росте осознанности (ибо для начала этот долг нужно осознавать, с неосознанным долгом ничего поделать уже нельзя). Но главный ход тут -- это использовать инженерные методы работы и организации разработки и обучения-как-эксплуатации по типу DevOps или SRE. EduOps (увы, нету, придётся сочинять) как одна из практик организации образования нам как раз поможет: именно там обсуждается разработка курсов и выкатывание их в "эксплуатацию" -- как организовать смычку в работе методологов, разработчиков курсов, преподавателей и тьюторов.
Тут можно было бы ещё больше приблизить рассуждение про образовательный проект к рассуждению про инженерный проект (инженерный подход/approach: использовать структуру типового инженерного проекта и состав его ролей в образовательном проекте -- без этих привычных внеролевых "завучей"), но пока и так достаточно важных моментов для отслеживания. Так что оставим уточнения на будущее.
Источник: блог А.Левенчука