2019

lytdybr

Завтра веду "Машинный интеллект" (https://system-school.ru/machine), опять переделывал слайды -- там ведь продолжаются по два прорыва в неделю. Мои мысли в последнюю неделю довольно плотно занимает текст François Chollet "On the Measure of Intelligence", last revised 25 Nov 2019, https://arxiv.org/abs/1911.01547. Текст задаёт какой-то набор понятий (framework) по сравнению AI и человеческого интеллекта, при этом позволяет начинать осторожно говорить об AGI без немедленного прихода любителей порассуждать о SkyNet, "роботы заменят людей" и прочих робо-апокалипсисах. Мы продолжаем говорить про интеллект в терминах решения задач, не переходя на личности (pun intended), то есть не втягивая в разговор "сознание", "свободу воли" и прочие сомнительные конструкты. И это не единственная работа, из-за которой пришлось менять слайды.

John Sowa жжёт в ответ на реплику Jack Ring в Ontolog Forum (https://groups.google.com/d/msgid/ontology-summit/910a0b7fca29e91e0401a15c43659778.squirrel%40webmail2.bestweb.net):
Jack R> The only way to resolve different perspectives is through dialog.

I certainly agree. For interoperability among independently developed and developing systems, there must be a dialog among all the people and groups of people who need to collaborate and cooperate.

That implies several points: (1) The best language(s) for carrying on a dialog are our familiar natural languages. (2) The main reason why NLs are so useful is that their words and patterns of words are flexible -- they can shift their meanings and patterns of meanings to adapt to any imaginable situations. (3) After various parties to the dialog have reached agreement, the informal NL can be formalized in a precisely defined language (natural or artificial) in which the details are specified to whatever degree of precision is appropriate for interoperation.

Note that precision is only achieved *after* a lengthy process of design, analysis, discussion, refinement, negotiation, and agreement. The degree of precision is determined by the nature of the applications and the problems that must be solved during the design and development process.

This is another reason why a precise, rigidly specified top-level ontology is a terrible starting point for independently developed, but interoperating systems. But it also explains why precisely defined mid-level ontologies (AKA microtheories) are valuable for the various components within a single project or family of projects. The precise ontology determines a silo for a single purpose. But interoperability among silos requires a looser overall framework.
John

А вот ещё про динамические онтологии:

In fhe Ontology Summit telecon last week, there was some talk about the dynamic nature of knowledge graphs. It implies that the subject matter described by typical KGs is constantly changing. That makes it impossible to have a fixed schema -- no fixed, completely specified formal ontology.

I made the point that natural languages have a similar nature. In a typical dialog or debate, people have different points of view. They sometimes agree, sometimes disagree. They ask questions. They may revise, clarify, or change their opinions. Sometimes there may be more points of view than there are participants in the discussion. Whether or not they agree on a final outcome, the senses of many words and phrases may change during the discussion.

This afternoon, I received an anouncement of a new journal that will be devoted to this topic: "Interactional Linguistics". Its goal is to analyze evidence of "language as locally contingent, temporal, and ever-adaptive."

The reason why language changes dynamically is that it expresses the dynamic interactions among the people who use it.

But some uses of language are static, and they can be translated to some version of formal logic. For example, consider the owner's manual for your car. That is a static description of a finished product. It's possible to specify a fixed ontology for all the parts, their interconnections, and their functions during the operation of the car. But cars from different manufacturers or from the same manufacturer in different years will require ontologies with different definitions for many of the same terms.

In fact, automobile designs undergo a major revolution every 20 years. Just compare the horseless carriages of 1900 and the Model T Fords of the 1920s. In the 1980s, no cars had computers. But by 2000, they all had multiple computers. Today, you can see Teslas going down the highway with the so-called driver sound asleep. Just imagine the cars of the 2040s. Any ontology for cars would require a major revision every 5 years.
John

Там дальше было описание журнала интерактивной лингвистики, но оно не так интересно. Потом Джон в ответе на реплику Matthew West написал про dynamic theory of ontology:

JFS> the dynamic nature of knowledge graphs... implies that the subject matter described by typical KGs is constantly changing. That makes it impossible to have a fixed schema -- no fixed, completely specified formal ontology.

MW> No it doesn't. It just means your schema needs to take change into account and be extensible.

We agree in principle, but the time scale makes an enormous difference in practice. If the time scale is measured in years or months (as in the example about cars), it's possible to update the ontology on a rgular basis. But when the time scale is measured in seconds (as in a discussion among two or more people), the practical problems require a major change in strategy.

Anybody who took a course in philosophy probably read a couple of dialogs by Plato. In each one, Socrates asks leading questions that cause the other participants to make major changes in their ontology from one sentence to the next. For another example, just listen to any telecon for the Ontology Summit.

For more about interactional linguistics, see the Wikipedia article and the references cited there: https://en.wikipedia.org/wiki/Interactional_linguistics

That article distinguishes written languge (the source data for most theories of language) from rapidly changing perspectives in any dialog among two or more people. But similar changes occur from one article to the next on every subject -- ranging from scientific publications to news stories to political commentary.

Articles on the same subject by different authors or by the same author in response to the others will have different senses for the same words and phrases. Any task that requires an analysis and comparison of multiple inputs from different sources must accommodate changes in the ontology for each text (including each text message or tweet).

These comments don't mean that formal ontologies are impossible, but they must accommodate an open-ended system of microtheories. And the choice of which microtheory to use at any moment must take the context into account. See "A dynamic theory of ontology", http://jfsowa.com/pubs/dynonto.pdf .
John
Поскольку у нас в курсе онтологики много про коммуникацию, нам нужно как-то особо выпятить моменты изменения схемы в ходе коммуникации, как это на это специально обратить внимание. Так сказать, "непрерывная схематизация, непрерывный рендеринг" — чтобы не было ощущения одноактности этой процедуры (статичная неизменяемая с трудном полученная схема и потом долгая коммуникация по её поводу, не меняющая эту схему никак, только передающая её содержание для других ролей).

Одна из студенток ВШЭ начала в качестве курсовой делать приложение, которое будет сочетать две функции: давать читать учебник "Системное мышление 2019" и решать (с проверкой) к нему задачи, но ещё и напоминать, что нужно таки читать, и нужно решать -- что-то типа приложения Keep Yoga, только это будет Keep Systems Thinking Learning. Интересно, что из этого проекта получится, но процесс пошёл.

С техпредами в МФТИ всё пока плохо: оценки по экзамену поставлены, из тридцати человек половина получила "неуд". Но есть и несколько "отлично", что хоть как-то утешает. Ещё не встречал группы с таким отношением к предмету. Например, были письма в личку с предложением мне "пойти на компромисс" (от автора одной из самых плохих работ). Что у этих людей в мозгах?! Повторюсь: когда говорят, что "жизнь их научит", я и есть та самая "жизнь, которая учит". Но мои возможности тут скромны, им для вправления мозгов нужны какие-то более сильнодействующие варианты учащей жизни.

Опубликовано видео одного урока из курса Церена Церенова по системному мышлению для школьников -- https://www.facebook.com/tseren.tserenov/posts/2443930382371570 (само видео -- https://www.youtube.com/watch?v=lMcHvw5Q2mU).

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216944199931289
2019

Мой киззук 2019

Давно я не постил своих танцевальных видео. Впрочем, их и не было -- это ж нужно или специально съёмку организовывать, или попасть на вечеринку, где видеограф на тебя обратит особое внимание. Вчера я на такую вечеринку попал, и мой киззук (микс урбан киза и зука) с Ириной Парамоновой (наш препод социального мультиданса) оказался запечатлён для истории (https://youtu.be/sNbYrc8eJ3I):

Интересно на себя, танцующего, смотреть со стороны. Ощущения примерно такие же, как при прослушивании своего голоса: "это что, я так выгляжу?!". Изнутри-то себя и не видно, и не слышно.

И нужно запомнить: если хочешь внимания видеографов-фотографов и много свободного места, то это вот тут -- https://vk.com/zouk_thursday.

Но видео редкая вещь, чаще бывают фото. Мои танцевальные фото в изобилии можно найти тут: https://vk.com/album2449939_251919283?rev=1

А наша первая группа социального мультиданса (и там много больше разбирающихся в системном мышлении, чем можно предположить) прямо сейчас на своей первой вечеринке в https://vk.com/hustle_buff -- и ещё успевают писать в чат, кого там пригласили, и кто там кого пригласил!

Танцы интересней марафонов, качалок и прочих физкультур, не правда ли? Хотя фор хум хау ;-)
2019

lytdybr

Принимал сегодня экзамен по системному мышлению у техпредов МФТИ, очники. Фейспалм. Мой совет им -- RTFM, я его четырежды переписывал как раз по итогам предыдущих сдач, с 2012 года ежегодно, опыт ведь накоплен немаленький. На каждой консультации говорил, что нужно читать учебник, а не смотреть видео. Нет, смотрели только видео, и не до конца, и невнимательно -- и воспроизвели все типичные ошибки тех, кто смотрел только видео, и не до конца, и невнимательно. Те, кто читал учебник, такие ошибки уже не делают. Основная печаль, конечно, по поводу онтологики: https://ailev.livejournal.com/1465753.html. Аналитики на аналитике и аналитиками погоняют: то, что все эти описания и отчёты описывают какие-то системы (в конечном итоге описывают что-то в физическом мире) -- эта мысль не понимается. Отношения часть-целое заменяют словом "объединение", используют в смысле "почта России объединяет всех жителей России". Вопрос "являются ли жители России физической частью почты России?" ставит в тупик -- разницу отношений, обозначаемых термином "объединение" понять не можем: слово-то одно! Функциональные описания не поняты от слова "совсем", пять слов "модуль" под заголовком "функциональная диаграмма" никого не смущают -- считают, что преподаватель явно ведь придирается! Впервые вижу такое безобразное отношение к предмету (время на него студентами не тратилось вообще, все эссе писались за пару часов до экзамена, учебник не читался, видео "листалось"). Результат: нулевое понимание, что и фиксирует экзамен. При этом группа онлайн-магистратуры (там ребята чуток постарше) демонстрирует ровно обратное поведение: активное посещение консультаций, много вопросов, нормальная связь учебного материала с жизнью. Молодые же содержания предмета не знают, но пытаются качать административные права. Ну, они этих административных прав преподов получат по самое не балуйся. А всего-то нужно было вовремя читать учебник, к первым консультациям, которые шли пару месяцев назад. Времени ведь было навалом, преподы были свободны. Нет, синдром студента таки победил. Именно эту группу. Дружно, всем коллективом. Эх.

Обсуждаем очередное переструктурирование курсов онтологики -- обсуждается объединение всех микрокурсов в один большой курс, чтобы гарантировать хоть какую-то целостность материала в головах курсантов. Вот эта программа (это уже третья большая переделка: онтологика, потом онтологика 2.0, потом разбиение на 5 отдельных курсов -- и вот новый вариант содержания): https://thpectrum.livejournal.com/13568.html. Моя критика там простая: указанное содержание полностью ОК, но указанное время -- оно слишком мало, обучить надёжно за это время не удастся. Машинку типов за ползанятия в головы не вставишь, байесовщину за один вечер не поймёшь. Нужны какие-то реалистичные оценки времени обучения (даже с учётом интенсивной домашней работы). Но программой можно гордиться. Факультеты философии, методологии науки и т.п. в крупных университетах пусть завидуют.

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

В группе шестнадцатого потока "Системный менеджмент и стратегирование 2019" мы нагнали полдня, и теперь идём примерно по графику предыдущей группы -- то есть всё успеем вовремя. Но если прошлая группа застревала на управлении конфигурацией, то эта группа застряла на архитектуре: функциональные и конструктивные описания (да ещё и в различении практик и работ в том числе). Это означает, что материал архитектуры предприятия можно почти и не рассказывать: там же ровно вот этот материал ключевой! В группе очень интересные проблемы вскрываются: даже найден пример "скрипки Энгельбарта" в рабочей жизни курсантов (https://ailev.livejournal.com/1158826.html). Один из курсантов при попытке применить материал курса обнаружил неучтённые 60млн. руб -- так что курс для него уже окупился. Брали бы студенты-очники пример с этой группы в части отношения к учёбе! Хотя один студент таки написал мне в личке буквально перед экзаменом, что "впервые за 6 месяцев работы и размышлений над проектом взглянул на него совершенно иначе (это все равно никак не влияет на корректность эссе, но лично меня очень радует), задумался, для кого это все делается и как это влияет конкретно на меня. В общем - спасибо!". Ну, это дословно совпадает с тем, что я говорил на установочной лекции: именно при составлении эссе вы впервые вынуждены будете подумать о вашем проекте в целом -- и вас там будут ждать разные (приятные и неприятные) открытия.

На курсе социального мультиданса начали приглашать преподавателей и опытных танцоров поглядеть на результаты. Их (внешнее! не наше!) мнение: обучение ведению-следованию быстрее примерно вшестеро, чем в среднем при текущих методов преподвания. И это сразу для многих танцев, а не для одного! То есть выигрыш во времени по факту ещё больше. Так что ещё один крутой проект одолел успешный успех: методика работает! Почитать о происходящем в группе (резюме каждого занятия, методические материалы, а также публичную часть отзывов) можно тут: https://vk.com/buffdance (и там уже 311 подписчиков, счёт интересующихся методикой пошёл на сотни). Лаборатория телесного мышления начала еженедельно выкладывать видео своих лабораторий (чат в телеграме -- https://t.me/labolatoryTM, там более полутора сотен человек), и теперь довольно много убедительных демонстраций телесного фитнеса и разъяснений его принципов доступно не только москвичам и питерцам.

Следующий открытый курс у меня -- "Машинный интеллект 2019", 7 декабря 2019 (https://system-school.ru/machine). Материал на слайдах опять прокис, буквально за месяц -- два прорыва в неделю продолжаются. И я переделываю там ещё и теоретическую часть. Ибо 19 ноября вышла статья François Chollet по тому, что такое интеллект и как его замерить (https://arxiv.org/abs/1911.01547) -- и я учитываю ещё и этот материал. Ну, добавляю всякие новости прошлого месяца, а этих новостей много -- если я не пишу обзоров происходящего у себя в блоге, это совсем не значит, что ничего не происходит. Происходит, и ещё как происходит! Чего стоит только Mastering Atari, Go, Chess and Shogi by Planning with a Learned Model -- https://arxiv.org/abs/1911.08265. Умение алгоритма выигрывать самые разные игры, не зная их правил, и делая при этом меньше вычислений при обучении, чем алгоритмы, которые учатся играть в игры, зная правила. Фишка в том, что один и тот же алгоритм сверхчеловечески выигрывает и в видеоигры типа тех, что играются на Atari, и игры "переборного планирования" типа Го, шахматы и шоги, при этом не зная правил ни игр на Атари, а их 57 разных, ни правил Го, шахмат, шоги. Это очень, очень круто! По сути, речь идёт не о том, что алгоритм запрограммировали не на победу в какой-то игре (ограниченная компетенция), а об общей возможности побеждать в каких-то играх, где правила неизвестны, но есть симулятор, дающий ответы на ходы машины -- это возможность научиться выполнять какой-то класс задач. Интеллект -- это в меньшей мере про умение что-то делать, а больше про умение научиться что-то делать -- когда выясняется, что текущих умений для выполнения дела недостаточно.

И в связи со всем этим я дополнительно пересматриваю "Образование для образованных" -- наша Школа ведь как раз учит трансдициплинам, которые предназначены для разборок с другими дисциплинами. Мы учим тем практикам, которые позволяют быстрее разбираться с другими практиками. По сути дела, мы учим тому, как стать более интеллектуальными людьми, более разумными, быстрее распознавать ситуации, когда нам нужно чему-то научиться, а потом быстрее этому учиться. Так что я потихоньку разбираюсь со всеми этими теориями интеллекта (g-VPR, CHC, Gf-Gc и т.д.), а дальше мы будем связывать их с разными теориями творчества (некоторое время назад я делал обзоры на эту тему, например творчество в системном мышлении -- https://ailev.livejournal.com/1425331.html, open-endedness про эволюционное "творчество" https://ailev.livejournal.com/1463013.html и разные теории творчества из искусственного интеллекта https://ailev.livejournal.com/1251987.html, и ещё куча материалов, поминаемых в конце текста "За пределами менеджмента и инженерии" https://ailev.livejournal.com/1411106.html, где я пишу о связи творчества и сжатия информации -- про правильную репрезентацию/абстрагирование мира как основу творчества, и поэтому важности обучения эффективным абстракциям. Интеллект и творчество в машинах, людях и симбиозах машин и людей -- этим мы и занимаемся.

Дома появился новый гаджет -- МФУ HP DeskJet Ink Advantage 5075 M2U86C, а старые принтер и сканер уволены по моральной старости. Из интересных фич -- двусторонняя печать при весьма небольших габаритах. Стоит этот гаджет на кухне, пользуются им все -- он цепляется к домашнему WiFi и доступен со всех компьютеров и телефонов. Больше гаджетов богу гаджетов! А что я им делаю больше всего? Правильно: "распечатать, подписать, отослать подписанный скан". Морально не устаревающая процедура, ещё со времён факсов. Факс даже проще было передавать, чем сканировать и пересылать результат по почте -- в разы меньше нажатий кнопок.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216874837917282
2019

Об цифровую трансформацию: то же оргразвитие, и даже не в профиль

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

Цифровая трансформация -- "цифровая" означает, что будет много компьютеров. Как будто их не было и в автоматизации! Автоматизация -- вроде как что-то делал человек, а потом это же стал делать компьютер. Но нет, если что-то стал делать компьютер, то он это будет делать по-другому, и человек тоже займётся чем-то другим: организация от использования компьютеров не столько "автоматизируется", сколько "трансформируется". Ага, с использованием компьютеров. По сути дела, речь идёт об организационном развитии

Можно было бы поддаться веянию времени и начинать говорить о цифровой трансформации, это ж синоним (цифровой -- компьютеризированный по самые брови, трансформация -- это как раз оргразвитие), но этот термин как придёт, так и уйдёт. Скоро, скоро уже заговорят о какой-нибудь "искусственноинтеллектуальной трансформации" или как это будет называться (когда выяснится, что подойдёт не просто работа с данными, а только работа с данными при участии машинного интеллекта), заменят компьютеры на квантовые -- это будет "квантовый оргскачок" и так далее. Вон, несколько дней назад Гартнер выдал новое слово "hyperautomation", гиперавтоматизация. Что, выучиваем и его? Больше buzzwords богу buzzwords?

Мы помним, что почта вдруг стала электронной, а потом просто почтой (а потом переписка ушла вообще мессенджеры и какие-нибудь Slack или MS Teams). Бухгалтерия тоже становилась механизированной (с Феликсами и табуляторами на перфокартах), а потом компьютеризированной, а потом осталась бухгалтерией.

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

Нам не нужно называть проект так, чтобы попадать в правильную строчку госбюджета. Все эти поветрия с модными buzzwords приходят и уходят, а шаги развития организации, которые нужно делать -- остаются. И они сегодня не бывают без компьютеров.

Повторюсь:
-- компьютеры используются для того, чтобы была память для модели организации (архитектура, операционный учёт)
-- компьютеры используются для управления коллективным вниманием к этой памяти (issue tracking, управление работами)
-- компьютеры используются для принятия решений (машинный интеллект, и не нужно думать об AGI. Любое вычисление подойдёт, лишь бы не в голове человека).

Подробней об этом я писал в:
-- системная осознанность, https://ailev.livejournal.com/1487672.html
-- киборгизация людей и организаций: поднимаем осознанность, то есть рулим вниманием, https://ailev.livejournal.com/1488271.html

И мы всё это используем в нашем проекте развития -- использование информационных технологий в реализации стратегии Школы:
-- EdTech для blended learning -- те же PLM/ALM + CAD/CAM/IDE, только в образовательный профиль, https://ailev.livejournal.com/1473691.html
-- чего мне не хватает в MS Teams -- https://ailev.livejournal.com/1490524.html
-- стратегирование Школы системного менеджмента -- https://ailev.livejournal.com/1493744.html
-- видео семинара по созданию AIsystant и blended learning services, https://ailev.livejournal.com/1494270.html
-- чеклисты в blended learning services: не прощёлкать важное, но и не забюрократизироваться, https://ailev.livejournal.com/1497117.html
-- множество заметок в lytdybr (например, https://ailev.livejournal.com/1496250.html -- там я говорил про RPA как ведущий тренд)

Дальше нужно понимать, чем же именно проекты развития с компьютерами отличаются от "просто проектов развития". По большому счёту, ничем. Но в этих проектах развития заимствуется огромное число находок из управления жизненным циклом и управления работами из software engineering. В частности, в управлении жизненным циклом из существенных новаций можно заметить DevOps (плавно переходящее в NoOps, https://ailev.livejournal.com/1367897.html) и свеженький его извод SRE (site reliability engineering, включая обширную дискуссию его похожести и отличий от DevOps -- главным образом то, что в NoOps куда-то делись Dev, а в SRE они в полной мере присутствуют).

Так что отдельных курсов в Школе системного менеджмента по цифровой трансформации не будет, но тема вполне раскрывается -- это курс "Системный менеджмент и стратегирование", ибо день "совершенствование и развитие" (да и все остальные дни, впрочем, тоже) там как раз про вот это вот всё. Организаций без цифры уже не бывает вообще, организации без развития/трансформаций (конечно, с цифрой!) -- мертвы, и скорее раньше, чем позже.

В НИУ ВШЭ мы читаем также курсы в магистратуре "Цифровая трансформация образования" -- https://www.hse.ru/ma/dt/. Там, конечно, всё завязано на госбюджет, поэтому "цифровая трансформация". Мы же сказали бы просто: это школа менеджеров развития образования. Если есть практика организационного развития, то есть и деятельностная роль -- управляющие развитием, менеджеры развития.

В Школы мы сделали отдельный чат поддержки выпускников, которые ведут проекты развития в своих или в клиентских организациях. И в ближайшее время проведём несколько семинаров, где будем обсуждать их проекты развития (пока запланирована уже парочка, но их будет много, много больше). Отдельно говорить о том, что это проекты "цифровой трансформации", "информатизации", "автоматизации" и т.д. -- не нужно. Это само собой. По-другому не бывает.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216830525489499
2019

Чеклисты в blended learning service: не прощёлкать важное, но и не забюрократизироваться

Почему мы в Школе хотим избежать традиционного айтишного зоопарка? Взять две дюжины самых лучших и дешёвых онлайн сервисов для разных применений -- и voila, Айсистент (AIsystant ещё начали называть AllSystant, олсистентом-всесистентом) наш! Нет, так не пойдёт. Даже если мы закупим 10 сервисов для 10 функций по 10 копеек на установку каждый, результатирующие blended learning services будут стоить отнюдь не рубль: разница накопится в ходе всего жизненного цикла -- обслуживание 10 разных контрактов, коммуникация на 10 разных языках, интеграция 10 разными способами дадут в ходе жизни сервиса затраты много больше исходного рубля. Любое изменение станет дорогим кошмаром. Если мы закупим 2 сервиса за 50 копеек, которые закроют все те же 10 функций (разницу между функциями и сервисами смотри в учебнике "Системное мышление 2019"), то обслуживание будет в разы проще -- меньше контрактов, меньше способов интеграции, меньше знаний в головах персонала. Для того, чтобы использовать поменьше заказных компонент и тем самым обращаться к "всеохватному" и "всепрограммируемому" кровавому энтерпрайзу (для нас, похоже, это MS Office 365 Education), существуют чисто экономические соображения.

Кстати, SpaceX сделал ровно то же самое: изготавливает огромное количество детальков космического корабля сам, что резко уменьшило расходы на коммуникацию с контракторами. Те же принципы за программой повышения культуры "вы можете себе это позволить" (affordability) на флоте США, где идёт программа по enterprise commonality, то есть унификации модулей для всего флота-как-предприятия, (https://www.navsea.navy.mil/Media/News/Article/1391473/navsea-commonality-teams-findings-could-save-millions-in-fleet-maintenance-costs/ -- почему-то смог открыть только через VPN, там тоже свой Штаткомпозор работает. Начиналась enterprise commonality с программы замены самых разномастных дешёвых насосов на небольшую номенклатуру более дорогих насосов -- уменьшение номенклатуры и закупка типового насоса оказывается в ходе полного жизненного цикла дешевле покупки уникального самого дешёвого насоса для каждого отдельного применения).

Что мы сейчас будем делать в плане описания Школы, документирования архитектуры предприятия? Мы все наши кейсы "обоснуем" (essentialize, азаза -- essence это "основа", вот её и выделим), то есть установим проектные альфы для каждого кейса (черновой список кейсов -- https://ailev.livejournal.com/1492409.html, по каждому кейсу типовая альфа, а дальше для каждого экземпляра кейса -- экземпляр альфы), сделаем чеклисты для состояний альф, меняемых практиками (список практик для курса и потока нарезаны тут: https://ailev.livejournal.com/1496250.html). Для каждого чеклиста сделаем предложения по evidence/рабочим продуктам в виде форм, и привяжем к этому issue tracker. Потихоньку всю школу переведём на чеклисты: проверку наступления предписанных практиками событий для альф-кейсов и порождение работ, если события почему-то не наступили. Вводим учёт событий, управляем вниманием -- поднимаем осознанность в том, что происходит в Школе.

Поэтому формальный язык (SysMoLan) сначала заточим для этой чеклистизации. У нас была идея ArchiEssence, мы к ней возвращаемся на новом уровне (только альфы уже не просто основные альфы Essence, и SysMoLan вместо Архимейта). А потом да -- конфигурация описания Школы как скрипты на SysMoLan, а они конвертируются в скрипты конфигурации Айсистента (про пересечение с тематикой "скриптов как конфигурации" и RPA я писал в https://ailev.livejournal.com/1496250.html). Поэтому SysMoLan как DSL заточим поначалу на это. А пока нет DSL, будем писать просто псевдокод произвольного синтаксиса. По сути, это всё DDD -- только event storm мы делаем по идеям OMG Essence.

Отдельное дело будет -- как не забюрократизироваться. Ибо нет ничего более бюрократизирующего, чем все эти многочисленные обязательные чеклисты, от заполнения которых не даёт уклониться компьютер. Но при этом помним, что в клинике чеклист перед опирацией снижает смертность на 30% (книжка https://www.ozon.ru/context/detail/id/26845885/). Чеклисты у нас, кстати, в ходу на тех курсах, где зашкаливает количество разных мелких разномастных практик -- тот же системный фитнес. Не факт, что этими чеклистами пользуются, но при разработке курса они оказываются очень удобной формой документирования. Чеклисты не заменяют учебник, не учитывают подробности, но управляют вниманием: не дают забыть о важном. Вот это важное и пишем. Это шанс не прощёлкать важное, но и не забюрократизироваться.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216791384510999
2019

lytdybr

Слетал на сутки в Сочи, позанимался там системным мышлением с инженерами, моря не видел. Узнал, что корпоративная стратегия, над которой работали четыре года назад, начала реализовываться в каких-то частях. В момент её создания нам казалось, что шансов нет. Прошло четыре года, и дело пошло. Это не первый консалтинговый мой проект, в котором рекомендации начинают выполняться сильно погодя. Я подозреваю, что в обучении всё то же самое: учатся сейчас, а использовать результаты обучения будут через несколько лет, когда забудут всё содержание, но зато прочувствуют, что без этого забытого содержания никак нельзя. Собственно, в Сочи летал примерно по тому же принципу "позднего прочувствования": за четыре года альтернативных системному мышлению методов договаривания инженеров и менеджеров клиентом найдено не было, так что я съездил презентовать учебник. Но и то правда, что четыре года назад был только второй вариант текста учебника, а сейчас уже четвёртый.

В лицее прошли съемки в школьный альбом. Оформить это можно было договором как "мастер-класс по фотографии". Но мастер-класса, конечно, никакого не было, формулировка тут только для ублажения чиновников. На выходе -- тот самый "просто альбом". Школа, она такая школа. Мне очень понравилась фирма, которая делает фотосъёмку: она буквально заставляет родительский комитет дать доступ всем родителям ко своим фото, чтобы выбрать лучшие, чтобы проверить все надписи. И потом альбом будет свёрстан автомагически -- каждый родитель проверит ошибки в фото и надписях своего ребёнка. Там же на сайте представление команды проекта (менеджер, фотограф, дизайнер альбома), с ними можно пообщаться. Прямо таки прошла цифровая трансформация фотофирм! В альбом нужно даже загрузить детскую фотку (обычно грузят первый класс, чтобы сравнить с одиннадцатым).

Вот наш первый класс:


Вот одиннадцатый:


Дальше принято с довольным видом писать: "я сделяль". Вот, пишу.
2019

Умненькие дебилы: умны в деле-в-малом, дебилы в деле-в-большом

Человеческая деятельность коллективна. Но почему-то образование в части мышления часто сводят к умению пораскинуть мозгами в части решения каких-то олипиадных задачек: условие таких задачек полностью однозначно, время решения 2-4 часа одного человека, уточнений условий задачи не требуется, ответ короткий и по факту нигде дальше не используется (проверка/верификация есть, приёмки/валидации нет). Вот из школы и из вузов ровно такие люди и выходят: победители олимпиад, крайне сообразительные, умненькие.

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

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

В программировании это различение известно как программирование-в-малом (по сути, олимпиадное программирование, programming-in-the-small) и программирование-в-большом (programming-in-the-large). Я потом эту тему обобщил до моделирования, онтологизирования, проектирования (это ведь в всё одно и то же по большому счёту) в малом и большом (см. пост "Онтологические модели -- это про проектирование/программирование/моделирование-в-большом" ещё 2009 года, https://ailev.livejournal.com/748188.html). А потом говорил и про производство в малом и в большом (см., например "стандарты производства-в-большом, 2010 -- https://ailev.livejournal.com/851977.html, и продолжение про стандарты каталогизации -- https://ailev.livejournal.com/852642.html).

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

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

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

Мой пойнт тут в том, что деятельности-в-большом нужно и можно учить. Но это обучение не какой-то прикладной "олимпиадной" дисциплине. Это обучение трансдисциплинам: логике, онтологии, коммуникации (важно! коллективный характер проектов тут!), коллективному принятию решений (важно! это не самому "напружиниться, и решить"), научному мышлению, далее системному мышлению, вычислительному мышлению -- все из которых оказываются коллективными (да, и вычислительное мышление тоже! олимпиадное программирование имени Дональда Кнута осталось в далёком прошлом), а дальше кругозоры -- про практики системной инженерии, менеджмента, предпринимательства и т.д., и множество ролей для этих практик, без понимания которых проект в голову не уложишь. А не уложишь проект в голове -- будут проблемыв со вписыванием своей работы в работу команды, и работы команды в ещё более широкий круг работы всех остальных людей на планете. Будешь очень умным в части решения никому не нужных проблем, но идиотом в части реальной проектной работы. Умным теоретически (ибо хорошо вышколен в плане рукоделия -- хоть мыслительного, хоть ремесленного!), но бесполезным "по жизни".

Чтобы про вас не говорили "умная голова дураку дадена" -- обращайте внимания не только на своё рукоделие, но и на проект в целом, на окружающую жизнь. Для этого придётся разобраться, как они устроены. И это совсем не ваши любимые дисциплины, в которых вы собаку съели. Это те самые трансдисциплины: методологические, кругозорные.

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

Это просто ещё один способ говорить о Т-людях (глубокие прикладники, но с широким кругозором -- https://ailev.livejournal.com/1459798.html). Но в посте ещё и акцент на различие самих практик-в-большом и практик-в-малом. Владение трансдисциплинами позволит легче разобраться с более сложными практиками-в-большом (программирование того же кровавого энтерпрайза, например, по сравнению с олимпиадным программированием, или менеджментом в крупной организации по сравнению с менеджментом команды из только себя, любимого).

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

Техноэволюция идёт (open-endedness, https://ailev.livejournal.com/1463013.html ), жизнь становится сложней. Нужно учиться, нужно как-то этой жизни соответствовать. Быть умненькими и не дебилами.
2019

Разработки в образовании: тоже state-of-the-art

В https://ailev.livejournal.com/1495662.html я рассказал об исследованиях, образовании и просвещении в Школе системного менеджмента. Предметом исследований (research) я определил state-of-the-art в трансдисциплинарных практиках. Школа проводит исследования, вытаскивая этот state-of-the-art из его текущего состояния раскиданных по разным источникам фрагментов знания, а потом гармонизируя полученные фрагменты. Результаты исследований оформляются в виде курсов, иначе нет шанса, что эти результаты попадут в головы людей, а не закончат свою жизнь в виде никем не востребованных текстов научных статей в узкопрофильных журналах. Вот это оформление в виде курсов -- это и есть разработка (development). У нас, конечно, R&D -- исследования и разработки. Никаких "особенностей образовательных учреждений", черпаем обеими ладошками из жизни современного хайтека.

Наши разработки используют state-of-the-art практик обучения, об этом явно говорит стратегия: "8. Школа учит современными методами: flip teaching, blended learning, interactive collaborative learning и т.п. Большинство из этих методов опираются на использование как живого обучения с преподавателем, так и задействование компьютеров".

Flip teaching, "перевёрнутый класс".
Это означает, что мы ничего не объясняем в классе. Наши преподы не работают говорящими головами, не работают живой книжкой, не работают хрестоматией на встречах. Всё это делают:
-- их учебники, которые как раз и нужно разработать. Вот мой учебник "Системное мышление 2019" на 534 страницы. Я перестал объяснять материал курса, его ведь можно прочесть в этом учебнике в удобное время. В крайнем случае сойдёт и видеокурс (но видеокурс обычно работает хуже). Аудиокнижки плохи, ибо внимание не удерживается визуальной структурой текста, диаграммы и другие картинки в аудиокнижках тоже не разберёшь. А ещё используется набор оригинальной литературы, из которой нужно вычитать тот самый "state-of-the-art в изучаемой практике". Например, по 4D экстенсионализму все читают BORO Book, по операционному менеджменту книжку Reinertsen по lean for development. Время в классе на это чтение не тратится.
-- гугль, предоставляющий ссылки на дополнительные разъяснения в самой разной форме. Не понял чего-то -- погугли, найди объяснения, разберись.

На занятия курсанты приходят уже знакомыми с материалом. На занятиях курсанты получают не лекцию и объяснение нового материала, а обратную связь при попытках использования выученного дома материала. Разбирается решение задач, возникшие затруднения, устраняются ошибки понимания, курсанты получают опыт использования нового знания. Занятия перестают быть лекциями, это занятия-семинары. Занятия в классе не имеют целью дать знания, они имеют целью перевести эти знания в умения и навыки и (по возможности) в компетенции.

Blended learning, "смешанное обучение".
Это означает, что максимизируется та часть семинарской работы, которую можно сделать без преподавателя -- максимизируется работа курсантов с компьютером. Решение задач с автоматизированной проверкой, работа с симулятором для предметной области, самые разные другие формы работы, но не с живым преподом, а с заменяющим его компьютером. Труд ученика невозможно автоматизировать. Труд учителя автоматизировать можно и нужно, в в том числе с задействованием машинного интеллекта.

В курсе системного мышления у нас сейчас 181 кейс, варианты решения которых проверяются компьютером. Первый вариант этого работал в курсере, второй вариант делается немного по другому (см. описание в https://ailev.livejournal.com/1482241.html). В курсе онтологики уже более 40 подобных кейсов. И это только самое начало подобной деятельности.

Мы будем всячески развивать это направление, развивать нашу информационную систему, основанную на blended learning services (см. рассказ об этом на видео семинара по созданию AIsystant и blended learning services -- https://ailev.livejournal.com/1494270.html).

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

При этом улучшение качества образования при использовании blended learning не сводится только к тому, что ученики могут провести больше своего времени с легко доступным компьютером, чем с малодоступным преподавателем. Компьютер добавляет возможность управления вниманием ученика. И это настолько важно, что вошло в стратегию Школы отдельным пунктом: "7. Когда толпы хорошо обученных маркетологов и лидеров борятся за твоё внимание, чтобы использовать особенности работы твоего обезьяннего мозга и заставить тебя что-то сделать, мы используем компьютер, чтобы помочь тебе присмотреть за этим вниманием -- с компьютером оно не сбежит, проблему дефицита внимания решаем технологически. Мы работаем с киборгами -- человеческими и организационными. Школа у нас тоже киборг (её компьютерная часть: AIsystant на базе blended learning services)". Вот текст, раскрывающий понятие системной осознанности как присмотра за вниманием https://ailev.livejournal.com/1487672.html, а вот уточнение по использованию компьютеров для подъма уровня осознанности -- https://ailev.livejournal.com/1488271.html. Вот ровно эти механизмы дают улучшение качества обучения при использовании blended learning.

Interactive collaborative learning, учебная групповая работа
Компетенции, которым мы учим, должны применяться в самых разных проектных ситуациях. Это означает, что нашим курсантам придётся занимать различные роли в командах, участники которых занимают другие проектные роли. Нужно знать не только свою роль, нужно уметь свою игру по роли адекватно вставить в общую игру всей пьесы. Collaborative learning is based on the model that knowledge can be created within a population where members actively interact by sharing experiences and take on asymmetric roles. Мы занимаемся учебной групповой работой, в которой её участники активно общаются и обмениваются опытом занятия различных проектных ролей.

В простейшей форме речь идёт даже не о выполнении групповых проектов и именно ролевом тренинге ("ролевое мастерство" -- да, мы озабочены и этим тоже). Мы занимаемся в группах, где курсанты помогают друг другу разбирать их самые разные проекты из самых разных предметных областей, при этом сами курсанты занимают в этих проектах самые разные роли. Проекты маркетплейсов, интеллектуальных роботов, создания новых материалов, фармацевтические, образовательные, интернет-магазинов -- все они обсуждаются на занятиях всей группой. Наши курсанты занимаются в Школе трансдисциплинарными дисциплинами, и именно на вот этом разнообразии живого применения материала курсов к их рабочим (не учебным!) разным проектам и понимается мощность и универсальных предлагаемых мыслительных компетенций. Когда курсант видит, что системное мышление помогает разобраться и с проектом фемтосекундного лазера, и с проектом реорганизации детского садика Монтессори, он лучше понимает универсальную применимость системного мышления.

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

Лучшие практики разработки курсов
Конечно, при разработке и проведении наших курсов мы не ограничиваемся flip teaching, blended learning, interactive collaborative learning. Мы активно используем достижения instructional design и самых разных других образовательных дисциплин.

При этом мы предпочитаем использовать в наших разработках курсов те методы образования, которые используют достижения когнитивистики (cognitive behavioral engineering -- на базе достижений cognitive behavioral therapy, только мы тут не терапией занимаемся, у нас не больные). И те методы образования, которые могут быть легко автоматизированы без потери результативности и эффективности образования (более того, мы считаем, что автоматизация должна приводить к росту результативности и эффективности -- как и везде в других областях деятельности).
2019

lytdybr

Группа "Системного менеджмента и стратегирования" (шестнадцатый поток! третья версия курса!) опять отстала на полдня от графика. Прошлый поток более подробно проходил управление жизненным циклом и управление конфигурацией. А вот эта группа вдруг вернулась к материалу про функциональные объекты, функции, порты и соединения против конструктивных объектов, сервисов, интерфейсов. При этом в материале управления жизненным циклом по этой же линии различали практики и работы. Баек (то бишь "примеров из жизни") было рассказано немерено. Половина группы -- строители. Но есть и парочка "маркетплейсов", и диалоговые AI-боты. Как всегда: одно мышление, помогающее во всех проектах. А ещё час был потрачен на вопрос об управлении вниманием с использованием технических средств -- на примере меня, любимого (основной тезис был: "это не у меня память хорошая, а у Гугля". Ну, и дальше по мелочи -- полторы тысячи заметок в Evernote, почти шесть тысяч записей в "Лабораторном журнале", обсуждение на почти тридцать тысяч моих комментов в ЖЖ и несчитанное количество в фейсбуке и других сетях, и прочие средства помощи коллективному мышлению с моим участиемсо стороны компьютеров и интернета).

Завтра вечером вылетаю в Сочи на корпоративную конференцию, буду там всю среду заниматься системным мышлением в части обеспечения смычки между инженерами и менеджерами (увы, в той тусовке с предпринимателями будет туговато). Участники конференции даже учебник получат бумажный, лишь бы учились. Всё это "государственный бизнес", то есть не бизнес, и поэтому весьма искажённая инженерия (не очень системная). Но учить буду: сегодня тамошние инженеры и менеджеры работают в госкорпорации, но мы не знаем, где они будут работать завтра -- поэтому осмысленно их учить (но не консультировать по их текущим проектам. Именно учить, готовить к реальной инженерии и реальному менеджменту, а не искажённому дармовыми для них деньгами налогоплательщиков). В мировой системной инженерии (и заодно менеджменте), которые быстро-быстро отплывают от государственного финансирования, сейчас идёт выход на принципиально иной уровень сложности: четвёртый запуск одной и той же ракеты Falcon 9 (и второй запуск сохранённого обтекателя), которая вывела на орбиту 60 первых (то есть не экспериментальных, а рабочих) спутников StarLink -- https://www.space.com/spacex-starlink-launch-fourth-rocket-landing-success.html. Эта ракета планируется быть запущенной в космос и в пятый раз -- об этом говорится явно. В середине 2020 сеть StarLink уже планирует начать работу -- и интернет опять существенно поменяется. Вот это -- и бизнес, и инженерия. Про бизнес SpaceX, кстати, читайте вот тут: https://smoliarm.livejournal.com/419187.html (текущее снижение цен на запуск малых спутников силами SpaceX втрое-вчетверо).

Провели методологический семинар по схематизации и рендерингу (обсуждали https://ailev.livejournal.com/1494762.html). Написал длинный протокол в преподский чат. Содержание трёх курсов (онтологики, схематизации, коммуникации) будет в ближайшее время существенно пополнено и доработано. Длительность курсов увеличится. Очень хочется, чтобы состояние курсантов "знакомы с идеями, очень интересно" перешло в состояние "имеем компетенции, используем "на автомате"". Пока же, увы, этим похвастаться не можем. Для интересующихся темой агентности и обучения мышлению рекомендую поглядеть текст про обучение мышлению машинного интеллекта (и я считаю, что это же применимо для обучения мышлению и человеческого интеллекта тоже. Поглядите, там все слова знакомые): https://medium.com/intuitionmachine/an-advanced-capability-maturity-level-for-artificial-general-intelligence-b300dafaca3f. Просвещение переводит людей со ступеньки неосознанной некомпетентности к осознанной некомпетентности. А дальше — образование.

Провели методологический семинар по Айсистенту и blended learning services. Неожиданно тема SysMoLan пересеклась с тематикой RPA (и да, там новости по линии Microsoft -- https://venturebeat.com/2019/11/08/microsoft-has-entered-the-rpa-market-what-does-that-mean/). Текущий RPA состоит из набора коннекторов к софту, набора коннекторов к человеку (все эти распознавания речи), плюс BPM-движка (можно думать, насколько там близко к case management -- они ж себя процессниками считают, и языки там типа CMMN есть, хотя пока выглядит как "голимый недоBPMN"). На чём пишут архитектуру RPA? На диких скриптовых языках довольно низкого уровня, "архитектуры нет, есть коды -- они же документация". Дальше вопрос "адаптивности" как в кейс-менеджменте: если шаблоны пишут программисты, то "просто кейс-менеджмент" (так что RPA сегодня это "просто RPA"). Но если шаблоны пишут непрограммисты, то это будет adaptive RPA. Очередной виток процессного управления. Дальше вопрос: кто пишет на SysMoLan. Если SysMoLan это язык представления знаний (скажем, Common Logic или что-то типа CYC и так далее по линии логических движков), то редкие люди, их в природе единицы. Если SQL (первое же, что предлагают обычно), то герои-админы. Если DSL на Julia, то можно думать об инженерах (но именно что думать). В любом случае, речь в Айсистенте идёт о том, чтобы скриптами (конфигурация -- это код) держать федерирование нескольких разных тяжёлых систем типа той же Teams, корпоративного вебсайта, биллинга и т.д.. В общем, после этой встречи есть о чём подумать. Опять же -- длинный протокол, хотя и не в преподавательской, а в спецчате.

Заодно отладили интерфейс решения задач по системному мышлению. Там решаются программерские проблемы, и я очень надеюсь, что в конце этой недели первая группа из 15 студентов ВШЭ начнёт идти по курсу из учебника-2019 и кейсы-2019 с проверкой. Напомню, постановка задачи была вот тут (и задачи после этого хочется называть кейсами): https://ailev.livejournal.com/1482241.html

Один из побочных выходов посиделки по Айсистенту -- уточнение пары кейсов на один уровень:
Курс
-- решить про курс
-- найти препода
-- подготовить материалы
-- заслушать на семинаре
-- дать анонс (видео)
-- сделать landing page
-- перейти к ЖЦ первого потока
-- менять материалы курса
-- уволить курс

Поток
-- согласовать с преподом курс и время
-- дать объяву на сайт + вставить в расписание
-- начать сбор заявок ("объявить набор")
-- в день X принять решение о старте потока (ибо может быть недобор, или может быть перебор, тогда запустить набор на новый поток, а этот продолжить)
-- оформить договора и оплаты
-- прогнать через онлайн курс (учебник+задачник)
-- дать доступ к материалам курса (библиотека+слайды. Слайды могут быть к каждому дню "оперативно", а не сразу)
-- завести списк курсантов потока
-- завести для курсантов чат потока
-- завести репо для материалов потока
-- зарезервировать аудиторию (возможны пересечения с другими курсами)
-- вести занятия потока (координация через чат): использовать аудиторию и дистант (сейчас ZOOM)
-- снимать и публиковать видео только для потока
-- проверять домашние задания в репо
-- провести защиту
-- выписать сертификаты
-- занести курсантов потока в чат выпускников (закрытая коммуникация)
-- занести курсантов потока в список выпускников (у них будут скидки)
-- занести курсантов потока в комьюнити выпускников (фейсбук, открытая коммуникация)
Опубликовали первое видео наших курсантов социального мультиданса: https://vk.com/wall-179019873_373. В группе много выпускников курсов ШСМ, а на видео есть два профи -- сможете их отличить от начинашек в танцах? Методика работает, ускорение обучения социальным танцам получается в разы по сравнению с традиционным способом, я очень доволен. Чему мы учили целый месяц эту группу, сформулировано вот тут: https://vk.com/wall-179019873_372. А ещё получили развёрнутую правильную рецензию от приезжавшей к нам на пару дней Елены Унру из Питера (и там фотография меня, изображающего непослушную партнёршу): https://vk.com/wall-170497991_610. Правильность рецензии в том, что про социальные танцы нужно именно так и писать: про ощущения в паре, а не про внешние формы. Из забавного: использовал свежую разработку MIT по равновесию двуногих роботов для разговора о равновесии в социальных танцах -- https://vk.com/wall-179019873_374. А вот и я попал на видео танцующим -- на вечеринке Ностальжи Кизомба в эту субботу: https://vk.com/video40271596_456239303. И ещё один мой текст: про удовольствие в социальных танцах -- https://vk.com/wall-179019873_367.

НИУ ВШЭ опять отличилась в казарменную сторону: меня не пустили на факультет компьютерных наук с самокатом -- даже с самокатом в руках (весит-то он всего 4.2кг). Это вообще первый случай, когда меня не пустили куда-то с самокатом (а уж в каких только офисах, вузах, предприятиях или клубах я ни побывал с самокатом за последних пятнадцать моих самокатных лет!), предложили оставить самокат на уличной стоянке для велосипедов и самокатов. А у меня даже цепи для него нет, это ж ручная кладь по габаритам и весу. Конечно, все дурацкие запреты были обойдены -- сел в местную преподскую машину вместе с самокатом, и въехал на машине прямо на тамошнюю подземную стоянку. В машине же можно провозить хоть пулемёт. Но вот самокат приравнивать к пулемёту -- это что-то новенькое. У меня уважение к НИУ ВШЭ после последних тамошних политических подвигов и так было не очень, но упало почти до нуля. В казарме наука не живёт, она чахнет и умирает.

Блюдо недели -- тыквенная запеканка из Пан Запекан (при этом тыква на вкус там не обнаруживается ни мной, ни другими людьми -- проверено. Но очень вкусно). Я пришёл туда целевым визитом (у меня их точка на Октябрьской в самокатной доступности, прицелился и назначил там встречу-обед), не рассчитал вес-объём, и взял 0.7кг разных запеканок. Едва осилил, под 0.4л латте. Правильное место, я такие люблю: показываешь пищу пальцем и немедленно её получаешь, а не тыкаешь в фотографию из меню и потом ждёшь сюрпризов.
2019

Про типичные роли в проекте, метонимию и конкретность

Алексей Корнилов спрашивает про типичные роли в проекте (https://www.facebook.com/alx.kornilov/posts/2438413123036909), там уже 129 комментов от самых разных людей. В треде для меня важны два положения из онтологики:
-- не попадаться на метонимии, https://ru.wikipedia.org/wiki/Метонимия (есть исполнитель роли и роль, их не нужно путать -- Принца Гамлета плохо называть Васей Пупкиным, но вот Васю Пупкина часто называют Принцем Гамлетом)
-- чтобы договориться, нужно идти не к абстрактному, а к конкретному в ситуации: роли нужно называть по ситуации, избегая "всеобщности". Минимально абстрактная роль, минимальный класс, а не самый объемлющий из возможных. Роль "человек" для человека мало что проясняет, роль "пользователь" для игры лучше назвать "игрок".

Вот мои ответы в той дискуссии (as is):

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

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

[-- инвалид может быть и заказчиком, и плательщиком, а может и не быть. Вот эти базовые типовые представления какие лучше использовать?]
"Инвалид может быть и заказчиком, и плательщиком, а может и не быть" -- это мы разбираем на онтологике. Путаются Иван Иванович (исполнитель ролей) и его роли "инвалид", "плательщик", "заказчик", "муж", "отец", "матерщинник" и т.д.. Это метонимия -- когда мы вдруг Ивана Ивановича называем его ролью "инвалид" и потом говорим, что "инвалид -- это плательщик" (то есть роль -- это роль, имея ввиду исполнителя роли, а не саму роль).

[-- если нет общепринятых, то каждая роль должна быть как-то описана, причём так, чтобы всем участникам проекта было понятно, о чем речь. Поэтому все равно должен быть какой-то общий контекст. Он как задается, при том, что у участников проекта может быть разное образование, разный опыт и пр. ?]
Вообще-то в команде проекта принято обсуждать проект и договариваться, а как иначе? Если не договариваться, то проект сделать невозможно. Если я называю уборщика территории дворником, а кто-то таки уборщиком -- нам нужно договориться, мы про одну роль говорим или таки про разные. Ибо "общепринятые" у меня и у моих собеседников могут быть совершенно разные представления. Поэтому общепринято только договариваться о ролях, добиваться однозначного понимания командой, и признавать, что роли таки разные.

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

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

[-- но мы же не скажем, что "а давайте того, с кем заключён договор на создание приложения, называть «договорщиком», а пользователя, который через него будет делать заказ - «заказчиком»"]
Мы не скажем, а в какой-то команде скажут. И нормально, если будет понятно, какие практики у этих ролей.

Вообще, роли называются по практикам, которые они практикуют. Если инженерная практика -- роль инженер. Если практика закупок (procurement), то закупщик. И так далее.

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

[-- вышесказанное ко всем стейкхолдерам относится?]
Мы не рекомендуем пользоваться термином "стейкхолдер", ибо он таки порождает путаницу: путают исполнителя роли и саму роль. Стейкхолдером и Принца Гамлета легко назвать, и играющего эту роль Васю Пупкина. Васю Пупкина ролью не назовёшь. В учебнике это написано.

[-- предприниматель делает робота для инвалидов, рассчитывая, что роботов будет приобретать и раздавать инвалидам социальная служба. Чтобы договариваться с командой о ролях в проекте, с какого варианта роли для инвалида и для социальной службы начали бы обсуждение?]
Если "инвалид" это роль, то вопрос про роль клиента (роль роли) или пользователя (роль роли) бессмысленный. Иван Петрович -- инвалид (играет роль инвалида, а ещё у него есть роли писатель, отец, инженер). Иван Петрович может быть инвалидом, писателем, отцом и инженером одновременно. Это в треде мы уже разбирали, но использование метонимии (это именно она! в учебнике тоже прописана) продолжается. Этого не нужно делать, от этого как раз проблемы непонимания.

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

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

Так что никаких шаблонов и переобобщений. Тщательное обсуждение для каждого проекта.

ISO42010, например, даёт минимальный состав ролей, который должен быть обсуждён -- и я привожу обычно тамошний список как совершенно недостаточный. Это просто неуклюжий способ авторов стандарта сказать, что ролей много и они не все технические:
The following stakeholders shall be considered and when applicable, identified in the architecture description:
— users of the system;
— operators of the system;
— acquirers of the system;
— owners of the system;
— suppliers of the system;
— developers of the system;
— builders of the system;
— maintainers of the system.

[-- Нет, инвалид - не роль, мы как раз выясняем, в какой он роли! Вот, из перечисленных - он user, operator, acquirer или owner?]
Проблема в онтологике, точной работе с понятиями и отношениями при их более-менее строгой типизации. Инвалид, конечно, роль. А исполнитель роли инвалида (человек) может иметь ещё десяток других ролей -- желательно более конкретных, а не более абстрактных.

Я третий раз уже указываю, что метонимия тут совершенно сбивает с толку -- не разобравшись с тем, что есть роль "инвалид" и есть исполнитель разных ролей "Иван Петрович", мы дальше не двинемся. И ситуацию помощи инвалиду много лучше описывать с использованием роли "инвалид", а не роли "user".

UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216738778395879
А вот ещё одна дискуссия про обобщения в ролях: https://www.facebook.com/photo.php?fbid=2440011399543748&set=a.1377271229151109 -- обсуждаются роли потерпевших от проекта, "как это будет сказать по-русски".