Внешние и внутренние проектные роли

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

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

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

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

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

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

Думать о том, как (методы/«виды труда»/«рабочие процессы») и кем (какими ролями, актёрами в каких ролях) будет эксплуатироваться система, которой ещё нет, которая едва-едва замыслена в её MVP --- это не только нормально, это просто необходимо, с этого вообще нужно начинать думать о системе! Если система не будет кому-то нужна, не будет кем-то эксплуатироваться/использоваться, то зачем её вообще делать?!

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

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

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

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

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

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

  • Stakeholder иногда означает только внешнюю роль, иногда --- любую проектную роль.
  • Stakeholder иногда означает именно роль, но часто --- агента-исполнителя роли, то есть путают Васю Пупкина и играемого им Принца Гамлета. Иногда поэтому уточняют: stakeholder и stakeholder role, иногда для исполнителя роли stakeholder representative, особенно когда этих исполнителей ролей много, например, есть 1000 пользователей какого-то устройства, так вот ответственного за выражение интересов пользователей назовут stakeholder representative. Но часто уточнений не делают, и тогда Принца Гамлета начинают спрашивать, как ему спалось между спектаклями, а Васю Пупкина --- что он думает о «Быть или не быть, вот в чём вопрос!». Эта путаница с понятием stakeholder очень часта, поэтому в нашем курсе мы избегаем этого синонима проектной роли.

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

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

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

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

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

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

Успешность системы определяется сегодня не «объективно», а субъективно --- по удовлетворению потребностей (needs)заказчиков, пользователей и самых разных другихпроектных ролей, включая договаривающихся с ними внутренних ролей команды проекта[1]. Агенты (люди, а также AI-агенты и самые разные их организации), играющие самые разные роли по отношению к системе и проекту по её созданию, должны быть довольны --- успех в этом. Нельзя узнать про успех системы, глядючи только на саму систему. Как система (её границы!), так и её успех --- в глазах смотрящего. Разные агенты и даже одни и те же агенты (в разных проектных ролях!) могут быть разных мнений по поводу успеха системы. Так что задача создания системы прежде всего --- это договорить между собой проектные роли (выглядеть это будет как договорённости исполнителей ролей: «Маша договорилась с Сашей», но правильно понимать, что это «инженер договорился с менеджером», желательно такое обсуждать в ролях, а не в лицах). Задача тут --- предлагать такую систему или такой метод работы, по поводу которого им не нужно будет договариваться, ибо они сразу будут реализовывать предпочтения всех ролей.

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

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

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

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

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


  1. 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. ↩︎

  2. Высказывание Г.П.Щедровицкого. ↩︎