Учительский долг/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/1 316 601.html). Не уговорил, не хватает «часов налёта» -- нарастает лидерский долг, недоработка лидера.
-- консультант, его главная задача провести ученика через множество проектных ситуаций, чтобы связать знания из учебника-задачника с жизнью (тренинг в постановке задач, это отличается от тренинга в решении задач, третий пункт из https://ailev.livejournal.com/1 282 190.html). Если не была обеспечена генерализация компетенции в решении задач на жизненные ситуации -- это долг консультанта. И тут ещё валидация работы instructional designer и лидера (и тут бросается в глаза конфликт интересов лидера и консультанта, но сразу возникает много нюансов) -- если недоученный ученик работает в проекте, то бесполезно: пустая голова не может в жизни увидеть объекты из учебника и применить способы мышления из задачника. Собственно, консультант должен «доварить до готовности», в какой-то мере у него и роль «экзаменатора» (справился с проектом -- ОК, сдал экзамен. Ибо экзамен на знание текста учебника или решение стандартных задач -- бесполезен. Нужно уметь использовать освоенную компетенцию в жизни, проверять интеллект).

4. Тьютор/коуч занимается общим образовательным маршрутом ученика, помогает ему выйти на бесконечное развитие (мои предварительные заметки про тьюторство и его автоматизацию -- https://ailev.livejournal.com/1 145 422.html). Для него все учебные курсы и проекты -- кирпичики из life long learning. Мы тут сознательно не разделяем тьютора и коуча, посколько далеки от концепции резкого окончания обучения (где ответственность тьютора) и перехода к бесконечному развитию (где ответственность коуча). Условно мы можем говорить, что тьютор должен вывести ученика на тот уровень владения трансдисциплинами (фундаментальные и кругозорные), где он сможет дальше бесконечно развиваться самостоятельно, самостоятельно формулировать свой учебно/рабочий план (curriculum) в рамках life-long learning. Ученик плавно переходит от обучения не только и даже не столько на учебных курсах, сколько в каких-то рабочих проектах -- которые ученик или инициирует сам, или к которым принимает решение присоединиться сам. Тьюторский долг накапливается в том случае, если образование получается однобоким, кругозор узким, выход на уровень самостоятельного развития не получается. Это происходит, если ученика недоучили личному стратегированию и не дали ему полного курса трансдисциплинарных предметов. После окончания обучения ученик не может самостоятельно двигаться по жизни, это будет огромной проблемой.

5. Организатор образования с подролями (обычно эти подроли исполняет много людей-исполнителей):
-- стратег (чему и кого учим)
-- системный менеджер учебного процесса (операционная деятельность в образовательной программе)
-- архитектор обучающей организации со всеми вышеупомянутыми ролями (и обычный долг тут -- недокументированная архитектура)
-- управление оргизменениями и лидерство (и обычные долги тут -- развал управления конфигурацией, все работают с разными версиями материалов и полно коллизий, а также развал коммуникации в команде вышеописанных ролей, плохая работа исполнителей ролей, необученные исполнители)

Как бороться с этим учительским долгом? Если всё делать в рамках какой-нибудь heavyweight методологии из этих ваших академических университетов, то ни один курс, ни одна учебная программа из множества курсов (помним о тьюторстве) не взлетит -- так и умрут на стадии разработки, а на выходе будут не ученики, а те самые «учебные материалы» и «методики. Если делать всё agile/lightweight (что часто читается как «на коленке»), то долг будет нарастать с каждым шагом по проекту -- и это тоже не выход.

Выход в повышении производительности труда за счёт организации труда и использования IT, поднятии квалификации исполнителей всех этих ролей (их тоже нужно учить!), и росте осознанности (ибо для начала этот долг нужно осознавать, с неосознанным долгом ничего поделать уже нельзя). Но главный ход тут -- это использовать инженерные методы работы и организации разработки и обучения-как-эксплуатации по типу DevOps или SRE. EduOps (увы, нету, придётся сочинять) как одна из практик организации образования нам как раз поможет: именно там обсуждается разработка курсов и выкатывание их в «эксплуатацию» -- как организовать смычку в работе методологов, разработчиков курсов, преподавателей и тьюторов.

Тут можно было бы ещё больше приблизить рассуждение про образовательный проект к рассуждению про инженерный проект (инженерный подход/approach: использовать структуру типового инженерного проекта и состав его ролей в образовательном проекте -- без этих привычных внеролевых «завучей»), но пока и так достаточно важных моментов для отслеживания. Так что оставим уточнения на будущее.

Источник: блог А. Левенчука