8. Практика администрирования обучения

Администрирование обучения как инженерия обучающей платформы

В системной инженерии есть роль инженера внутренней платформы разработки (подробней это рассказывается в курсе «Системная инженерия»). В системном менеджменте ей соответствует роль администратора (подробней это рассказывается в курсе «Системный менеджмент»). В инженерии личности/практике обучения это администрирование обучения, выполняет эту практику обычно деканат/учебная часть/администратор.

Как обычно в случае администрирования, задача инженеров платформы — создать и развивать внутреннюю обучающую платформу, как «холодную тёмную фабрику» из LXP и преподавателей (возможно, живых, но возможно и AI-агентов), получающую на входе абитуриентов, проводящую по «конвейеру» студентов и выдающую на выходе мастеров.

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

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

• Собственно платформу LXP как систему развития ученика (система-создатель целевой системы), а именно LXP (learning experience platform) со включением туда живых «рабочих на станках» (преподавателей), если они оказываются нужны.

• Команда инженерии LXP. Стратегирует, проектирует, разворачивает на серверах и поддерживает/operations LXP, включая найм и дообучение пула преподавателей как частей LXP. Тут может быть и поддержка CAD/CAM (моделеры для методологов и методистов, подготовка учебных и методических материалов), и подержка собственно ведения учебного процесса (ведение занятий), чаще всего это поддержка blended learning/смешанного человеко-компьютерного обучения (поддержка софтом интерфейсов студентов, преподавателей, администраторов).

Отдельно надо смотреть команду организаторов проекта обучения, эта команда должна сорганизовать как авторов учебных программ, так и команду инженерии LXP, а потом ещё и группу продвижения, а также учесть оргзвенья для ведения работ по привлечению инвестуры (пула инвесторов) и абитуры (пула абитуриентов — просвещение, маркетинг), плюс сюда же клубная работа (по поддержанию сообщества практики).

Интеллект студента как «выносная часть LXP»

В какой-то мере интеллект (мыслительное мастерство) можно рассматривать как часть LXP. Как об этом думать «инженерно»? Надо просто вспомнить, что интеллект (включая вменяемость, как способность изменить поведение агента на основе предоставленных рациональных аргументов) своей главной функцией имеет cognition/познание/learning/обучение, на входе получая проблему с неизвестной практикой её решения, а на выходе выдавая какое-то прикладное мастерство в практике решения уже не проблемы, а задачи какого-то класса. Так что рассматривать проект обучения можно двояко:

• Учительская команда учит студента, как «пассивную нейросетку».

• Личность студента самообучается (часть «интеллект» строит в личности часть «новое прикладное мастерство», или даже развивает какое-то мыслительное мастерство в составе того же интеллекта), взаимодействуя с учительской командой непосредственно (агент-агентское взаимодействие в диалоге) или опосредованно через тексты учебных материалов (или даже не тексты, а интерактивные модели и тренажёры, находящиеся в учебных материалах).

Это означает, что мы имеем два варианта curriculum learning (последовательности обучения):

• Берём прикладной курс и «дрессируем» нейросеть студента на базе уже имеющегося интеллекта студента (скажем, умеет читать-писать, и больше ничего).

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

Так что в долгосрочном периоде выгодным оказывается развернуть в студенте мыслительное мастерство по-максимуму, а затем по-быстрому обучить его прикладным практикам, особенно, если прикладных практик ожидается много.

Это очень условно соответствует тому, как учат студентов-инженеров: все они получают абсолютно неприкладной четырёхсеместровый курс матана (проходится один раз), а затем знание высшей математики используется студентами в самых разных прикладных курсах.

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

Для какой-то инженерии мы можем сказать, что речь идёт о некотором стеке практик, где нижние (относительно фундаментальные) практики стека представляют собой платформу для верхних (относительно прикладных) практик. Например, можно рассмотреть инженерию телесного интеллекта (курс «Системный фитнес») как обучение мастерству решать различные непредвиденные проблемы, появляющиеся перед двигающимся телом. А затем много быстрее будет осваиваться и бокс, и фигурное катание, и танцевание, и даже многочасовое сидение перед компьютером так, чтобы после этого ничего не болело, не затекало, не отсиживалось.

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

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

Обучающая платформа в поддержке организационного моделирования

Если модели с чеклистами в универсальных моделерах — это корпоративные чеклисты (где по Atul Gawande приводится только самое важное, а нюансы все остаются в учебнике), то корпоративные регламенты — это те самые учебники, из которых ясны все нюансы. Так что можно брать Aisystant, и говорить, что это и есть «интранет предприятия с регламентами». В курсах Aisystant «домашки с моделированием рабочих проектов» это и есть работа с чеклистами, в которых только самое важное без нюансов, а «учебники» этих курсов — это регламенты с нюансами метода. И заодно в «клубе» получаешь поддержку communities of practice для практикующих метод, описанный регламентом. С одной стороны, Aisystant — это универсальный табличный моделер с AI, поддерживающий инженерное и организационное, а также личное моделирование, где курсы используются как «help для набора типов мета-мета-модели к табличкам в моделере». С другой стороны, Aisystant — это LXP с набором курсов, поддерживающий документирование методологом результатов моделирования процессов/практик/деятельностей/стилей/методов работы в формате регламентов с поддержкой моделирования альф в формате домашних заданий. Просто выпячиваем роль регламента для практик «объяснить новому сотруднику, что ему надо делать» и «дать справку по тому, как надо делать в случае разногласия между уже имеющимися сотрудниками» по сравнению с регламентами для «понять, как лучше обвинить напортачившего сотрудника». И всё, Aisystant готов быть таким интранетом уже прямо сейчас. Там даже студенческие группы — это группы сотрудников, которые следуют тому или иному регламенту, а препод — ответственный по связи сотрудников с авторами регламентов.

Итак, регламенты — это «справочники» (результат работы методолога), но там может поработать и методист. Обсуждение идёт текстом, самая неформальная модель. Этот регламент должен, как и материал любого курса, улечься в голове нового сотрудника как ожидаемое от него на работе мастерство. Табличное моделирование альф, проводимое в ходе организационного моделирования — это более формальная модель: там более строгое присвоение типа и убраны все нюансы, они останутся только в регламенте. Это оргмоделирование проводится прямо в ходе работы над созданием регламента. Регламент и «домашние задания» в виде заданий на отражение состояния альф как раз и будут «содержанием курса». Обсуждение проблем моделирования — это «клуб», он устроен как набор «форумов»: там обсуждается как разработка самого курса/регламента или учебной программы/распорядительной документации предприятия (время оргмоделирования/методработы), так и выполнение «домашек»/работа сотрудников над их рабочими проектами (время целевой работы). А «начальники» — это преподаватели, они присматривают, чтобы сотрудники/студенты не «сачковали» (мотивация/лидерство), решают проблемы непонимания (предметные эксперты). Старшие студенты и AI выполняют работу преподавателей, оценивают результаты работ.

Тем самым Aisystant получается ещё и софтом поддержки проектов оргразвития, его можно считать как LXP, так и организационным моделером. Это буквальное рассмотрение поминаемой Peter Senge идеи Learning organization¹, где один из вариантов айтишной поддержки — это объединить орг-моделер с LXP. Это будет работать, потому как люди в организации должны будут научиться следовать регламентам и отслеживать состояние альф своих рабочих проектов — и мы сразу попадаем в ситуацию проекта обучения, и в этом проекте нам нужна поддержка со стороны обучающей платформы.

Возьмём для примера курс системного менеджмента, в котором даётся операционное управление как обобщённая подпрактика менеджерского труда. Это только один из разделов курса, но в курсе говорится о том, что есть многочисленные практики проектного, программного, процессного управления, управления кейсами. Все эти практики базируются на некотором наборе знаний из самых разных дисциплин, которые собраны в книгах Steve Tendon по подходу TameFlow², а также в книге Donald G. Reinertsen «The Principles of Product Development Flow: Second Generation Lean Product Development»³. Далее предлагается прочесть книгу для знакомства с этими принципами.

Но простое прочтение «Учебника по езде на велосипеде» не даёт умения ездить на велосипеде! Книжки Tendon и Reinertsen сделали одно очень важное дело: дала результат методологической работы — собрала под одной обложкой знания, которым нужно научить: типы объектов внимания, которые нужно найти в жизни (мета-модель предметной области) и необходимые операции с объектами этих типов. Donald Reinertsen — это актёр, выполнивший роль методолога.

Чтобы гарантированно воспользоваться этими знаниями, нужно развернуть эту книжку с результатом методологической работы в курс:

• Найти способы объяснения, вставить их в текст

• Определить новичковые ошибки, типичные для данного материала, вставить их в текст

• Добавить «рабочую тетрадь» с заданиями

• Обеспечить курс с рабочей тетрадью в варианте онлайн-курса, чтобы можно было отслеживать прогресс прохождения, проверять выполнение заданий.

• Разработать методические материалы для преподавателей или инструкторов.

Но и этого мало. Нужно теперь под присмотром преподавателя решить несколько задач на производстве: находить нужные объекты внимания (для этого моделировать не только в Aisystant, но в принятой на производстве среде моделирования, например, в coda.io или notion.so, или аналогичной, а иногда даже в Excel-таблицах), выполнять необходимые расчёты (операционный менеджмент опирается на вполне определённые формулы, по которым нужно уметь делать вычисления — научиться находить данные для этих расчётов в реальном мире!), а затем менять мир вокруг себя на основе этих расчётов (задействовать какие-то технологии). Это требует преподавательской квалификации предметника, который будет разбирать поведение студента в реальном проекте.

Если речь идёт об учебной группе, то там появляется дополнительная польза от групповой работы: группа активно обсуждает проблемы проектов друг друга, при этом происходит domain randomization и задействование COIN (context inference): разные условия применения знания приводят к универсализации знания, студент лучше начинает понимать, что из знаний является общим, а что зависит от конкретных условий конкретной ситуации, конкретного проекта, а также надёжней вспоминает о возможной применимости материала курса к его конкретной ситуации. В учебной группе могут быть рассмотрены несколько самых разных вариантов применения знания за буквально одно занятие, это существенно ускоряет обучение. Но в отличие от ментора-предметника, который просто указывает студенту на его ошибки и подсказывает те материалы курса, которые он должен использовать в случае затруднений, групповое обсуждение требует новой квалификации, лидера: преподаватель следит за так называемой групповой динамикой (студенты в группе проявляют очень разную активность в обучении, в группе может возникать атмосфера враждебности, равно как и взаимопомощи) и мотивирует студентов, это подроль лидера. Преподаватель-лидер соединяет участников обучения как актёров с их ролью студента, занимается их мотивацией, а в групповой работе ещё и модерацией (то есть утихомиривает излишне активных, поощряет к участию излишне пассивных). Вторая подроль преподавателя — это уже знакомая по инструктору роль предметника, специалиста по изучаемой практике, указывающего на ошибки и подсказывающего, каким фрагментом знания нужно пользоваться в той или иной ситуации. Преподаватель-предметник должен знать предмет в достаточной степени, чтобы легко ориентироваться в десятке самых разных проектных ситуаций, которые дают ему студенты, легко переключаться с ситуации на ситуацию — и удерживать коммуникацию между студентами на мета-языке, в котором эти ситуации выглядят похожими.

Потом надо организовать и администрировать учебную программу: договориться о том, кто, когда, как, за сколько, у кого будет учиться, разместить учебный материал в Aisystant, сформировать учебную группу, назначить исполняющих роли преподавателей. А потом учить: предоставлять студентам доступ к Aisystant, а также следить за тем, чтобы выполнялись роли предментика (например, AI-ботом, отвечающим на вопросы в чате поддержки курса) и лидера в учебной группе.

Ситуация сложней, если речь идёт о русскоязычном курсе, а исходная работа доступна только по-английски. В этом случае нужно выполнить часть методологической и методической работы, связанной с переводом.

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

Интеллект нужен для того, чтобы работать с целевой практикой, которой нужно обучать: обсуждать объекты внимания в дисциплине этой практики, а также обсуждать технологии, поддерживающие дисциплину этой практики. Интеллекта (мастерства в практиках интеллект-стека) должно для этого хватать, поэтому методологическая работа будет точнее и быстрее, методическая работа тоже точнее и быстрее, преподавание точнее и быстрее, а если интеллект будет достаточным и у студентов, то само обучение будет тоже точнее и быстрее. Вот что пишет⁴ на эту тему выпускник ШСМ Михаил Гусаров:

После обучения в ШСМ становится ясно, что большая часть доступных прикладных курсов — мусор.

Составители прикладных курсов не рассчитывают на наличие у студентов знания трансдициплин, кругозора и умения собранности, а также пререквизитов, в результате чего часто наблюдаются следующие явления:

• Требуемые куски трансдициплины либо вставляются в прикладной курс, откуда их приходится выбрасывать при изучении (хорошо ещё, если эти трансдициплины не устаревшие), либо игнорируются и прикладное знание даётся без связи с трансдисциплинами.

• Полезные и тривиальные для хорошо владеющего материалом, но неочевидные для его изучающих кругозорные обобщения пропускаются.

• Курсы форсируют собранность обучаемых через сдачу заданий и привязку ко времени. В самых запущенных случаях приходится сдавать экзамены по кускам устаревших трансдисциплин, включенным в курс.

• Курсы включают в себя куски других курсов, требуемые для освоения материала, а также экзамены по ним.

Это вдобавок к тому, что сама прикладная часть может оказаться некачественной.

Примеры:

• Курс Coursera «Programming in R» экзаменует учащегося по истории (месту создания языка R) и юриспруденции (основам лицензий свободного ПО).

• Курс «Human-Centered Design» половину времени рассказывает про конкретную прикладную практику сбора требований.

Поэтому при переходе от методологической части (чему учить) к методической (как учить) нужно ориентироваться на интеллект-студента. Желательно поднять этот интеллект, и учить прикладным дисциплинам после этого. Если у студента есть достаточная сила интеллекта, то можно аннотировать в примерах ситуаций важные объекты их типами, можно указывать на связи разных практик друг с другом, можно исключать общеобразовательные куски (ибо они же уже освоены, образование — это ведь и есть усиление интеллекта студентов!), можно в заданиях полноценно задействовать современное мета-моделирование и моделирование, можно избегать ошибок преподавания, заложенных в исходный материал. Например, если в исходном материале (например, англоязычных стандартах или статьях, или даже учебниках) есть определения терминов, то можно не опираться на тамошние определения терминов, ибо значения понятий не даются через определения, а задаются их употреблением в текстах — важно обеспечить достаточное количество текста с употреблением предлагаемых понятий, а не просто привести «словарное определение», которое окажет медвежью услугу: студент будет считать, что ему всё с этим определением понятно, а в жизни окажется, что совсем не так и «есть нюансы».

Как это всё работает вместе

Как работает вместе команда разработчиков курса и преподавателей, а также организаторы образования, которые берут на себя менеджерскую сторону вопроса и инфраструктурную поддержку как разработки, так и преподавания? Ответ тут простой: подход, аналогичный DevOps или его более свежий аналог SRE (site reliability engineering) из программной инженерии, или даже ещё более современный подход platform engineering с опорой на LXP.

Так, учебные материалы нужно прямо ассоциировать с программным обеспечением, и сразу понимать, что к курсам относятся основные принципы современной agile-разработки:

• Любая версия учебных материалов не является последней, контроль конфигурации важен

• Release early, release often

• Авторы учебной программы должны понимать, что происходит в ходе как эксплуатации мастерства студента (учебные материалы описывают практику так, как она выглядит в момент эксплуатации/использования), так и в ходе преподавания (методические материалы описывают, как создавать мастерство какой-то практики), то есть глубоко знать как целевую практику, которой обучают (целевой метод работы/методологию), так и практику самого обучения (методику/метод обучения).

• Разработка не следует строгим стадиям «передачи полной проверенной версии без возможности вернуться и что-то доделать» (то есть водопадной/каскадной модели), когда культуртрегер что-то передаёт методологу, методолог потом передаёт методисту, методист потом отдаёт преподавателям. Нет, это «параллельная инженерия»: все работы идут по факту «одновременно», но поддерживается строгая дисциплина управления конфигурацией и командная коммуникация на предмет отслеживания потенциальных конфликтов конфигурации.

• Максимальная автоматизация (вплоть до NoOps) на стадии эксплуатации (исключение людей в преподавании, исключение людей в замене содержания курсов на серверах LXP).

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

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

Масштабирование обучения целевому мастерству серьёзно зависит от вот этого обучения авторов курса и администрации/деканата, а также организующих их менеджеров. Если эти команды не готовить специально, не учить их, то из каждых 100 человек, которые прошли обучение, будет «органически» появляться один человек, который потом будет помогать разрабатывать новые курсы, преподавать, организовывать обучение (работать в деканате). А если учить специально, то таких людей из каждой сотни будет 10 человек, и они помогут выучить или вдесятеро больше выпускников, или обеспечить индивидуализацию обучения такую, что выпускники будут «изготавливаться» более качественно.

Главное тут — это понимать, что основная работа над учебной программой только начинается после начала преподавания для первых студентов. Самая большая ошибка тут считать, что выход первой версии учебных материалов означает конец разработки и начало долгого преподавания. Нет, как и в случае разработки софта, «выход в продакшн» означает только момент, когда опираться можно не столько на часто оторванные от жизни ожидания разработчиков, сколько на реальное поведение студентов в ходе курса, реальные оценки того, насколько удаётся научить студентов, и это повод для активных изменений в курсе.

Ещё нужно помнить, что SoTA мастерства меняется, и это тоже повод для изменений в содержании учебных материалов. Так что начало преподавания — это важный момент в долгом проекте обучения, но никак не окончание стадии разработки из «водопадной модели», никак не закрытие разработки. Обучение — это сервис, а обучающая платформа с размещёнными на ней учебными материалами не является однократно проектируемым, изготавливаемым и затем вечно эксплуатирующимся в одной версии продуктом. Нет, никакого каскада/водопада с его «сделали, отдали, забыли». Нет, в проекте обучения непрерывно развивается деканатом обучающая платформа (на серверах и в головах студентов), авторскими командами материалы учебных программ, «развивающимися» само мастерство в их личностях. Непрерывное всё.