Методология 2025 - читать онлайн

О чём будет, и о чём не будет рассказано в курсе «Методология»

В системном мышлении мы встретили немало синонимов к понятию метода работы в его отличии от работы по методу:

• Метод, способ, паттерн, шаблон работы (way of working) – тут обычно обязательно добавляют «работу», говоря о паттернированности/шаблонности работы.

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

• Иногда с добавлением слова «вид» – вид инженерии, вид труда, вид деятельности, чтобы указать существование множества специализаций метода. Впрочем, имя типа для специализации необязательно, поэтому термины инженерия, труд, деятельность – это тоже метод.

• Иногда с указанием на свойство предмета метода, например, не собственный предмет метода – сервис,

• Функция – если создатель не слишком интеллектуальный и не слишком живой, хотя иногда говорят про функции и людей, и даже оргзвеньев со множеством людей и систем AI.

Метод работы и работа по методу – это виды/специализации поведения/изменения, заключающееся в том, что создатели в момент своей работы/эксплуатации меняют какие-то предметы в своём системном окружении.

Метод – аспект поведения, указывающий на способ/паттерн/шаблон работы создателя по переводу предмета метода через какие-то его состояния, указанные в знаниях/алгоритмах метода.

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

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

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

Сначала для перевода каких-то предметов метода из текущего состояния в ожидаемое конечное надо

• выбрать метод работы (метод выбора метода – стратегирование),

• затем планировать ресурсы (планирование::метод),

• затем задействовать ресурсы для работы.

Метод характеризуется своими знаниями/теориями/учениями/дисциплинами/объяснениями/алгоритмами и инструментарием, который задействуют создатели, выполняющие работы по методу. Создатели имеют мастерство выполнения метода – это особый «инструмент мышления» в составе инструментария, реализующего алгоритм метода. Создатель/constructor – это обобщение вычислителя, универсальный создатель (например, человек или робот с AI) – это который, если дать ему достаточно времени и материалов, может провести все теоретически (согласно принципам физики) возможные преобразования/transformations материалов ровно так, как универсальный (эквивалентный машине Тьюринга) вычислитель может провести все теоретически возможные вычисления/computations, то есть преобразования информации. Создатель при этом ведёт работы (задействует метод для всё новых и новых экземпляров предметов метода), сам не изменяясь в ходе работы (износ создателей в ходе работы, например, износ станка или робота, усталость человека, тут не в счёт – главное, что создатель тут не «расходный материал»).

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

Создатели – это агенты, всё что из методов умеет делать агент (совокупность мастерства агента) – это личность агента.

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

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

Методы могут быть

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

• так и очень общими, уровня мета-мета-модели например, настройка::метод чего-то:: «предмет метода» настройщиком::роль, где сигнатура метода/функции крайне абстрактна и не очень понятно, о какой конкретно предметной области идёт речь.

Пример сигнатуры метода для трёхместного отношения с двумя ролями: передача::метод чего-то:: «предмет метода» дающим::роль принимающим::роль. Можно специализировать метод передачи до покупка::передача::метод чего-то:: «предмет метода» покупателем::принимающим::роль у продавца::дающего::роль.

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

Представление графа состояний для целей контроля этих состояний в виде списка контрольных вопросов о достижении этих состояний в ходе проекта называют чеклистом альфы. Так для альфы подарка:: «предмет дарения::метод» можно определить следующие состояния:

• Необходимость подарка признана (подарок:: «предмет метода» перешёл в состояние «необходим» после применения к нему признания::метод).

• Подарок выбран (подарок:: «предмет метода» перешёл в состояние «известен» после применения к нему выбора::метод).

• Подарок приобретён (подарок:: «предмет метода» перешёл в состояние «в собственности» дарителя::роль после применения к нему приобретение::метод).

• Подарок подарен (подарок::предмет метода перешёл в состояние «в собственности» «одариваемого лица»/«получателя подарка»:: роль после применения метода «передача в дар»:: передача – это специализация передачи::метод).

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

Ввиду сложности работы с методами как объектами первого класса (с которыми явно даются методы работы – моделирование метода, сравнение и выбор методов, развитие метода) уже довольно давно появился метод мышления о методе – методология, базирующаяся на одноимённом трансдисциплинарном/фундаментальном «учении о методе» (теория/объяснения/алгоритмы работы с методом). Метод является предметом методологии как метода мышления о методе, входит в интеллект-стек методов мышления. Роль агента, выполняющего методологическую работу – методолог.

Наш курс посвящён этому «учению о методе», в дополнение к тому, что вы уже знаете из курса «Системного мышления» мы дополнительно изучим:

• Как развивалось знание о методах разработки (которые тоже известны под самыми разными названиями: инженерный процесс, процессы жизненного цикла системы, методы создания и развития системы, методология разработки). Это иногда называют «системноинженерный менеджмент» (SEM, systems engineering management), поскольку непосредственно связывают с организацией инженерной работы коллектива инженеров. Больше материала будет в курсе «Системная инженерия», но надо разобраться, как вообще думать о том, что работы инженеров в самых разных проектах по созданию и развитию самых разных систем проходят не абы как, а в соответствии с каким-то шаблоном/способом/паттерном, то есть по какому-то методу. С одной стороны, в каждом проекте метод работы уникален, с другой стороны, все эти методы разработки имеют общие черты и надо как-то уметь об этом разговаривать, а также проектировать методы инженерной работы.

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

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

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

Моделирование: онтика методологии из курса системного мышления

Выпишите по памяти в первой колонке таблицы понятия типов объектов из онтики методологии (метод, предмет метода и т.д.), которую вы проходили в курсе системного мышления и которая изложена в первом подразделе курса «Методология». Затем уже не по памяти, а сверяясь с текстом первого подраздела, во второй колонке таблицы выпишите понятия типов объектов онтики методологии, но уже не все, а которые вы забыли указать в первой колонке. В третьей колонке укажите процент того, что у вас удержалось в памяти (игнорируйте при подсчёте лишние понятия не из методологии, которые попали в первую колонку таблицы, поделите число понятий в первой колонке на сумму числа понятий в первой и второй колонок и умножьте на сто).

⠀

Что такое методология

⠀

Несмотря на то, что методология относится к фундаментальным методам мышления, её приложения довольно распространены в разных прикладных предметных областях. Прикладная методология просто занимается не «методами вообще», а методами работы с конкретным видом предметов, прежде всего:

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

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

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

• Даже в новом понимании архитектуры архитектор будет заниматься и прикладной методологией тоже, но у него это будет прикладная методология именно методов работы с системной архитектурой, работа со специфическими для этой предметной области объектами: архитектурными характеристиками и их метриками, архитектурными решениями.

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

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

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

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

Термин довольно древний, первым его использовал Платон4, и речь шла о методе, которым производится «познание»/cognition. Но потом получилось так, что «методология» по своему предмету (учение о методе/способе познания) стала неотличима от самых разных других фундаментальных методов мышления. Попытки определить, чем занимаются

• методология,

• научный метод,

• философия науки,

• эпистемология,

сводились к тому, что предметом каждого из этих вроде как разных методов является научное знание (и каждый из этих методов отвечает на онтологический вопрос в том, «каково оно, научное или не очень научное знание, что это такое»). Более того, все эти разные «учения о познании» – это собственно методы получения научного знания.

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

После более чем столетней давности прагматического поворота в философии6 значения слова «методология» и «метод» продолжали меняться и познание/исследование/изучение/learning/cognition перестало быть только моделированием мира, сейчас основное – это изучение методов многоуровневого (действие на многих системных уровнях одновременно) изменения моделей мира и агента (при этом есть и такое мнение, что это общая неразделимая модель мира-с-агентом, главное, что ошибка предсказания становится мала7), а также физического мира и агента. При этом чёткое разделение на мир и агента в этих формулировках оказывается не очень удобным. Как любит говорить Karl Friston, агент не всегда уверен, где его тело, а где уже внешний мир – и поэтому постоянно тестирует границы своего влияния, так что «все взаимосвязанные модели и взаимосвязанные части мира изменяются одновременно, в одном процессе». Как всегда, «о границах системы надо коллективно договариваться, выдвигая и критикуя гипотезы».

Агент/IPU (information-processing unit8) при этом мыслится безмасштабно и его разумность тоже может быть совсем разной: у молекулы нет порождающих/generative моделей мира и себя, у кошки их побольше, а команда людей может иметь множество подробных таких моделей (которые необязательно в мозгу, иммунная система тоже содержит такую модель, отличающую «своё» от «чужого»9, а ещё такие модели могут быть в компьютерах). При этом границы моделей мира и себя, а также границы себя и мира, а также границы модели как программы-для-моделера и себя и мира как моделеров – они тоже размыты, прагматизм позволяет думать о том самом «одном процессе, одномоментном изменении всего». Методология как общее учение о методе даёт набор понятий, которые позволяют думать о таких изменениях. Тут поработали и физики: David Deutsch предложил понятие создателя/counstructor10, которое позволяет рассуждать о методах работы создателя, причём создатель при выполнении экземпляров работ по методу остаётся неизменным – но появляется при этом ход на безмасштабное неантропоцентричное описание методов работы как поведения создателей.

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

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

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

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

Мы разделяем понятия

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

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

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

Слово «методология» может иметь два словарных значения:

• как «учение о методе», то есть «метод мышления о методе» или дисциплина этого метода.

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

Так что «методология разработки XYZ» или «метод разработки KLM», а также «инженерия методов»12 и даже её вариант «ситуационная инженерия методов»13 как один из методов для самой методологии как учения о методе – так вполне можно говорить, а значения слова нужно выделять по контексту.

Это точно такое же использование слова «методология», как и в случае «логики» – она тоже может быть учением о разных логиках, а «Аристотелевская логика» – это одна из логик, изучаемых учением о логиках. Или «геометрия» – это учение о разных пространственных объектах в пространствах разных размерностей, а «Евклидова геометрия» – это один из вариантов геометрии, изучаемых учением о геометриях.

Понятия методологии вы начали изучать ещё в курсе «Системное мышление», понятия методологии неразрывно связаны с понятиями системного подхода (прежде всего современная методология изучает методы работы систем-создателей в графах создания каких-то целевых систем). Более того, в 2018—2022 годах методология входила в состав курса «Системное мышление» и была вынесена как отдельный курс только в 2023 году. Так что смело можно рассматривать курс «Методология» как продолжение курса «Системное мышление».

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

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

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

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

Есть ещё одно название для методологии как общей теории деятельности – праксиология, и у праксиологии тоже есть самые разные понимания того, в чём предмет этой фундаментальной науки18. Например, для праксиологии в варианте австрийской школы экономики предполагались построение на её основе дисциплин экономики, социологии и права, удачным оказался только проект создания самой австрийской экономической школы, совсем чуть-чуть было сделано в области права и практически ничего – в области социологии. Праксиология как методология и её особенности и проблемы затрагиваются в курсе «Системный менеджмент». В «Системном менеджменте» описывается связь менеджмента и экономики, а в части экономики даётся и обосновывается рекомендация изучения экономики в варианте австрийской школы, базирующейся на праксиологии как общей теории деятельности. Наш курс «Методология» не касается праксиологии как общей теории деятельности и исходит из других традиций описания деятельности, которые развивались прежде всего в инженерии и менеджменте на базе системного подхода.

Понятие метода

Метод/way of working (не будем тут перечислять самые разные синонимы) – это в инженерии способ/паттерн/шаблон работ. Это функциональное определение, единица повторной используемости в работе, паттерн/похожесть в выполнении множества работ, относимых к одному методу работы. В мире мы видим работы как изменения при взаимодействии каких-то физических объектов (называемых в случае работ ресурсами). Похожести в действиях работников, связываемые с целями работ, и будут методом/способом этих работ. Метод/функция – это функциональный аспект поведения какой-то системы (если неживой, то чаще говорят функция, если живой – метод или один из его многочисленных синонимов для системы-создателя) как роли/функционального объекта. Работа/функционирование/«задействование/выполнение метода» – конструктивный взгляд на поведение системы как конструктивного объекта.

Если рабочий Петя выполняет рытьё канавы лопатой с 10 утра до 18 часов, а рабочий Вася роет канаву в другом городе, тоже лопатой, причём ночью – то это будет две работы::поведение, но выполняются они по одному методу::поведение «рытьё лопатой» ролями «землекопов», имеющими мастерство «рытьё лопатой», имеющими лопаты и работающими с предметами метода – канавой, проходящей состояния (это пример! В каждом проекте тут будет разное, на разном уровне детальности!) «определено, какая по глубине канава нужна и где она будет», «работник с лопатой для рытья выбран», «рытьё происходит», «канава вырыта».

Так что метод::поведение роли/«функционального объекта» с (функциональными) предметами метода реализуется в физическом мире работой конструктивного объекта с предметами работы. Но так не говорят, а говорят о применении метода в работе или выполнении метода.

В методе/практике/«виде труда/инженерии» вполне могут быть шаги во времени как последовательности операций, но они даются как относительные, без привязки к конкретным моментам времени, иногда говорят о «логическом времени».

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

Так что тут всё то же самое, что с воплощением ролевых объектов конструктивными объектами: как «принц Гамлет»:: оргроль появляется в физическом мире, когда его играет/реализует/воплощает «Вася Пупкин»:: оргзвено (а до этого есть только её описание, но принца Гамлета в физическом мире нет), так и «моделирование табличками»:: метод появляется в мире только в момент его реализации работой «моделирование в курсе методологии в ходе занятий 23 мартобря 2024». Метод работы «моделирование табличками» при этом выполняются оргролью «модельер» (если рассматривать метод инженерии мастерства, то метод работы будет «выполнение домашнего задания» – мы можем одну и ту же работу рассматривать как выполнение разных методов работы разными ролями, это ОК), а вот работа – конкретным оргзвеном, играющим роль студента и роль модельера, например, Зинаидой Фёдоровной (а то, что студент, модельер и Зинаида Фёдоровна – это один и тот же объект, это нам даст 4D экстенсионализм: если обсуждаем одно и то же место в пространстве-времени, то это один и тот же предмет, даже если называем его по-разному).

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

Конечно, во взаимодействиях и изменениях в ходе работ по методу задействованы самые разные физические объекты и даже абстрактные объекты (описания) – рабочие продукты (расходные материалы, инструменты, оборудование), а также описания самых разных систем. Мы называем это всё «предметами метода», для нас важно, что по ходу выполнения метода эти предметы метода будут менять свои состояния. Сигнатура – это просто название метода и определение предметов метода в желаемом состоянии. Потом надо будет предъявить разложение метода (следуем математической аналитической традиции, «декомпозиция») или, что то же самое, наоборот – синтез метода (следуем инженерной традиции, как в «синтезе программ» и «логическом синтезе»). Например, сигнатуру метода «рыть::метод котлован:: „предмет метода“», дальше можно разложить на «рыть лопатами» или «рыть экскаватором», они будут различаться инструментарием и мастерством создателя (умение управлять экскаватором или управлять лопатой).

Помним из курса системного мышления о том, что нам удобно использовать понятие создателя, как его определял David Deutsch в constructor theory: это такая система, которая многократно может изменить/transform какие-то другие системы, сохранив при этом себя неизменной. Например, молекула-катализатор. Или станок. Или робот (станок с компьютером). Или человек (который может изготовить пять роботов, оставшись при этом неизменным, или даже изготовить человека, оставшись при этом неизменным!). Или транснациональная корпорация. Важно, что это обобщение вычисления с преобразования информации на все возможные изменения физического мира. И ещё помним, что методы могут описываться как последовательности операций (императивно), как набор логических высказываний о мире, как применение набора функций – знания создателя могут быть в самой разной форме (принцип соответствия Curry-Howard, унивалентные основания математики – это всё довольно тщательно обсуждается в computer science и конструктивной математике). Универсальный создатель тем самым похож на универсальную машину Тьюринга: он потенциально может выполнить любое преобразование физического мира, следуя алгоритму. Если создатель не совсем интеллектуальный (и мы говорим не о методе, а о функции), это не меняет общий ход рассуждения (подробности такого неантропоцентричного подхода к интеллекту даются в курсе «Интеллект-стек»).

Методы обычно дробны, они раскладываются на составляющие, тоже методы. Иногда говорят подметоды, но тут может быть путаница между разными видами отношений, скрывающимися за приставкой «под», чаще всего это отношения:

• Композиции/декомпозиции (часть-целое). Это отношение плохо определено для процессов (хотя есть способы об этом думать через части-целые создателя и предметов метода в 4D – но тогда проще сразу говорить про части-целые создателя и предметов метода, а не части-целые поведения).

• Разложение/составление (не сводимое к «частям целым»). Для «приготовления борща»:: сигнатура (приготовление::метод, борщ:: «предмет метода») мы будем «пассировать овощи»:: сигнатура (пассировать::метод овощи:: «предмет метода») и «варить овощи»:: сигнатура (варить::метод, овощи:: «предмет метода»). Борщ:: «предмет метода» будет проходить состояния задуман, продукты закуплены, готовится, готов, съеден.

• Специализации (род-вид). Подметоды производства – это аддитивное (например, 3D-печать) и субтрактивное (например, фрезерование) производство.

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

• Метод/методология разработки – это самое крупное деление, «все методы, необходимые для выполнения проекта».

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

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

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

«Разделение деятельностей/методов/практик» и «углубление разделения деятельностей/методов/практик» обычно не говорят, дробность по агентам обсуждают традиционно главным образом со словом «труд». Но вполне могут сказать «подпрактика», «рабочий подпроцесс», но не «подтруд» или даже «подметод», «поддеятельность». Избегают говорить про «надметод», говорят просто «метод» (помним, что чем крупнее метод, тем больше вероятность, что его назовут методом или методологией).

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

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

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

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

Зачем изучать методологию

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

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

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

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

• Методология нужна только прикладным методологам (тем, кто занимается функциональностью каких-то целевых систем или систем-создателей). Размышлять о методах, моделировать/описывать методы нужно редко. Например, при создании учебных курсов методологию нужно знать только тем, кто занимается ролью методолога, а в менеджменте – только тем, кто занят описанием рабочих процессов (если оно вообще делается). Производственникам и менеджерам в целом она не нужна, а если уж кому приспичит (в какой-нибудь «службе качества», где проверяющие потребуют очередной «список методов» или «список процессов», как обычно, не имеющий отношения к тому, как реально проходит работа) – то и без обучения разберутся, все эти «службы качества» аналитические по принципу, никакого качества они на-гора не выдают, а просто готовят какие-то описания для разных проверяющих да инвентаризующих. Учить этих людей можно, но необязательно: свои пухленькие стандарты они и без «методологии» прочтут. Если верить этому аргументу, то «методолог» – это не роль человека, который рассуждает о методе, а должность. Нет, «пловец» – это не только спортсмен, который плавает где-то на соревнованиях как член команды пловцов, это любой человек, которому нужно проплыть из точки А по воде в точку Б, и нет ни лодки, ни спасательного круга. И в этот момент надо понимать: дана только сигнатура метода, но не его разложение. Так что дальше выбор – плыть топориком, по-собачьи, кролем или брассом. Неплохо бы знать при этом различия этих стилей. И ещё в этом «плыть» целый стек методов, например, надо ещё знать, как дышать. И ещё как управлять усилиями в теле – это делается одинаково для всех выбранных стилей плавания. С методологией так же: если обсуждать «как будем работать» (обсуждать метод/способ работы, way of working), то неплохо бы знать, на какие объекты в мире обращать внимание – например, такой объект, как «сигнатура метода». Нужно знать типы мета-мета-модели «из учебника» (типы объектов, обсуждаемых в нашем курсе «Методология»), чтобы обсуждать затем организацию работы в проекте.

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

Аргументы за изучение методологии:

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

• Большинство людей, которые явно занялись методологией в инженерных и менеджерских проектах, были поставлены перед проблемой научить какую-то новую команду работать каким-то методом, которым они владели неосознанно. Они не знали, чему именно нужно учить людей: «что такое метод», как о нём рассказывать. Такая проблема (научить новому способу работы/way of working какую-то команду, адаптировав этот способ работы к новым условиям) появляется перед людьми чаще, чем можно подумать. Проблема переноса и адаптации метода работы появляется практически в каждом проекте. Правильно было бы сэкономить время на изобретение велосипеда: дать людям в этой ситуации знания по методологии как таковой, а не только по конкретной технологии/методу/практике. Выучить один раз (наш курс!), а потом использовать во всех рабочих проектах.

• Если «простой практик/деятель» (инженер-конструктор, менеджер, врач, политик и т.д.) не осваивает постоянно новые методы/практики, то он порастает мхом, его работа обесценивается, он становится неконкурентоспособен. Чтобы он мог эффективно обновлять свои знания, ему нужно уметь сравнить два метода: его собственный и новый (а новых методов – множество, их эффективность обычно неочевидна), и принять решение о том, какой из них SoTA. Для сравнения методов надо понимать, какие объекты внимания есть в методе и как их можно сравнивать, для этого надо понимать, как моделировать метод.

• Все предыдущие пункты – это про методологию в составе интеллект-стека, то есть про фундаментальную дисциплину, которую надо знать хотя бы на уровне кругозора. Роль прикладного методолога в разработке прямо подразумевает профессиональные занятия методологией, то есть глубокое знание методологии как метода собственной работы, а ещё глубокого разбирательства в методах своей инженерии/труда/практики – будь то образование, медицина, кораблестроение. Подробней об этом будет в курсах «Системная инженерия», «Инженерия личности», «Системный менеджмент», подроль методолога будет у роли разработчика, исполняют её обычно самые опытные разработчики. Вот им и надо не просто знать методологию, «как всем», но владеть ей на более профессиональной степени мастерства.

Приложения методологии уже начинают изучать и на производстве, и в вузах, и не только неявно (то есть знакомством с разными Body of Knowledge как формой представления знаний о методах работы и неявным пониманием, что они по большому счёту устроены все примерно одинаково), но и явно – через изучение методологических стандартов (обычно посвящённых какой-то записи способа работы, это OMG Essence:2024, популярный у инженеров ISO 24774:2014 и многие другие, обычно применяющиеся для описания «рабочих процессов», «процессов разработки», «видов жизненного цикла» и тех самых BoK по разным методологиями разработки). Эти стандарты стремительно отстают от жизни, и нужно иметь более общее знание о том, как устроены такие стандарты, чтобы замечать отставание и не следовать таким стандартам слепо.

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

Методология в интеллект-стеке

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

• Использовать уже имеющееся знание о прикладном методе. Это прикладная методология, задействования мета-модели: в данной конкретной ситуации с конкретными объектами предметной области надо что-то сделать – вот брать теории/знания/объяснения/алгоритмы предметной области, и делать. Скажем, у вас ситуация проектирования метода лечения какого-то больного жирафа. Берём предметную область ветеринарии, далее делаем назначения, сообразуясь с лучшими на сегодня знаниями о том, как лечить зверей, а ещё лучше – именно жирафов. То есть важное тут задаётся типами уровня мета-модели, далее делается модель ситуации в этих типах – и, соответственно, в этой ситуации мы создаём модель метода лечения конкретного жирафа в его конкретной ситуации, а затем планируем работы по лечению. Конечно, эти шаги стратегирования и планирования могут чередоваться: мы выбираем не любой метод, а исходим из ресурсных ограничений, то есть шаги стратегирования и планирования взаимосвязаны – но рекомендация всё-таки сначала разбираться с вопросом «что будем делать», а затем уже «какие ресурсы берём и в какой момент что с этими ресурсами делаем», сначала обсуждаем функциональный аспект, и только потом – конструктивный. Если есть какие-то проблемы и результаты работы прикладного метода не соответствуют ожидаемым (оказались в неизвестной ситуации, «видим что-то неожиданное, происходит что-то непонятное, что и с чем делать – непонятно»), то переходим к работам на более высоком уровне абстракции, это изложено в следующем пункте текущего списка подходов к выбору метода.

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

• В современном интеллект-стеке признаётся, что кроме представления о методах работы в форме локальных (символьных) представлений с типами и отношениями, а в более современных вариантах – с типами и операциями конструирования типизированных объектов (конструктивный подход в математике и логике, переход к алгоритмам от логических «доказательств»), существует вариант с распределёнными представлениями. И тогда можно применить representations learning, «обучение представлениям» – и какая-нибудь нейросеть (включая, заметим, и «мокрая» нейросеть человека, и «сухая» нейросеть какого-нибудь робота) может выполнить выявление паттернов как предметов метода, так и паттернов эффективных действий с ними. Скажем, можно пробовать сформулировать метод вождения автомобиля в виде набора правил, но можно просто обучить нейросеть на примере огромного числа дорожных ситуаций, и есть множество методов подобного обучения. Скажем, так ставит проблему команда Виталия Ванчурина, которая использует закономерности физики для выработки стратегии (в мире искусственного интеллекта стратегию часто называют policy). Подход этой команды сводится к тому, что важную информацию не нужно извлекать «грубой силой», но можно использовать понимание симметрии системы, чтобы извлечь очень небольшое число важных типов, описывающих важные объекты (команда называет эти типы «инвариантами»), чтобы получить работоспособные стратегии20. Вся литература по «обучению с подкреплением» (reinforcement learning) по большому счёту – это литература по стратегированию, обучению выбору действий в незнакомой ситуации методом проб и ошибок, при этом известно, что будет ошибкой (известная «функция награды»). Современная методология наиболее бурно развивается как методология в распределённых представлениях. Мы её не будем подробно касаться в нашем курсе, но вся проблематика современных систем с искусственным интеллектом – она связана со стратегированием и планированием в распределённых представлениях.

Тем самым понимание того, как же мы работаем с методами, как мы выбираем метод, существенно связано с тем, как мы представляем/represent этот метод:

• В локальных представлениях – на каком уровне абстракции (мета-мета-модель, мета-модель, модель)

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

Так что для разбирательства с современной методологией надо разобраться с современной семантикой (учение о представлениях, раньше – только локальных, а теперь локальных и распределённых), которая в свою очередь отсылает к физике и математике, а также семиотике и обучению представлениям (representations learning) в случае нейросетевых технологий с их распределёнными представлениями:

При этом для коллективного обсуждения методов и эволюции/развития методов нам всё равно требуются локальные представления. Без локальных представлений нельзя передать компактно информацию о методе из, например, какой-то «сухой» нейросетки, которая научилась что-то делать в «мокрую» нейросетку человека, чтобы он научился делать что-то подобное. Скажем, программа AlphaGo научилась играть в Го лучше чемпионов мира. Но вот передать это знание людям программа не может, указать на важные объекты в игре – не может. Проблема совмещения работы с локальными и распределёнными представлениями (другое её название – «нейросимволические вычисления») на сегодня в AI не решена. Более того, не решена и проблема стратегирования и планирования в распределённых представлениях для искусственных интеллектуальных агентов. Выбирать длинные цепочки методов и затем строить разумные планы выполнения длинных цепочек действий на текущий момент системы искусственного интеллекта не могут.

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

Тут ещё надо заметить, что понятия policy и plan в AI относятся к выбору метода и планированию одновременно, а в менеджменте стратегия и план – различаются предметом (стратегирование – про выбор метода, а планирование – про построение графика работ и оптимизацию использования ресурсов для выполнения работ по методу). Более того, policy – это понятие для современного AI, работающего с распределёнными представлениями и задействующего обучение с подкреплением, а в старом «логическом» (с экспертными системами) искусственном интеллекте прошлого века понятие «план» ещё и как в классическом проектном управлении – это up front plan (то есть полное планирование перед производством всех работ, что в реальной жизни уже признано практически недостижимым, кроме довольно редких ситуаций). План будет представлять собой строго определенную последовательность действий, ведущую от начального состояния предметов метода к конечному (ну, он может быть и сложнее, если у вас есть параллелизм, но это все равно основная идея). Политика будет определяться набором пар «состояние предмета метода -> действие», которые должны позволять из любого достижимого состояния в конечном итоге достичь заданного сигнатурой метода состояния23.

Интеллектуальные агенты из всего множества IPU (живых и неживых) выделяются как раз как способные спроектировать по каким-то методам изменения в своих моделях себя и окружения, а также себя и окружения как предметов методов, а также запланировать и провести действия по этим изменениям. Это довольно большой спектр систем, микробы тут вряд ли будут подходить под «интеллектуальных агентов», кошки – в малой степени, а вот люди и тем более «люди с компьютерами»/cyborgs или даже «компьютеры с людьми в их составе»/hybrots как оргзвенья – вполне подходят. И когда мы говорим об агентах, мы чаще всего будем представлять не просто систему-агента, но интеллектуального агента, причём чаще всего – агента-создателя где-то в графе создания какой-то целевой системы.

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

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

• Всегда есть более одного варианта разложения метода, и они абсолютно разные в части задействуемых ресурсов и качества результата. Возможно, вам надо разложить метод на несколько уровней вниз. Если вы считаете, что есть только один вариант, никаких «развилок», никакого принятия решений по выбору из нескольких вариантов методов/способов действий, то вы что-то упустили. Подумайте ещё и вспомните, погуглите или спросите у AI-ассистента, примените какие-то приёмы генерации идей.

• Затем примите рациональное (то есть на базе лучших теорий принятия решений) решение: выберите между альтернативами. Это будет неоптимальный выбор, «наименее худшего из всех имеющихся» (ибо лучший метод или вы не знаете, или его ещё не изобрели).

• Обоснуйте выбор, приведите его инженерное обоснование.

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

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

Так что для работы с методами нужно ещё и уметь рационально принимать решения, опираясь на лучшие известные нам контрфактуальные объяснения. И это мы даже ещё не весь интеллект-стек методов мышления прошли.

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

Ещё нужна риторика, чтобы как-то убедить других агентов следовать методу. Так что для понимания и практикования методологии нужно быть высокообразованным человеком, то есть человеком с сильным интеллектом, то есть человеком, который бегло владеет всеми методами мышления интеллект-стека. Собственно, прохождение нашего курса «Методология» в какой-то мере продвигает в решении этой задачи.

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

Вот, например, праксиология в варианте Murray Rothbard24 от 1951 года (и нельзя сказать, чтобы человечество сильно продвинулось в построении этой праксиологии):

1. Теория изолированного агента (экономика Робинзона Крузо)

2. Теория добровольного межличностного обмена (каталлактика, или рыночная экономика)

2.1. Бартер

2.2. Со средствами для обмена

2.2.1. Свободный рынок

2.2.2. Эффекты насильственного вмешательства в рынок

2.2.3. Эффекты насильственного запрета рынка (социализм)

3. Теория войны – враждебная деятельность

4. Теория игр (например, работы von Neumann and Morgenstern)

5. Неизвестное

Как при этом должны быть устроены сообщества, общества и человечество в целом политически и как там должно быть устроено право, основанное на праксиологии как общей теории деятельности – это большой вопрос. Наш курс методологии не будет касаться в текущей версии практик/деятельности/труда сообществ, обществ и человечества, равно как будет мало говорить о «методе работы станка» или «методе работы робота», хотя в этом случае всё будет проще и понятней, разве что станок и робот не могут принимать решений о методе своей работы, это за них делают люди и организации людей, в состав которых входят и станки, и роботы. Но сейчас с развитием машинного интеллекта возможен и другой вариант рассмотрения: какой-нибудь отдел может быть представлен как компьютер, в состав которого входят люди – и по мере развития постепенно люди замещаются компьютерами, это и есть тренд «автоматизация всего», концепция киборга (cybernetic organism) как образа агента будущего заменяется концепцией гиброта (hybrot – hybrid robot25).

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

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

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

• Фундаментальное методологическое мастерство (из методов мышления интеллект-стека, раскрывается в нашем курсе «Методология», более подробно его место в интеллект-стеке раскрывается в курсе «Интеллект-стек»). Это умение рассуждать о методах, сравнивать методы, описывать методы, убеждаться в реальном выполнении методов в ходе работ (например, умение создавать чеклисты). Это уровень мета-мета-модели.

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

Так, из фундаментальной методологии вы знаете, что в ходе создания какой-то системы вам нужно будет создавать функциональные описания – и без этого никак нельзя. Всегда будет вопрос «как оно работает», и ответ должен быть методологический: надо описывать, какими методами мы меняем состояние каких предметов метода. Но дальше надо владеть каким-то кругозором многочисленных методов работы и уметь выбрать подходящие методы работы для получения в ходе работы по этим методам необходимых состояний объектов – это владение предметной областью, но не просто прикладной/предметной онтологией как описанием объектов и отношений в предметной области, но и прикладной/предметной методологией – описанием методов изменения состояний объектов предметной области, специфичных для этой предметной области.

Моделирование: выбор метода

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

Метафора разложения метода в стек. Спектр мастерства по стеку методов как спектральной шкале

⠀

Есть множество трудностей с пониманием самого понятия метода работы – очень трудно представить себе, что же это такое. Так, легко представить себе бегуна, но если попробовать представить бег этого бегуна, то представится опять-таки бегун, хотя и «развёрнутым видео бегуна в движении», без бегуна представить бег сложно, это ведь поведение без того, кто как-то себя ведёт. Похоже на попытки обсуждения Чеширского кота: улыбка кота есть, а самого кота нет. В 4D экстенсионализме это нормально, это подробно разбиралось в курсе «Системное мышление».

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

⠀

Одна из трудностей тут – путаница между:

• самим методом как тем, что происходит в жизни в ходе работы,

• описанием метода,

• методом обучения мастерству выполнения метода (в том числе описание метода путают с описанием метода обучения мастерству выполнения метода).

⠀

Скажем, когда пловец участвует в заплыве, то он одновременно дышит по какому-то методу, гребёт руками по какому-то методу, выполняет правила заплыва, то есть участвует в соревнованиях – и эта «одновременность» характеризует сам метод в момент его выполнения. А вот как это обсуждать? Обсуждаем описание – и отдельно обсуждаем метод дыхания как составляющую метода плавания, который сам будет составляющей метода участия в заплыве, метод выполнения гребков, методы участия в заплывах. А как это описывать – описывать это «одновременно» не получится, ибо всего много, всё слишком запутанно. А вот по-отдельности – описывать можно. При этом не забывать, что описания раздельны, а в момент выполнения метода – всё происходит одномоментно, причём порядок и самого описывания/моделирования, и затем чтения модели не соответствует происходящему: моделирование и чтение моделей составляющих последовательны, а в жизни составляющие происходят одновременно.

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

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

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

Роман Варьянко предложил метафору не математического «разложения функции в ряд», а «разложение света в спектр», что выполняет примерно ту же функцию разложения сложного объекта не-вещи на составляющие.

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

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

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

Вот именно спектры от разных источников света:

Дальше надо бы рассмотреть много терминологических нюансов. Например, разложение в спектр света на английском – dispersion/дисперсия, ибо так это назвал Ньютон. Бывают и разложения в спектр не света или электромагнитных колебаний по длинам. Можно брать масс-спектры, где линии спектра соответствуют отношению массы к заряду иона (характеризуют природу иона, разные ионы имеют разные отношения массы к заряду), а высота линии – соответствует концентрации иона. Там тоже смесь ионов существует как одно целое и происходит разложение для понимания, из каких ионов составлен раствор. Но в растворе нельзя как-то выявить один вид ионов как его истинную часть, они же там все перемешаны, нет границы между ионами разной природы в их растворе! Иногда разложение даётся как spectral decomposition, таки «разложение», а вот разложение в ряд в математике – это расширение (expansion series).

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

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

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

Вернёмся к этому примеру и представим его в виде спектра степени мастерства танцоров по шкале из разложения методов в некоторый стек составляющих методов, разве что заменим «метод» словом «культура» – это синоним «метода», означающий, что метод получил распространение:

Онтологически различаем разные типы, которые тут отображены:

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

• Предметы метода – функциональные объекты, предметы работы – конструктивные объекты (которые тоже могут быть заданы типами). Помним, что нам желательно заземлять все предметы методов, ибо в конечном итоге нам надо изменить физический мир, но предметы метода в общем случае могут быть и описаниями.

• Культуры характеризуются их теориями/объяснениями/алгоритмами, но это знания, которые только описывают поведение точно так же, как алгоритм описывает вычисление по нему, он сам – не вычисление. Один алгоритм описывает множество вычислений, которые можно выполнить над самыми разными входными данными этого алгоритма. Метод – это «обобщённое вычисление как преобразование/transformation входов в выходы, в том числе обобщённое на объекты реального мира», производимое какой-то программой как «алгоритмом, по которому идёт обобщённый вычислитель как создатель/constructor».

• Составляющие для культуры социальных танцев – это отдельные культуры, каждая работающая со своими предметами методов. Эти культуры и будут «шкалой спектра» для мастерства отдельного агента. Её можно считать как-то упорядоченной в «стек» методов, аналогичный в каком-то смысле платформенному стеку, об этом чуть ниже.

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

Хотя мы легко могли бы предложить и другие варианты спектрального представления (кроме спектра мастерства в выполнении метода, тут «культурного мастерства») для метода, разложенного в этот же стек:

• спектр общепринятости (распространённости этой культуры среди населения),

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

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

Шкала разложения методов для спектра мастерства по ним нами представлена как «стек методов», аналогично платформенному стеку – и тут примерно те же ограничения (начиная с того, что платформенный стек не столько стек, сколько «дерево», об этом скажем чуть позже). В социальных танцах на верхнем уровне мы можем говорить об их общей культуре, в серединке – культуре отдельных танцевальных стилей, внизу – о каких-то телесных практиках, нужных для танцевания. Можно говорить о «стеке», если обсуждаем разложение разных методов. Если делаем замер мастерства – о том же «стеке» говорим как о «шкале спектра».

Если это мастерство разбираться с чем-то новым, ранее не виденным, то его мы называем интеллектом – для прикладных методов это будет прикладной интеллект. Грубо говоря, в ПТУ учат действовать в хорошо известной ситуации, дают мастерство, а в университете – учат действовать в новых ситуациях, дают интеллект. Подробнее – в курсах «Инженерия личности», «Интеллект-стек».

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

Но проиллюстрируем идею «стека» как шкалы для разложения мастерства плавания. Вот вам табличка для разложения в стек культуры плавания (авторство Юлии Чайковской). Посмотрите, насколько сложней реальный пример того учебного примера, который мы рассмотрели в начале подраздела (см. таблицу ниже).

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

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

«Оценить культуру плавания» – это частый способ говорить об общем мастерстве в самых разных культурах, в которые разлагается культура плавания. Или даже не просто мастерстве, о его высшем виде мастерства – прикладном плавательном интеллекте, если речь идёт о решении проблем в самых разных новых ситуациях, в которых приходится плыть. Для этого вы можете оценить свой уровень владения каким-то из упомянутых в табличке методов из «плавательного стека», и построить ваш спектр мастерства.

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

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

Вот практики (возьмём ещё один синоним) картинга на базе того же разложения телесной культуры, которое мы использовали для танцев и плавания27:

Вот капоэйра в таком же представлении, уберём оттуда линю спектра мастерства28:

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

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

• объяснение того, что в одной и той же работе какой-то системы (в том числе системы-создателя, работе агента) можно увидеть много разных шаблонов/методов, как много разных «частных» цветов можно увидеть в белом «полном» свете (много частей спектра29 можно разглядеть в полном спектре, «разглядеть» тут – буквально, spectrum – это «видение» от латинского spectare, «смотреть»). Говорим о шкале.

• объяснение того, что мы можем переиспользовать какую-то часть разложения метода как «методы платформы», «основание стека методов», а другую – заменять. Говорим не столько о шкале, сколько о «стеке».

Моделирование: разложение культурного движения в стек

Представьте табличку разложения какого-то знакомого вам метода культурного движения (спорт, единоборства, танцы, паркур и т.д.) по образу и подобию таблиц из предыдущего подраздела. Укажите свою степень мастерства в каждой из субкультур (по десятибалльной шкале, 0 – «вообще не умею», 10 – «я олимпийский чемпион»).

Представление разложения метода деревом

Метафоры спектра и стека, конечно, не полные представления о методе, они одномерные и поэтому крайне невыразительные. А ещё все эти «стеки», конечно, ни разу не линейные стеки, а графы-деревья, их трудно представлять стеком. Всё то же самое, что и с системными уровнями: вроде как платформенные уровни выглядят «уровнями стека» и подразумевается «матрёшка», но нет, там много разных матрёшек внутри каждой матрёшки.

Так, semantic web technology stack легко гуглится, он также называется semantic web layer cake, но слои в нём весьма и весьма условны (более того, ещё и на разных картинках разных авторов их число и состав разнится). Вот только один из вариантов изображения этого «слоёного пирога», обратите внимание, что там отнюдь не только плоские «блины» в этом пироге, не получается чистой «стопки», это и есть беда всех «стеков» в платформах и разложениях методов:

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

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

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

В старом понятии архитектуры (примерно до 2017 года, когда именно архитекторы создавали концепцию системы в целом как «самые опытные разработчики») это означает, что функциональные описания в рамках разработки архитектуры делают разработчики-проектировщики. Вот доклад 2021 года одного из главных архитекторов крупной (единорог) компании, который так и изображает эту проблему в заголовке: «как из одного архитектора вырастить 100+ архитекторов»30. В самом докладе говорится главным образом о том, как сделать, чтобы разработкой функциональных описаний (методов, которыми работает система) занимались 100+ сотрудников, которых мы сейчас назвали бы прикладными методологами своих частей проекта общего проекта создания системы. А современное понятие архитектора подразумевает как раз разбиение системы на модули такое, чтобы прикладные методологи были по возможности автономны в своих решениях. В разработке каждого «микросервиса» в инженерии корпоративных программных систем надо определить его функцию и сделать так, чтобы все предложенные функции микросервисов укладывались в предложенный архитектором способ разбиения на части конструкции из микросервисов и способы организации коммуникации между этими частями конструкции. Это нужно для того, чтобы достичь удовлетворительных значений каких-то архитектурных характеристик «-остей», например, малое время отклика (малая латентность), высокие показатели доступности, высокие показатели в наработке на отказ (надёжность).

Если в порядке разделения труда для роли разработчика выделить роль методолога, владеющего методами работы предметной области и роль проектировщика, который задействует результаты методологической и архитектурной работы для разработки и реализации концепции системы – этот доклад смотрелся бы совсем по-другому.

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

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

Есть множество методов (в том числе методов описания системы, удобных для применения этих методов) ведения методической, методологической и архитектурной работы в их взаимоувязке. Для примера мы можем использовать классический фреймворк Wim Gielingh из работы «A Theory for The Modelling of Complex and Dynamic Systems»31, он был использован как один из источников идей для семейства стандартов описания систем STEP, ISO 15926 и далее BIM.

Gielingh вводит понятия functional unit (функциональный объект, «роль» – то, что будет задействовать метод) и technical solution (конструктивный объект, который выбран как аффорданс для реализации роли, то есть выполнения работы функции/метода) и показывает концепцию системы в ходе её эволюции, то есть создания и развития: каким образом происходит совместный функциональный синтез/декомпозиция и модульный/конструктивный синтез/декомпозиция. Если смотреть на диаграммы снизу вверх – синтез, «разработка снизу вверх», bottom-up. Если смотреть на диаграммы сверху вниз – декомпозиция, «разработка сверху вниз», top-down. В реальности же рекомендуемый метод разработки – «изнутри среднего уровня наружу вверх и вниз, inside out»). Вот предложенная нотация концепции системы для определения системных уровней с учётом отношений род-вид и выбора вида:

Такая нотация называется гамбургер-диаграмма, где указывается множество кандидатур методов в разложении для какой-то сигнатуры (обсуждение ведётся не в терминах самих методов, а в терминах ролей, работающих по этим методам, Functional Units, FU) и дальше метод назначается какому-то типу конструктивов (Technical Solution), чтобы разобраться с модульностью в порядке формирования концепции системы. «Гамбургер» тут – половинки булки, между которыми «начинка» – это выбор назначений технических решений (конструктивы) на функциональные единицы (роли). В нотации предложено принимать решения по модульности на каждом уровне функциональной декомпозиции, чтобы поощрить выделение модулей в целях унификации. Но современные архитекторы сказали бы, что такой принудительный ход на унификацию модулей – способ ввести межмодульные зависимости, поэтому подход Gielingh не получил особого распространения, умер вместе с очень популярной в 90х годах идеей разработки модулей с повторной используемостью, reuse. Это подход второго поколения системного мышления, где система разрабатывалась как экземпляр, но не как развивающийся вид, не было «непрерывного всего», разработка мыслилась итеративной, но однократной.

Фреймворк от Gielingh важен тем, что различает generalization hierarchy (иерархия сигнатур), specification hierarchy (выбор вида из рода) и installation hierarchy – уже выбранное по типу и инсталлированное как экземпляры в целевой системе, работающее – и делает это на уровне проектирования («воображаемый проект») и конфигурации конечной воплощённой системы (as built). Вот шесть иерархий, служащих предметами рассмотрения во фреймворке Gielingh – верхний ряд это «воображаемый проект» в его общем/генерализованном виде, а нижний ряд – это с конкретными расчётными функциями и указанными уже моделями конструктивов, самого Gielingh тут интересовала знаниевая работа над проектом, уточнение ролей с какими-то их методами работы и их поддержки со стороны конструктивов:

Эта диаграмма характеризует важное для методолога, разработчика и архитектора:

• Методологу надо рассмотреть альтернативы разложения метода для какой-то сигнатуры. Если у вас в системе предусмотрен метод «чистка зубов», то вам надо рассмотреть варианты еды на ночь семян кунжута (удивительно хорошая очистка!), использования зубной нити, зубочистки, зубной щётки или ультразвуковой щётки с выбором из многих видов зубной пасты и вариантами щёток (например, V-образная зубная щётка, если у вас брекеты), задействование ирригатора (чистка водой под давлением), и т.д.. Каждый метод обладает своими плюсами и минусами, а если это верхнеуровневый метод, то может быть реализован очень по-разному, его составляющие будут иметь в свою очередь, разные разбиения – и надо будет опять выбирать, и там, скорее всего, будут какие-то другие предметные области. Это и есть работа. По большому счёту, именно методолог делает «разузловку», разбиение системы на функциональные единицы. Понятно, что в силу разделения труда это очень плохо делать «сверху вниз», ибо ключевое понимание того, как же именно работает система, будет на нижних уровнях. Но это уже нюансы, о которых будет в курсе «Системная инженерия».

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

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

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

⠀

«Схемотехника»: представление метода работы графом потоков

А дальше можно сразу обратиться к традиционному представлению методов в виде функциональной диаграммы, часто называемой принципиальной схемой. Такие диаграммы разбирались в курсе «Системное мышление»: предметы метода текут/flow между создателями, которые меняют их состояния. Если это непрерывные потоки (поток/flow – это идентификация объекта на основе сохранения маршрута/пути, определение из ISO 81346:2022), то примеры сразу очевидны – методологи там называются «схемотехники», они строят принципиальные (принципиальность – это указание на функциональность, «метод работы», а не конструктивность) электрические схемы, радиотехнические схемы, но могут быть также и гидравлические схемы, и кинематические схемы и самые разные другие схемы.

• Так что очевидный следующий шаг в выражении методов – сразу пройти весь путь: от последовательностей/chains (последовательности методов, например, «стек» тут тоже последовательность вложений или последовательность использования, да и «шкала» – последовательность, упорядоченность в ряду объектов)

• к деревьям/trees (хорошо представимы разными MindMaps, которые легко сводимы к аутлайнам/outlines, по факту это «хорошо структурированное оглавление», где в листьях этого оглавления могут лежать какие-то более подробные описания, фреймворк Gielingh с диаграммами гамбургера как раз такой граф «почти дерева»),

• и далее к графам/graph как общей форме представления потоков чего бы то ни было – в том числе предметов метода между ролями, задействующими метод.

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

Потоковые (движение предметов метода по каким-то путям) представления, удобно представимые графом, распространены и в менеджменте. Фон Берталанфи выделял исследование потоковых представлений систем как «исследование операций» (operations research), речь шла о времени эксплуатации (operations) – и эта дисциплина легла затем в основу операционного менеджмента, логистики, теории массового обслуживания. Конечно, в исследованиях операций в основе лежали «работы», речь шла прежде всего о потоках ресурсов между рабочими станциями. Но это можно было представить и как специфически функциональное представление: «рабочая станция» – это ведь роль, её могут выполнять разные конструктивы, она может действовать разными методами (прикладными методами операционного управления!). Опять мы попадаем в то, что методология – фундаментальная дисциплина, и даже если речь идёт об управлении работами по методу, то это рассмотрение может быть функциональным, и тут методология будет задействована для разбирательства с работами и работниками как прикладная методология операционного менеджмента – несмотря на все предупреждения «не путать метод работы и работы по методу». Методы исследования операций, методы проектного управления работами, методы операционного управления – это всё методы, только ими занимается прикладная методология этих предметных областей.

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

• Вы смотрите на них, как на «пассивную модель». Это означает, что интерпретатором модели является «тот, кто смотрит», алгоритм в вашей голове в виде программы «мастерство рассмотрения принципиальной схемы», а граф – данные для этой программы. Помним из курса «Рациональная работа», что модель – это программа, она исполняется, чтобы получить результат моделирования. Исполнитель программы, даже если он «просто смотрит на диаграмму» – тот, кто смотрит на эту диаграмму, и он также проводит с помощью диаграммы рассуждение, получает результат моделирования. Если нет рассуждения по диаграмме, то диаграмма не нужна. Когда вы пытаетесь разобраться в ходе ремонта «почему не работает», это как раз такая работа с графовым представлением разложения методов. Ваше мастерство проделывает рассуждения с описанием системы как графа связанных какими-то потоками предметов методов подсистем. Каждая из подсистем выполняет какие-то преобразования предметов метода, проводит их по состояниям, чтобы получить какой-то результат. Скажем, в логистической схеме – это работы по методам транспортировки и хранения предметов работ, а также работы по заказам партий предметов работ.

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

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

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

В непрерывном производстве (нефтехимия, энергетика) функциональные диаграммы часто гибридны, в них приводится результат методологической работы (выбор метода) и одновременно указываются и результат проектирования: элементы конструкции. Это оформляется как P&ID диаграммы, piping and instrumentation diagram и PFD, process flow diagram диаграммами33.

Каждый отдельный тип конструктива из крупной «нарезки на модули» архитекторами проектировщики будут потом в концепции системы упоминать не просто сам по себе, а как реализующий какую-то подсистему в её роли в системе.

Концепция системы часто представляется в форме какой-то гибридной диаграммы. В её основе часто – функциональная диаграмма (в системах функциональность – первична), но для функциональных объектов указано, какие конструктивные объекты будут играть эти роли, часто это делается «аннотированием» обозначений на «принципиальной схеме» указанием на то, какие конструктивы будут задействованы для воплощения этих функциональных объектов. Какого-то специального представления «отображения» функционального представления на конструктивное представление системы, например, таблицы соответствия, не делается. Иногда функциональные диаграммы в форме принципиальной схемы гибридизируются каким-то указанием разнесения её элементов на модули («функциональный насос» реализован «тремя конструктивными насосами и системой управления для них», это сделано для повышения надёжности), и часто ещё указывается и компоновка в пространстве, поэтому обозначение каких-то элементов делается состоящим сразу из нескольких имён, если это возможно: функциональное, конструктивное, пространственное и так далее (стандарт ISO 81346 как раз про правила такого именования, обозначений/designations).

Так что большая часть методологической работы часто делается сегодня в формате графовых представлений «принципиальных схем». Расчёты по таким функциональным диаграммам потоков жидкостей, электрического тока, энергии, даже денег, предметов работ, пассажиропотоков, а ещё потоков информации и т. д. учитывают «одномоментность во времени» и называются 1D-моделированием, ибо это одномерное представление – какая-то характеристика в каждом месте диаграммы разворачивается во времени.

Такое функциональное (это потоки в ходе функционирования моделируемой системы, функциональное представление – это ответ на вопрос «как работают в момент эксплуатации») моделирование чаще всего делают при помощи систем дифференциальных уравнений, учитывающих «одномоментность». Иногда такое физическое 1D моделирование называют системным моделированием, ибо речь идёт о моделировании работы системы как функционального объекта в целом на основе понимания того, как именно работают отдельные подсистемы.

В менеджменте такое моделирование чаще всего делают средствами системной динамики34 – и это хорошо, только не надо считать, что это будет единственное моделирование в ходе проекта по созданию системы. Нет, это только 1D-моделирование, но будут ещё и другие. Более того, сегодня системным моделированием чаще называют 1D-моделирование не только упрощёнными дифференциальными уравнениями системной динамики (там очень ограниченный набор элементов модели и допустимых видов уравнений в системе дифференциальных уравнений), но и полноценным физическим описанием системы. В физическом системном моделировании (physical systems modeling), узко понимаемом как численное 1D моделирование, конкурируют каузальное моделирование с системой уравнений из обычных дифференциальных уравнений (ODE) и акаузальное моделирование с системой из алгебраических дифференциальных уравнений (ADE). Каузальное моделирование требует указывать порядок решения системы уравнений, а акаузальное моделирование – нет, систему уравнений решает сам компьютер, тренд при этом – переход от каузального моделирования к акаузальному.

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

Текущий текст подраздела предназначен главным образом для «технарей», его может быть трудно одолеть людям, которые не имеют высшего инженерного образования. Но если вы «технарь», а текст плохо понятен – попробуйте пройтись по ссылкам на оригинальную литературу и хотя бы чуть-чуть её полистать. Всё-таки инженеров такому должны учить, и освежить эти знания никогда не поздно. Курс «Методология» – это курс вузовского уровня, делать из него «попсовый курс» без отсылок к физике и математике – неправильно.

1D-моделирование довольно долго делалось на акаузальных языках моделирования, например, Modelica35, одновременно с графическим и текстовым представлением систем алгебраических дифференциальных уравнений. В физическом системном моделировании учитывается уже более-менее разная физика системы (механика, гидравлика, энерготеплопереносы и т.д.) или какие-то её другие свойства (например, умение производить работы, пропускать через себя поток предметов работ – иногда это называют даже factory physics). Но это всё моделирование функционирования, по факту – это моделирование метода работы системы. Вот пример представления модели на Modelica36:

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

По итогам эксплуатации многочисленных систем с Modelica оказалось, что диаграммное представление функциональных схем менее удобно в работе: модельеры-проектировщики проводят много времени в текстовых представлениях, а диаграммы используют главным образом в «презентациях», для красоты, которую называют «наглядностью». Любые изменения-исправления, вставки и удаления, предложение альтернатив и комментарии делаются в текстовой форме, она банально удобнее. Поэтому современные средства 1D-моделирования по факту представляют собой пакеты численного моделирования для обычных языков программирования, например, один из самых мощных таких пакетов – JuliaSim37. Отсутствие «визуальности» функционального моделирования с лихвой компенсируется удобством использования: тексты менять в ходе разработки много быстрее, чем диаграммы. И тексты можно пересылать друг другу, легко комментировать, чего не сделаешь с диаграммами – учитывая ещё и то, что откомментировать фрагмент текста программы функциональной модели можно и в чате, а вот с диаграммами всё не так просто, нужны специальные дорогие программы для работы с диаграммами, и они должны быть установлены у всех участников проекта, что обычно невозможно.

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

Инженеры в ходе проектирования обсчитывали принципиальные и технологические схемы, иногда называя это одноразмерным/1D моделированием, чтобы противопоставить трёхмерному прочностному и тепловому моделированию – речь-то идёт о функциональных описаниях, и тут у математиков, системных инженеров, программистов и всех остальных терминология существенно различается. Это как раз наша задача – ввести какой-то общий язык описания этого моделирования и этих вычислений, привязав эту терминологию и способы моделирования к современным методам разработки. «Хитрая физика» в функциональном физическом моделировании ведёт к «хитрой математике», которая ведёт к «хитрым языкам моделирования», которые реализуются достаточно необычными приёмами в разработке компиляторов и библиотек, поддерживающих моделирование в конкретных областях физики (электротехника, оптика, теплоперенос), но и не только физики – речь идёт вообще о моделировании мира в момент работы системы.

В традиционной «железной» инженерии принято было использование MatLab (более удобен для вычислительных задач, чем Фортран) и SimuLink для создания имитационных моделей, программные среды для вычислений с ODE (odinary differential equations in state space form – дифференциальные уравнения для пространства состояний входов и выходов). Это стало мейнстримом, но оказалось, что сопровождать модели в такой форме невозможно: для типовых случаев нельзя сделать библиотеки отдельных функциональных элементов, которые присутствуют в системе, и приходится каждый раз понимать, куда и как вписать очередное уточнение модели, или куда и как вписать очередное изменение модели.

Потому моделированию в ODE было противопоставлено акаузальное моделирование/acausal modeling с использованием DAE (differential algebraic equations) с алгебраическими переменными, которым a priori не могло быть придано никакого входного или выходного статуса – порядок вычислений не мог быть предсказан, ибо непонятно заранее, где у какого-то резистора вход, а где выход в составе модели.

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

Первые принципы физики естественным образом приводят к рассмотрению акаузальных моделей с алгебраическими дифференциальными уравнениями (DAE), таких как на рис. 1 слева. Например, рассмотрим случай электрических цепей. Законы цепей, такие как законы Кирхгофа, естественно выражаются в виде уравнений баланса: алгебраическая сумма токов в сети проводников, встречающихся в одной точке, равна нулю; или сумма всех напряжений в петле равна нулю. Это верно будет и для операционного менеджмента (потоки работ, денег, материалов в сетях/цепях поставки), в любых других системах, в которых что-то «течёт» (в том числе и «текут данные»).

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

И в итоге были предложены специальные акаузальные (не требующие учёта порядка влияния друг на друга элементов через входы и выходы) языки программирования и вычислительные среды для них. Компания MathWorks к SimuLink с его ODE добавила SimScape с DAE, компания Siemens предлагает Amesim, но де-факто стандартом и экспериментальной средой для отработки новых идей стал язык акаузального имитационного моделирования мультифизики Modelica (https://modelica.org/), для которого было разработано полдюжины компиляторов самыми разными фирмами и университетами. На смену Modelica сейчас приходит проект JuliaSim с акаузальным инструментарием ModelingToolkit. jl39.

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

А поскольку разнородных средств физического/имитационного моделирования оказалось очень много, для объединения самых разных моделей на уровне обмена данных между их входами и выходами был предложен стандарт FMI40 (functional mock-up interface – он поддерживается более чем 150 программными инструментами для моделирования).

Но и DAE/acausal моделирование оказалось с проблемами. Главная проблема тут – невозможность использования Multi-Mode DAE Models (mDAE). Multi-mode models – это моделирование режимов, связанных с разными структурами одной и той же системы. Если у вас летит ракета с тремя ступенями, потом с двумя, потом с одной ступенью – моделировать это нужно по-разному, это же будут лететь совсем разные ракеты, у которых только название общее, а физика совсем разная! Если у вас моделируется атомный реактор в ходе его нормальной работы, то там одна физическая модель. А если он уже начал плавиться – то моделировать его плавление нужно по-другому, прошлая модель реактора не будет работать. Это явление носит разные имена, Multi-mode DAE models только одно из них, в математике и физике используют и другие, например, VSS (variable structure system, – и они тоже имеют много разных подвариантов, «частных случаев»)41. Есть и другие имена, разные группы исследователей приходят к этой проблеме учёта изменения структуры модели вслед за структурой моделируемой физической системы в разных исследовательских ситуациях и подчёркивают в имени разные аспекты проблемы.

Математика mDAE хитра, и языки акаузального физического моделирования и их компиляторы должны учитывать эту хитрость математики, иначе результаты моделирования будут кривые. Вот одна из работ 2020 года, проясняющая трудности: «The Mathematical Foundations of Physical Systems Modeling Languages»42. Трудности там демонстрируются на вот таком простом примере, с которым не справляются нынешние компиляторы Modelica, и дело там не только в computer science (плохом языке моделирования и плохом его компиляторе), но и в математической-физической стороне вопроса:

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

После того, как разобрались с физикой и описывающей её математикой, подключается computer science, ибо нужно теперь создать язык с нужной для этой математики операционной семантикой и (оптимизирующий!) компилятор для него. Это оказывается в случае mDAE не так легко, ибо уже не хватает уровня продвинутости человечества в computer science. Исследования (computer science) и разработки (software engineering) для акаузального мультифизического моделирования идут по вот этим основным линиям, а основное развитие сейчас происходит в ModelingToolkit. jl43 в проекте JuliaSim44.

В какой-то мере этот тренд с использованием «языка» mDAE вместо ODE для физического моделирования похож на создание разных языков программирования для решения expression problem в самой computer science45. Суть этой expression problem ровно в том же: разработка библиотек универсальных вычислительных элементов требует от языков программирования и реализующих их компиляторов возможности добавлять новые объекты для старых операций и новые операции для старых объектов, чтобы не нужно было переписывать весь код программы. Обратите внимание, что в предыдущем предложении мы по факту говорим, что языки программирования и языки моделирования – это одно и то же, функциональное моделирование делается на языке программирования. Это отдельная долгая история, ибо на самой заре программирования «языки высокого уровня» как раз и считались языками моделирования (например, Simula46, первая версия которой появилась в 1962 году, это был первый объект-ориентированный язык). Это лишний раз подтверждает, что моделирование может и должно делаться не только на специализированных упрощённых языках моделирования, но и на самых обычных языках программирования общего назначения – но оно предъявляет специальные требования к этим языкам.

В mDAE против ODE мы расширяем expression problem с обсуждения только программных объектов и операций до обсуждения описания/моделирования физических сущностей: или ты делаешь язык, на котором разные функциональные объекты описываются разными наборами уравнений (декларативно), и просто добавляешь эти модели друг ко другу, или в языке у тебя такой возможности нет, и ты вынужден каждый раз переделывать программу при малейших изменениях моделируемой системы или малейших изменениях в идеях самого моделирования.

Если ты не решил эту «model expression problem», то тебе нельзя сделать стандартные библиотеки, оформляющие стандартные поведения функциональных объектов. Знания моделей становятся плохо переносимыми между моделями, модели плохо модифицируемыми – каждый раз при внесении изменений нужно переписывать и перекомпилировать всю модель.

Есть ещё и многомасштабность моделирования: объединение моделей разных системных уровней, разных масштабов времени, тут тоже свои математические и выразительные трудности в языках программирования47, – и там тоже проблемы с ODE против DAE, плюс много чего собственного, и для этого тоже может потребоваться учёт в языках программирования/моделирования. Увы, языки программирования/моделирования не системны/многомасштабны «из коробки».

Для моделирования в реальном времени (цифровой двойник/digital twin, скорость моделирования имеет значение, проблемы алгоритмики как алгоритмов, дающих при заданной точности вычислений максимальную скорость счёта, тут всплывают в полной мере) тоже есть множество проблем, например, высокая скорость получается за счёт различных суррогатов48 моделей (быстрых аппроксиматоров сложных функций, например, нейросуррогаты получаются на базе нейронных сетей). No free lunch theorem гласит, что нет универсально быстрых алгоритмов: алгоритм, хороший для одной задачи будет плох для другой, и наоборот. И в каждом «общем решении» всё равно будут возникать (сотнями, тысячами!) многочисленные «частные случаи», требующие отдельных способов решения. Обсуждение качественного имитационного/simulations моделирования обычно связывают с суперкомпьютерами, это не случайно. Для удешевления и ускорения моделирования нужно делать прорывы в алгоритмике, менять физику компьютера (например, переходить к оптическим или квантовым вычислениям).

Когда директор стадиона обсуждает цифрового двойника для своего стадиона, хорошо бы, чтобы он понимал SoTA в области моделирования. А то ему теоретики-математики без понимания сути computer science намоделируют так, что мало никому не покажется – моделирование тут похоже на безопасность, про него ведь можно легко сказать «моделирования много не бывает», и тогда оно может съесть все деньги и ничего не дать взамен, как и излишняя безопасность. Лекарство легко может стать болезнью.

Задания: принципиальные схемы

Поставьте отметку о выполнении:

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

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

Пример: методы создания систем AI

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

Главный посыл этого подраздела: материал курса «Методология» общеприложим к самым разным системам. При этом мы признаём, что начиная со следующего раздела мы главным образом будем рассказывать про методологию в её версии для методов работы систем-создателей в графах создания каких-то систем. Но вот первый раздел показывает, что методология вполне приложима как метод мышления о не слишком интеллектуальных «железных» агентах, хотя там термин больше используется не «метод», а «функция». Методология приложима и к методам/функциям работы таких «не совсем пока интеллектуальным» агентов, как нынешние системы AI.

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

Стек тут – любой проход по одной вертикали в этом дереве, но помним о сложностях разложения методов в дерево. Есть сложности моделирования разбиения функциональных объектов – роли ведь тоже можно декомпозировать по-разному, трудности разложения в спектр их методов работы тут проявляются в полной мере. Так, обратите внимание, что слои есть и у голов, и у бэкбонов как частей ANN, ибо «слой» из «нейронов» вроде как составная часть ANN, но верхние слои – это «головы» (их может быть и несколько), а нижние слои – бэкбоны. Как мы и говорили, очень трудно представить «чистый стек», но и «чистое дерево» представить тоже трудно, и то же самое будет даже с графами. В следующих разделах мы покажем, как многие такие представления конвертировать в табличные, но содержательно это не убавит проблем. При разузловке/разбиении и синтезе что ролей, что их методов, придётся каждый раз в каждом проекте включать голову – и думать.

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

В текущем подразделе мы приводим пример разговора про методы работы систем AI: что там делают подсистемы и подсистемы подсистем, обмениваясь данными, это dataflow представление. Центральное место в функциональном разбиении системы AI занимает искусственная нейронная сеть (ANN, artificial neural network), подсистема системы экспертов (несколько нейронных систем объединяются как «эксперты» в смеси экспертов, MoE, mixture of experts)49:

В суперупрощённом виде мы видим функциональную диаграмму: какая-то входная информация даётся на вход маршрутизатора, который выбирает пару экспертов из четырёх возможных, а затем ответы этих экспертов как-то замешиваются в выходную информацию. Вот эти «эксперты» обычно – искусственные нейронные, ANN, artificial neural network сети с классической декомпозицией на «слои» из вычислительных «нейронов»50. Вот типичная функциональная диаграмма для ANN (традиция называет такие диаграммы «архитектурами», но в этой «архитектуре» ни слова не говорится о конструктивах, это в других предметных областях было бы «принципиальная схема»), на ней представлен трансформер/transformer51 как вид ANN, отвечающий подобного сорта функциональной диаграмме, эта «принципиальная схема» была предложена в 2017 году:

Стрелки тут обозначают движение потоков данных (dataflow), а блоки – обработчики данных (функциональные объекты, выполняющие обработки каждый по своим методам). Обработчики данных представляют по факту как-то модифицированные «слои» из отдельных «нейронов», плотно перевязанных связями.

Обзором техноэволюции ANN занимается прикладной методолог систем AI Григорий Сапунов в канале «Gonzo-обзоры ML статей»52. Основное содержание его обзоров много лет было как раз посвящено модификациям принципиальных схем ANN. В Gonzo-обзорах первый раз слово «метод» встречается 25 февраля 2019 в обзоре работы «AET vs. AED: Unsupervised Representation Learning by Auto-Encoding Transformations rather than Data»53, там фраза «Дальше в работе рассматривают только параметрические преобразования. Это типа проще реализовывать, а также проще сравнивать с другими unsupervised методами». Онтологически из фразы следует, что «unsupervised learning»:: метод – это род методов, в котором есть множество видов методов. Обратите внимание, что методы – это поведение, а до этого в подразделе мы обсуждали вроде как функциональные разбиения ролей на подроли (систем на подсистемы, в функциональном рассмотрении – разбиение функциональных объектов, а не поведения). Вот эта связанность роли и метода должна как-то удерживаться, нельзя думать про одно без другого: не может «никто» делать что-то, и «кто-то» не может ничего не делать! Опять же, роль может работать по какой-то сигнатуре метода, а там внутри можно даже менять методы в их разложении для этой сигнатуры, а роль поможет удерживать внимание на результирующем методе, абстрагируясь от его разложения.

Если продолжить читать текст статьи, пытаясь найти там «методы», то придётся признать, что в статье они обсуждаются, но называются крайне разнообразно – и меньше всего словами, которые у нас в курсе даны как синонимы слова «метод». В статье «метод» обозначен то как «подход», то как «архитектура», и даже «efforts» как метонимия усилий команды, разработавшей метод, в фразах типа «Among the efforts on unsupervised learning methods, the most representative ones are Auto-Encoders and Generative Adversarial Nets (GANs)». Весь наш курс посвящён тому, что мы под всеми этими именами распознаем метод::тип – и с этого момента всё содержание нашего курса «Методология» приложимо к этим «подходам», «архитектурам» и даже «efforts». Заодно заметьте, что слово representative в текущей фразе не имеет отношения к representation learning, хотя казалось бы, могло бы и иметь. Со всем этим можно разобраться из контекста, как это и изучалось в курсе «Рациональная работа».

Помянутые методы «Auto-Encoders and Generative Adversarial Nets» (ещё раз внимание: методы называют как функциональные объекты, «автоэнкодеры» и «сети», а не поведения!) в их совокупности называют вместе родом Auto-Encoding Data (AED) как выучивание распределения по данным (выучивание – глагол, «выучивание распределения по данным» – это таки метод), и вводят ещё один род на этом же уровне: Auto-Encoding Transformations (AET, и transformations – это опять-таки отглагольное существительное, метод), где могут быть ещё и виды таких трансформаций: large variety of transformations can be easily incorporated into the AET formulation. Так, виды будут – параметрические преобразования::метод (Parameterized Transformations, как подвиды там пример – афинные и проективные), а ещё GAN (generative adversarial network – сеть, неожиданно существительное, то есть роль, а не способ работы, имеется в виду метонимия – «преобразования, которые производят GAN») и непараметрические преобразования.

Преобразования – это transformations, в русском тексте gonzo-обзора синонимизируются трансформации и преобразования. Вопрос, преобразования чего – какой предмет метода? Ведь «данные» – это явно совсем высокий уровень мета-моделирования, надо всегда стараться слова «информация» и «данные» как слишком общие типы мета-мета-модели в предметной области заменять на типы мета-модели (в курсе «Системное мышление» специально подчёркивалось, что сверхобобщения – вредны). В статье речь идёт о данных изображений, ибо текст 2019 года обсуждает главным образом распознавание изображений на тестах типа CIFAR-1054.

Статья, несмотря на всё разнообразие используемой терминологии по части методов, следует давней традиции: роды самых разных методов называют именно «методом», а всё более мелкое в видах методов и разложениях выбранного вида метода называют «как бог на душу положит», и только иногда – методом, рабочим процессом, культурой, практикой и т. д. В обсуждаемой статье supervised learning консистентно называют «метод машинного обучения» (то есть вид «машинного обучения»:: метод работы какой-то «статистической модели»:: «функциональный объект», познающей/выучивающей/learn какое-то статистическое распределение), а вот виды этого метода как рода (то есть разные варианты supervised learning, из которых в конечном итоге будет выбран только какой-то один) и методы в разложениях этих видов (составляющие метода, которые будут задействованы «одновременно», отражены одной принципиальной схемой) называются уж как придётся. Но мы-то знаем, что всё это методы!

Поэтому наше мышление тут работает одинаковыми ходами, чему и посвящён наш курс. Вы можете не быть большим специалистом в машинном обучении – но если вы читаете статью про машинное обучение, то сможете разобраться, как минимум, какие типы объектов там рассматриваются и как они соотносятся друг с другом. Это существенно помогает разбираться с новыми предметными областями.

Как же выглядит разложение методов работы нейросетей? Когда вы смотрите на диаграммы «архитектуры нейросетей», то вы должны понимать, что это функциональные диаграммы, которые по принципу мало отличаются от принципиальной схемы холодильной установки. Эта «принципиальная схема»/«функциональная диаграмма»/«dataflow diagram», показывающая потоки данных примерно так же, как электрическая принципиальная схема показывает потоки электрического тока, а гидравлическая схема показывает потоки жидкости – это и есть один из способов показать работу ролей по их методам работы, разложение метода, ответ на вопрос «как оно работает».

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

Пробегаем Gonzo-обзоры до 30 апреля 2024, когда там55 появилась ссылка на обзор PEFT (Parameter-Efficient Fine-Tuning) алгоритмов для LLM. Смотрим на то, как употреблено слово «алгоритм» – ах, это те же методы! Как проверить? Берём картинку из статьи56 и видим типичную ламаркианскую классификацию родов-видов именно методов, причём картинка названа именно классификаторски, «таксономией», аж на пять уровней:

Но если мы поглядим на то, что же такое PEFT даже не в самой статье, а просто аннотации, то увидим, что слово «метод» употребляется не как объект первого класса, а как что-то литературно-художественное, что тоже требует синонимизации, для пущей выразительности, термином авторы «метод» не считают: один раз это род разных видов «процессов» (но из курса «Методология» мы знаем, что «процесс» – это тоже часто синоним «метода», а уж «рабочий процесс» – это точно «метод», только в менеджменте), а вот в другой раз – это род алгоритмов. Как это читать? А так и читать: алгоритм/теория/объяснение описывает метод (а чтобы не было сомнений, что теория и алгоритм – это одно и то же, то можно вспомнить про соответствие Curry-Howard – императивные и логические программы суть одно и то же, математические доказательства – это программы). Метод – это то, что делают в жизни нейросетки, проявляя «мастерство выполнения метода», а алгоритм – это то, что было взято для реализации этого мастерства для программирования вычислителя, проявляющего затем метод.

Если попытаться формализовать методологическую работу для систем AI, то от простых dataflow диаграмм можно перейти к псевдокоду, используя парадигму функционального программирования, а потом и просто к программному коду (возможно, уже мультипарадигмальному) – и там кодировать алгоритм метода с точностью, достаточной для машинного исполнения этого кода. Но если пытаться строже формализовать описание методов работы систем AI, не погружаясь в детальные описания на языках программирования, на помощь приходит теория категорий, дающая удобный формализм для математического описания методов/функций, в том числе и дающая диаграммную нотацию. Примером тут может служить работа «On the Anatomy of Attention»57, где приводится диаграммная теоркатегорная нотация для методов работы систем AI, при этом особое внимание уделяется методам внимания. Вот пример диаграммы таксономии методов из этой работы (см. диаграмму ниже).

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

А где-то будет достаточно памяти, но важна будет латентность: сколько времени будет занимать обработка входной информации, сколько ждать результата. И надо будет выбирать метод, дающий меньшую латентность. Ну, или оставлять тот же метод, только поручая выполнение алгоритма этого метода какому-нибудь более быстрому ускорителю вычислений методов в его разложении – то есть используя специальный инструментарий. Об этом иногда говорят как hardware aware architectures. Тут архитектура уже не совсем «принципиальная/функциональная схема», «алгоритм работы», ибо хоть как-то упомянуто и конструктивное/материальное описание системы, зацеплена работа современного архитектора, предписывающего ограничения на конструктивы и способы их взаимодействия.

Представление метода работы как алгоритма: методология как алгоритмика-на-стероидах

Материал этого раздела весьма сложен, может оказаться, что вам нужно освежить азы алгоритмики. Как минимум, вы проходили алгоритмику в школе, возможно, сдавали по ней ЕГЭ, но методология требует, конечно, не школьного понимания алгоритмики. Увы, даже азам алгоритмики мало где учат. Мы можем указать на курс «Интеллект-стек» и дополнительные материалы к этому курсу58, посмотрите там, чем же занимается алгоритмика. Конечно, программистам материал этого раздела будет понимать легче, но наш опыт показывает, что и это не всегда так: материал отсылает не к «программистскому опыту», а к теоретическому знанию – объяснениям азов алгоритмики в её связи с математикой и физикой. Увы, этому даже в вузах учат отнюдь не всех «программистов с высшим образованием».

Мастерство выполнения метода – программа, которая описана алгоритмом. Мы пока опустим тот нюанс, что алгоритма совершенно недостаточно для описания программы, ибо программа – это алгоритм плюс структуры данных59, да ещё и реализованные каким-то вычислителем (подробней это обсуждалось в курсе «Системное мышление»). В случае методов мы говорим, что создатели – это обобщение «вычислителя» до «создателя» (то есть не только работаем с данными на входе и получаем данные на выходе, но берём какие-то предметы метода на входе и получаем предметы метода на выходе – делаем физические преобразования). Так что «программа метода» понимается не просто как «вычислительная программа», а как «преобразовывающая мир», «программа для станка с ЧПУ» в простейшем случае. А если создатель умный и эта программа – алгоритм в мокрой нейросети, или даже гибридной нейросети предприятия (из мокрых нейросетей множества людей и компьютерных сухих нейросетей плюс много компьютерной памяти и ещё станки в поддержку вычислений и преобразований), то мы назовём её «мастерство».

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

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

• алгоритма и предметов метода на естественном языке, это самая маленькая формальность представления метода на шкале формальности

• алгоритма и предметов метода на псевдокоде (похоже на какой-то формальный язык – но на самом деле формализация недостаточна для полностью машинного выполнения на классическом компьютере с языком программирования)

• алгоритма и предметов метода в виде кода на каком-то языке программирования, полностью формальное (подразумевающее «машинное» однозначное) выполнение.

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

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

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

Тут можно напомнить, что когда-то школьное программирование вводилось в школах СССР в 1985 году ровно как попытка научить школьников планировать какие-то последовательности действий с условиями, описывать какое-то поведение. Под планированием имелось в виду не ресурсное планирование, то есть составление плана-графика (кто когда что с чем делает), но как раз методологическая работа – описание того, что вообще надо делать. В обосновании звучало, что выражению алгоритма как описанию каких-то действий (слово «метод работы» тогда не звучало, в лучшем случае звучало «описание работы», а не «описание методов работы») не учат ни в одном предмете, изучаемом в школе – физика, математика, география и любой другой предмет мог сам рассказывать о каких-то методах работы, но вот записать какой-то метод работы хоть в каком-то формальном виде ни один предмет не учил. Как и во всём мире для обучения школьников, для выражения алгоритма был выбран императивный язык.

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

Так что для возвращения тематики «обучения составлению алгоритмов выполнения работ» в обучение программированию нужно сделать довольно много:

• Сразу вводить понятие метода как работ не только с описаниями (абстрактными объектами, информацией, работы с данными – «компьютерное программирование»), но и с предметами метода. Алгоритмика не компьютерная, а созидательная (программирование создателей/constructors из теории создателей).

• Добавить обсуждение работы с типами предметов метода (а не только типами данных и структурами данных), ибо программа = алгоритм плюс данные.

• Алгоритмы надо будет выражать на декларативном (скорее всего, функциональном) языке. Хотя, по большому счёту, нужно владеть мультипарадигмальным программированием – ибо для разных вариантов алгоритмов удобней разные варианты парадигм программирования62, отражённые в разных языках программирования, всё большее число современных языков программирования сегодня – мультипарадигмальные языки, поддерживают и процедурную, и функциональную парадигмы.

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

Алгоритмика сама по себе связана как с выражением способа вычислений на языке какой-то парадигмы (выражение способа – это методология), так и скоростью вычисления (это операционный менеджмент, исследование операций), что зависит от физики компьютера. Так что алгоритмика – экспериментальная наука, физика компьютера вносит реализм, а формальность вычисления – математику. Поскольку каждая программа – это доказательство (соответствие Curry-Howard63), то соответствие физического процесса в компьютере (классическом, квантовом, оптическом и т.д.) и абстрактного процесса вычислений «в математике» может быть проверено только экспериментально, через экспериментальную науку. Deutsch прямо называет алгоритмику «наукой о доказательствах», ведь программы – это доказательства, конструктивная математика – это программирование, и дальше через алгоритмику можно делать ходы на выполнение доказательств (алгоритмов) на компьютерах, проекты унивалентных оснований математики и языков Agda и Coq как раз нацелены на помощь математикам со стороны компьютерной техники (подробней об этом – в курсе «Интеллект-стек», и там много ссылок на литературу).

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

Алгоритмика должна экспериментально подтверждать, что алгоритм эффективно выполним на каком-то железе. В силу no free lunch theorem нет универсально быстрого алгоритма для всех задач, для разных ситуаций будут эффективны разные алгоритмы, а разница в эффективности алгоритмов на разном «железе» с разной физикой может быть драматической, в пересчёте на методы – это как копать котлован лопатой по сравнению с экскаватором, по сравнению с гидромеханическим размытием, по сравнению со взрывным способом. Методология с задействованием исследования операций в паре с операционным менеджментом должна экспериментально подтверждать, что создатель с его мастерством (реализованным тоже аппаратно!) и инструментарием (tooling), реализуя метод, будут получать результаты заданного качества/точности (предметы метода в заданном состоянии) в приемлемое время и при приемлемом расходе ресурсов. В алгоритмике говорят, что синтез алгоритмов должен быть hardware aware для того, чтобы алгоритм был эффективен. Вот и метод должен быть оптимизированным по инструментам (hardware aware), то есть учитывать наличные особенности инструментария, включая аппаратуру для мастерства как «управляющей программы».

Алгоритм – это вроде как последовательность вычислений, а тут – последовательность каких-то трансформаций для создателя, обобщение алгоритма для вычислителя (машины Тьюринга) на материальный/физический мир. И тут надо разбираться с теоретическими обобщениями, например, constructor theory64 как обобщения машины Тьюринга как универсального вычислителя в сторону универсального преобразователя. С помощью подобной теории мы можем пробовать выдать какие-то достижения современной алгоритмики за начальные идеи в методологии, мы вполне можем понимать алгоритмы как «алгоритмы в том числе для станка с ЧПУ» и теории не математические, а вполне себе теории про реальный мир.

Вполне можно рассматривать методологию как учение по «программированию роботов и людей» (включая «нейролингвистическое программирование» людей в его оригинальном понимании, как бы оно ни было скомпрометировано, и современный prompt engineering систем AI). Эта идея тоже может быть обобщена и на организации. Скажем, какой-нибудь стадион со всем его персоналом и сооружениями – робот, хотя и неантропоморфный. Этот робот выполняет работы по каким-то методам (описанным алгоритмами разной степени формальности), чтобы как-то загнать в себя несколько десятков тысяч человек, малая часть из которых будут развлекать другую часть, затем провести развлечение, включая пропуск только по билетам, затем кормление всей этой толпы, физическую безопасность, предоставление услуг туалетов. Часть оборудования робота-стадиона – живые люди, которые ещё не заменены каким-то оборудованием, но они выполняют относительно простые программы. Надо понимать, какими методами работает такой робот, как эти методы непротиворечиво описать и поставить, как отследить их выполнение, как разработать и построить такого робота, как эксплуатировать такого робота – и это «как» тоже про методы, и это тоже про общую алгоритмику, ибо выполнение должно быть эффективно при заданном качестве выполнения! И ещё «цифровая трансформация стадиона», то есть сдвиг выполнения методов работы в стадионе с людей на какое-то оборудование.

В существенной мере алгоритмы методов работы зависят от представления/representation знаний о предметной области: алгоритм сложения чисел с мастерством, реализующимся мокрой нейронной сеткой в человеческой голове, даже при условии её усиления ручкой-бумажкой для безошибочно работающей памяти и облегчения удержания внимания существенно зависит от нотации. В римской нотации всё плохо, а в арабской65 нотации (позиционная запись и явно представленный ноль) – даже дети справляются не только с умножением десятизначных чисел, но и с делением, что казалось бы чудом ещё тысячу лет назад. Есть разница с нотациями, которые пригодны для непосредственно мышления об объектах (операции со знаками соответствуют операциям в реальном мире – вот как с арабскими цифрами, «рассуждение легко алгоритмизируется»), и «описаниями» каких-то операций в естественном языке или даже псевдокоде, которые не так-то легко алгоритмизируются66. Хорошие нотации позволяют описать простые одинаковые последовательности операций с предметами метода для получения конечного состояния предметов метода. Плохие нотации заставляют каждый раз изобретать последовательность операций – это возможно, конечно, но только самым одарённым. А вот не для самых одарённых (тем более для компьютеров!) надо бы делать операции простыми и одинаковыми. Можно не «творить» каждый раз, а просто «посчитать по предлагаемой инструкции счёта». Не делать догадки и опровергать их, а просто «взять входные значения и без содержательного разбирательства с ними механически посчитать выходные значения».

Хорошие нотации тут как иероглифические системы, они не соответствуют текстам на естественном языке – японец и испанец прочтут 2+2=4 абсолютно по-разному, а выполнят – одинаково. Но особенность хороших нотаций не в том, что они именно «иероглифичны». Иероглифы могут быть использованы или как знаки для описания чего-то другого, или они сами могут быть объектами, с которыми ведутся манипуляции по известному уже алгоритму, без шага стратегирования (придумывания алгоритма) и планирования (уточнения того, когда что с чем надо сделать, чтобы получить результат эффективно) – нас интересует «непосредственное манипулирование». В методологии всё то же самое, но нотации будут не только для абстрактных понятий, как в математике, но и для предметов метода. Скажем, нотация чеклистов с контрольными вопросами оказывается удобной для контроля достижения состояний предмета метода: это не просто какое-то длинное текстовое описание, но буквально чеклист, в нём есть место, куда поставить птичку «выполнено». Это тоже нотация.

Дальше по этой линии идёт DDD (domain driven design, где объекты реального мира сопоставляются объектам программы, как минимум – моделируются структурами данных), и дальше вычислитель с этими данными сам по себе становится объектом реального мира, а не просто работает с описанием объекта – это линия как «станка с ЧПУ», так и линия реестров и регистров. Если что-то поменялось в регистре, то это означает изменение в реальном мире, например, будет или не будет работать турникет допуска в помещение. Это всё важно для обсуждения тех методов, которые описываются в том числе и теорией речевых актов67, то есть методы, включающие высказывание каких-то утверждений, которые по сути являются действиями (перформативы68 – поручения, обещания, акцепты и прочие коммуникационные акты, которые меняют ситуацию, то есть являются поступками, а не «просто словами»). Например, работы по инженерии предприятия69 Jan Dietz с коллегами как раз основаны на теории речевых актов.

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

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

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

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

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

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

Автор этих строк в качестве первого рабочего задания после университета (1980 год) получил задание создать язык для описания строительства здания – и не знал, что он попал в отдел, который как раз занимается проблемами AI на базе класса систем, известных как «фреймовые»71 (кодирование методов в структурах данных для «стереотипных ситуаций»). Постановка проблемы была примерно такой: «давай опишем алгоритм строительства дома на каком-то языке. Но мы знаем продолжительность каждой операции и требуемые ресурсы – для этого у нас есть СНиПы, строительные нормы и правила. Затем мы просто посчитаем длительность стройки в компьютере. Так что дай нам соответствующий язык описания». Конечно, в головах у всех в 1980 году был именно императивный подход к таким описаниям – который доблестно провалился, поэтому и обратились к фреймовому подходу в AI. Но как описывать эти «фреймы» и как находить их в жизни? Попытки сначала сделать язык для чего-то маленького (конечно, автор через пару недель попытки описания стройки понял, что проблема пока никому не по зубам, хотя за неё брались многие – но был молод и не отчаивался, поэтому просто решил пойти через решение более простых проблем), например, сделать язык формального описания для книг кулинарных рецептов, тоже ни к чему не привели. И только после многих лет автору стало понятным, почему всё было так плохо и почему идеи методологии трудно показать в их формализме на уровне, достаточном для автоматической/машинной реализации метода (а ведь вся цифровая трансформация – она про это!):

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

• Метод описывается алгоритмом, а алгоритм – это одновременно и теория, для объяснения надо разбираться в конструктивной математике, соответствии Curry-Howard и прочих основаниях математики и computer science.

• Более того, это не просто алгоритм действий с данными, а алгоритм действий в реальном мире, и это тоже трудно понимается. Речь идёт об идее 4E (extended, embedded, embodied, enactive) cognition72, и это алгоритмы роботов с датчиками и актуаторами (станка с ЧПУ в простейшем случае), а не алгоритмы классического компьютера. Иногда это алгоритмы, реализуемые вычислителями на мокрой нейронной сетке (у людей) и задействующие сложные инструменты (станки), и ещё и многоуровневые (скажем, ваш заказ пиццы по каким-то методам в пиццерии обрабатывает довольно много людей и компьютеров, а также довольно много разного кухонного оборудования). Об этом трудно думать как-то в общем виде. Но именно такие размышления «в общем виде» позволяют переносить найденные в одних предметных областях методологические решения в другие предметные области. В частности, в ходе цифровой трансформации надо как-то сдвигать выполнение работ с физических двойников на цифровые двойники (например, подстройку режимов работы), а с людей на роботов. Это требует единообразного описания методов работы софта, людей, станков и даже AI-агентов.

• Трудность ещё и в том, что разложение алгоритма представляется как код – и понимание разных парадигм этого разложения алгоритма трудно, с мультипарадигмальным программированием с трудом справляются и профессиональные программисты. Автор этих строк знает огромное число программистов, которые в начале своей работы буквально страдали, пытаясь писать объект-ориентированно, но выдавая императивный код, а когда речь шла о переходе на функциональное программирование, например программирование на Haskell, имели вообще непреодолимые трудности. Даже если прорваться через типизацию объектов (что тоже проблема для многих людей – поэтому-то и нужно использовать трюки типа «онтологического дребезга» и всякие другие альтернативные интерфейсы к мокрой нейросетке новоявленного методолога), то прорваться через функциональную парадигму будет очень трудно. Та же печальная судьба трудностей в изучении постигла средства логического программирования (прежде всего Prolog, но дальше и Agda73, и Coq74 – они считаются ещё более трудными в изучении, чем средства функционального программирования, ибо могут рассматриваться и как функциональные языки, и как логические языки с зависимыми типами75). Радикальное решение тут – сразу учить конструктивизму, конструктивной математике, теории категорий, гомотопической теории типов. Но это оказывается ещё труднее, чем учить распространённым функциональным и логическим языкам программирования. В любом случае, пошаговые представления метода хорошо применимы в мизерном количестве случаев, сама методологическая/функциональная действительность требует функциональных/декларативных представлений, а не императивных/процедурных. Рабочий процесс какого-то завода нельзя разложить на более мелкие рабочие процессы – и так довести это разложение до рабочих процессов, выполняемых отдельными людьми, если использовать идею «пошагового выполнения процесса», ничего не получится.

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

Например, по данным Американской ассоциации психологии с 1993 года было опубликовано около 39000 новых конструктов и 43000 новых методов76. Более половины этих методов никогда не использовались за пределами своей первоначальной статьи, в которой они были представлены. Можно поглядеть, как выглядит картинка «методов в психологии» – интерактивная карта со ссылками на оригинальные описания предложенных методов психологической работы77.

Это дополнительная сложность для прикладных методологов: если вы хотите как-то связно рассуждать про «методы в психологии», то вам надо понять, как вообще этому многообразию методов учить, как понять, что там важно, а что не очень. Распространённость методов тут не очень поможет. Так, теория флогистона и теория эфира когда-то были в физике тоже чрезвычайно распространены вместе с базирующимися на них методами описаний мира, а термодинамика едва-едва появилась, и была крайне контринтуитивна в понимании. Впрочем, и сейчас можно утверждать, что термодинамика контринтуитивна, идеи флогистона и эфира много легче в понимании, но термодинамические расчёты работают, а расчёты по теориям флогистона и эфира – нет. В случае теорий менеджмента или теорий психологии так однозначно сказать о работающих или не работающих методах – нельзя.

То же самое разнообразие методов наблюдается сегодня во всех предметных областях, например, методах создания систем AI, и даже в самих методах физики, и даже в методах самой методологии, да и в кулинарии – число рецептов как методов готовки конкретных блюд огромно, различать их трудно. Похоже, с таким многообразием должны работать не люди, а какие-то системы AI – и даже в случае AI нет впечатления, что можно эффективно участвовать в этой эволюции методов, ведь каждый день надо будет отслеживать появление сотен новых методов, придуманных как людьми, так и AI – и тут же запатентованных как smart mutations по отношению к предыдущему методу. Патенты ведь – это тоже описание методов работы, «как работает» (и сложность их текста показывает, что методы крайне сложно описывать формально). Но как определить, каким патентом стоит воспользоваться, а какие патенты уже устарели?

В этом месте любой человек, разбирающийся с методологией вообще и методологией прикладной предметной области говорит «Ааааа!» и хватается за голову. Много легче жить, когда просто не знаешь о всех этих трудностях. Как обычному человеку совладать с таким объёмом знаний в каждой предметной области, как стать методологом какой-то прикладной предметной области? Этот вопрос остаётся открытым.

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

Задание: разложение метода вашей работы

Поставьте отметку о выполнении:

1. Написан пост о представлениях метода работы по материалу первого раздела. Что так и осталось непонятным? Что оказалось контринтуитивным? Что вам удалось уже применить в рабочих проектах?

2. Написан пост о методе вашей собственной работы. Для этого определите, какая работа занимала у вас основное время на прошлой неделе. Опишите метод/способ, которым вы делали эту работу – и используйте для этого какие-то представления из пройденного раздела нашего курса.