Бесплатный фрагмент - Методология 2025

Введение

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

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

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

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

Обязательными пререквизитами для прохождения «Методологии» является прохождение курсов «Рациональная работа» и «Системное мышление». После курса «Методология» предполагается изучение курсов по нормативным методам создания и развития систем — «Системная инженерия», «Инженерия личности», «Системный менеджмент». Курс методологии — это курс обучения фундаментальному методу мышления, методология входит в число дисциплин интеллект-стека. Материал курса важен для обсуждения прикладных методологий — учений о методах работы в каких-то предметных областях, например, в менеджменте или программной инженерии.

Курс займёт примерно 70 часов, в это число часов входит и чтение материалов, и выполнение заданий, и встречи с преподавателем (эта оценка времени получена экспериментально в ходе прохождения курсов первыми группами). Тем самым курс эквивалентен примерно двухкредитному университетскому курсу (европейский кредит — это 30 учебных часов).

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

Задания по моделированию и мышлению письмом обязательны, без выполнения этих заданий прохождение курса будет похоже на чтение учебника езды на велосипеде без попыток проехать хотя бы 100 метро. Только чтением текста мастерство методолога не получишь. Больше замечаний о том, как устроен курс в части методики обучения и как учиться, можно найти в курсе «Рациональная работа», в первом разделе курса «Системное мышление», и ещё больше объяснений будет в курсе «Инженерия личности».

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

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

Материал этого курса впервые появился как часть учебника «Системноинженерное мышление» в 2013 году, текущий текст — это его девятая переписка 2024 года.

Автор выражает благодарность студентам и преподавателям кафедры технологического предпринимательства МФТИ, где велось начальное преподавание методологии и был получен первый опыт обучения этой фундаментальной дисциплине, членам Русского отделения INCOSE, с которыми велись многочасовые обсуждения содержания курса, сотрудникам, студентам и волонтёрам Школы системного менеджмента, где велась доработка курса в последние несколько лет. Десятки замечаний было представлено читателями блога автора (ailev в живом журнале, трансляции блога есть в телеграме, мордокниге, вконтакте, фрифиде), учтены замечания десятков бета-тестеров. Особая благодарность Роману Варьянко, который оперативно выполнял корректуру текста, не ограничиваясь грамматикой и орфографией, но и делая содержательные замечания.

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

1. Методология как фундаментальный метод мышления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⠀

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

⠀

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Терминология обсуждения разделения труда довольно скудна и ограничена, но сама идея дробности метода, причём возможности дробить (или наоборот, составлять-синтезировать) метод так, чтобы его раздавать разным оргролям, в мастерстве выполнения метода в которых потом будут специализироваться разные агенты — это крайне важная идея. Особенно часто идея разделения труда обсуждается экономистами, ибо это даёт возможность каждому работнику специализироваться на отдельных методах работы (профессионализация), а также сдвинуть часть труда с людей на механизмы/станки, что резко увеличивает экономическую эффективность производства. В менеджменте идея разделения труда принципиально важна: в командах никто не занят одним и тем же методом работы (скажем, все члены команды, все сотрудники предприятия — операционные менеджеры, или все — инженеры-прочнисты). Поэтому надо понимать, как поделить работы между людьми, а также между людьми и компьютерами. Так, «водитель, если ты одной рукой ведёшь автомобиль, а другой рукой обнимаешь девушку, то ты и одно, и другое дело делаешь плохо». Но большинство должностей устроены на предприятии именно таким образом, поэтому какой-нибудь «начальник отдела» по факту вынужден половину времени заниматься работой, например, архитектора, а остаток времени делить между работой операционного менеджера для своего отдела (а ведь методам работы операционного менеджмента агент на должности начальника отдела вообще не учился, он часто самоучка и поэтому операционный менеджер из него никакой), а также исполнителя ещё десятка ролей, занятых ещё десятком методов работы (скажем, роль преподавателя, который своим сотрудникам преподаёт курс работы согласно учебнику-регламенту, а ещё роль лидера, который создаёт атмосферу сотрудничества, и так далее. Должности начальников обычно как джокеры: они могут заниматься работой по каким угодно методам, от них можно ожидать выполнения каких угодно ролей). И тут оказывается, что «универсальных мастеров» не бывает, и выполнение этого букета ролей одним человеком плохо в силу отсутствия мастерства по многим таким ролям, но дальше будут осложнения ещё и с отсутствием необходимого объёма внимания для объектов всех этих ролей. А как надо? Для начала надо в явном виде обсуждать, что именно делает начальник: какие роли он играет, по каким методам он работает в этих ролях, ибо по сигнатуре метода мало что можно сказать, надо обсуждать разложение метода хотя бы на один уровень вниз — отдельно, что он сам думает по этому поводу, а что происходит при независимой оценке (самооценка и оценка со стороны могут разительно отличаться). Так, начальник может считать, что он главным образом инженер — но потом оказывается, что инженерная работа занимает не более 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). Подход этой команды сводится к тому, что важную информацию не нужно извлекать «грубой силой», но можно использовать понимание симметрии системы, чтобы извлечь очень небольшое число важных типов, описывающих важные объекты (команда называет эти типы «инвариантами»), чтобы получить работоспособные стратегии. Вся литература по «обучению с подкреплением» (reinforcement learning) по большому счёту — это литература по стратегированию, обучению выбору действий в незнакомой ситуации методом проб и ошибок, при этом известно, что будет ошибкой (известная «функция награды»). Современная методология наиболее бурно развивается как методология в распределённых представлениях. Мы её не будем подробно касаться в нашем курсе, но вся проблематика современных систем с искусственным интеллектом — она связана со стратегированием и планированием в распределённых представлениях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот, например, праксиология в варианте Murray Rothbard от 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 robot).

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

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

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

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

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

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

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

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

---

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

⠀

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

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

⠀

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

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

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

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

⠀

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

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

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

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

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

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

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

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

---

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть множество методов (в том числе методов описания системы, удобных для применения этих методов) ведения методической, методологической и архитектурной работы в их взаимоувязке. Для примера мы можем использовать классический фреймворк Wim Gielingh из работы «A Theory for The Modelling of Complex and Dynamic Systems», он был использован как один из источников идей для семейства стандартов описания систем 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 как общей форме представления потоков чего бы то ни было — в том числе предметов метода между ролями, задействующими метод.

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для моделирования в реальном времени (цифровой двойник/digital twin, скорость моделирования имеет значение, проблемы алгоритмики как алгоритмов, дающих при заданной точности вычислений максимальную скорость счёта, тут всплывают в полной мере) тоже есть множество проблем, например, высокая скорость получается за счёт различных суррогатов моделей (быстрых аппроксиматоров сложных функций, например, нейросуррогаты получаются на базе нейронных сетей). 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):

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

---

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

Обзором техноэволюции ANN занимается прикладной методолог систем AI Григорий Сапунов в канале «Gonzo-обзоры ML статей». Основное содержание его обзоров много лет было как раз посвящено модификациям принципиальных схем ANN. В Gonzo-обзорах первый раз слово «метод» встречается 25 февраля 2019 в обзоре работы «AET vs. AED: Unsupervised Representation Learning by Auto-Encoding Transformations rather than Data», там фраза «Дальше в работе рассматривают только параметрические преобразования. Это типа проще реализовывать, а также проще сравнивать с другими 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-10.

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Создание и развитие: не жизненный, не цикл

Биологический жизненный цикл, нулевая версия

Поскольку системный подход поначалу развивался на примерах относительно простых физических, а затем (фон Берталанфи был биологом) сложных биологических систем, то часть его терминологии осталась с времён зарождения общей теории систем. Вот сборник работ фон Берталанфи, 1940—1968, это как раз про первое поколение системного подхода:

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

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

В инженерии/деятельности/практике как создании систем самого разного масштаба всё не так (если игнорировать время эволюции/развития систем как вида):

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

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

---

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

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

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

Жизненный цикл системы 1.0:
работы, меняющие состояния целевой системы

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

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

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

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

Одна из самых популярных книжек по проектному управлению, вышедшая первым изданием ещё в июне 1979 года, это Harold Kerzner «Project Management: A Systems Approach to Planning, Scheduling, and Controlling». То есть управление проектами в момент его появления было применением системного подхода к планированию, построению графика работ и контролю выполнения работ. Это похоже на то, как понималась в те времена и классическая «железная» системная инженерия: применение системного подхода к инженерной работе.

Конечно, использование системного подхода в менеджменте не ограничивается сегодня только операционным управлением. По сути, весь менеджмент как специализация системной инженерии для создания и развития организаций строится на базе системного подхода. И это уже был системный подход второго поколения, которое ассоциируется главным образом не с работами фон Берталанфи, а с более поздними работами по «мягким системам» (soft systems), под которыми понимались прежде всего системы-создатели из людей с их инструментами. К таким системам из людей (организациям) оказались неприменимы жёсткие требования «как к железным системам», которые были характерны для системного подхода первого поколения, рассматривавшего главным образом какие-то не слишком живые целевые системы, но не граф создания из людей и их коллективов. Графы создания (хотя и в чуть другой терминологии) с их коллективами и менеджментом как «инженерией организаций» — это уже предмет второго поколения, наиболее характерны там работы Питера Чекланда. Вот его сборник работ в соавторстве с Jim Scholes, 1972—1981:

Понятие жизненного цикла 1.0 как времени производства работ создателя с создаваемой целевой системой (о цепочках создания речь не заходила) активно разрабатывалось и в системной инженерии, и в менеджменте, а именно — в классическом проектном управлении (project management) для принятия решений о планировании и составлении графика работ в инженерных проектах.

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

Так что работа — это Анастасия забивает гвозди молотком в доски 16 мартобря 2028. Забивание гвоздей 16 мартобря — это и есть работа, которую она выполняет, а Анастасия, молоток, гвозди, доски — это всё ресурсы, которые должны провзаимодействовать в момент работы и поэтому должны наличествовать. Нет ресурсов — нет работы. Так что управление работами (work/operations management, операционное управление) сводится к тому, чтобы оптимально распорядиться ресурсами: выполнить максимальное количество работ с минимальными ресурсами. Как? Например, вы можете пригласить Анастасию забивать гвозди на один день — 16 мартобря 2028, заплатить за один день. А можете пригласить на месяц и договориться платить зарплату месяц, а задействовать только один день — 16 мартобря 2028. Можете закупить гвозди и доски за два года до планируемой работы, а можете закупить так, что они прибудут сразу 16 мартобря 2028 и даже не успеют попасть на склад, а будут выданы сразу «в монтаж» Анастасии. Операционное управление, цепочки поставок (supply chains), логистика, исследование операций — всё это методы максимизирования прохода/throughput работ и предметов метода по какому-то графу создания за счёт снятия логистических (ресурсных, в том числе транспортных, то есть наличия ресурсов для работ вовремя) ограничений.

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

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

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

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

Если у вас сдельщина по результату работ — будет мало работы, много результатов. Если сдельщина по самой работе, то будет много работы, а результатов работы — мало, значительная часть работ будет бесполезной.

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

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

Операционный менеджмент и методология

В общей теории систем фон Берталанфи предложил operations research как науку, изучающую работы/operations в части их производительности/скорости. Проход как раз замеряется в единицах скорости, первой производной чего-то по времени. Проход — это первая производная объёма выходной продукции по времени — штуки для дискретной продукции или объёмы для непрерывного производства (химическая промышленность) в малую единицу времени, dx/dt. Единица времени должна быть малой, чтобы это было настоящей производной. Если единица времени большая, то менеджмент, по большому счёту, невозможен. Если вы хотите выпустить 500 штук продукции в год — то сколько надо производить в день? Весь год ничего и брать кредиты, а потом в последний день 500 штук? Или каждый день по паре штук — и иметь даже запас на случай сбоев (хотя что там про выходные дни, сколько их будет)? Если равномерный выпуск и оплата, тогда и кредиты брать не надо. Замеры должны быть точными, это означает, что дискретизация замера прохода должна быть поменьше, вы должны знать «ускоряемся» или «тормозим» не раз в год.

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

• Нужно рассматривать операционный менеджмент как методы работы в предметной области работ с задействованием ресурсов, изучаемый прикладной методологией.

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

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

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

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

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

Поясним это чуть подробней — но по-настоящему подробный разговор будет в курсе «Системный менеджмент». У операционного менеджера главный интерес — сделать рывок, то есть увеличить ускорение прохода (а проход — это скорость выпуска). Он должен постоянно (так и говорят: процесс непрерывных улучшений, POOGI, process of On-Going Improvement) поднимать throughput/«проход» как скорость выпуска целевой системы, замеряемую на выходе предприятия (включая склады, ибо непроданные системы нам не нужны, за них не будет заплачено). В одну сторону (от поставщиков сырья или исходной информации) текут потоки вещества, информации, работ и вытекают из фирмы к клиентам, а в другую встречным потоком текут деньги, из которых происходит оплата за каждый ресурс, проводящий обработку потока.

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

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

Как выполнять «распожаризацию»? Тут есть следующие логически последовательные шаги, в которых тесно переплетены работы с методом (предмет методологии) и работы с работами (предмет операционного менеджмента):

1. Нужно выполнить инженерную работу по принципам Lean/элегантности, так в бизнесе называют физический принцип наименьшего действия. То есть первым делом надо найти то, что можно не делать — и при этом риски что-то ухудшить в характеристиках целевой системы или величине прохода останутся более-менее приемлемыми. Учтите, что вы сейчас собираетесь резко ускорить работу (даже если у вас главная задача выпустить новый продукт хоть в каком-то единичном объёме — то это будет ускорением работы: проход был нулём, стал ненулевым. Но каким ненулевым? Одна система в сутки? Одна система в месяц? Одна система в год? Одна система в десять лет? Надо это оценивать количественно). Ненужную работу не нужно ускорять, она вредит делу! Поэтому просто перестаньте эту работу делать. Более точное выражение тут — не выполняйте работы по какому-то ненужному методу. Элон Маск как-то сделал замечание, что если вам не приходится возвращать одну из десяти убранных работ, то вы слишком мало убираете ненужных работ: ищите их тщательней! Это инженерная, содержательная работа, и важны тут не сами работы, которых может быть множество, а важны методы работы. Надо перестать делать работы по какому-то ненужному методу, для этого понять, какой метод ненужный. Это методологическая работа, работа с методами. Дальше с тем же количеством ресурсов вы просто будете делать меньше работы, и дело пойдёт быстрее.

2. Ни в коем случае не начинайте ускорять работы, пока вы не наладили управление конфигурацией (об управлении конфигурацией говорилось в «Системном мышлении» и будет ещё говориться в «Системной инженерии»). Конфигурационные коллизии ведут к появлению переделок/re-work. Если у вас в проекте беспорядок, то вы будете прихватывать лишние работы. Если у вас в проекте беспорядок, то вы будете быстро-быстро производить эти конфигурационные коллизии и тем самым быстро-быстро увеличивать объём работ, а не быстрее делать минимально нужный объём работ: подавать к супу вилку, варить в супе вместо картошки хлеб, потом говорить «ай, извините» — и переделывать это всё снова и снова, вместо 5 минут тратя на работу много раз по 5 минут плюс ещё некоторое время для устранения последствий ошибок. Скажем, забыли поставить прокладку при сборке станка, ошибка в конфигурации собранной системы: станок надо потом разобрать, вставить прокладку, снова собрать. Потери времени: не просто ещё одна сборка, а одна добавленная разборка, а затем добавленная сборка. Время, потраченное на проверку того, что вы всё сделали правильно (методологическая работа, чеклисты по тому, что все предметы метода пришли в правильное конечное состояние) окупается многократно в ходе операционной работы — будете тратить на 5 минут больше в ходе принятия решений по содержанию работ, по выбору метода работ, по конфигурационному учёту самих работ и предметов этих работ (всё это требует методологической работы, разбирательства с методами и предметами методов), но за счёт уменьшения неизбежных переделок экономия времени может быть в разы (само понятие «экономия времени» — это понятие операционного менеджмента). Мы относим управление конфигурацией и наведение порядка к методологической работе: надо определить типы учитываемых предметов, надо составить чеклисты, сделать необходимые проверки, организовать работу по методам управления конфигурацией. Но делается это для того, чтобы в операционной работе, в операционном управлении всё пошло быстрее и с меньшим количеством ресурсов (переделки часто занимают не только время сотрудников, но и требуют новых расходных материалов, если речь идёт о материальном производстве). Чтобы убрать много инженерной работы, нужно добавить немного учётной работы, «навести бюрократию». Это всё разбирательство с методами работы, методологический вопрос, а не собственно вопрос операционного менеджмента. Итак, чтобы дела пошли быстрее, надо просто не делать лишнюю работу — и это вопрос методологии, lean/элегантная работа оказывается не столько делом операционного менеджера, сколько методолога, который проектирует маршруты предметов метода между создателями в графе создания в ходе превращения предметов метода в конечном итоге в целевую систему.

3. Дальше устраняем wait time, время пауз в работе. Устранение пауз в работе делается методами операционного менеджмента. Паузы в работе могут быть больше или меньше просто от того, что вы начинаете или пять работ в параллель и делаете их «вперемешку», или делаете все эти работы последовательно (мультитаскинг), запускаете работу «в последний момент» (поздний старт) или «как только будут наличествовать ресурсы» (ранний старт). Операционный менеджер минимизирует время пауз в работе путём рационального планирования. Терминология (например, «время ожидания», wait time) тут отличается от терминологии разговора об элегантности и разговора об управлении конфигурацией, ибо отличается набор понятий. Мы дальше берём терминологию метода операционного менеджмента TameFlow, которая по большому счёту и отражает SoTA в операционном менеджменте, ибо кроме управления промышленным производством (manufacturing) имеет дело с управлением разработкой — это недавнее введение в операционном менеджменте. В этом третьем шаге речь идёт о собственно работе операционного менеджмента, а не о методологической работе, не инженерной работе. Без предыдущих двух пунктов методологической работы в «распожаризации» использование TameFlow или любых других видов метода опереционного менеджмента будет вредным! Вы резко ускорите беспорядок! Будет не просто хаос и пожары на работе, а крайне быстрый, ускоренный хорошим операционным менеджментом хаос и пожары! Операционные менеджеры вредны, если они хорошо делают свою работу без предварительной работы инженеров целевой системы и инженеров предприятия, занимающихся методологией разработки. «Устранение времени пауз», предотвращение «пробок» в работе, поддержание стабильного скоростного потока — это и есть операционный менеджмент, работа с работами, а не методами работ. Логически это только третий шаг! Если вы занялись организационными реформами, то начинать надо с методологической работы, это уже даст резкое ускорение. И только потом можно говорить об ускорении работ за счёт собственно практик операционного менеджмента.

4. После того, как вы добились успеха в устранении времени пауз (там очень, очень много нюансов, для их понимания нужно читать специализированные учебники операционного менеджмента, в курсе «Системного менеджмента» будет рассказано, какие учебники надо читать, и там не только литература по TameFlow), вам нужно опять обратиться к методологии: заняться уменьшением времени обработки рабочих продуктов на определённых операциях (touch time), которые будут вам даны по итогам предыдущего шага. Для этого вы должны выбрать новые методы работы, которые дадут вам сокращение времени обработки. Например, автоматизировать какие-то операции. Важно, что не нужно сокращать время любых производственных операций, а только находящихся на критических местах в потоке работ — вся арифметика для нахождения этих мест вами будет выполнена на предыдущих шагах. И это опять будет инженерная задача, которая потребует методологических (по изменению метода работы) решений по существу инженерного вопроса, а не чисто менеджерская задача по распределению работ по ресурсам и учёту выполнения этих работ. Именно тут требуется продемонстрировать, почему вы вдруг занялись новыми методами работы вот прямо сейчас: как это отразится на проходе/throughput? Если никак, то вы занимаетесь не той методологической работой!

5. Не давайте инерции себя остановить! Вернитесь к пункту 1 и повторите всё с самого начала: выкиньте работы по ненужным методам — то есть прямо уменьшите число работ, наладьте управление конфигурацией (операционный учёт) — это высвободит ресурсы от многочисленных переделок/re-works, далее займитесь действиями по уменьшению времени пауз в работе, а затем вернитесь в расчётах к работам, где надо вернуться пересмотру их методов, чтобы сократить время работы за счёт изменения способа работы. Но это в самом конце, когда уже известно из расчётов (буквально: из арифметики), время каких работ надо уменьшать, а затем надо выполнить организационное изменение: перейти на работу по новому методу, и дальше вернуться к пункту 1 — не давать инерции остановить себя однократным прохождением цикла.

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

За забивку гвоздей у нас ответственна Анастасия в должности «плотник» (не путать с оргролью «плотник»), и обычно она забивает 180 гвоздей за час. Обсуждаемая работа начинается в полдень 3 мартобря 2029 года, и планируемая её продолжительность — десять минут. За это время Анастасия как оргзвено «плотник» должна забить 20 гвоздей в четыре места на досках.

Работы легко наблюдать: это просто взаимодействующие между собой ресурсы (включаемые в работу по отношению участия/participation, это такая специализация отношения composition/состава/is_part_of/часть-целое), но взятые не только как объёмы в пространстве, но и протяжённые во времени. Так, работа по методу «забивка гвоздя» представляет собой поведение взятых на интервале 30 секунд молотка, гвоздя, доски и забивающего их работника как конструктивных объектов. Их нужно собрать вместе на эти 30 секунд, чтобы они провзаимодействовали, то есть поучаствовали как ресурсы в этой 30-секундной работе. Если будет забито 180 гвоздей за час, то это 180 работ по методу с сигнатурой «забивка гвоздя».

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

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

⠀

Жизненный цикл 1.0 — это работы создателей
над создаваемой системой

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

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

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

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

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

Чтобы собрать какую-то нужную нам (целевую, думаем о времени эксплуатации/использования) конструкцию из досок, нам нужно создать проект/project — организовать создателя::оргзвено на выполнение работ по сборке конструкции. Оргзвено (создатель, думаем о времени создания конструкции из досок как целевой системы) состоит из модулей Анастасии-с-ответственностью, молотка, 20 гвоздей, четырёх досок. Нам нужно ещё запланировать эти все ресурсы на 20 минут, иначе работы не случится. Это всё менеджерские работы: проекты создают и затем ими управляют (то есть управляют последовательностью выделения ресурсов на работы — возможно, привлекая временно свободные ресурсы из других проектов) менеджеры (создатели и операторы эксплуатации организаций).

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

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

Обратите внимание, что по факту «жизненный цикл системы X» ничего не говорит о самой целевой системе X и её состояниях. Он говорит про то, что делают системы создания X: работают-то они, а не целевая система. Целевая система пассивна, это предмет работ, в современном операционном менеджменте работы над каким-то изменяемым предметом работ называют case/дело (от «судебного дела», медицинской «болезни», case file — это папка «Дело №__» или в медицине папка «истории болезни», то есть описание работ дела/случая/ситуации/болезни). Запоминаем: кейс — это работы, только для этих работ не всегда известен план, а в самом начале этих работ часто известна сигнатура («вылечить больного», «раскрыть дело, наказать преступника»), но неизвестно ещё разложение метода, поэтому и планирование этих работ up front (перед проведением работ) невозможно, оно проводится после каждого шага работ. Судебные дела, лечения, исследования, отладка/troubleshooting/debug, проектирование — всё, что требует высказывания и проверки гипотез — ведётся «непрерывно открывающимися обстоятельствами», для планирования каждого шага работ используется свежеполученная от предыдущих шагов работы информация.

В кейсе/деле забивания гвоздей целевая система (в момент эксплуатации!) — это забитый гвоздь. Кейсом будут все работы для этого, а сам кейс::работа будет назван по его предмету — «гвоздь» (предмет этих работ, который нужно привести в конечное состояние «забит». Если предмет работ не гвозди, работы — «забивание гвоздей», а доски с работами по скреплению досок заранее непонятным методом, то кейс будет «доски», приводимые в состояние «скреплены»). Описывает вариант с заранее непонятным планом работ вид «операционного менеджмента»:: метод, известный как case management. «Case management»:: метод, в свою очередь, род для разных его видов, например adaptive/dynamic/advanced case management, который в последнее время перестал быть в силу общей распространённости отдельным компактно излагаемым вариантом метода case management со специальным софтом его поддержки. Само операционное управление теперь связывается с case management — вплоть до того, что классическое проектное управление с up front планированием считается частным случаем кейс менеджмента (ибо редко бывает, что состав работ заранее известен и возможно составить качественный план), а управление работами по этому методу называется «проектное управление». Поддержка со стороны программного обеспечения перешла от специализированных систем проектного управления в системы с облегчённым программированием, универсальные моделеры, LowCode. Так что сегодня «проектом» называют то, что ещё вчера было более-менее крупным кейсом (работы, названные по имени предмета кейса, предмета работ — то, что надо привести в какое-то конечное состояние). Значение слова «проект» окончательно оторвалось от классического «проектного управления».

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

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

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

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

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

• Они занимают место в пространстве-времени.

• У них тоже есть полная стоимость владения.

• … и на них можно ещё смотреть очень по-разному, в зависимости от проекта.

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

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

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

Итак, Анастасия, предоставляющая сервис забивки гвоздей, берёт свой молоток и забивает выданный ей гвоздь №143 в доску #26, то есть выполняет работу. Жизненный цикл гвоздя в представлениях прошлого века (первое поколение, 1.0) состоит уже не из состояний гвоздя («лежит в коробке», «взят в руки», «нацелен», «забивается», «забит»), а происходящих с ним работ, которые, конечно, можно описывать и как конечные состояния гвоздя, но всё-таки это работы систем создания, сам гвоздь при этом ничего не делает, он пассивен. В не жизненном не цикле принят аналог «аристотелевской физики», где палец давит на стол, а стол не давит на палец. Работают создатели, а гвоздь в ответ не работает, он пассивный объект для систем создания, он просто меняет состояния по мере выполнения с ним работ, «претерпевает изменения».

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

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

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

• Выдача в монтаж (или гвоздь доступен в месте забивки — указание на работу по выдаче гвоздя в монтаж. Дальше мы просто не будем писать эти разъяснения, идея тут понятна).

• Нацеливание гвоздя (гвоздь нацелен).

• Вколачивание гвоздя (гвоздь вбит).

• Проверка крепости соединения («гвоздь держит крепко», но объект поменялся. Теперь это «соединение». Куколка стала бабочкой! Другой объект, по-другому называем).

• Эксплуатация соединения (соединение держит и стабильно при нагрузках)

• Вытаскивание гвоздя (гвоздь вытащен).

• Ликвидация гвоздя (гвоздь выкинут — жизненный цикл всегда идёт до исчезновения объекта работ).

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

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

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

Моделирование: предметы кейса, их состояния, практики достижения состояний

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

Жизненный цикл 1.0 — предмет управления работами

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

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

Конечно, чтобы работы были выполнены, надо ещё сделать организационную возможность (capability):

• У оргзвена есть мастерство выполнения метода и все необходимые инструменты и материалы.

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

• Известно, кто может давать предметы метода на входе и известно, кому отдавать результаты на выходе (если это конвейер, то принимать работу нужно от одних оргзвеньев, а отдавать её — другим).

Конечно, в организационном контексте не так часто говорят слово «метод», но используют самые разные другие синонимы. Часто, например, говорят «практики» (practice), не менее часто используют и понятие «рабочие процессы» и даже кривой термин «бизнес-процессы» (в западных стандартах по IT рекомендуют business process менять на organizational или organization process в зависимости от того, что принято, на русском это «оргпроцессы» или «административные процессы»). Давайте посмотрим абзац про оргвозможности с синонимом метода — «рабочий процесс». Конечно, чтобы работы были выполнены, надо ещё сделать организационную возможность (capability):

• У оргзвена есть мастерство выполнения рабочего процесса и все необходимые инструменты и материалы.

• У оргзвена есть полномочия выполнять работы рабочего процесса (то есть выполнять оргроль).

• Известно, кто может давать входы рабочего процесса и известно, кому отдавать выходы (если это конвейер, то принимать работу нужно от одних оргзвеньев, а отдавать её — другим).

Как видите, ничего не изменилось, разве что «предметы метода на входе» были согласно традиции обсуждения рабочих процессов названы входами/input, а предметы метода на выходе метода названы выходы/output. При этом мы свободно говорим про мастерство выполнения метода/«рабочего процесса» оргзвеном, ибо минимальное оргзвено — это один человек, но это может быть и какое-то подразделение или даже коллективный орган (скажем, собрание акционеров какого-то предприятия, научно-технический совет, комиссия, рабочая группа проекта) или даже какое-то предприятие (скажем, предприятие, входящее в холдинг — «дочернее или зависимое общество»).

Обсуждение оргзвеньев идёт как конструктивов:

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

• Как из оргзвеньев на каких оргинтерфейсах собирается вся организация как целое (из каких конструктивов на каких интерфейсах собирается целая система, как её собрать без лишних зависимостей, задача архитектора), как там работает логистика.

• Как сделать так, чтобы сотрудничали: чтобы оргзвенья выполняли работы, а не артачились, задача лидера.

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

• Как сделать так, чтобы умели работать по методу (было мастерство сотрудников)

• Как сделать так, чтобы наладить управление работами, чтобы всё было вовремя (ресурсы были, старт работ был оптимальный).

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

Каждая работа проходит следующий цикл взаимодействия оргзвеньев (это подробно обсуждается в подходе к архитектурному описанию предприятий DEMO и курсе «Системный менеджмент»):

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

• Работа принята к исполнению оргзвеном-исполнителем, это тоже координационный акт.

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

• Результаты работы предъявлены к приёмке оргзвеном-исполнителем, это координационный акт.

• Результаты работы приняты оргзвеном-инициатором работы, координационный акт.

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

Деление на координационные и производственные акты в обсуждении работ важно, чтобы делать правильные оценки времени на выполнение работы: от момента затребования работы до момента принятия результатов работы на координационные акты легко может уходить до 60% времени, и только 40% времени на проведение самой работы, а в случае знаниевых (проектных, а не изготовления физического воплощения) работ это может быть и 80% на 20% в среднем, ибо работы по «обоснованиям решений о том, что надо сделать» очень трудоёмки сами по себе: надо не просто запросить работу, но и обосновать то, что её надо выполнить (это может быть более трудоёмко, чем сама работа!), и надо не только предъявить результаты работы, но и обосновать то, что эти результаты приемлемы.

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

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

Как планировать работы — по полному времени координации+производства работ, или только по актуальному времени потребления ресурсов? Разные школы управления работами (проектного управления, управления процессами, управления программами, управления кейсами — тут тоже изобилие синонимов) отвечают на этот вопрос по-разному. Управление работами как раз занимается планированием работ и контролем выполнения работ, где работы — это поведение оргзвеньев/оргединиц. Управление работами не обсуждает то, как правильно выполнять работы создателей так, чтобы они меняли создаваемую и развиваемую систему в нужном направлении (т.е. без обсуждения оргролей и их методов работы).

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

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

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

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

Помним: геном и мемом — это наследуемый материал (гены в ДНК и мемы на каких-то носителях информации, например в PLM-системе в машиностроении или репозитории кода в программной инженерии), а феном — это проявленный в организме наследуемый материал. Техноэволюция идёт быстро, и в жизненный цикл (то есть не жизненный и не цикл) заодно попали стадии/работы, в которых идёт работа по получению и развитию мемома (иногда в промышленности это идёт как «проектная документация») целевой системы, проекта/design целевой системы. Слово «проект» в русском языке имеет не только значение проекта/project::работы по созданию системы, но и значение проекта/design как мемома создаваемой системы, то есть описания ещё не реализованной системы. Мы будем отличать проект-работы и проект-описание-системы как проект/project и проект/design. В жизни нужно различать эти значения, как обычно — по контексту, смотреть на «что хотели сказать», а не на употреблённый термин. В трудных случаях — переспрашивать. На вопрос «ты сделаешь мне проект сепульки?» надо уточнять — сделать только описания системы (design), или вообще сделать саму сепульку (project) — как описания системы, так и изготовление самой системы?

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

Целевая система осталась только как «объект проекта», объект для группы работ, объединённых понятием «жизненный цикл объекта проекта»: указание того, над чем идут эти работы жизненного цикла. Иногда вместо проекта появлялись и более мелкие деления работы — кейс/case (из управления кейсами: аналог проектного управления, не требующий up front планирования, позволяющий планировать «на лету») или управления задачами/task (как правило, это то же самое, что управление кейсами, разница в нюансах).

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

Вскоре повсеместно жизненным циклом стали называть уже не сам отрезок времени жизни целевой системы «от рождения до смерти», а работы как выполнение сервисов систем создания: совокупность стадий/фаз жизненного цикла в его понимании первого поколения. Эти работы упоминались на всём времени существования системы: от появления первых описаний до ликвидации использованного и уже не нужного никому воплощения. Создание оказалось ведением жизненного цикла как ведением работ, необходимых для изменений состояний целевой системы в ходе её «жизни» как изменений внешними силами.

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

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

Итак, жизненный цикл создаваемой системы в версии 1.0 означает просто последовательность работ, которые производят создатели этой системы.

Изображались такие жизненные циклы 1.0 с периодизацией работ очень просто: такими «колбасками», в которых поминались производимые последовательно крупные работы каких-то периодов времени внутри периода времени всей работы. Эти крупные отрезки времени внутри всего времени работ по изменению состояний системы были названы стадиями/фазами жизненного цикла. Вот примеры такого изображения жизненного цикла разных типов систем из стандарта ISO 15288, и обратите внимание на то, что каждое название стадии там говорит о работах создателей, а не о состоянии создаваемой системы (хотя иногда и случаются наименования состояния, но они используются как альтернативное название проводимых работ для достижения этого состояния, в духе положений PRINCE2 о том, что работы лучше бы называть по их результату как выполнению метода — конечному состоянию предмета метода):

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

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

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

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

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

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

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

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

Методология (обсуждение способов выполнения работ, а не только последовательности выполнения работ и группировки работ в стадии/фазы) пришла чуть позднее. Идея безмасштабности создателей (например, понятие создателя/constructor из constructor theory Дэвида Дойча) пришла ещё позже, по большому счёту эта идея ещё даже не вошла в методологический мейнстрим, это ещё фронтир. И уж совсем недавно пришла идея, что однократным проектированием-изготовлением дело не обходится, системы эволюционируют, они непрерывно развиваются — но не столько развиваютСЯ (сами себя развивают), сколько их развивают их создатели, ведут техно-эволюцию систем как вида, а не как экземпляра или серии одинаковых экземпляров.

Жизненный цикл проекта

Но поскольку уже было понятно, что речь идёт о работах, а естественной максимальной (соразмерной стадиям ЖЦ) единицей работ в проектном управлении стал «проект» (project, а не design), то появился ещё один термин: жизненный цикл проекта (project life cycle) — он означал те работы полного (от замысла до ликвидирования системы) жизненного цикла, которые попадали в рамки конкретного проекта с конкретными организаторами. Проекты эти обычно совпадали с работами, проводимыми для каких-то полных стадий жизненного цикла, одной или нескольких — скажем, только разработка, только изготовление, только эксплуатация. Это называлось «естественным делением жизненного цикла», потому что разные проекты часто выполнялись разными организациями — и нужно было как-то выделять части жизненного цикла, за которые несла ответственность проводящая проект организация/оргзвено.

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

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

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

Особо нужно отметить о времени жизненного цикла в его 1.0 понимании:

• Понятие жизненного цикла — всегда полные работы на всём протяжении от замысла до ликвидирования системы (это влияние системного мышления)

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

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

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

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

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

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

---

Так, в военной системной инженерии киберфизических систем про жизненный цикл какого-то военного самолёта могут говорить как о программе этого самолёта — это ровно вот эта подмена нейтрального для самых разных практик/деятельностей/инженерий (киберфизики, менеджмента, основания предприятий/предпринимательства) понятия жизненного цикла понятием из проектного управления, которое сегодня развилось из просто project management в program and project management (иногда этот переход от «просто к проектов» к «проектам и программам проектов» называют «третье поколение проектного менеджмента», совместное мышление о программах работ и проектах как частях программы работ). При этом при переходе от проекта (от даты-1 до даты-2) переходят к «открытой дате окончания» (её просто не указывают, «работы над системой можно только начать, их нельзя закончить», это неявно отражает переход к концепции «непрерывного всего», но всё-таки с удержанием идей классического проектного и программного управления).

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

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

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

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

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

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

Садовник создаёт (в данном случае замышляет, проектирует, выращивает, эксплуатирует, ликвидирует) цветок: ведёт работы по методам замысливания появления цветка в конкретном месте, посадки семечка, полива семечка, а потом и растения, удаления сорняков из окружения растения, удобрения почвы для благоприятного окружения цветка, а после цветения выведения из эксплуатации (ликвидации/выкидывания) уже отцвётшего цветка. Цветок ничего не делает сам, все работы его жизненного цикла делает его система создания в лице садовника.

---

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

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

Проблемы с жизненным циклом 1.0

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

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

Эпоха «водопада/каскада/cascade» как «последовательного прохождения стадий жизненного цикла, как вода течёт в водопадах всегда сверху вниз» закончилась даже до появления полноценной идеи «непрерывного развития», в которой множество линейных жизненных циклов и системы в целом, и её фич замыкались в изначальное «квазибиологическое» кольцо/цикл. Квазибиологическое кольцо, когда никакая версия системы не является последней — это всё-таки техно-эволюция, когда создатели делают всё новые и новые версии системы, но не система делает себя сама снова и снова как в дарвиновской биологической эволюции (в техноэволюции мутации не случайны, это smart mutations, а наследственный материал не реплицируется вместе с системой — он хранится где-нибудь в конструкторском бюро). Но это уже была эволюция, не «от рождения до смерти» даже с учётом проектирования, и даже не «круговерть рождений и смертей», как в биологической эволюции, а круговерть доработок системы — и доработок в замысливании, и доработок в разработке, и доработок в изготовлении — типичная инженерия из идеализированной greenfield («с нуля») инженерии превратилась в повсеместную brownfield (не с нуля, доработка уже имеющегося) инженерию.