Найти тему
LeColoboqueJournal

На день учителя: некогда праздновать, работать надо!

учеба
учеба

Вдруг все вспомнили, что день учителя. Хороший день объявлять, что курс про обучение таки переименован правильно – теперь это “2.5. Инженерия личности”, содержание пока не менялось. Инженер личности там как раз “учитель”, при этом дана разбивка на множество учительских ролей. И так же, как нет “инженера вообще” (но есть проектировщик, архитектор, технолог производства, инженер внутренней платформы разработки и т.д.), так и нет “учителя вообще”. Есть культуртрегер, методолог, методист, преподаватель (предметник и лидер), архитектор/составитель учебной программы, декан/администратор, тьютор и т.д. Месяц против названия “Инженерия личности” было много возражений. Теперь более менее понятно, что там внутри курса (остался раздел про клуб/сообщества практики, плюс примеры нестандартки), а идея “три инженерии подряд” не вызывает никаких возражений – и если добавить инженерию управляемого тела (делаем body control в системом фитнесе), то даже “четыре инженерии подряд”. При этом надо просто поглядеть, не займёт ли всё это вместе два семестра (второй и третий) вместо одного (второго).

Объявлены даты очередного “Системного фитнеса” (очный и онлайн варианты), не прозевайте, начало там уже через пару недель – Объявляется набор на курс «Системный фитнес», с преподавателем 1. Очень хотелось бы для этих потоков сделать очередной апдейт собственно курса в Aisystant, сейчас там вторая версия текста, а будет третья: материал должен быть переструктурирован по образу и подобию курса обычной инженерии, а также налажена работа с упражнениями. Как минимум, в новой версии станет понятно, для чего это всё и как использовать. Наши выпускники более-менее справляются с пониманием, но все остальные продолжают путать этот курс с “ещё одной гимнастикой, я их уже пять штук разных знаю – пилатес, фенделькрайз и бернштейн”. Нет, это образовательный курс (то есть курс усиления интеллекта), позволяет поднять телесный интеллект: то есть сделать мастерство, которое будет создавать практики работы в ситуациях телесной работы, о которых не знает ни разработчик курса, ни студент в момент прохождения курса. У нас есть лаборатория, которая занимается выпуском курса, так что после летних каникул оживим её работу.

Aisystant уже начал работать как организационный моделер ШСМ: регламенты запуска потоков оформлены в виде короткого курса, а также сделаны чеклисты для запуска потока. Прохождение этих чеклистов сотрудниками идёт как выполнение студентами домашних заданий по проекту, а администрация Школы наблюдает за ходом запуска потоков ровно так как преподы смотрят за работой студентов. Тем самым оргразвитие в ШСМ поддерживается универсальным моделером (проще вряд ли бывает, но что Aisystant позволяет создавать и заполнять таблички – это всегда там было), причём этот моделер заточен на освоение новых процессов “из коробки”, а также имеет для всех студентов и сотрудников школы привычный интерфейс: ровно тот, который используется для обучения студентов. Ещё через несколько дней планируется запуск этого дополнения не на тестовом, а на основном сервере Aisystant.

Окончательно приняты решения по утягиванию оргподдержки курсов из телеграма в клуб. это форумы/чаты/проекты/сообщества поддержки курсов, а не какие-то маркетинговые каналы, так что посторонние люди (сейчас туда любят зайти зеваки и поговорить о чём угодно, кроме материала поддерживаемого курса), свободный вход “с улицы” (им сейчас активно пользуются спамеры) не нужны. Но зато будет работать и AI-агент школы для поиска, и перегруппировка форумов поддержки при изменении набора курсов (вот как сейчас поддержка “инженерии личности” должна бы переехать из “Образования для образованных” в “Системный менеджмент и инженерию”), и автоматическое предложение стать участником форума поддержки в момент начала курса, и ещё много чего другого. И ещё сильно подняли в приоритете табличный моделер в составе Aisystant.

На методсовете в среду прошло обсуждение курсов по объяснениям и причинности: что требуется сделать в нашей основной программе, чтобы научить наших выпускников разговаривать с data scientists на современном языке. Ибо SoTA опять изменилась, а работы того же Pearl по лестнице причинности – это только маленькая часть того, что надо бы знать выпускнику. Основная идея там – это что-то аналогичное “семантике” с её семантическим треугольником, только данное конструктивно на чуть другом материале: есть измерения (физика) и есть модели (математика), они дают данные (“знаки”, дающие возможность записи на носителе для памяти и обработки), и есть две операции – (simbolic) discovery как моделирование и inference/запрос к модели (которая, получается generative, то есть умеет делать демоделирование/рендеринг состояния мира), и эти операции делает какой-то агент, которого лучше бы обсуждать явно. И дальше куча нюансов. Так вот причинность появляется там и тогда, когда измерения уже сделаны и надо разбираться с данными и моделями: поставить задачу для data scientist, который что-то там может посчитать (даже если этот data scientist – доброжелательный AI, говорящий на естественном языке). Но чтобы понимать общую картину мира про причинность и не отрываться от физичности происходящего, надо состыковать несколько разных курсов. Вот моя задача как научного руководителя – озаботиться, чтобы произошла такая состыковка.

Выложен новый текст десятого раздела в части собранности, там уже наполовину новая версия. А новая версия части моделирования будет сделана до конца октября. Так что к началу ноября курс “Моделирование и собранность” будет в новой версии. Большой вопрос у студентов там обычно про кортежи, ибо слишком много математиков и программистов, которые обычно игнорируют основную направленность курса: моделирование жизни, а не формальную работу с математическими структурами. Я советую (в чате поддержки курса это Telegram: Contact @modelcollect) раскрывать этот материал на базе обсуждения арности кортежей, которое сделал John Sowa в https://groups.google.com/g/ontology-summit/c/dkIXLHfMLUQ/m/NdBD5y_ZAwAJ:

the verbs buy and sell normally relate four things each: “A buys B from C for D dollars” and “C sells B to A for D dollars”.But each of those verbs that relate four things can be replaced by two verbs, each of which only relates three things: :“A gives B to C and C gives D dollars to A:”. That is an example of a tetradic relation that is replaced by two triadic relations Those two acts of giving may be separated by an arbitrarily long period of time.But the verb give has three obligatory participants, which must always be present in any act of giving.However, some people claim that a triple store which uses only dyadic relations is sufficient to represent anything. But that is true only under one condition: Some triads such as give can only be replaced by three dyadic relations if and only if each of the three dyads are never separated. They must occur in a single indivisible event.For example, “A gives B to C” my be replaced by three dyads and a monad: “Giving(X) and Agent(X,A) and Patient(X,B) and Recipient(X,C)”. In this translation of an obligatory triad to a monad and three dyads, the act of giving X has three parts that must occur at the same time… You can’t perform the different dyads in separable actions.I used the verb ‘give’ as an example of an obligatory triad: any act of giving must have three participants. The mapping to three dyadic relations is a purely syntactic transformation that replaces the verb “give” with a gerund ‘giving’ and three linguistic dyads. But the node labeled 'giving" (in any notation, linear or graphic) still has three links. If you delete any of those three, the semantics is incomplete.As another example, consider the sentence “I dropped the box on the floor”. The verb ‘drop’ happens to have three connections, but only two are obligatory. You can replace that sentence with two semantically complete sentences: “I dropped the box” and “the box landed on the floor.”In that example, each sentence, by itself, is syntactically and semantically complete. The verb ‘give’ is semantically an obligatory triad; there must always be three participants. But the verb ‘drop’ only requires two participants for a complete sentence. The verb ‘land’ only requires one – the sentence “The plane landed” only has one participant for the verb to make a syntactically and semantically complete sentence.C. S. Peirce observed that relations that express intentions (by humans or other sentient beings) require a third participant who has or had the intention that caused or explained the dyadic relation that links the other two.For example, an act of giving may be performed by sending a package in the mail. But the package is not gift unless it contains a card that explains why it was sent. That obligatory Thirdness is essential to show the intention.

Много думаю, что любое учительство начинать надо с установки студенту датчиков, чтобы он смог стать тренером самому себе. Скажем, надо учить агентности. Первым делом ставим датчик: вводим понятие и учим оценивать сначала чужую агентность, затем свою. И только потом можно давать какие-то операции, которые должны эту агентность менять. Или в танцах ты хочешь регулировать “жёсткость ведения”, что обычно вообще непонятно – что такое “жестить?”. Сначала калибруешь понимание веса/силы (в граммах, на кухонных весах). Затем учишься выдавать вес/силу рукой. Потом учишься определять, какой вес/силу выдали в тебя. И только потом можно начинать учить тому, как уменьшать усилие – и затем самому себе оценивать прогресс: “было нужно 350 грамм, а стало достаточно 50 грамм”. Если учишь выращивать помидоры, то ставишь датчик цвета – со значениями “красный” и “зелёный”. Калибруешь на реальных помидорах. Затем можно выращивать, рассуждая не о “зрелости” или “готовности к поеданию”, а о “красноте” и “зелёности”. Сначала вставить датчик на целевую характеристику, затем давать актуатор (чем можно влиять на показания датчика – моторчики), затем учиться управлять целевой величиной. В курсе “Инженерия личности” обсуждается, как трактовать специалиста, практика, мастера, реформатора по линии инженерии организации и линии инженерии личности. А какая у вас агентность? Поставьте себе датчик на собственную агентность! Я вот поставил, и сильно удивился – у меня она оказалась во многих сферах сильно ниже, чем могла бы быть. Но я понимаю, как её поднять.

Когда начинаешь обсуждать оргреформы в каком-то предприятии, то обязательно надо удерживать во внимании (всё это есть в курсах, но каждый раз приходится напоминать):
– обсуждение процесса инженерии (а не процесса оформления результатов инженерии!). Какие технические решения принимаются? Не какие документы разрабатываются и пересылаются! Не кто какой софт использует! А какие решения делаются, какими практиками! И начинать с концепции использования, то есть целевой системы в момент использования, и только потом переходить к концепции системы, и только затем к изготовлению. Функция ведёт конструкцию!
– чтобы не скатываться в обсуждение административных моментов, задаваться вопросом, есть ли в фирме инженеры. Обычно выясняется, что инженеров нет, а есть множество аналитиков, а решения принимают начальники. А процесс надо писать такой, как будто работают инженеры! Это огромная беда, но топ-менеджеры сразу её понимают – и говорят, что с инженерами будет трудно, ответственности они боятся и хотят быть “консультантами начальника” и не более, а начальникам тоже будет трудно – им придётся признать, что у них не сотрудники, а их советники. Нужна инженерная культура.
– обсуждать данные и модели, а также операции над ними, но не виды/классы софта и роли агентов (людей подразделений), которые эти операции делают. Ибо приписать потом виды софта и ролей к операциям – это пять минут на все. Но если писать сразу, то функциональное обсуждение будет заменено на конструктивное (вместо видов софта будут подставлены конкретные имеющиеся уже софтины, и планировать их будет далее невозможно), а вместо ролей будут какие-нибудь должности или даже конкретные люди или подразделения в их нынешнем наполнении, планировать что-то будет невозможно.
– вопрос об увеличении скорости отвечается двояко: 1. если культура “советования начальникам”, то будет каскадирование задач, а это всегда дико медленно, а роль архитектора остаётся в тумане, а должна быть явно. Поэтому обсуждаем нормальный инженерный процесс, а не административный. Инженеры принимают решения, согласовывая свои работы с другими инженерами, а не советники дают советы тем, кто вместо них примет решение и поможет согласовать от их имени. Испорченный телефон не нужен. 2. Сейчас в конце дня у инженеров-начальников может скапливаться до 200 документов на рассмотрение. Если мы будем не выкидывать лишнее сначала, а просто ускорять (скажем, поставим электронный документооборот вместо бумажного, ибо все же только “за”?), то всё остановится: у инженеров начальников в конце дня будет при ускорении втрое 600 документов на рассмотрении, и они вымрут. Мы же не этого хотим? Вот и не надо ускоряться и переходить на электронный документооборот. Надо сначала понять, какой должен быть процесс и затрагиваемые им модели, а потом только обсуждать “цифровизацию” или что там будет.
– принятые орг-решения надо принимать всерьёз. То есть при отсутствии внятных возражений разработчикам программ оргазвития надо просто брать, и реализовывать все запланированные изменения, в режиме ошпаренной кошки. Обычно такие команды состоят из топ-менеджеров. Вот они должны обсудить оргизменения, а затем провести их своими распоряжениями, а не считать, что это каскадирование, и они должны “доложить о планах, чтобы потом коллективно принять решение об изменениях, после всестороннего рассуждения”. Нет, всё не так. Организация тут ничем не отличается от целевой системы: если решили, что диаметр фланца будет не 100мм, а 120мм, то это обычно отражается в проекте немедленно, а затем так и изготавливается. Вот так же надо и с организацией: если решили, что создаётся какое-то оргзвено, то приказ о создании должен выйти в тот же день. Нечего откладывать, поручать принятие решений каким-то специально обученным людям, которые как председатель Фунт согласен “сидеть”, но которые ничего не понимают в обсуждаемом проекте. А кто понимает, те не хотят “сидеть”, а при принятии решений хотят “отсидеться”. Нет, инженерия и менеджмент требуют агентности. Не просто понимать свой domain (специалист), не просто договориться о своём вкладе в проект, “договориться со всеми” (практик), но и договорить всех (мастер).
– тормозить разговор о софте до последнего. А потом предлагать самый простой софт, а не самый навороченный. И всё будет работать!
– сразу запускать обучение топ-менеджмента по программе “Организационное развитие”. Через 8 месяцев (пара семестров) это будет очень крутая команда, которую нигде не купишь. Там две выгоды: 1. каждый конкретный член менеджерской и инженерной команды станет умней (программа усиливает интеллект её проходящих, и не в столицах это может быть критичным, ибо “людей нет, совсем нет, и взять неоткуда”), будет много меньше ошибок в мышлении 2. При принятии коллективных менеджерских и инженерных решений обсуждения будут идти быстро, ибо коммуникация будет только о важном и с использованием компактного языка очень высокого уровня абстракции (мета-мета-модель).
– … и такого много, в наших курсах всё это есть, но каждый раз приходится начинать разговор с самого начала.

Как художник представляет себе учителя, празднующего свой профессиональный праздник. И то верно: некогда праздновать, работать надо!

#познавательное

#интересное

#учитель
#учеба
#системное мышление

#левенчук