2. Графы создателей

Отношения создания

Простейший граф создателей метафорически (то есть весьма вольно) можно проиллюстрировать диаграммой:

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

Целевая система проявляет свои внешние свойства в надсистему «в ходе»/«во время» её работы/operations, это обозначено словами «феном¹ тут». Слова run-time часто используются в программной инженерии, чтобы обозначать время функционирования/работы/эксплуатации готовой системы. Но мы обозначили на диаграмме его другим, не менее употребимым словом — Ops-time, время работы операторов системы, когда система в рабочем состоянии, функционирует.

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

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

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

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

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

Конечно, есть проблемы и единства рассмотрения этого времени, так называемая проблема DevOps, когда разработчики/создатели системы никак не связаны с операторами/пользователями и поэтому делают систему, которой невозможно пользоваться. Эта проблема решается прежде всего организационными мерами, но сегодня часто задействуют и технические меры: операторы и даже пользователи вообще исключаются как люди, заменяются роботами, так называемый подход NoOps². В любом случае, в системном мышлении принято не столько считать всё происходящее в разработке и использовании принадлежащим к одному физическому времени, сколько различают «логические» времена создания (development, design, construction, implementation, enabling — везде в центре методы работы создателей, а целевая система тут пассивна, ещё не готова к работе) и времени эксплуатации (run, operation, use — функции/методы самой целевой системы, а создатели тут уже не работают, пассивны).

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

Между системами в окружении (целевой, надсистемой, системами в составе надсистемы из ближнего окружения и т.д. — если встретилось слово окружение/среда/environment, надо всегда помнить, что это «операционное окружение»/«operations environment», то есть рассмотрение времени работы) и их создателями тоже отношение создания (development, design, construction, implementation, enabling в инженерии, в constructor theory — универсальное transformation), когда один создатель::система описывает и/или меняет другую систему. И таких систем можно рассмотреть целый граф по отношению создания, а если поглядеть на все такие цепочки как пути на графе, то это будет граф создателей: узлы — это системы (целевая и создатели) а рёбра — отношения создания. Внутри одного времени — отношения часть-целое/композиции, через границы времён/realms — отношения создания (X::система создаёт/«изменяет состояние» Y::система).

На диаграмме показан вариант такого графа создателей. Для каждого создателя тоже было его создание, и его эксплуатация/использование/работа/operations. Поэтому на диаграмме представлено несколько разных «времён» рассмотрения (realms), и что для создателя будет его ops-time, для целевой системы будет dev-time. А что для создателя его dev-time, то для создателя создателя — ops-time.

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

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

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

Отношения создания — это не отношения часть-целое! Enabling/construction это не composition/part_of! Кастрюля, в которой варится борщ — это не кастрюля в составе борща, или борщ в составе кастрюли! Это кастрюля для создания борща!

А теперь поставьте крестик на любом из кружков этой диаграммы, которым в составе большой команды проекта будет заниматься ваша маленькая команда (возможно, в ней будете только вы один) — это будет «наша система» (system-in-hand, engineered system, MySystem, OurSystem). И повторите все рассуждения про целевую систему для нашей системы — ни на секунду не забывая про целевую систему и отношения нашей системы и целевой системы!

Запутались? Запишите все эти системы в каком-нибудь редакторе текстов или другом моделере, как шахматист записывает шахматную партию. Думайте не «в уме», думайте над текстом, или аутлайном, или таблицей!

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

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

Документирование в системном мышлении важно. Внимание, которым управляют без записей, управляется ненадёжно. Люди забывчивы, поэтому документируйте/записывайте всё (всё-всё!).

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

Моделирование: граф создателей

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

Концепция использования

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

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

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

Мы описываем систему как чёрный ящик минимально четыре раза, это и есть «системное рассмотрение»:

• Функционально: как роль (функциональный/ролевой объект) и его функцию во взаимодействии с окружением во время эксплуатации/работы/функционирования. Забивало — прикладывает усилие от руки к забиваемому острому предмету.

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

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

• Стоимостно: Как совокупная стоимость владения чёрным ящиком. Вот эта штука, стоит 1000 рублей купить и практически нисколько эксплуатировать.

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

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

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

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

«Описываем систему» — это или

• «прямая инженерия», то есть проектирование/design в части придумывания того, какая нужна система в составе надсистемы.

• «обратная инженерия»/reverse engineering уже существующей системы, если такое описание недоступно, но для чего-то нужно.

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

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

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

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

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

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

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

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

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

Главное тут:

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

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

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

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

• Отказ от требований привёл ещё и к тому, что начали активно использовать A|B тестирование⁶, когда гипотез выдвигается сразу несколько (требования обычно требуют что-то одно!), и проверяются они все вместе, а потом выбирают вариант, который оказался по каким-то критериям лучше. Если у тебя «гипотезы», а не «требования», то ты с ними поступаешь другим образом: не столько «удовлетворяешь», сколько «проверяешь и постепенно корректируешь».

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

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

«Нефункциональных требований» не было, хотя такой термин часто встречался в литературе, но обычно разъясняли, что его использовать неправильно. Чаще говорили просто о других видах требований — например, требованиях качества (-ости/-ilities, типа доступность, ремонтопригодность, надёжность), которые интересны не только разработчику, но и другим ролям в проекте, прежде всего роли архитектора. Сейчас стало очевидно, что архитектура имеет дело с архитектурными характеристиками (прежде всего эти -ости), но они относятся к системе не в части выполнения своих прикладных функций, а к общему какому-то поведению и в момент работы/operations (например, характеристики надёжности работы) или даже на момент создания и развития (например, характеристики возможности лёгкого изменения в ходе непрерывных улучшений, evolvability). И эти характеристики хотя и разные, но всё-таки более-менее одинаковые у самых разных видов систем. Например, масштабируемость/scalability: насколько легко поднять производительность системы, если это надо — нужно будет только добавить какие-то дополнительные модули (скажем, добавлять ещё пару колёс на каждую новую тонну грузоподъёмности тележки, или придётся всё разрабатывать по-новой с самого начала — ибо для увеличения грузоподъёмности менять надо в тележке и раму, и колёса, и вообще всё?). Архитектурные характеристики — описание поведения системы при работе в необычных условиях или не в момент эксплуатации: способность работать под высокой нагрузкой, ремонтопригодность, доступность по цене/affordability (помним, что совокупная стоимость владения затрагивает и стоимость расходников и обслуживания при эксплуатации, но ещё и стоимость изготовления включает не только стоимость материалов, но и стоимость работ системы создания, то есть затрагивает описание ещё и систем не из окружения, а из графа создателей), лёгкость монтажа. Руководство по системной инженерии подробно разбирает работу архитектора, архитектурные характеристики, способы достижения приемлемых значений для метрик, которыми измеряют архитектурные характеристики, даёт современную дополнительную литературу на эту тему.

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

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

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

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

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

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

• механического замка с поворотным ключом,

• механического замка с нажимным ключом,

• электрического замка с программируемым электронным ключом-«таблеткой»,

• электрического замка с управлением через приложение в смартфоне,

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

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

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

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

Концепция системы и архитектура

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

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

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

Обычно организация проекта (например, коллектив из нескольких команд) согласовывает с внешним заказчиком системы функции/поведение, которые должна бы выполнять целевая система как чёрный ящик, свойства этого чёрного ящика, т.е. разработчики согласовывают концепцию использования (чаще всего даже не всю, а какие-то отдельные сценарии использования по отдельным «фичам», которые будут реализовываться какой-то отдельной командой), а архитектор системы согласовывает архитектурные характеристики и их приемлемые значения для всех команд разработчиков. Не факт, что эти гипотезы по концепции системы и приемлемым архитектурным характеристикам формулирует заказчик! Это совместная с заказчиком работа. Как устроена система внутри, то есть какие функции выполняют подсистемы и какими физическими объектами реализована конструкция системы — это коллектив проекта определяет самостоятельно, заказчика больше интересует обычно надсистема, она для него «прозрачный ящик», а целевая система — «чёрный ящик». Более того, это часто делается не за один приём, а долго — и продолжается даже после того, как первая версия (MVP, minimal viable product) уже изготовлена и начала использоваться. Часто самые интересные идеи и у агентов-заказчиков в самых разных их ролях, и у агентов-исполнителей этого заказа будут появляться уже после появления MVP, в ходе последующего развития системы.

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

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

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

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

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

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

Моделирование: концепция использования и концепция системы

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

Рекурсивное рассмотрение в системном мышлении

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

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

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

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

• целевая система — описывается как «чёрный ящик» преимущественно постепенно детализирующимися сценариями использования. По большому счёту тут то же самое рассмотрение, что и для надсистемы, в ISO 15288:2023 это называется рекурсивным применением системного мышления.

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

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

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

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

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

В рассмотрении времени создания (construction time) создатели::системы, мы просто не рисуем кружки и их вложенные/внутренние части.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры системной терминологии

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

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

Дадим пример использования терминологии системного мышления в описании простой механической системы с электрическими элементами — напорного насоса.

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

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

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

• Насосная станция (наднадсистема)

• Насосный агрегат (надсистема)

• Насос (система)

• Роторная сборка как ротор с лопатками (подсистема)

• Ротор (подподсистема)

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

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

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

Другой пример: электроника с островками софта — наручные смарт-часы.

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

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

Ещё одна интересная система этого класса, включающая людей — это домашнее хозяйство (household), которое может включать и самих владельцев, и дом, и домашнюю утварь.

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

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

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

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

Системы в окружении — рука, одежда (как минимум, рукав рубашки или пиджака), зарядное устройство. Подсистема — защитное стекло (например, из Gorilla glass — закупается отдельно у контрактора, занимающегося производством защитных стёкол на заказ).

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

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

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

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

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

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

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

Ровно такой же рассказ будет и о менее классических системах, нежели традиционные для инженерии электромеханические (насос) и киберфизические (дрон, смарт-часы) системы.

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

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

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

Более того, это может быть в случае командного системного мышления и несколько мозгов и компьютеров плюс средства коммуникации между ними). Системы в ближнем окружении мастерства системного мышления: мастерство онтологического мышления, мастерство собранности. Создатель мастерства —онлайн-версия руководства по системному мышлению как программа на серверах дата-центра и опционально наставники стажировки — они могут быть, но их может и не быть. Создатели создателя мастерства, то есть создатели онлайн-версии руководства по системному мышлению — автор текста руководства и заданий (Анатолий Левенчук), сотрудники и добровольцы мастерской инженеров-менеджеров с их LXP (learning experience platform) Aisystant.

Моделирование: краткое описание системы

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

Разделение труда и системные уровни

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы. Концепция использования и концепция системы

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

+++ ожидается, что ребёнок будет улыбаться не менее 20% времени при игре с этой игрушкой ### Да, это из концепции использования — речь идёт о части надсистемы, т.е. о говорится о ребёнке, находящемся в окружении куклы, целевая кукла своим поведением приводит его в состояние улыбки.

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

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

+++ игра с игрушкой по часу в день за три месяца даёт рост IQ ребёнка на 10 единиц ### Да, это из концепции использования — речь идёт о части в окружении целевой системы/куклы.

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

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

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

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

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

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

+++ расходы на антикоррозийные мероприятия для вентилятора с ротором с покрытием будут меньше на 10% по сравнению с обычным ротором ### Да, это про надсистему (вентилятор), в состав которой входит ротор с покрытием, в состав которого входит целевая система (покрытие), то есть это высказывание из концепции использования.

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

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

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

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

--- сделаем нанопокрытие ### Нет, это концепция системы: указание на то, как должно быть устроено покрытие.

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

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

--- концепция использования ### Нет, это описание тетрахопореза как «чёрного ящика».

+++ 3D-модель в САПР ### Да, 3D-модель в САПР — это описание внутреннего устройства тетрахопореза, описание «прозрачного ящика».

+++ программа для станка с ЧПУ ### Да, это описание «прозрачного ящика», в программе для станка с ЧПУ отражено внутреннее устройство тетрахопореза, форма его деталей (хотя тут можно вести философские споры: описывается поведение станка с ЧПУ или описывается форма деталей тетрахопореза «в конструктивной манере, через операции создания»).

--- акт приёмочных испытаний (acceptance test) ### Нет, это про поведение экземпляра тетрахопореза — и ничего про устройство тетрахопореза.

Йон Тихий хочет узнать функциональность сепулькария. На поиск какого из описаний системы ему стоит направить максимум усилий?

+++ концепция использования сепулькария ### Да, именно концепция использования описывает функциональность целевой системы: то, для чего она предназначена, что она делает.

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

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

--- компьютерную модель здания для сепулькария ### Нет, компьютерная модель расскажет только про устройство здания сепулькария, но ничего не скажет про сам сепулькарий.

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

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

Моделирование: концепция использования

Заполните табличку для трёх и более целевых систем известных вам проектов

Системы систем

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

Системой систем называют такую систему, которая имеет (критерии Maier⁹):

• независимые системы создания/enabling её подсистем (у ответственного за SoS нет полномочий предписать общее развитие-модернизацию для входящих в SoS систем)

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

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

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

• географическое распределение входящих в SoS систем.

Эти критерии различаются, конечно, в разных инженерных и менеджерских школах, но общее остаётся:

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

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

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

В системе систем важны прежде всего владеющие частями-системами и полномочные в распоряжении ресурсами труда и капитала агенты (люди, предприятия), именно они делают систему систем/system of systems/SoS особым случаем.

В ISO/IEC/IEEE 21841:2019 выделено четыре типа систем систем, отличающихся степенью их автономности:

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

• подтвержденные (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать владельцев составляющих SoS систем изменить свои системы согласно разработанной им архитектуре (то есть у архитектора нет отношения надзора/governance, только менторинг по поводу принимаемых им архитектурных решений).

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

• виртуальные (virtual), в которых владельцы систем, составляющих SoS, вообще не знают друг о друге ничего, и тем самым команды проектов создания и развития составляющих систем не влияют друг на друга явно.

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

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

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

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

Сегодня SoTA-метод лидерства — распределённое/shared лидерство¹⁰ (нет одного «режиссёра», все выполняют роль лидера, каждый вокруг себя). Но в любом случае тут идёт опора на гуманитарные дисциплины/теории социологии, политологии, психологии, конфликтологии и т.п. Была надежда, что выделение «системы систем» как отдельного класса систем что-то даст для того, чтобы лучше организовать их создание. Но ничего не получилось. Все достижения методов «инженерии систем систем» (systems of systems engineering) на поверку оказываются достижениями других методов работы, главным образом менеджмента. Частично используются результаты развития методов системной архитектуры, которая пытается обеспечить максимальную автономность работы команд в «обычных проектах». Эти же результаты применимы и в проектах создания и развития систем систем.

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

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

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

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

Интеллектуальные агенты в системах

Человек, равно как и AI-робот в составе систем учитывается сложно, ибо он одновременно может быть

• и целевой системой («продуктом»)

• и надсистемой, где чаще удобней рассматривать даже не всего человека, а его часть — часть тела::hardware или мастерство как часть личности::software,

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

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

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

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

Люди могут договариваться друг с другом по самым неожиданным поводам и предпринимать по линии этих договорённостей самые неожиданные для команды проекта действия, причём из лучших побуждений. Скажем, вы поручаете заводу-изготовителю сделать по вашей 3D инженерной модели медный теплообменник. Инженеры этого завода вдруг находят, что меди там многовато, и они из лучших побуждений убирают медь — меньше материалоёмкость, более тонкие стенки, лучше теплообмен! И изготавливают «улучшенный вариант, наши улучшения — это наш бонус вам». Вы включаете теплообменник, тонкие стенки под напором жидкости начинают гудеть громче, чем концертный орган! Теплообменник стал генератором вибраций, источником шума! Вот так бонус! «Хотели как лучше, получилось как всегда» — это весьма распространённое явление в проектах по созданию и развитию систем, поэтому-то любые изменения и имеют статус «гипотезы», всегда надо быть готовым к тому, что «гипотеза не подтвердилась». И ведь без «инициативы снизу» проекты тоже не живут!

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

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

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

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

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

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

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

Сложнейшими системами с людьми и AI-агентами являются такие групповые создатели/enabling/constructor systems как предприятия, рабочие группы проекта, расширенные предприятия (extended enterprise, предприятие с его контракторами, занимающееся какой-то большой целевой системой, например, атомной электростанцией, или серийным выпуском сложных транспортных систем — самолётов или автомобилей).

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

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

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

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

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

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

Трудно представить, что левый ускоритель в ракете будет подговаривать правый ускоритель лететь не к Марсу (куда они должны лететь), а к Луне — потому что так надёжней и быстрей, заведомо хватит топлива и менее хлопотно. А вот в системе из интеллектуальных агентов такое бывает сплошь и рядом. Осторожней с применением технических инженерных методов работы с «железом» и «софтом» к системам с людьми и AI. Хотя так же осторожно нужно относиться и к обратной ситуации — неприменению общих системно-инженерных методов работы, которые являются обобщением как раз методов работы с «железом» и «софтом» к системам на всех эволюционных/системных/организационных уровнях (уровнях сложности), включая не только инженерию предприятия, но и социальную инженерию сообщества, общества и даже человечества в целом. Обсуждение последствий этого неприменения см. в работах John Doyle¹⁷.

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

Системная этика

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

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

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

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

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

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

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

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

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

Этичность точно так же рассматриваться должна без какой-либо индивидуальной, расовой/религиозной и даже видовой пристрастности. Деантропоморфизация этического мышления будет полезна в том числе и для людей. Этична ли смерть? Ведь программируемая смерть²⁰ — это свойство всей жизни! Один ответ — нет, ни разу, ни в коем случае, а другой ответ — да, ибо эволюция в ней нуждается!

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

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

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

Ещё пример: дети могут сунуть руку или железный гвоздь в розетку — запретим 220 вольт в домашней сети? Что, не все дети это будут делать, а только очень некоторые, а электричество очень полезно для освещения и стиральной машины? Ну, «мы» (кто «мы»? где проходят границы этого «мы», кто входит в состав «мы»? кто выражает мнение этого «мы»? почему выразители противоположного мнения не должны включаться в «мы», а мнение этого «мы» после этого пересматриваться?) за ценой не постоим, детские жизни дороже! Переходим на 12 вольт, хотя понимаем, что и потери на таком напряжении будут выше, и провода заведомо толще! Но дети, дети с их гвоздём в розетке!

Этих примеров множество. В социальной сети с миллиардами постов взрослые могут написать неправильный с точки зрения каких-то людей (но вполне ОК с точки зрения многих других людей) пост, а потом какие-то люди случайно (ну вот как дети, которые случайно суют руку в розетку) могут там этот неправильный пост прочесть. Решение: запретим все миллиарды постов соцсети в страновом интернете, чтобы нельзя было случайно прочесть эти единичные посты! Что, социальные сети для чего-то там полезны? «Мы» (те же вопросы про «мы»! всегда их задавайте, когда вам говорят от имени «мы»!) за ценой не постоим, неправильных 100 постов в сутки оцениваем как больше вреда, чем может оправдать вся польза от остальных 10млн. постов в сутки — а выкинуть миллиарды уже написанных постов, так миллионы людей, которые писали эти посты, спокойно это переживут!

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

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

Подробней место метода/культуры этики в интеллект-стеке фундаментальных методов мышления рассматривается в руководстве по интеллект-стеку.

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

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

• Общество — каталлактика²⁴/экономика, политии²⁵ (в том числе государство). Желающих рассказать, что этично или что неэтично делать с обществом (в том числе кому делать — кто или что агент таких изменений, и каким способом этот агент будет работать) по части его нарезки на государства, ограничения торговли и т.д. можно найти в любой рюмочной, в любой пивной, что уж говорить о редакциях СМИ, где журналисты с их профильным чтением художественной литературы имеют своё просвещённое мнение по всем этим вопросам, а уж блогеры так и вообще тут профи! Вопрос привязки к территории тоже обсуждается, и ответ на него не так очевиден²⁶. Или такие вопросы как здоровье (санитарное государство: локдауны и карантины при любых подозрениях на эпидемию, принудительные вакцинации и другие медицинские процедуры, назначаемые без особых на то оснований — а кто и как будет определять основания? Суды? Эксперты? Они врут более часто, чем можно ожидать. То есть они не врут, но два эксперта — три мнения, это называется «шум» в решениях²⁷).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этично ли проводить опрос о целостности страны/сепаратизме/«освободительном движении»/сецессии³¹ только среди жителей, которые не живут в спорной местности? Или только среди жителей всей страны вместе со спорной местностью, их обычно вдесятеро больше живёт не в спорной местности, результаты примерно те же будут, что в предыдущем случае? Или только среди жителей самой спорной местности, но на них предъявляют права те, кто в этой местности не живёт! Что делать с их интересами? Там же кипят страсти! И как доказать, что опрос был не под дулом пистолета? Не фальсифицирован? Пример фальсификации опроса тут выборы президента США: вроде как развитая демократическая страна, а фальсификация вторых выборов Трампа вдруг оказалась важной плохо решаемой уже много лет проблемой.

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

Является ли голосование нормальным способом решения инженерных содержательных проблем, проблем изменения состояния мира с одного на другое? Этично ли решение проблем именно голосованием, «демократия»? Карл Поппер считал, что демократия — это даже не механизм бескровной смены власти, а механизм исправления ошибок в выборе власти. Но кто считает действия власти ошибкой? Большинство ведь отличненько может заблуждаться! Этично ли вести решение проблем голосованием? Ход на репликацию безошибочных мемов в ходе эволюции вроде намечает какую-то линию рассуждений на эту тему, но аргументация по этой линии не выглядит убедительной.

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

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

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

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

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

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

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

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

Консультант как инженер должен предпринимать меры, чтобы его инженерные/содержательные решения в виде «советов» таки вели к изменениям в окружающем мире, иначе зачем вообще советовать?! И ещё нужно учитывать, что работа эта обычно коллективна, и тут «роль инженера в проекте» примерно так же может обсуждаться, как «роль личности в истории» (да, от одного инженера многое зависит, но отнюдь не всё).

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

Опять же, этика тут нормативная наука, которая задаёт некоторую цель, но эта цель тоже предмет обсуждения, как в любой науке³⁹.

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

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

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

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

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

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

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

Государственное строительство и госпроекты

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

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

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

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

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

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

Часто ли мы слышим учёт интересов совести::роль в госпроектах, обсуждение передовых этических методов принятия решений по поводу возможности того или иного действия? С учётом того, что в сверхбольших системах, в которых взаимодействует очень много людей, хуже можно предсказывать последствия тех или иных решений — часто ли это обсуждается в явном виде в ходе госстроительства?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нужно также очень осторожно относиться к примерам системной инженерии из военных проектов и проектов из других областей, которые полностью зарегулированы государством, например, проектов атомной энергетики. Поскольку в этих отраслях принят принцип оплаты из бюджета «затраты плюс» (затраты, реально понесённые в ходе проекта, плюс оговорённый небольшой процент прибыли), то только полные идиоты не будут потихоньку год от года повышать стоимость проектов и сроки их выполнения, повышая тем самым и размер прибыли. Посмотрите на гражданскую технику, её стоимость, рост технических характеристик, сроки разработки за последние двадцать лет (возьмите хоть те же смартфоны: двадцать лет назад даже сотовых телефонов толком не было, не говоря уже о смартфонах) и сравните с военной техникой — сроками и стоимостями разработки. Разница будет разительна. Поэтому нужно признавать, что в военной системной инженерии есть множество интересных методологических находок, но слепо копировать этот опыт нельзя: вполне возможно, что вы откопируете заодно и прилично выглядящие способы повышения стоимости и удлинения разработки. На свободном рынке фирмы с такими методологиями бы не выжили, но на военных якобы рынках действуют совсем другие закономерности. И конечно, каждый системный инженер решает для себя сам этический вопрос: хочет ли он проектировать и строить машины для убийства (именно этим занимается военная системная инженерия). В 2007 году был доклад SpaceX на конференции Международного совета по системной инженерии (INCOSE)⁴³, а в 2020 году на этой конференции не было SpaceX, но присутствовало много инженеров из военных и правительственных проектов. Фронтир уже не рассматривается в INCOSE, системное мышление ушло в компании, ориентированные на рынок, а не на военные и государственные применения. С государством и войной сегодня ассоциируется не прогресс и технические достижения, а застой и неэффективная трата денег на инструментарий.

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

Будущее и проактивность деятельности

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

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

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

• и мир меняется, и сами агенты меняются физически,

• а ещё меняются у агентов модели мира и модели себя, а также

• степень уверенности в точности этих моделей мира и себя,

• культура работы тоже меняется, содержание методов эволюционирует — и лучший метод на какой-то момент требует интереса к объектам, которые были неинтересны предыдущим версиям метода.

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

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

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

Будущее представляется агентам как окружение для их целевых систем, которые эти агенты (например, люди) будут создавать и развивать в каких-то своих будущих проектных ролях. Окружение — это самые разные надсистемы. Какие? Это описывается будущими потребностями. Какие именно целевые системы будут люди делать в будущем? Это описывается будущими концепциями использования. Мы узнаём будущее по описаниям его целевых систем и их надсистем — по концепциям использования каких-то будущих (то есть пока не существующих, пока неизвестных нам систем) по удовлетворяемым потребностям, которых пока нет.

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

Деятели/практики/инженеры должны уметь строить порождающие модели/generative models, чтобы предвидеть детальное будущее, исходя из своих (иногда неосознаваемых) абстрактных знаний. Порождающая модель — это модель, из которой можно выполнить обратное моделированию действие: породить какие-то представления об исходном объекте моделирования, «вообразить» варианты мира, которые дали бы при моделировании модель. Если это порождающая мета-модель, то вообразить/отрендерить/породить/сгенерировать модель. Если это модель, то вообразить/отрендерить/породить/сгенерировать мир. А какие ещё модели есть? Дискриминативные/discriminative models, они дают нам классификацию, отвечают на вопрос «вот описание — что это за тип объекта?». Порождающие модели отвечают на запрос: «дай пример объекта, отвечающий описанию его типа». Порождающая модель по тексту (описание) сгенерирует картинку (добавит подробностей, уберёт абстракцию). А дискриминативная модель по тексту скажет тип объекта, который описан текстом (уберёт подробности, поднимет абстракцию)⁴⁴.

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

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

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

Так, Элон Маск основывал фирму Tesla, предвидя, что электромобили будут хорошо продаваться. В его модели мира он учитывал, что стоимость аккумуляторных батарей для электромобилей будет понемногу опускаться каждый год, и в какой-то момент электромобиль будет выгодней автомобиля с двигателем внутреннего сгорания, и он оказался прав — где-то в 2022 году совокупная стоимость владения электромобилем и автомобилем с двигателем внутреннего сгорания стали примерно одинаковы⁴⁵. Дженсен Хуанг, когда основывал NVIDIA, посчитал, что на компьютерах можно будет играть в графические игры — и если это будет развиваться, то потребуются аппаратные ускорители для видео. Так и получилось.

Стратегирование как выбор коллективного метода/стратегии работы фирмы — это ведущий метод

• серийного предпринимательства (основание фирм, эти люди называют себя founders),

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

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

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

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

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

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

• а ещё надо создать инвестуру, которая даст инвестиции на создание фирмы, иначе нельзя будет создать ни саму фирму, ни её целевую систему, ни клиентуру.

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

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

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

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

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

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

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

• из модели (детального описания)

• и/или мета-модели (предметного абстрактного описания),

• и/или даже мета-мета-модели (абстрактного трансдисциплинарного описания, на уровне общих представлений о мире)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сложность и меры сложности

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

1. Насколько трудно описать систему? Обычно это измеряется в битах, затрачиваемых на представление описания. Мерами сложности тут будут информация, энтропия, алгоритмическая сложность или алгоритмическое содержание информации, максимальная длина описания, информация Фишера (Fisher), энтропия Рени (Rényi), длина кода (беспрефиксного, Хаффмана, Шэннона-Фано, корректирующего ошибки, Хамминга), информация Чернова, размерность, фрактальная размерность, сложность Lempel-Ziv.

2. Насколько трудно создать систему? Сложность как трудность создания измеряется во времени, энергии, долларах и т.д. Меры сложности тут вычислительная сложность, временна́я вычислительная сложность, пространственная вычислительная сложность, основанная на информации сложность, логическая глубина (depth), термодинамическая глубина, цена, шифрованность (crypticity).

3. Какая степень организованности? Тут может быть два варианта:

а) «результирующая сложность» (effective complexity), трудность описания организационной структуры, неважно корпоративной, химической, клеточной. Приведём их по-английски: Metric Entropy; Fractal Dimension; Excess Entropy; Stochastic Complexity; Sophistication; Effective Measure Complexity; True Measure Complexity; Topological epsilon-machine size; Conditional Information; Conditional Algorithmic Information Content; Schema length; Ideal Complexity; Hierarchical Complexity; Tree subgraph diversity; Homogeneous Complexity; Grammatical Complexity.

б) количество информации, которой нужно обмениваться между частями системы из-за такой организационной структуры: Algorithmic Mutual Information; Channel Capacity; Correlation; Stored Information; Organization.

Есть и понятия, которые не являются понятиями сложности, но очень близки: Long-Range Order; Self-Organization; Complex Adaptive Systems; Edge of Chaos. Есть и совсем альтернативные меры сложности (например, основанные на скорости описания оцениваемых объектов, а не объёме этого описания⁴⁷).

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

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

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

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

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

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

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

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

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

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

Задания: системность мышления окружающих вас людей

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

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

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

Проблема наборов/collections как систем: чаще всего нет, но иногда — да.

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

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

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

Чаще всего затруднения по классифицированию систем происходят со следующими объектами:

• Партии/batches, лоты — единицы обработки.

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

• Парки/fleet (на русском — это по месту стоянки транспорта, а по-английски — указание на то, что движется).

• Запасы/резервы/pools — в том числе пул проектных менеджеров, пул вагонов для парка электровоза.

• Указание на материал (неисчисляемое существительное, типа «молоко — наша система», или «мы делаем полиэтилен» без указания на форму выпуска и количество)

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

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

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

• скорость выпуска (первая производная выпуска по времени)

• ускорение выпуска (вторая производная выпуска по времени, «рост скорости выпуска»)

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

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

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

• Партия/серия/batch/series/round деталей проявляет эмерджентные свойства, но они относятся обычно ко времени изготовления, а не ко времени использования детали. Скажем, доля дефектов тут --свойство/качество, которое не существует на уровне одной детали. Если речь идёт о каком-то товаре, то какой-то объём партии может обвалить цены на рынке при продаже, а при покупке — наоборот, задрать цены. Если речь идёт о страховке, то актуарные расчёты (размеры страховой выплаты) тоже зависят от вероятностей страховых случаев, эти вероятности относят ко всей совокупности объектов. В биологии речь может идти о свойстве выживаемости для генов, ибо только ничтожный процент каких-то "партий" спермы или яйцеклеток будет доходить до стадии взрослых организмов, дающих потомство.

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

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

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

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

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

• клиентура (client base, clientele) тоже обладает характеристиками целого для тех, кто её «эксплуатирует»: там проявляются разные свойства вроде «трендов» роста, ухода к конкурентам, обновляемости состава и т.д. С этими трендами работают маркетологи и менеджеры сообществ. Тренды характеризуются метриками по тем свойствам клиентуры как целого, которых нет у отдельных клиентов. То же самое с другими ролевыми группами, и даже необязательно «физическими лицами», это могут быть и компании. Скажем, поставщики/контракторы/suppliers будут представлять собой один объект внимания как совокупность (неважно, юрлица или физлица) — и дальше могут приниматься решения о минимизации или увеличении числа поставщиков, известные как инсорсинг/insourcing и аутсорсинг/outsourcing. Для этого их надо обсуждать как один объект даже в ситуации, когда они вроде не взаимодействуют между собой. Но они взаимодействуют через изменение работы компании, они ведь входят как подсистемы в расширенное предприятие. Скажем, один из ключевых пунктов стратегии SpaceX — это для скорости согласований минимизировать число поставщиков (это было прямо противоположно государственным космическим программам, которые явно дробили заказы для "обеспечения конкуренции, облегчения распространения знаний", и это оказалось очень дорого из-за изобилия ошибок конфигурации и вело к очень большим срокам разработки).

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

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

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

Отдельно нужно упомянуть разнообразные сети, но они не вызывают подобных вопросов: в сетях обычно «что-то течёт/flow» и поэтому очевидно взаимодействие, так легко обнаружить эмерджентные свойства, например, «пропускная способность сети», «полезность сети для клиентов» (это отсылка к закону Metcalfe⁵²).

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

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

При этом бытует два разных словарных значения слова «эмерджентность»:

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

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

В системном мышлении исследование каких-то систем, составленных из вроде как не взаимодействующих непосредственно или минимально взаимодействующих (например, через окружающую среду, через какие-то причинные связи с задействованием конфаундеров — то есть «через мышление агента-создателя», моделирующего какой-то кусок реальности) довольно распространены. Так, это типовой предмет изучения в предметной области complex systems⁵⁴ (изучает системы, где «всё от всего зависит», в том числе и то, каким образом появляется поведение в системах из «одинаковых элементов», которые вроде как работают независимо — но при этом получается внешний видимый макроэффет), а ещё network science (, тут ещё определяются с точным предметом, но сюда в том числе попадает изучение распределённых представлений — ибо сети как раз среда, где возможны такие представления). Там такие ключевые слова как sparse networks, epidemics, synchronization and oscillator networks — но чаще всего это относится к "математической" эмерджентности, одномерной: есть какое-то свойство, растёт сложность сети, и "вдруг" появляется explosive phenomena (скажем, возникает цепная ядерная реакция). То есть взаимодействия есть, они ограничены, но их хватает для того, чтобы резко выросла какая-то характеристика — обычно при росте сети или пороговом воздействии (скажем, пропускная способность транспортной сети от "никаких препятствий для потока" до "стоячая пробка" меняется при добавке буквально 5% единиц транспорта к какому-то предельному значению). Но всё-таки тут довольно легко разобраться с системой (например, мозгом) и подсистемами на несколько уровней (отделами мозга и так далее до отдельных нейронов).

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

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

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

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

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

Кто хочет копнуть ещё глубже — смотрите про эмерджентность в обзорах философской энциклопедии⁵⁸.

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

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

На картинке то ли фрагмент какой-то системы, то ли просто много людей.