Практическое системное мышление – 2023

Одним из примеров такого подхода служит инженерный способ разработки требований «сценарии использования» (use case, но автор Ivar Jacobsen оговаривал, что в шведском языке, на котором он сначала предложил этот способ разработки, вместо слова case использовалось слово «сценарий»). Сценарий – это последовательность действий актёра/актора/actor, то есть активного действующего предмета. Это может быть как человек (и в предлагаемом для описания сценариев использования для описания актёра служит фигурка человека), так и вовсе не человек, и даже неодушевлённый предмет – тот же молоток, который предлагается активным элементом в последовательности действий, складывающихся в пьесу-сценарий. Сценарии использования оказались очень удачны для описания работы/процессов/последовательностей_действий/сценариев/поведения системы и её частей. Этот способ описания стал повсеместным для инженеров, он приводит к построению функциональных/ролевых описаний.

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

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

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

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

Знания передаются из ситуации в ситуацию в виде норм поведения для ролей, а не норм поведения для разных физических объектов.

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

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

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

Физические и функциональные объекты

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

Мы можем мыслить о Принце Гамлете, подразумевая что он существует в тот момент, когда его роль играет один из актёров (например, известный артист Василий Пупкин). По Принцу Гамлету в этот момент можно постучать, можно ткнуть в него пальцем, он занимает место в пространстве-времени. А когда Принц Гамлет идёт обедать? Ответ: никогда, ибо обедать идёт Василий Пупкин, а Принц Гамлет во время обеда не существует – он прекращает в этот момент своё существование.

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

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

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

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

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

Второе поколение системного подхода

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

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

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

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

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

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

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

Разные роли имеют разные ролевые предпочтения/оценки интереса в достижении предмета интереса. Если общий интерес проектных ролей покупателя и продавца – цена, то ролевое предпочтение покупателя минимизации цены (если принята терминология оценки интереса[67 - Assessment, элемент языка ArchiMate 3, http://pubs.opengroup.org/architecture/archimate3-doc/chap06.html#_Toc489946014 (http://pubs.opengroup.org/architecture/archimate3-doc/chap06.html#_Toc489946014)]: цена слишком высокая), предпочтение продавца – поднять цену (оценка интереса: цена слишком низкая).

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

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

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

Если человеку, находящемуся в проектной/деятельной роли, что-то в системе или проекте, который занимается этой системой, не нравится, или наоборот, нравится (есть интерес к системе, и в этом интересе у него предпочтения) – он начинает что-то предпринимать, он не просто наблюдает, он реализует свои предпочтения, у него появляется деятельностное намерение[68 - Тут мы обращаемся к «прагматическому повороту» в философии,https://plato.stanford.edu/entries/pragmatism/ (https://plato.stanford.edu/entries/pragmatism/)]. А если ничего не предпринимает – то его просто не учитывают, у него тогда нет роли, нет действий, которые он выполняет по отношению к системе или проекту по её созданию. Если кто-то просто проходит мимо окна конструкторского бюро, то он явно не играет никакой проектной роли в проекте, над которым работает это конструкторское бюро.

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

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

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

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

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

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

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

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

Успешность системы определяется сегодня не «объективно», а субъективно – по удовлетворению потребностей (needs) заказчиков, пользователей и других проектных ролей/стейкхолдеров[69 - http://sebokwiki.org/wiki/Systems_Engineering_Overview – Systems engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. Successful systems must satisfy the needs of their customers, users and other stakeholders.]. Люди, играющие самые разные роли по отношению к системе и проекту по её созданию, должны быть довольны – успех в этом. Нельзя узнать про успех системы, глядючи только на саму систему. Как система (её границы!) так и её успех – в глазах смотрящего. Разные люди и даже одни и те же люди (в разных проектных ролях!) могут быть разных мнений по поводу успеха системы. Так что задача создания системы прежде всего – это договорить проектные роли/стейкхолдеров между собой, или предложить такую систему, по поводу которой им не нужно будет договариваться, ибо она сразу будет реализовывать предпочтения всех ролей. Системный подход, системное мышление – это оказалось и про людей в их ролях по отношению к системе, а не только про саму систему. Система определяется этими людьми и без внимания людей к ней просто не признаётся каким-то важным объектом окружающего мира, а поведение людей в одном из связанных с системой проектов не произвольно, а определяется их культурно-обусловленной (часто – профессиональной) ролью.

Единственный вариант «объективности» – это хорошо организованная субъективность[70 - Высказывание Г. П.Щедровицкого.], когда все стейкхолдеры договорятся о том, какова их система, и что они от неё ожидают.

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

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

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

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

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

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

Этот поворот от «объективности научного мира» к «субъективности деятельностного мира» и обращение к стейкхолдерам произошёл в мире примерно в 1975—1985 годах. В СССР как раз начались гласность и перестройка, из системных мыслителей на эту тему в те времена говорили представители системнометодологического движения (последователи Г.П.Щедровицкого[71 - https://ru.wikipedia.org/wiki/Щедровицкий,_Георгий_Петрович (https://ru.wikipedia.org/wiki/%D0%A9%D0%B5%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D1%86%D0%BA%D0%B8%D0%B9,_%D0%93%D0%B5%D0%BE%D1%80%D0%B3%D0%B8%D0%B9_%D0%9F%D0%B5%D1%82%D1%80%D0%BE%D0%B2%D0%B8%D1%87)]), в их языке использовалось очень близкое к проектной роли/стейкхолдеру понятие «позиция» и они первые начали говорить о том, что привнесение деятельностной субъективности в системное движение через понятие проектной роли/стейкхолдера/позиционера означает появление нового, второго поколения системного подхода. В современной терминологии можно было бы говорить о системном подходе 2.0.

Вот график частоты упоминания слова «стейкхолдер» в библиотеке англоязычных книг Гугля[72 - https://books.google.com/ngrams/graph?content=stakeholder&year_start=1950&year_end=2008&corpus=15&direct_url=t1%3B%2Cstakeholder%3B%2Cc0 (https://books.google.com/ngrams/graph?content=stakeholder&year_start=1950&year_end=2008&corpus=15&direct_url=t1%3B%2Cstakeholder%3B%2Cc0)], и это примерно отражает распространение системного подхода в его второй версии (прежде всего в литературе по проектному управлению, а затем в системной инженерии):

Театральная метафора

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