Обсуждали на методсовете МИМ названия наших программ и основные в них форматы определяются локусом изменения (мастерство изменения чего на выходе), что надо предъявить по завершению (демонстрация мастерства с пакетом evidence/свидетельств, ибо без этих evidence остаются “разговоры об успехе”), насколько упаковано знание:
– программа личного развития, которая основным форматом имеет тренинг, результат тут в изменении себя, любимого и мастерстве себя менять, единолично.
– программа рабочего развития, в которой основным форматом является резидентура, результат тут - изменения вовне себя и мастерство делать изменения вовне себя в коллективном проекте.
– программа исследовательского развития, в которой основной формат – семинар, там переносится знание из головы в голову, стандартизовать “что тут результат” трудно (в качестве результата ожидается понимание, из которого следует затем “всё хорошее против всего плохого”, но контрактовать “понимание” обычно нельзя, поэтому обсуждаются разные proxy - возможности репликации, в том числе воспроизводимости аргументации, воспроизводимости результатов, идей по применению в проектах. С FPF мы именно так и делали – вот семинар, а вот файл FPF, бери да пользуйся. И то же с семинарами по руководствам: вот тебе про руководства рассказали, а вот само руководство – бери да пробуй по ним работать. И это – работает!).
Ещё выяснили, что вне тусовки МИМ плохо понимается разница между тренингом, стажировкой и резидентурой:
– тренинг: работаете над собой, вместо работы – упражнения и тренировки в контролируемой среде, важна повторяемость. Тренинги у нас в программе личного развития.
– стажировка: мы пытались говорить о стажировках примерно полгода, но выяснилось, что стажировок в классическом смысле слова у нас нет: во всех программах инженеры-менеджеры работают не над нашими проектами, а над своими проектами. И вот это “над своим проектом” нас и отличает от всех стажировок, которых два разных формата: internship-as-employment: “чужой проект, часы/ставка, роль в оргструктуре” и internship-as-apprenticeship: “учусь, делая порученное, под наставником, с постепенным усложнением задач; артефакты важнее часов”, но это всё-таки с чужим проектом, а в МИМ – с рабочим, с основной своей работы по найму или даже работы в собственном бизнесе, и это не стажировка. Internship предполагает host organization как владельца задаваемых работ (пусть даже “learning-as-apprenticeship”). MIM residency предполагает learner-owned работу + задаваемую host organization дисциплину и оценивание.
– резидентура: работаете над своим проектом по местному регламенту (у нас это – руководства), начальника нет, но есть наставник и ритм разборов/review. На выходе какие-то заранее оговорённые результаты (в МИМе мы предпочитаем говорить “шедевр”). Сейчас у нас программа рабочего развития включает десяток тематических проектных резидентур по полтора месяца каждая. Это apprenticeship, но на своём проекте, поэтому и не “стажировка”, не даём ложных ожиданий. Ещё раз: Residency (MIM) = apprenticeship на собственном рабочем проекте + внешняя дисциплина руководств + ритм review + контрактуемый deliverable. Так понятней? Можно ещё отстроиться от “стажировки” типа ординатур у медиков (ибо все LLM тут же приплетают эту ординатуру, а не резидентуры в бизнес-акселераторах): (guided) project/work residency, выбрать сочетание по вкусу.
– семинар: нет руководств, обязательств менять что-то в проекте, но есть новинки мышления, которые ещё толком нигде не опубликованы, не объяснены, руководств нет, поэтому тренинги, стажировки, резидентуры невозможны. Но можно попробовать объяснить, что нового получено, почему это важно и что с этим можно делать дальше.
Ужимаем эти два больших абзаца и переводим на английский (это будет ещё короче!):
– Personal development / Training: change target = individual capability; setting = controlled practice; work unit = drills; evidence = performance traces on standardized tasks.
– Work development / Project residency: change target = a real project/system; setting = operational; work unit = increments; evidence = deliverable + operational traces + review/entrustment decisions.
– Research development / Working seminar: change target = shared epistemic state; setting = open-ended inquiry; work unit = epistemic moves; evidence = knowledge artifacts + critique/replication traces (minimal).
Если всё это обобщить, то все наши и не наши программы и форматы становятся какими-то точками в пространстве характеристик “внешне обеспечиваемого развития” (externally scaffolded development, structured development with accountability). Это легко разворачивается в “канву развития”, генератор форматов развития (обучение тут только часть развития) в каком-то “акселераторе” (МИМ тут как раз такой “ускоритель развития”) – по мотивам businessmodelgenerator и lean canvas, только для форматов развития. Обязательно для EduTech, вариантов будет тьма, фишка в мышлении при заполнении полей для вашей конкретной фирмы:
– Кого меняем: один человек или LLM (легко! у нас ведь есть FPF), команда (корпоративный формат), что-то в проекте, …
– Мастерство: в чём, собственно, развитие. В том числе “в чём дельта: каков ожидается прирост”.
– Единица работы: упражнение, поручение начальника, исследовательский ход, кейс-разбор, …
– Упаковка знания: tacit (ни разу не explicit, то есть “не упаковано”), руководства, тренажёры, эталонные результаты работы (шедевры прошлого), тесты, …
– Роли и власть: начальник есть/нет; наставник; кто принимает результат; кто задаёт ограничения (в МФТИ их там множество: преподы, наставник/ментор, куратор на предприятии, научный руководитель), …
– Проект: нет, свой, “с моей работы”, выданный учебный, выданный производственный, …
– Наблюдаемые следы (что проверят на выходе, это же конструкционизм, внутрь головы не заглянешь, нужны свидетельства): отработанные часы, шедевр, факт живой демонстрации мастерства, …
– Протокол свидетельствования успеха на входе (обязательно!), в процессе (reviews, “обратная связь”) и на выходе: кто замеряет, какая процедура, в какой момент (ритм! частота замеров!), кому жаловаться на необъективность замера, сколько попыток демонстрации результатов, (и тут можно договориться до Entrustable Professional Activities, и прочих Федеральных Образовательных Стандартов, но мы в эту сторону двигаться не будем, хотя формат canvas всё стерпит) …
– Затраты ресурсов и риски, IP и NDA: ритм (challenges как раз тут!), уровень риска (что будет в случае ошибки и какие вообще классы ошибок допустимы), степень автономии резидента (что можно делать без разрешения, а что нельзя), кто владеет артефактами и можно ли рассказывать о происходящем (NDA), цена: без проговаривания этого набора характеристик не продать.
– Инфраструктура: что из ресурсов надо, чтобы “всё происходило” (инструменты, помещения, IT-системы и т.д.).
– … попросите вашу любимую LLM, чтобы она кастомизировала этот список и вписала туда что-то, что подходит вам и/или вашему предприятию.
Каждая фирма хочет развивать своих сотрудников, просто МИМ берёт это развитие на аутсорс. Аутсорсится формат (конкретная точка МИМ в пространстве характеристик предыдущего абзаца), но не весь (скажем, проект как раз не аутсорсится, он внешний для МИМ). Назвать красиво, Employee Development as a Service, EDaaS, для HR/L&D можно и позаковырестей, Employee Learning & Development as a Service, L&DaaS, чтобы точно прочли и прониклись, но лучше это “learning and” опускать, ибо в наших резидентурах проектные изменения, а не обучение. Но можно и не опускать, ибо с рынком не поспоришь, а мы слишком мелкие, чтобы его переделывать. Можно вести два разговора на двух языках:
– внешний язык “Work-based L&D with measurable project deliverable/capstone/demonstrable project outcome". Привет всем корпоративным заказчикам обучения и развития (L&D) своих сотрудников: вы хочите программ развития, их есть у нас.
– внутренний язык рабочего развития (внутреннее и исследовательское не по этой корпоративной линии), то есть резидентуры, шедевры, руководства и всё прочее.
На лаборатории по первым четырём резидентурам обсуждали путаницу с упражнениями по поводу нахождения “вещи”: там спутались три аспекта (физическая вещь, какая-то система в её отличии от эпистем, свойств, процессов и т.д., а также целевая система как “главная координата”). Решение: таки вводить понятия холона, эпистемы, системы поближе к началу программы рабочего развития. Ещё обсуждали как проверять уверенные различения, ибо мы разрешаем пользоваться FPF - но затем у наставников уходит по шесть часов на то, чтобы проверить легко сгенерированные (а не трудно написанные) резидентами тексты по своим рабочим ситуациям. Конечно, проверять тоже надо с помощью FPF - задавать а) точный формат сдачи, что очень проблематично, б) точные промпты проверки. Я в качестве такого “проверяющего промпта” предложил поглядеть паттерн E.19 в FPF, а формат сдачи результата надо будет доработать (впрочем, там сейчас “заполнить таблички” в основном, это уже довольно много по линии упрощения проверки). Ну, и надо поглядеть ещё на форматы сдачи, чтобы оценивать не текст на килограммы, а мысль на наличие структуры и точности. Работа по перенарезке “Рациональной работы” на четыре новых руководства кипит - старт резидентур новой линии уже 13 января.
Я согласился со всеми, что буду заниматься FPF в ближайшее время, а руководства свои пока не буду трогать. Это не означает, что текущие (свежие! 2025 года большинство из них!) руководства уже уволены, наоборот: без них шансы разобраться с FPF довольно призрачны, это не “попсовый продукт из трёх промптов и пяти шаблонов – только добавь локальную LLM и всё заработает”. Нет, всё заработает, но только в умелых руках. Как говорится, “из той же мучки, да не те ручки” – так и с FPF у кого-то получается лучше, а у кого-то вопросы даже к тому, зачем он вообще нужен. Напомню картинку, из которой ясно читается “руководства+FPF”, а не “FPF вместо руководств” (это было в одном из семинаров):
