4. Как описывать системы

Фундаментальность/трансдисциплинарность системного мышления

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

Нам потребуются следующие понятия:

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

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

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

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

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

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

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

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

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

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

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

Четыре основных вида описания системы на базе четырёх способов разбиения системы

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

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

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

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

3. Пространственные/размещения: как мест в пространстве (обычно именно в пространстве, но мы бы рекомендовали говорить сразу о пространстве-времени), где размещаются/locate/allocate части системы (где во Вселенной находятся пространственные части системы, полученные пространственным разбиением). Иногда такие описания называют «компоновкой». Эти описания позволяют однозначно договориться о том, какой объект обсуждается: в 4D экстенсионализме важно, что как бы ни были разны описания, если они относятся к одному и тому же месту/размещению в пространстве-времени, то это описания одного и того же объекта.

4. Стоимостные/затратные (на что потребуется потратить деньги и иные ресурсы, cost). Тут сразу идёт речь о total cost of ownership/совокупной/полной стоимости владения¹. Это проявление уже второго поколения системного мышления, которое занялось не только целевой системой в её окружении, как это было в первом поколении, но и создателями, организованными в граф по отношениям создания и развития друг друга и в конечном итоге создания и развития целевой системы. Стоимостные описания затрагивают как целевую систему в момент эксплуатации (сколько стоит эксплуатировать систему), так и затраты на создателей во время создания целевой системы (сколько стоит её изготовить: или купить у создателей целиком, или закупить сырьё и заплатить создателям за работы по созданию).

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

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

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

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

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

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

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

Вот модификация диаграммы из стандарта IEC 81346-1:2022, иллюстрирующая первые три основных вида описаний, базирующихся на первых трёх основных видах разбиений (на ней ещё нет стоимостного описания, можете представить его как какой-то финансовый расчёт, например, «совокупной стоимости владения», total cost of ownership²):

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

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

1. Функциональные/ролевые части (functional elements, но мы переводим elements как «части», ибо элементы не подразумевают дальнейшей делимости, а мы всегда о ней помним; role elements³), обсуждение взаимодействия которых позволяет отвечать на вопрос о том, как работает система, чтобы она выполняла свою функцию/роль в её надсистеме. Это обязательно будет обсуждение времени эксплуатации/работы/операций/использования/службы. На картинке нарисована принципиальная электрическая схема, на которой приведено описание функциональных/ролевых частей системы и их соединений (connectors). Эти функциональные/ролевые части выполняют свою функцию в системе через соединения с другими функциональными частями, меняя своё состояние в ходе работы/функционирования целой системы от этого взаимодействия и меняя состояния других частей.

2. Конструктивы/продукты/модули/«материальные части» (modules, products, components как заказные единицы, сборочные единицы, логистические единицы, конструкты) — этот вид частей позволяет отвечать на вопрос, из чего собрать и как соединить через интерфейсы (interface) конструктивы/модули системы, отвечают на вопрос «как собрать систему», обсуждается время создания. Время эксплуатации, «как работать» по этим разбиениям и созданным на их основе другим описаниям обсуждать нельзя!

3. «Пространственные объекты», места (locations), или размещения (allocations), которые позволяют отвечать на вопрос, где в пространстве на заданный момент времени можно найти части системы, как система скомпонована из своих частей в пространстве. Чаще всего термин «место» даётся для run-time, а термин «размещение» даётся для пространства, определяемого в design-time. Место/размещение тем самым важно для совмещения ролевых и физических объектов в run-time: если оба находятся в одном и том же месте в одно и то же время, то это один и тот же объект, «конструктив реализует/воплощает роль». На картинке для этого разбиения изображены отсеки, в которых ведётся монтаж системы и в которых она затем работает, но из рассмотрений только мест/размещений непонятно — из чего система собрана и как она работает.

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

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

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

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

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

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

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

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

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

• И ещё есть тоже не изображённый на картинке интересующийся WBS/« какие с этим проводятся работы». Про методы работы мы и не говорим, но это по факту тоже описывают.

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

Системные уровни определяются по главному в системном мышлении разбиению — функциональному! Поэтому функциональное разбиение часто называют системным разбиением/system breakdown structure. А остальные разбиения? Они «просто» разбиения/breakdowns.

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

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

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

Функциональный анализ и модульный синтез

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

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

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

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

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

Обратите внимание, что в инженерии обязательно присутствуют

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

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

У нас руководство по полному системному мышлению и моделированию, в котором анализу и синтезу уделяется равное внимание. Это не руководство только по системному анализу, весьма небольшой и ограниченной части системного мышления и моделирования!

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

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

Инженерное мышление не должно быть только аналитично, умозрительно, оно должно быть адекватно, то есть не терять связи с физическим миром, не витать только в облаках, выходить на изменение мира к лучшему, к созданию и развитию систем, мало только объяснять мир, анализировать системы!

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

• функциональную/ролевую,

• конструктивную/материальную/модульную,

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

• стоимостную/затратную/экономическую/ресурсную.

Анализ/декомпозиция всегда только часть мышления! Опасайтесь проекта, где непонятно кто принимает решения по синтезу! Синтез меняет мир, анализ не меняет мира! Только решения по синтезу меняют мир!

Кто имеет право указать, что в ракете будет три ступени? Что в предприятии будет три подразделения? Что Вася Пупкин будет играть роль Принца Гамлета, а Даша Неврубкина не будет? Это точно не аналитики! Это инженеры, которые меняют мир, а не только понимают мир!

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

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

«Инженер предприятия»/менеджер::роль для «инженерии предприятия»/ менеджмента::метод. Орг-методологи, орг-проектировщики и орг-архитекторы/«архитекторы предприятия» понимают, что они по сути своей — инженеры организаций::система (иногда так и говорят: организационных систем). Иногда орг-проектировщики и орг-архитекторы (орг-методологи пока ещё довольно редко встречаются, эта роль полностью ещё не выделилась из роли орг-проектировщика) прямо называют себя инженерами предприятия, чтобы отличить себя от «просто менеджеров», имея ввиду, что они не «операционные менеджеры» и занимаются не методами operations time предприятия, то есть что они не «операторы предприятия» и не занимаются администрированием, но создают и развивают предприятие. Помним, что MBA — это степень master of business administration, менеджмент в разговоре сводят к администрированию. Орг-разработчики и орг-проектировщики подчёркивают при этом, что они в инженерии предприятия пользуются стандартами системной инженерии, относясь к организации как системе.

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

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

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

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

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

Одна система, но множество описаний, множество имён: это нормально!

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

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

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

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

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

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

• функциональный/ролевой префикс “=”,

• модульный/продуктовый префикс “-”,

• префикс размещения “+”.

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

Например, =S12=16 означает, что речь идёт о функциональной части 16, входящей в состав (отношение composition/is_part_of) функциональной части S12. Число уровней разбиения в имени не ограничено. Функциональное/ролевое имя инженеры часто называют тегом (tag). Проектирование, конечно, ведётся в типах/классах: это имя типов/классов частей системы, а не конкретных частей конкретной воплощённой/реализованной физической системы в конкретный момент времени (экземпляров материального воплощения объектов того типа/класса, который был в проекте/design).

Если имя -M87-K5, то речь идёт о продукте/модуле/конструктиве/изделии К5, который входит в состав надконструктива М87. Это тоже не конкретный физический объект с серийным номером, а тип/класс этих объектов, вид продуктов определённой марки.

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

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

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

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

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

• «манометр KLM-23 завода “Давижмимонтажавтоматика”»::«конструктивный объект»/продукт/модуль,

• датчик в «пятом ящике на третьей полке склада номер 4»::размещение,

• «$300»::стоимость.

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

Разные имена, указывающие на самые разные типы объектов, свидетельствуют о том, что мы будем задействовать самые разные методы работы с этим предметом метода, поэтому для нас один и тот же прибор выступает в разных ипостасях, так что удобно для разных методов работы называть его разными именами. Это нормально, этого в проектах не избежать!

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

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

Имя «Принц Гамлет — Василий Пупкин» вполне культурно (то есть будет понятно многим людям без дополнительных разъяснений), хотя в нём использовано сразу два имени отдельных ипостасей актёра: действующего лица и исполнителя роли. Так и имена систем в промышленности часто могут состоять из имён нескольких ипостасей, например, «=S12=16 –M87-K5 $300» (составное имя одной системы, состоящее из трёх частных имён этой системы). Такие имена служат для удовлетворения интересов разных проектных ролей, частные имена перечисляются через пробел. Мы условно цену посчитали тоже именем, хотя это и не совсем так, но интуитивно указание финансовой характеристики около имени не вызывает ощущения чего-то необычного, хотим именно это подчеркнуть.

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

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

• горячей системы (функциональное имя),

• вчера купленной (продуктовое/конструктивное имя) системы

• дальней системы (пространственное имя),

• дорогой или дешёвой (стоимостное имя) системы.

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

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

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

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

Альтернативные варианты основных видов разбиения системы на части

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

Исторически в разных школах мысли части системы выделялись очень по-разному:

• ISO 15926 — два основных вида частей: функциональные объекты, физические объекты. Остальные могут вводиться по потребности.

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

• Книга Косякова, Свита, Сеймура «Системная инженерия. Принципы и практика»⁶ — два вида: функциональный элемент, компонента (конструктивный объект).

• СМД-методология — пять (процессы, элементы и связи, внешние функции, морфология, материал)⁷

• … и так далее⁸, в среднем 3-7 основных видов частей, ипостасей системы. Впрочем, «ипостаси» тоже называются везде по-разному: структурные аспекты, типы/виды описаний, которые выполняются на заданном типе частей как предметы разных методов в разных школах системного мышления. И везде указывается, что это «по меньшей мере», то есть признаётся, что речь идёт только об основных вариантах, которые нельзя не рассмотреть. А разбиений может быть много, они делаются по потребности, разные в разных проектах. Но основные разбиения делаются во всех проектах.

В нашем руководстве мы принимаем вслед за IEC 81346-1:2022, что системы имеют три основные ипостаси/аспекта — функциональную, конструктивную и размещения, добавляем четвёртую ипостась/аспект: стоимостную, это уже де-факто основное описание в подходе цифровых двойников/digital twins⁹, и дальше продолжаем «и эти четыре — минимальное число аспектов/ипостасей/«вариантов разбиения» как основа для разных вариантов описаний, базирующихся на разных вариантах разбиений.

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

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

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

В презентации 8D digital twin experience от SNC-Lavalin с июньской конференции 2020 года по digital twins приводится 8 аспектов¹⁰, D там — это dimension, «измерение» (ещё одно слово для аспекта/ипостаси, подчёркивается тот факт, что система существует как объект во многих измерениях/dimensions). Всё тут ровно то же самое, что было ещё десяток лет назад в работах по управлению жизненным циклом продуктов (PLM), но сегодня уже разговор про digital twins, а не PLM, ибо акцент уже не только на создании системы, но и на её эксплуатации, и поэтому данные инженерии/engineering data дополняются данными по эксплуатирующимся активам/asset data, а конечная цель — автономная (без человека, где-нибудь в абсолютно безлюдной местности) эксплуатация на основе «единственного источника правды», single source of truth, то есть цифрового двойника как модели системы, поддерживающей согласованные между собой различные описания как целевой системы в её операционном/рабочем окружении, так и создающей системы. Обратите внимание, что до сих пор это «второе поколение системного подхода», потому как не предусмотрено множество версий целевой системы, то есть не только однократное прохождение «жизненного цикла системы», но непрерывное развитие системы:

• 1D метаданные, документация (тексты). Помним, что в машиностроении под 1D-моделированием понимают физическое моделирование функциональных характеристик системы, но в мире digital twins под 1D-ипостасью системы понимают совсем другое.

• 2D чертежи (там, где «обычные двумерные электронные чертежи» ещё есть, «родные файлы» из CAD/САПР — помним, что digital twins процветают на стройках, а там очень медленно развиваются методы проектирования/design и их инструментарий, 2D представления ещё встречаются повсеместно)

• 3D информационные модели (это представление физической формы/геометрии/компоновки системы с указанием материалов и многих других характеристик)

• 4D «видеоролик» стройки/сборки в развёртке во времени, то есть к 3D добавляется план/schedule сооружения (стройки и монтажа) или сборки

• 5D это ресурсы, material status/cost, то есть добавляется стоимость

• 6D вот тут появляется operation, real time data (и мы перешли из enabling realm/времени создания в operation realm/время эксплуатации, и с этого места принято говорить, что речь идёт не о «системе поддержки жизненного цикла»/PLM, а «цифровом двойнике»/digital twin уже созданной физической системы)

• 7D это live streaming, передача видеопотока работающей целевой системы и её окружения (с видеокамер, со спутника — отдельно от real time data с датчиков, ибо это огромные объёмы данных).

• 8D это уже аналитика, предсказания систем машинного обучения (ML predictive data)

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

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

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

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

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

Несовпадение функционального и конструктивного разбиений системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание на префиксы перед одними и теми же именами, они обозначают по IEC 81346-1:2022 как раз разные типы, «=ножницы» тут типа функционального объекта, а «-ножницы» — конструктивный объект. Если имена совпадают, то невозможно по одному только имени понять, о функциональных или конструктивных ножницах мы говорим, обсуждаем ли время эксплуатации или время изготовления: требуется или задать префикс, или определять это из контекста, а если контекста не хватает, то обязательно переспрашивать.

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

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

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

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

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

Моделирование: функциональные и конструктивные разбиения

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

Разработка концепции системы: функциональный анализ и модульный синтез

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

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

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

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

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

• компоновки с учётом прохождения пространственных ограничений,

• стоимостного разбиения с учётом прохождения ограничений по затратам.

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

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

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

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

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

Вот рисунок из стандарта IEC 81346-1:2022 (а этот стандарт взял этот рисунок из более раннего стандарта IEC 1392/09):

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

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

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

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

Это ключевой момент: чтобы изобретение было возможно, на текущем уровне развития цивилизации должны существовать известные аффордансы для нужной функции. Если изобретение невозможно, то системы не будет. Хороший тут пример — изобретение вычислительной машины. Функционально с ней всё было понятно ещё Чарльзу Бэббиджу и Аде Лавлейс в начале 19 века. Но вот аффордансы для потребных функций логических операций работали ненадёжно: механика сбоила (это пробовал сам Бэббидж), пневматика не работала, электрические реле тоже сбоили, гидравлика тоже не работала! В итоге сработала электроника, после изобретения: было предложено использовать для создания универсального вычислителя логические вентили на радиолампах-триодах, задействованных не в режиме усилителя (для чего они первоначально и использовались), а в ключевом режиме. Эти лампы были доступны и относительно дёшевы, но изобретены они сами были только 1906 году, а изобретение компьютера на базе радиоламп состоялось только в 1945 году, но примерно половину времени компьютер не работал из-за ненадёжности радиоламп, супер-надёжные радиолампы появились только в 1948 году. Подробней эта история рассказана в руководстве по методологии, она и имеет отношение к стратегированию: вы не должны полагаться на то, что сделаете изобретение в проекте. Наоборот, вы можете начинать проект новой системы, если сделали изобретение! Если вы не понимаете, какова концепция системы хотя бы в общих чертах, если не понимаете, какие есть аффордансы — не начинайте проекта! Возможно, вы будете гениальным изобретателем, но возможно, это вы пытаетесь изобрести летательный аппарат тяжелее воздуха ещё до того момента, как появились лёгкие двигатели внутреннего сгорания (недаром братья Райт, изобретатели самолёта, были владельцы мотоциклетной мастерской). Концепция системы как раз говорит о том, что изобретение сделано, и можно приступать к детальному проектированию.

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

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

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

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

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

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

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

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

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

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

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

Вопросы. Функциональные, конструктивные, пространственные, стоимостные части - 1

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

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

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

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

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

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

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

Первичное рассмотрение целевой системы в составе надсистемы проводится как:

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

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

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

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

Инженер Марфа обнаружила, что в переданной ей документации на принципиальной схеме 14 функциональных частей, а на печатной плате 11 модулей, и всё работает. Как это получилось?

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

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

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

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

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

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

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

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

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

Инженер Лена и снабженец Богдан долго спорили: выбранные Богданом к закупке покупные изделия никак не соответствовали принципиальной схеме продукта, подготовленной Леной. Тем временем уже пора начинать закупку. Что делать?

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

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

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

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

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

«Для наиболее эффективного разделения частот перед усилителем применяется преобразование эллиптического фильтра Кауэра.» О каких описаниях системы идет речь?

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

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

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

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

--- О топологии ### Нет, топология системы тут вообще ни при чём.

"Предлагается установить на крышах домов солнечные батареи. Для хранения накопленной в течение дня энергии предлагается включить в цепь в качестве накопителей энергии не только стационарные аккумуляторы, но и электромобили, находящиеся во владении жильцов домов». Что такое в этом тексте «стационарные аккумуляторы» и «электромобили»?

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

+++ модули ### Да, электромобили и стационарные аккумуляторы — это конструктивы/продукты/модули, выполняющие роль «накопитель энергии».

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

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

Вопросы. Функциональные, конструктивные, пространственные, стоимостные части — 2

Каталог онлайн-магазина поделён на товарные категории («Напольные покрытия»), далее на товарные группы («Ламинат»), в которых перечислены товары («Ламинат 31 кл Kronospan Kronofix Дуб Ройял 2,47 м.кв. 7 мм»). Если рассматривать ассортимент магазина (совокупность товаров, доступную к продаже через данный онлайн-магазин) как целевую систему, то товарные группы в каталоге будут:

--- Конструктивными объектами ### Нет, в каталоге находятся только описания конструктивов, сами конструктивы (ассортимент) лежат на складе.

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

+++ Описанием конструктивов ### Да, товарная группа в каталоге описывает относящиеся к ней товары как лежащие на складе конструктивы, составляющие ассортимент магазина.

--- Описанием функциональных объектов ### Нет, товарная группа в каталоге не описывает функциональности товаров, только сами товары как конструктивные/материальные объекты.

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

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

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

Маркетолог завода-изготовителя сомневается — как назвать продукт в каталоге завода: «система напора» или «насосный агрегат».

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

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

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

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

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

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

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

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

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

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

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

+++ Функциональное ### Да, раз нужная мощность ему уже известна. Он понимает, что будет происходить в момент эксплуатации трансформатора.

--- Конструктивное ### Нет, он как раз его и разрабатывает, раз ищет нужный конструктив/продукт/изделие трансформатора.

+++ Пространственное ### Да, раз он уже понимает, какие габариты ему подходят, т.е. где он будет этот трансформатор устанавливать.

Моделирование: изобретение (поиск аффорданса)

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

Альфы и артефакты/«рабочие продукты»

Стандарт OMG Essence¹⁷ предлагает для контроля за изменением состояния проекта особый вид функциональных объектов — альфа (ALPHA). Если мы хотим как-то связно мыслить о том, насколько продвинулись создатели в создании и развитии системы, то согласно стандарту OMG Essence нам нужно удерживать внимание в проекте не на любых произвольных объектах, а на альфах, которые они определяют как предметы метода.

OMG Essence — это стандарт описания методов разработки, один из последних стандартов так называемой инженерии методов¹⁸, а потом и ситуационной/ситуативной/situational инженерии методов¹⁹. Основное отличие OMG Essence от предыдущих стандартов инженерии методов (их было множество, все они безнадёжно устарели) в том, что:

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

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

В нашем руководстве мы рекомендуем использовать OMG Essence, но берём из него только language, а не описанный в нём пример kernel — ровно как этого и требует стандарт, ибо для каждой новой предметной области разработки надо бы разрабатывать свой kernel, а не брать описание метода разработки софта из стандарта. Подробней об этом будет рассказано в руководстве по методологии.

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

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

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

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

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

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

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

• затем будет состояние «проект/design разработан» — здания как физического объекта нет, но есть только описание здания, достаточно детальное для его строительства,

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

• затем состояние «эксплуатируется/используется»

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

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

Например, Василий Пупкин в ходе включения в команду проекта каким-то методом (чаще всего этот метод в части привлечения людей называют onboarding²⁰) должен принять роль финансиста заказчика (должна появиться оргвозможность финансиста заказчика) и в ответ на вопрос «быть или не быть?» сказать «быть!» и поставить подписи на документах. Альфа «финансист заказчика» нужна для отслеживания состояний объекта «финансист заказчика» во время всего проекта:

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

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

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

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

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

• вот «все работы финансиста заказчика закончены», Вася Пупкин покинул проект.

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры самых важных альф (по сути дела — это указание на kernel в терминах стандарта OMG Essence, мы тут предлагаем более универсальный вариант, чем в самом стандарте, и в нём меньшее число альф):

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

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

• функция/метод работ (way of working), функциональное описание поведения системы (если неодушевлённая система — назовут «функция», если интеллектуальный или коллективный создатель — «метод/способ работы»), это время эксплуатации системы.

• работы системы (это относится ко времени эксплуатации воплощённой системы, ибо работы системы создателя — это другая альфа! Состояние работ свидетельствуется какой-нибудь диаграммой Ганта или списком работ из информационной системы управления проектом, issue tracker).

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

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

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

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

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

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

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

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

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

Альфы документируются в рабочих продуктах проекта, чтобы договариваться о состоянии важных объектов внимания в проекте, они отвечают на вопрос «в каком состоянии важные объекты проекта».

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

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

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

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

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

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

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

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

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

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

Вопросы. Рабочие продукты

Что из нижеперечисленного — документация?

+++ Отчёт «Результаты испытаний сепулькария от 13 мартобря 2026г.» на 14 страницах ### Да, это документ (указано число страниц! Это не просто содержание отчёта!).

+++ База данных с концепцией системы фазовыпрямителя ### Да, база данных с моделью — это документация, она где-то хранится на носителе информации.

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

--- Архитектура фазоуловителя ### Нет, сама архитектура — это описание принятых архитектурных решений, она должна быть отражена в документах (например, в виде ADR, architecture decision records), которые могут существовать как файлы, или как записи в базе данных, но сама она — не документ.

+++ Диаграмма Ганта для проекта создания фазозаместителя (доступна в формате MS Project) ### Да, модель работ в файле (указан формат файла) — документация системы создания фазозаместителя (диаграмма Ганта описывает работы проекта, то есть описывает поведение создателей фазозаместителя).

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

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

Первоклассник учит арифметику. Что у него в проекте рабочий продукт?

--- Выражение 2*2 ### Нет, просто выражение, без материального носителя — не документация, не рабочий продукт. Выражение абстрактно, у него нет объёма, занимаемого в физическом мире.

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

+++ Счётные палочки, которыми он обозначил число 3 ### Да, это рабочий продукт. Счётные палочки занимают место в физическом мире и представляют описание (число 3 что-то описывает).

+++ Закаляканный листочек с ответами на обороте ### Да, это материальный предмет, документация ответов, рабочий продукт.

+++ Сборник задач ### Да, это материальный предмет, представляющий задачи, документация, то есть артефакт/рабочий продукт.

+++ Учебник ### Да, учебник занимает место в пространстве-времени, это физический объект/рабочий продукт/артефакт/документация.

--- Знания о 2*2 ### Нет, просто знания, без материального носителя — не документ, не артефакт.

+++ Часть головного мозга с запечатлённым в ней знанием 2*2 ### Да, это материальный предмет, рабочий продукт/артефакт.

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

+++ Таблица умножения на плакате, который повесила в классе учительница Марья Ивановна ### Да, это материальный предмет как носитель описания, т.е. рабочий продукт/документация.

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

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

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

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

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

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

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

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

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

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

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

Менеджер Ирина в ответ на предложение продемонстрировать состояние альфы «Работа» показала содержимое issue tracker (софта для управления задачами, стоящими перед инженерами). Это был правильный ответ на предложение?

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

--- Нет, ведь содержимое issue traсker — не документ ### Нет, содержимое issue traсker (база данных) — это вполне носитель информации для описания, т.е. документ, и этот документ представляет/описывает работы.

+++ Да, всё ОК ### Да, issue tracker документирует состояние альфы «Работа», это был правильный ответ на предложение.

Яблоки из жизни, яблоки из задачи

В реальном мире мы видим конкретные физические объекты, с которыми мы имеем дело:

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

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

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

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

• Тип «пища» из метода «съесть» (пищу::«предмет метода» едят::«способ/метод работы»).

• Тип «счётный объект» из метода «сосчитать объекты» («счётный объект»::«предмет метода» сосчитать::метод).

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

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

Тут нужно привести байку про яблоки из задачи и из жизни, например, в таком варианте²¹:

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

Вот ещё про то же самое²²:

— Мы займёмся арифметикой... У вас в кармане два яблока...

Буратино хитро подмигнул:

— Врёте, ни одного...

— Я говорю, — терпеливо повторила девочка, — предположим, что у вас в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас осталось яблок?

— Два.

— Подумайте хорошенько.

Буратино сморщился, — так здорово подумал.

— Два...

— Почему?

— Я же не отдам Некту яблоко, хоть он дерись!

— У вас нет никаких способностей к математике, — с огорчением сказала девочка.

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

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

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

Альфа обычно не очень формально специфицирована. Онтологи/методологи, настаивающие на строгой и однозначной формализации мира, остаются недовольными тем, как определены альфы. Сами альфы появились так: команда разработчиков OMG Essence задалась вопросом: а что у нас присутствует в каждом проекте по разработке софта? Какие предметы метода изменяют свои состояния в каждом варианте метода разработки софта (software process)? И просмотрела в 2011-2013 годах порядка 250 конкретных проектов разработки софта, придя к предложенному набору 7 основных альф стандарта (kernel в терминах этого стандарта, этот набор «примера kernel» из стандарта мы перестали использовать в нашем руководстве, он безнадёжно устарел и весьма специфичен именно для софта). И там уж что нашли, то нашли: никакой дополнительной формализации, приведения к одному онтологическому типу для альф (сами понятия метода, альфы, рабочего продукта — language в терминах этого стандарта, объекты kernel типизированы объектами language) не делалось.

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

Примером, когда неумение работать с типами сочетается с незнанием основ системного мышления, может быть дискуссия среди разработчиков подхода active inference/деятельного познания (в котором вы в познании меняете ваши модели мира и себя, но деятельно — меняя не только модели, но и себя и мир!). Там была предложена концепция Markov blanket как «граница системы», но «как-то странно» — странность была отмечена²⁴ и породила огромную дискуссию²⁵. Если бы участники дискуссии были знакомы с современным фундаментальным мышлением, включая системное мышление, они бы быстро нашли сразу три источника путаницы (все они отмечены в нашем руководстве как важные для мышления):

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

• Путаница между функциональным и конструктивным объектом. Markov blanket — это функциональный объект с каким-то поведением, или физический объект или группа, которые будет демонстрировать соответствующее поведение? Граница клетки с каким-то поведением — это неважно из чего она состоит, или чётко понимаем, что речь идёт о мембране клетки, или мембране «со всем, что на неё налипло изнутри и снаружи».

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

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

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

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

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

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

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

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

Моделирование: классификация типов мета-модели типами мета-мета-модели

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

Альфы

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

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

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

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

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

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

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

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

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

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

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

Альфы (alphas) — это объекты, по которым мы судим о продвижении/progress («как много мы уже сделали?») и здоровье/health («всё ли в проекте идёт хорошо?») проекта, отслеживая изменение состояний каких-то предметов метода.

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

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

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

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

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

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

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

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

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

• описаниям из текстов стандартов, а сами файлы с текстами стандартов тут будут рабочими продуктами

• user stories, рабочие продукты — карточки с user stories,

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

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

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

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

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

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

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

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

В стандарте OMG Essence²⁷ для ALPHA придумали аббревиатуру, Abstract-Level Progress Health Attribute, но эта аббревиатура про health attribute была для альфы подобрана задним числом (просто потому, что альфы нужны были для отслеживания их изменения в ходе проекта — если не изменяются, то проект «нездоров»), а слово alpha часто пишут поэтому маленькими буквами, чтобы не акцентировать липовую «аббревиатурность».

Повторим: в стандарте OMG Essence есть две части: язык/language, который вводит понятия альфы, рабочего продукта, работы (и мы их используем), и ядро/kernel как предлагаемый стандартом начальный набор основных/ядерных/kernel альф (в kernel также предлагаются и какой-то набор стадий/этапов проекта, мы их тут не рассматриваем), чаще всего встречавших в софтовых проектах некоторое время назад. Предложенные стандартом в kernel альфы — проектные роли, возможность создания системы, требования, воплощение системы, команда, способ работы, работы. Стандарт активно разрабатывался где-то до 2015 года (последние косметические изменения там сделаны были в 2024 году, версия 2.0), поэтому одна из основных альф предложенного примера kernel в стандарте — требования. Но инженерия требований как один из частных методов общеинженерной работы оказалась не такой удачной идеей, когда перешли к непрерывной гибкой/agile разработке, поэтому требования перестали разрабатывать. Так что мы используем language из этого стандарта, но предлагаем другой набор основных альф (kernel), что прямо предусмотрено в стандарте (подробней об этом будет в руководстве по методологии). В нашем наборе альф для kernel — воплощение системы, описание системы, метод работы системы и работы системы в области интересов каждой из систем.

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

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

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

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

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

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

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

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

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

Эта связь продуктов и их альф обычно определяется в рамках какого-то метода работы. Рабочие продукты и инструментарий метода ситуативны для каждой конкретной организации и даже конкретного проекта, а вот альфы более стабильны. Скажем, в методе проектного управления теория проектного управления (в науке — operations research³¹) одна и та же, а вот инструментарий (софт проектного управления, моделер для проектов) в разных проектах может быть очень разным. Метод/способ/практика работы определяется по его теории/дисциплине/объяснениям с их предметами, но в целом метод описывается не только теорией и дисциплиной работы с предметами прикладной предметной области, но и включает в себя описания работ с инструментарием. Инструментарий обычно уникален для проекта, он состоит из разной аппаратуры, оборудования, программно-аппаратных комплексов, которые часто надо ещё и разработать в рамках самого проекта, поэтому работы по одному и тому же методу могут сильно отличаться — рытьё котлована лопатами и экскаватором имеет один и тот же метод «рыть», предмет метода «котлован», альфа котлована будет отражать его состояния (начиная с «потребность в котловане осознана», дальше через «проект/design котлована готов», «инструментарий рытья выбран», «рытьё начато», «котлован вырыт»), но вот как это в мире будет выглядеть — отличаться для лопат и экскаватора будет сильно. А ещё котлованы роют взрывом.

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

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

Мы будем смотреть на какие-то артефакты, чтобы понимать, в каком состоянии находятся представляемые ими альфы — главные объекты нашего внимания в проекте. Как альфа меняется, проходя по мере выполнения с ней работ метода разработки свои состояния, продукты/артефакты меняются в ходе проекта, проходя уровни детальности. Код компьютерной программы может быть записан в виде идеи, в виде псевдокода, в виде кода с ошибками, в виде компилируемого без ошибок кода, в виде хорошо откомментированного кода — детальность нарастает, но это вовсе не означает, что альфа «код компьютерной программы» при этом приближается к готовности: вполне возможно, что не нужно было хорошо комментировать код, а нужно было даже поменять идею этого кода, документировать совсем другую идею! Подробней это различие состояний альф и уровня детальности рабочих продуктов разбирается в OMG Essence, мы не будем это разбирать в нашем руководстве. Работа с состояниями рабочих продуктов рассматривается в инженерии, мы же в системном мышлении и тем более методологии будем сосредоточены на альфах: на важнейших объектах внимания в проектах, изменение состояний которых говорит о ходе проекта.

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

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

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

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

• Замышлено (ясно, каково будет описание системы)

• Непротиворечиво (описание системы создано и непротиворечиво)

• Используется для изготовления (описание используется для изготовления воплощения системы)

• Используется для инженерных обоснований воплощения (описание используется для проведения тестов и испытаний)

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

• Используется для вывода из эксплуатации (используется для ликвидации и/или переработки воплощения системы)

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

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

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

• Ограничена (bounded, основная функция/назначение/сервис новой системы понятна)

• Непротиворечива (coherent, концепция использования непротиворечиво описывает основные сценарии использования, в том числе существенные характеристики новой системы)

• Приемлема (acceptable, концепция использования описывает такую систему, которая приемлема как для внутренних, так и для внешних проектных ролей)

• Отвечена (addressed, воплощение системы удовлетворяет концепции использования настолько, что система принимается внешними проектными ролями в эксплуатацию)

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

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

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

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

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

Системное описание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарт ISO 42010:2022 даёт рекомендации о том, как думать о системном описании/описании системы. Сам стандарт говорит только об архитектурном описании, причём в старом понимании архитектуры, но его положения вполне применимы к любым описаниям, то есть и концепции использования, и концепции системы, и архитектуре.

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

Диаграмма системного описания начинается с уже знакомого нам различения воплощения (realization) и описания (definition) системы.

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

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

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

Фиксация или фиксирование требований в инженерии прошлого (сейчас так иногда продолжают говорить о фиксации концепции использования, а ведь исключение фиксации/заморозки требований и было одной из причин отказа от разработки требований в пользу разработки концепции использования) для большинства людей означает не запись требований на бумагу или в базу данных, а объявление текущего состава требований стабильным и неизменяемым. Но в системном мышлении вы лучше и лучше описываете систему (или описываете всё более лучшую систему, по мере понимания того, как именно она будет использоваться, в каком окружении), меняя и меняя тем самым концепцию использования — документирование этому не мешает, модели системы не «фиксированы» ни в один момент времени проекта! Вы можете какую-то версию административно объявить стабильной. Инженеры говорят в этом случае о базисе/baseline, но это не означает «фиксации»! Просто изменения системных описаний будут собираться и документироваться в других артефактах (документе «рабочей версии», а не документе уже утверждённого «базиса»), а потом базис будет меняться по какой-нибудь административной процедуре управления изменениями проекта/change management. Но и тут изменения: магистральная разработка/trunk-based development³² подразумевает, что вся разработка не порождает отдельные долго живущие ветви, а в современной инженерии (например, на заводах Tesla, в SpaceX) каждый отдельный автомобиль или ракета имеют уникальные описания (project description), выпускаются по уникальному проекту и производственному процессу каждый, нет двух одинаковых автомобилей или ракет. Но с этим разбирается уже третье поколение системного мышления, там речь о версионировании — и как жить, когда версия каждого экземпляра системы уникальная, а сами эти системы непрерывно развиваются.

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

Вот эта же диаграмма на английском языке:

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

Конечно, ролевых/аспектных/видов описаний может быть множество. Например, роль могут интересовать финансы. Тогда ролевое описание — финансовое, модели там будут — бухгалтерский баланс, отчёт о прибылях и убытках, поток денежных средств. Как сделать эти описания? Эти описания могут быть сделаны по методу описания РСБУ (Российская система бухгалтерского учёта) или МСФО (Международная система финансовой отчётности), а мета-модели — это форматы представления бухгалтерского баланса, отчёта о прибылях и убытках, потока денежных средств в соответствующих ролевым методам описания (РСБУ или МСФО). Если финансиста заинтересуют оба метода описания, то он получит два описания — и по РСБУ, и по МСФО. Как будут документированы эти описания? Или на бумаге, или в табличках Excel, или в базе данных компьютерной бухгалтерской программы — в любом случае, содержание описаний можно обсуждать без обсуждения формата представления на носителях информации.

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

Заполните табличку для не менее чем пяти видов описаний, которые вы нашли в вашем проекте.

Системное описание (предметов) деятельности предприятия

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

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

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

Если говоришь «проектная роль», то инженеры-менеджеры тут же вспоминают про предпочтения, но забывают, что роль выполняет какой=то метод работы (это же в других абзацах!). Если говоришь «важная характеристика», то тут же вспоминают про предпочтение, но забывают о том, что ролевое описание/view отвечает на вопросы по этой характеристике ровно для того, чтобы понять, что там происходит с предпочтением, а сам предмет интереса отражается/framed ролевым методом описания/viewpoint (это же в совсем другом разделе и даже в другом руководстве!).

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

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

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

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

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

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

Будет ли после разглядывания этой диаграммы³⁴ (если вы сможете там что-то прочесть из-за мелкого шрифта, проблема большинства больших диаграмм на маленьких экранах!) при появлении в мышлении роли::«тип какого-то объекта в предметной области» (скажем, при взгляде на экран с «Аристархом Владимировичем»::агент-AI вспоминается, что он инженер-архитектор::роль) приходить в голову теперь не только желание подумать про его предметы интереса и предпочтения в них, но и приходить желание подумать про практики архитектурной деятельности? Желание подумать про методы описания, которые устанавливают соглашения для описаний, используемых в архитектуре (например, ADR как architecture decision records), чтобы поддержать содержательный разговор с Аристархом Владимировичем как инженером-архитектором? Не факт. Много текста, который продемонстрирует примеры рассуждений (то есть ещё и выполнил заземление/grounding), тут поможет больше.

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

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

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

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

Системное описание, описание, метод описания

В системном описании есть различные аспектные/ролевые/частные описания (views), которые отвечают на вопросы о каких-то «областях интереса»/«area of concerns». Проектная роль может иметь и несколько областей интереса, и множество интересов в каждой из областей интереса. Это всё интересы к предметам методов работы этой роли.

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

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

Успешность системы мы часто можем определить ещё тогда, когда воплощения системы ещё нет, а есть только описание системы, и даже не полное описание (ошибки неучёта каких-то интересов могут быть видны и по частичным описаниям). Использование 3D-информационных моделей, чертежей, имитационных моделей в инженерии, нот в музыке и любых других записей в проектировании и конструировании как раз имеет целью подробно обсудить реализацию самых разных предпочтений в важных для всех ролей в проекте характеристиках/concerns разных систем проекта ещё до того, как целевая система будет воплощена. Рассуждение не меняется, если речь идёт просто о выпуске очередной улучшенной версии системы (не greenfield разработка «с нуля», создание системы, а brownfield разработка улучшений, развитие системы).

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

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

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

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

В литературе (например, ISO 42010:2022) часто слово «описание» даётся не для абстрактного объекта-альфы, а для документации/артефакта, и на английском это будет description. В системной инженерии наше абстрактное «системное описание» будет system definition. В русском языке слово «определение» путается с словарным, поэтому мы перевели более подходящим по смыслу словом «описание», а description тоже перевели более подходящим по смыслу русским словом «документация». Путаница с описаниями вездесуща. Так, онтология (или архитектура, или цвет системы) могут означать:

• То, что есть в жизни (нарезка мира на какие-то объекты, или архитектура какой-то системы, или цвет какой-то системы — они «в реальности»)

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

• Документ с описанием, и тут тоже часто говорят онтология, архитектура, цвет. Но это уже название документа!

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

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

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

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

Это только геном обязательно будет в каждой клетке организма, собран в одном «документе», на одном носителе информации. Геном³⁵ сам по себе — это носитель информации, «совокупность наследственного материала, заключённого в клетке организма», то есть это набор всех хромосом³⁶, каждая из которых образуется у эукариот одной очень длинной молекулой ДНК. Геном — это документ с описанием генетической информации. Более чем часто имеют ввиду под геномом не набор хромосом/«молекул ДНК» (документ), а саму генетическую информацию, документированную геномом! В инженерии речь идёт о мемоме (по аналогии с геномом), который хранится где-нибудь в конструкторском бюро и является результатом не биологической (дарвиновской), а техно-эволюции. Договорённости о том, что мемом — это материальные носители (проектная документация) нет, поэтому это может быть равным образом проектная/design документация, но может быть и проектное/design описание. Идея о том, чтобы собрать всю проектную документацию в одном месте — она обычно провальна. Даже если считать, что вся проектная документация находится в каком-нибудь конструкторском бюро, то немедленно окажется, что есть производство, на котором тоже есть часть документации, часть документации находится у подрядчиков (например, поставщиков заказных комплектующих), часть документации будет у наладчиков и операторов (например, какие-то настройки системы, о них даже проектировщики не будут знать). Так что идея о том, что системное описание (systems description) отражается в каком-то «супердокументе» — она провальна.

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

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

Тем не менее, мы говорим об альфе системного описания (system definition), поскольку в проекте совокупность всех описаний необходимо отслеживать в части их готовности. Продвинуть альфу системного описания по её состояниям можно, продвигая работами проекта по их состояниям подальфы отдельных частных/аспектных/ролевых описаний (views). Этих подальф описаний/views для альфы описания системы довольно много.

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

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

Разнообразные объекты, с которыми работают в проекте разные роли, являются:

• С точки зрения методов работы этих ролей — предметами метода,

• с точки зрения мотивов, побуждающих агентов к действию, являются предметами интересов,

• с точки зрения изменения состояния этих предметов, являются альфами,

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

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

• Необходимость системных описаний (system definition). Они важны, их надо делать и документировать, даже если очень лень и некогда.

• Необходимость явного указания для каждого из описаний/view в составе системного описания их методов описаний (viewpoint). Если вы не знаете, каким методом вы что-то описываете, то это не значит, что вы описываете это без метода, поэтому подумайте о методе и укажите его.

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

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

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

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

• если есть «песня» (предмет метода),

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

• это описание должно быть документировано. Не документировать нельзя (хотя есть и разные другие мнения, ведь ещё есть импровизационные жанры, но там это будет не «песня»³⁸)!

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

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

Метод описания (viewpoint) отражает (frame) важную характеристику/предмет интереса (concern), а описание (view) отвечает на вопросы о значении целевой характеристики, удовлетворяет к ней интерес. Например, «легенда карты фауны»::метод описания отражает «распределение фауны на определённой территории»::concern, а карта::описание отвечает на вопросы о «наличии или отсутствии фауны в тех или иных конкретных местах»::«значение целевой характеристики/предмета интереса».

Тем не менее, предмет интереса/concern, и «метод описания»/viewpoint, как и описание/view нещадно путают (то есть путают «распределение фауны как характеристику какой-то эко-системы/территории»::concern, «легенду карты [распределения] фауны»::viewpoint и саму «карту фауны»::view). Конечно, всё это близкие понятия, но все они привлекают внимание к разным объектам, поэтому для обсуждения нюансов они нужны все: надо найти в проекте объекты всех упоминаемых типов: concerns, viewpoints, views.

Если у меня ролевой предмет интереса/concern/важная характеристика — цвет системы, а моё предпочтение/preference/интерес — яркий цвет, у меня будет недовольство тем, что цвет неяркий. Я выбираю метод описания цвета (отражаю интересующую важную характеристику при помощи метода описания), включающий возможность описать значения насыщенности цвета — это позволит мне прогнозировать яркость цвета в системе моего интереса, испытывать полученную яркость окрашенной системы, формулировать предпочтения для яркости цвета, договариваться с другими проектными ролями по поводу насыщенности цвета. Другая проектная роль — инженер, который должен покрасить систему. И он может заботиться о том, чтобы краска была дешёвая (удовлетворять интерес ещё одной проектной роли — менеджера-финансиста), а яркость этой краски его волновать не будет. Но дешёвая краска яркой не бывает. Если я документирую нужную мне цветность, описав при помощи стандартных характеристик colorfulness, chroma, saturation, плюс учту внешнее освещение (brightness), то мы как минимум сможем провести переговоры на тему приемлемых характеристик цветности, по итогам переговоров инженер сможет подобрать дешёвую, но достаточно яркую на мой ролевой вкус краску (ролевой вкус! Как агент я могу предпочитать неяркие цвета, но в проектной роли я делаю профессиональное суждение по поводу яркости: реализую не собственное «как человека», а ролевое предпочтение) — моё ролевое предпочтение «яркого цвета»::«значение важной характеристики» будет реализовано.

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

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

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

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

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

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

Вопросы. Описания и важные характеристики

Царь послал в чужеземные края трёх мастеров, чтобы каждый из них описал заморскую самоходную тележку. Что должны спросить мастера, чтобы не попасть впросак?

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

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

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

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

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

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

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

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

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

При проектировании источника питания для СВЧ модуля инженер должен уложиться в указанные конструктором габариты. Какой метод описания габаритов может использовать конструктор, передавая задание инженеру?

+++ Эскиз компоновки СВЧ модуля на салфетке, с указанием габаритов в см отдельной строкой ### Да, инженер сможет использовать этот документ для удовлетворения своего интереса к габаритам.

+++ Вылепленный из пластилина в масштабе 1:5 макет СВЧ модуля ### Да, инженер сможет использовать этот рабочий продукт/артефакт для удовлетворения своего интереса к габаритам. Метод описания физической моделью вполне подойдёт.

+++ Чертеж СВЧ модуля с источником питания, выполненный по ГОСТам ### Да, инженер сможет использовать этот документ для удовлетворения своего интереса к габаритам.

--- Показ габаритов модуля на пальцах ### Нет, габариты не будут документированы, метод описания не приемлем.

--- Продиктовал габариты модуля по телефону ### Нет, габариты не будут документированы, и метод описания и не указан, и не приемлем.

+++ Табличка с габаритами модуля в мм ### Да, инженер сможет использовать этот метод описания для удовлетворения своего интереса к габаритам.

Задания: мета-моделирование

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

1. Опубликован пост со своими мыслями по итогам чтения материала и занятий моделированием текущего раздела руководства.

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