Данная заготовка содержит разные “вкусные” куски, которые показались мне весьма ценными для разъяснения системного мышления во время чтения разных текстов А. Левенчука с 2016 года (до начала освоения руководств летом 2025 года).
В минимальном проекте один человек будет организовывать сам себя как менеджер-организатор, потом обеспечит себя клиентами как маркетолог-продавец, потом будет проводить инженерные работы по созданию целевой системы как системный инженер проекта, и параллельно заниматься операционным менеджментом самого себя. Разделить труд/практики и работы нет между кем - человек один, ролей много. Надо играть все роли самому, и желательно хорошо. Как минимум, имея перед глазами системную схему проекта, чтобы не упустить ни одну из альф из внимания. А также быстро сообразить, что качественно выполнить проект в роли такого “многорукого многонога”, выполняющего множество работ, назначенных на множество практик, не удастся, что-то обязательно будет завалено, не хватит мастерства, или вообще забыто/упущено из внимания (в результате чего нужные рабочие продукты для последующих стадий будут просто отсутствовать), нужно разделение труда, коллективная деятельность, и создавать команду.
- Курс “Системная инженерия” даёт нормативный (“как нужно делать”, а не только “как бывает”) подход для практик создания каких угодно целевых систем.
- Курс “Системный менеджмент” даёт обзор практик создания создателей-организаций, то есть даст нормативный подход для работы с организациями (командами, коллективами, предприятиями).
Организованное с разделением на системные уровни и по разным ролям коллективное мышление - это огромное достижение цивилизации.
Системный подход и разделение на системные уровни проявляется в жизни как разделение труда. Человеческие роли в проектах специализируются на различных системных уровнях: рекурсивно на каждом системном уровне применяется мышление инженера, который собирает приемлемую для надсистемы (уровень выше) целевую систему (текущий уровень), используя эмерджентность от взаимодействия собранных вместе подсистем (уровень ниже). Каждый уровень специализируется на своей эмерджентности. Разделение труда, связанное с получением компетенций в работе на трёх смежных системных уровнях (знать, для чего делать и как использовать - разбираться в надсистемах; знать, как сделать целевую систему, знать, из чего делать - разбираться в подсистемах) даёт возможность выстраивать длинные цепочки деятельности самых разных людей, разбивая общую сверхсложную деятельность на всех системных уровнях на множество не таких сложных на каждом системном уровне.
Нужно тщательно выявить ту целевую систему, с выбором которой будут согласны все, синхронизироваться в действиях по отношению к которой будут все, и дальше уже разбираться с той системой, которая к тебе ближе всего. Интересы всех ролей разные, причём эти интересы могут быть к разным системам - и действия по преследованию этих интересов поэтому оказываются разными, часто очень изобретательными, неожиданными для окружающих. Лучше всем в проекте договориться перед тем, как эти действия начнутся (или начнётся активная реализация самых неожиданных стратегий самых неожиданных агентов).
Нужно коллективно/группой договориться, что считать целевой системой, какие цели преследует проект, в чём состоят его возможности. И ещё нужно понять, какой именно коллектив/группа договариваются, это ведь тоже часто сходу непонятно: если непонятно, что мы делаем, то непонятно, кто вовлечён в это делание, кто такие “мы”, кто в проекте потребуется. Каждые пять минут менять то, что ты/вы называешь/называете целевой системой - это неправильно. Релятивизм (когда всё на свете считается субъективным и относительным, зыбким и неопределённым - заведомо отсутствует точка отсчёта) в мышлении не поможет. Договорённость по поводу целевой системы должна достигаться из каких-то принципов, а не произвольно, и на достаточно долгое время - желательно не менять целевую систему во время всего проекта.
Целевая система определяется субъективно, “система в глазах смотрящего”. Поэтому вопрос “системы, которую вы хотите сделать”, начинается с внимания к тому, кто такие “вы”, сколько вас, какие у вас интересы. Системное мышление - это мышление коллективной/групповой деятельности, оно позволяет большим командам договариваться в проектах с миллионами индивидуальных деталей в целевых системах, удерживая внимание разных ролей на их общем важном, чтобы без потери внимания к этому системному целому позволить заботиться о деталях подсистем отдельным членам каждой команды. Для выявление целевой системы нет строгих правил, алгоритма, последовательности мыслительных шагов, порядка опроса каких-то людей, типологии случаев/cases (это предпринимательская задача! Нет алгоритма предпринимательства!). Так или иначе в решении по поводу выбора целевой системы будут участвовать самые разные люди в самых разных ролях, и речь идёт не только о членах команды, но и о внешних ролях. Если у вас проект, который вы можете сделать в одиночку, то вам не потребуется развёрнутого системного мышления, хватит его обрывков. Но если проект сложный и работает группа, то в принятии решений заведомо будет сложный переговорный процесс и о целевой системе придётся договариваться по ходу дела.
Все системы в глазах смотрящих, так что потребуется выявить и договориться с командой и внешними проектными ролями и целевую систему, и надсистему, и подсистемы, и системы в ближнем и дальнем окружениях, и самые разные системы создания (включая команду как систему!) по всей длине цепочки создания, и нашу систему. В проекте надо непрерывно договариваться. Системы создаются коллективно, в этих коллективах договариваются. Системное мышление помогает определить, по поводу чего договариваться. Прежде всего, по поводу того, что именно мы делаем: какая система является целевой, то есть успешность какой системы будет ключевой для проекта. Нет договорённости по поводу целевой системы - не знаем, что делать, нет проекта.
Тот, кто в проекте играет роль предпринимателя, главный, кто решает, что есть целевая система проекта (так как “шкура на кону”, его риск). Но остальные члены команды, играющие внутренние роли в проекте, должны с этим согласиться. Тогда, если целевая система выбрана верно, вероятность добиться успеха в проекте растёт. Если же такого согласия нет, то несогласный член команды должен перестать играть роль в этом проекте, ибо вероятность того, что он будет неуспешным, растёт либо в силу ошибки предпринимателя по выбору целевой системы, либо плохого исполнения практик роли несогласным членом команды.
Целевая система выявляется/discover ситуативно, о ней договариваются командно, нет никакого алгоритма или “типовых ситуаций”. Тем не менее, есть эвристики (догадки, хорошо себя зарекомендовавшие). Слово “выявление” / discovery тут используется не случайно: считается, что целевая система есть, и её нужно только найти/выявить - возможно, поговорив при этом с большим количеством самых разных исполнителей самых разных ролей. Нас тут не смущает, что речь идёт о будущем - в пространстве-времени эта система уже существует, только в будущем отрезке времени, не прямо сейчас, это не мешает описывать целевую систему и её роль в надсистеме уже сегодня. Потребности как описание “чёрного ящика” надсистемы, требования, как описание “чёрного ящика” целевой системы - их не “выдумывают”, не “разрабатывают”, их как раз выявляют и затем документируют (неправильно говорить “фиксируют”, т.е. закрепляют их состав. Нет, их продолжают выявлять в ходе всего проекта, и документируют - в них всё время будут вноситься изменения, ничего фиксированного в требованиях нет!). В системном мышлении вы всё лучше и лучше описываете систему (или описываете всё более лучшую систему, по мере понимания этих требований), меняя и меняя тем самым требования - документированные требования этому не мешают, они просто документированы, но не фиксированы ни в один момент времени проекта! Вы можете какую-то версию требований объявить стабильной. Инженеры говорят в этом случае о базисе/baseline, но это не означает “фиксации”!
Системное мышление - про договорённости. Вам нужно достичь договорённостей в проекте, а системное мышление подсказывает, по каким вопросам важно эти договорённости достичь. Первая из них - это договориться о целевой системе, определить её границы, её функции в надсистеме. Системное мышление по своей природе коллективно, оно позволяет разделить умственный (по проектированию) и физический (по изготовлению и эксплуатации) труд, задействовать множество разных исполнителей для самых разных проектных ролей - и при этом детально продумываются части системы на всех системных уровнях для всех ролевых интересов на каждом системном уровне. Но как договориться о том, как склеивать все эти самые разные описания самых разных частей системы в одно целое системное описание? Как договориться всем этим ролям и их исполнителям? Все эти описания можно совместить, если понимать, что они описывают одно и то же место в пространстве-времени, относятся к одному и тому же воплощению системы. В центре любых системных обсуждений будет физическое воплощение системы, рассматриваемое в момент эксплуатации (run-time), к нему будут привязаны все остальные рассуждения.
Убедитесь, что в вашем проекте воплощение системы в конечном итоге физично (может быть, позже по полному жизненному циклу, чем в жизненном цикле проекта, который вы выполняете, но делаете вы изменения в физическом мире, а всё остальное только в поддержку этого изменения, а не само по себе).
Примат альфы воплощения системы (состояние альфы свидетельствуется целевой системой в физическом мире) виден в том числе по отношению этой альфы с другими основными альфами на диаграмме системной схемы проекта. У воплощения системы на диаграмме оставлено максимальное число отношений: оно даёт возможности, его используют внешние проектные роли (им для включения в состав надсистемы нужно воплощение системы, это только членам команды бывает нужно определение системы - но только для того, чтобы с меньшим количеством проб и ошибок получить воплощение системы), его в конечном итоге и создаёт/производит команда. Воплощение системы - это и есть целевая система в её физическом виде, её создание и есть цель проекта.
Примерно то же самое происходит и со всеми остальными альфами и подальфами: состояния всех из них изменяются командой не порознь, а в тесной взаимосвязи, их изменения уторговываются командой, согласуются, о них договариваются. Команда совместно обсуждает текущее состояние альф и подальф проекта и на основе этого обсуждения планирует шаги/работы по достижению следующих состояний, далее следует планам. Команда сотрудничает в изменении состояний альф! При этом план не обязательно “от начала до конца проекта”, планироваться и выполняться может каждый отдельный мелкий шаг в проекте - это agile, работа в рамках кейс-менеджмента. Главная идея в том, что это командная работа, а не работа одиночек каждого над своей альфой.
Команда проекта определяет, что (какие части) в целевой системе нужно, а что (какие части) не нужно иметь, чтобы система могла выполнять свою роль/функцию/назначение в окружении и не стоила при этом больше, чем могут заплатить за её создание внешние роли. Роли/stakeholders определяют роли/функции/назначение системы в её окружении (обычно это предприниматели, инженеры и менеджеры из организации-заказчика, но и многие другие - регуляторы, представители общественности, атакующие/паразиты - хакеры, мошенники, воры, террористы). Системный мыслитель не забудет спросить, что будет создано в результате проекта, кто будет клиентом и заплатит за работы, каким способом это будет создано, как долго планируется потом развивать созданное и как будут организованы разработчики. Эти вопросы не зависят от того, продукт создаётся или сервис, предприятие или сообщество. А ещё учитываем, что работать надо будет в организациях, где не все сотрудники - люди (этими сотрудниками могут быть как другие предприятия, так и роботы, и AI).
Жизненный цикл 1.0 как последовательность крупных работ-стадий тем самым отражает модульное/конструктивное/продуктное представление о системах создания, рассматриваемых как проекты. Проект - это группа людей с каким-то оборудованием и материалами (оргзвено!), преследующая какую-то цель, организованная (понятны полномочия по распоряжению трудом и другими ресурсами) и ведущая для этого работы. Жизненный цикл в начальном 1.0 понимании - это по-крупному разбитые все работы систем создания с целевой системой. А уж одна создающая организация выполняет все эти работы, или много разных, занятых реальными жизненными циклами проекта - это менее важно. Главное тут - не забывать о полноте жизненного цикла, “от рождения до смерти”. Эксплуатирующая/функционирующая/оказывающая сервисы система в её окружении - это просто одно из многих её состояний, но она проходит множество самых разных состояний в ходе её создания и уничтожения. Жизненный цикл отражает этот факт. И он указывает на организационные системы, меняющие своими работами/сервисами состояние целевой системы от момента её замысливания до момента её выводы из эксплуатации - указывает на системы создания.
Если речь идёт о системах создания, то мы ни на секунду не забываем, что главное в них - люди, и работы выполняют люди, хоть и с помощью технологий, оборудования и материалов. Экземпляры сервисов, выполняемых оргзвеньями - это и есть работы.
В проектном управлении программа - это набор проектов, посвящённых какой-то цели, но проекты из этого набора планируются по мере осознания в них потребности, а не сразу в момент старта программы.
Попробуйте перестать рисовать целевую систему (да и любую другую) квадратиком или кружочком. Вместо этого рисуйте её жизненный цикл, обозначая его стрелочкой с засечками.
Это будет напоминать не только о воплощении целевой системы, но и длительности всех работ с целевой системой, и об её системах создания, то есть напомнит учитывать организации/предприятия/оргзвенья/команды/проекты, ведущие эти работы.
Оргзвенья играют оргроли, оргроли реализуются оргзвеньями (функциональные объекты реализуются конструктивными, это отношения реализации, помним 4D экстенсионализм). Оргроли выполняют практики (функциональное/ролевое/инженерное рассмотрение), а оргзвенья выполняют работы/сервисы (конструктивное/организационное/менеджерское рассмотрение).
Предпринимателю важно совмещать практические проекты и хорошую теорию, которая защищает от многих ошибок, экономит время, деньги, душевное спокойствие. Предпринимательская теория состоит из предпринимательского деятельностного кругозора и прикладных практик. Для предпринимательской теории можно выделить такие трансдисциплины, как праксиология (экономика), системное мышление, этика.
Развитие предприятия или личное саморазвитие - это постоянный процесс постановки новых и совершенствование текущих практик. С помощью определения важных решений команда пытается заглянуть в будущее и понять, как ей действовать в будущем. Поэтому можно сказать, что с помощью стратегии команда пытается решить два важных для себя вопроса: 1) не быть полностью зависимыми от внешних обстоятельств, которые могут постоянно сбивать с фокуса внимания; 2) снять текущее беспокойство о будущем. В проекте все должны договориться, а системное мышление подскажет, о чём нужно договариваться.
Основа работы с альфой возможностей - предпринимательство, которое принципиально не формализуемо, ибо связано как-то с оценками будущего. В современном мире предпринимательские решения слабо поддаются формализации. Пожалуй, альфа возможности - это самая сложная альфа для работы. По сложности работы с ней может сравниться только альфа команды. Среди подальф возможностей нужно особо указать “бюджет”, с которым работают практики бюджетирования (включая такие, как beyond budgeting), а также потребности (stakeholder needs), с которыми работают практики анализа потребностей (user needs analysis, целеориентированная инженерия требований и т.д.).
Предпринимательство нельзя алгоритмизировать, чтобы наладить неизбежное получение результата: всё новое приходит сбоку, любая идея живёт недолго, учесть нужно будущее, а оно заведомо неизвестно.
Стратегирование - это, безусловно, предпринимательская деятельность, умение предвидеть будущее. Стратегирование (выбор того, чем заняться) по мере принятия различных решений (реализации стратегии) плавно перетекает в маркетинг (привлечение внешних стейкхолдеров-покупателей) и продажи (заключение конкретных сделок). Если вы не знаете, делать ли вам дешевле, лучше или быстрее - делайте быстрее, это в долгосрочном плане самая выигрышная стратегия (на сэкономленное время вы успеете сделать другие проекты, причём и лучше, и дешевле). “Либо вы стратегируете, либо вас планируют”. Основной признак наличия стратегии - это прохождение теста Портера на сфокусированность (т.е. стратегия - это не “чем бы ещё заняться”, а наоборот: нахождение такого занятия, при котором отказываешься от многих и многих других занятий).
По предпринимательству и стратегированию учебников нет; кто слишком много знает (а не делает), тот обычно становится в этой сфере аналитиком, а стратегия требует таланта прежде всего в синтезе. Позиция предпринимателя крайне сложна, ибо нужно учесть интересы многих и многих стейкхолдеров, причём эти интересы должны быть синхронизированы во времени (“вчера ещё рано, завтра уже поздно”).
Разделение труда, обычный путь цивилизации: в прошлом выполняемое человеком вроде бы одно дело начинает выполняться дюжиной разных ролей, в которых специализируются разные люди - и в этих более и более узких видах деятельности люди достигают высоких уровней мастерства.
Управление жизненным циклом помогает системе создания пройти через стадии ЖЦ - группы практик, в результате которых меняется состояние (конфигурация) целевой системы. Нужно работать (выполнять какие-то практики жизненного цикла), чтобы альфа возможностей двигалась по своим состояниям. Достижение каждого состояния проверяется прохождением чек-листа, и свидетельствуется какими-то артефактами. Это предмет системноинженерного и системноменеджерского кругозора. Сама себя альфа не двигает, возможность сама себя не выявляет, а затем постепенно не переводит в состояние “извлекается выгода”! Для этого нужны работы команды, а работы должны использовать какие-то методы/практики.
Хорошей практикой является сразу разделение альфы “внешние проектные роли” на отдельные подальфы индивидуальных проектных ролей и раздельный учёт состояний каждой из этих подальф. И обычно этих подальф сразу от пятнадцати, а не от от трёх-пяти! И ещё помним, что в любой момент проекта число внешних проектных ролей на единицу больше числа выявленных проектных ролей - и вот эта единица будет неиссякаемым источником сюрпризов.
Об альфах говорят обычно с использованием метонимии, считая их реальными объектами: альфа и рабочий продукт сливаются в один объект.
Коммерческая возможность выполнить проект - это деятельная инициатива, предпринимательство как предсказание будущего, изобретательство в чистом виде, методы/практики работы с этой альфой слабоформализуемы, там больше работает не прикладное, а фундаментальное мышление. Прежде всего работа с этой альфой связана со способностью предугадать будущее, а это делается на основе хороших порождающих моделей/generative models, то есть лучших общих представлений об устройстве мира (в частности, фундаментальные курсы интеллект-стека дают ровно такую модель).
-
Возможность выявлена (identified): найдена идея; найдена как минимум одна проектная роль, желающая сделать инвестицию в понимание возможности; определены другие проектные роли.
-
Нужно решение (solution needed): выявлено инженерное и/или культурное решение; установлены потребности, определены проблемы и их причины, подтверждено, что внешним проектным ролям это решение нужно; было предложено как минимум одно архитектурное решение.
-
Польза установлена (value established): польза возможности была определена количественно; влияние решения на внешние проектные роли понятно; польза системы внешними проектными ролями понимается; критерии успешности ясны; результаты ясны и выражены количественно.
-
Жизнеспособна (viable): инженерное решение обрисовано в общих чертах; решение возможно с учётом ограничений; риски приемлемы и управляемы; решение выгодно; причины для разработки решения понимаются; ясно, что реализация возможности жизнеспособна.
-
Реализована (addressed): возможность реализована; решение достойно воплощения; внешние проектные роли удовлетворены.
-
Извлекается выгода (benefit accrued): решение приносит выгоду; возврат на инвестиции приемлем.
Нужно работать каким-то методом (выполнять какие-то практики жизненного цикла в нужной последовательности), чтобы альфа возможности двигалась по своим состояниям. Достижение каждого состояния проверяется прохождением вышеупомянутого чек-листа, и свидетельствуется какими-то артефактами. Вы должны знать (то есть выявить и документировать) то состояние, в котором у вас находятся работы по проекту. Следим за типами: слово “работы” в предыдущем предложении как раз и есть альфа “работы”! А документировать нужно будет менеджерское, а не инженерное описание (ресурсы, бюджеты, скорость работы и ожидания по срокам). Контрольные точки альф требуют работ по их прохождению, без работ систем создания, то есть работ команды (а иногда и цепочки систем создания, команду с её инструментами тоже нужно создавать!) состояния альф сами по себе в проекте не поменяются.
Возможность проекта определяется в том числе и тем, какие потребности внешних ролей фокусируют требования. Требования нельзя брать “откуда хочется”, “разрабатывать”, “придумывать”. При их выявлении/discovering фокус внимания инженеров задаётся потребностями внешних проектных ролей. Описываемая требованиями целевая система должна решать какую-то проблему надсистемы, то есть проблему внешних проектных ролей, занимающихся надсистемой. Анализ выявленных потребностей и reverse engineering/обратная инженерия (выявление архитектуры) надсистемы позволяет затем выполнить синтез требований. Явное описание (то есть документирование, приведение к явному/видимому виду на носителе информации) этих связей называют трассировкой/trace. Трассировка решений к требованиям помогает избежать типовых ошибок фокусирования, когда в проекте появляются лишние требования, или наоборот, недостаточно требований, то есть какая-то выявленная потребность не трассируется ни к каким требованиям.
Основные трудности в том, что практики работы с командой крайне неформализованы, имеют огромное количество вариаций в связи с личностным стилем руководителя. Они главным образом определяются дисциплиной “лидерство” (leadership), которая сама по себе крайне неформальна (хотя часть этих практик определяется более формализованными практиками human resources management и менее распространёнными talent management). Естественные подальфы - “командная роль” (внутренняя проектная роль, определяет необходимые компетенции члена команды в выполнении необходимых практик), “сотрудник” (носитель командных ролей), “оргзвено” (исполнитель командной роли, вместе с вверенным ему оборудованием, обладающий какими-то правами и обязанностями по распоряжению частью труда и капитала предприятия). Для команды важно существование команды как целого, это не просто набор занимающих какие-то места в штатном расписании актёров, которые выполняют время от времени работы согласно своим компетенциям. Вот состояния/контрольные точки, по которым отслеживают успешность изменений альфы команды в ходе проекта по созданию системы (опять ж, тут всё прописано для относительно небольшой команды, для большой команды придётся адаптировать, всё переписать по-другому):
- Намечена (seeded): миссия/рабочее задание команды определено; ограничения известны и явны; механизмы роста команды наличествуют; состав ролей в команде определён; обязанности команды обрисованы в общих чертах; уровень принятых командой обязательств ясен; требуемые компетенции определены; размер команды определён; правила надзора за деятельностью определены; вид/форма лидерства выбрана.
- Сформирована (formed): было набрано достаточное число членов команды; роли в команде понимаются её членами; все понимают, как работать; члены команды узнают друг друга при встрече; члены команды понимают индивидуальные обязанности и как они увязаны с их компетенциями; члены команды принимают результаты работ друг друга и смежников; внешние смежники (организации, команды и отдельные люди определены); механизмы общения в команде определены; каждый член команды принял обязательство работать так, как это принято в команде.
- Сотрудничает (collaborating): команда работает как одно сплочённое оргзвено; общение в команде открытое и честное; команда сфокусирована на достижении миссии/задания команды; члены команды знают друг друга.
- Производит (performing): команда постоянно выполняет обязательства; команда непрерывно адаптируется к изменяющемуся контексту; команда определяет и решает проблемы без внешней помощи; минимум возвращений к сделанному и переделок; работа впустую (waste) и причины работы впустую постоянно устраняются.
- Распущена (adjourned): обязанности были выполнены; члены команды доступны для участия в других командах; миссия завершена.
В оригинальном стандарте OMG Essense речь идёт об альфе way of working (способ проведения работ), а мы считаем way of working/метод/методологию (набор практик, необходимый для выполнения работ проекта “под ключ”) только частью описания организации. В принципе, организацию как создателя мы описываем так же, как целевую систему и вообще любую систему: стратегию как архитектурные требования, архитектуру организации (оргроли и их практики, оргзвенья и их сервисы). В практиках дисциплина грузится в головы исполнителей работ, её нужно искать в компетенциях команды, в человеческом капитале. Ещё мы ведём операционную модель, где учитываем ресурсы (команду и оборудование) и выполняемые работы.
Вся методология, конечно, разворачивается вокруг понятия “метод” (практика/деятельность/труд). Поэтому неудивительно, что в проектах “организацию” в смысле оргструктуры, сотрудничества людей строят прежде всего на основе понимания метода/way of working/набора практик/деятельностей/“видов труда”/“видов инженерии”, которые позволяют выполнить все работы проекта правильно. В основных альфах у нас “описание организации проекта”, “метод” тут является подальфой “описания организации проекта”, и превращается в мастерство сотрудников в части дисциплин метода и оборудование для поддержки этого мастерства в альфе “организация проекта” (то есть описание метода воплощается в оргзвеньях организации проекта). И помним, что есть ещё оргвозможность: этот самый “метод” вам должны ещё разрешить использовать (поручить использовать именно этот метод).
Контрольные точки/milestones достижения очередного состояния каждой альфы по ходу жизненного цикла проекта (формулируются как вопросы чек-листа, положительный ответ на которые означает достижение этой контрольной точки) требуют выбора практик для их достижения, а затем выполнения работ по их достижению. Состояния альф можно узнать не сами по себе, “умозрительно”, а посмотрев на состояние связанных с ними артефактов/рабочих продуктов. С альфами происходит мышление, с рабочими продуктами/артефактами (в том числе с документацией, но и воплощением системы непосредственно, и с инструментами поддержки дисциплин) происходит работа. Конечно, для описания (view, набор моделей) состояния альфы в рабочем продукте должен быть использован какой-то метод описания/viewpoint: мета-модель и принципы создания модели, методические указания по моделированию предмета интереса/concern. Помним, что предмет интереса отражается его методом описания, а само описание документируется, чтобы внимание коллектива на нём стабильно удерживалось независимо от уровня отвлечений людей в этом коллективе. Поэтому в реальной обстановке обсуждение ведётся не только альф, но и свидетельствующих об их состояниях рабочих продуктов/артефактов (и в том числе документов). Главное, не забывать, что в обсуждениях состояния проекта участвуют главным образом альфы, функциональные объекты, мышление идёт с ними. Но работаем в проектах с конструктивными объектами, отражающими/свидетельствующими/evidence состояния альф, т. е. с документами и другими артефактами/рабочими продуктами. И уровень бюрократии (типовых решений, выполняемых с использованием стандартизированного набора рабочих продуктов) можно и нужно выбирать в зависимости от профиля рисков проекта. Методология должна быть легковесной, но она должна быть достаточной для снижения риска утери внимания за важным в проекте. Системное мышление подразумевает письменную работу, оно не всё в головах! Лишние подальфы часто вызывают необходимость подготовки новых рабочих продуктов, по-разному повторяющих одну и ту же информацию. Для некоторых проектов лишнее документирование может быть хорошо, но для большинства проектов это непроизводительная трата ресурсов, отход от принципов lean (невыполнение ненужной работы), то есть бюрократизацию творческого инженерного процесса. Задавать вопросы по выпавшим из внимания важным объектам проекта/альфам - это и есть управление коллективным вниманием в проекте. Ещё один вариант использования системной схемы проекта - это понять, какие компетенции в команде проекта есть, а какие отсутствуют. Распечатайте системную схему проекта и дайте участникам проекта отметить крестиком те альфы, за состояние которых каждый из них планирует в этом проекте отвечать. Если какие-то альфы остались без своих крестиков - то проект ждут большие риски, и это надо немедленно обсудить: кто в команде берётся отвечать за состояние этих “бесхозных” альф? Вместо опроса может быть сразу осознанное принятие ответственности за какие-то альфы/подальфы в проекте. Проект как целое разбивается на изменяющиеся по его ходу объекты, требующие особого внимания (альфы), и команда проекта принимает индивидуальные ответственности за эти объекты - и коллективную ответственность за согласование действий по их поводу. Системный подход заключается тут в том, что ни на один момент не теряется проект как целое, но со сложностью проекта в каждый момент времени можно иметь дело по функциональным частям-альфам: все остальные части-альфы проекта при этом частном разбирательстве с одной альфой никуда не деваются, они отмоделированы, о них помнится, к ним обязательно вернутся и проверят, насколько они согласованно вписываются в проектное целое.
По поводу альф как постоянных объектов внимания в проекте разные “действующие лица”, то есть разные трудовые/проектные роли должны непрерывно договариваться. Все эти роли можно считать прикладными специализациями трёх основных ролей:
- Инженерная сообщества клиентуры: коммерческая/бизнес, которая решает, нужно ли вообще делать этот проект - кому будет нанесена непоправимая польза или вред этим проектом, кто за него заплатит достаточно, чтобы его окупить. Это продвижение, маркетологи, продавцы; сюда же относим рекламщиков, бренд-менеджеров, SMM и SEO. Все, кто ответственен за то, чтобы у создаваемой системы был клиент.
- Инженерная целевой системы, ответственной за такое преобразование части физического мира, чтобы целевая система с её включением работали как ожидается (прошла и проверка, и приёмка).
- Инженерная организации: это роль по эксплуатации организации, операционно-менеджерская, которая принимает ресурсные и логистические решения по ресурсам (люди, оборудование, материалы). Роль операционного менеджера планирует и отслеживает выполнение работ на имеющемся множестве ресурсов (людских, денежных, оборудования и материалов), чтобы работа была выполнена в срок без выхода за ресурсные ограничения и максимальной выгодой.
A key invention of Essense is the alphas. They are things that all teams care about and each one can be in one of a small number of states. As the team works, the state of each alpha will change as progress is made (or not!). The alphas help us work out what state we are in, but don’t help us much with what to do to move between states. This is where Activity Spaces come in. It describes 15 types of activity the teams will be doing in order to move between the alpha states. And, just like the state progressions, those activities will happen iteratively, causing waves of state changes each time. The Activity Spaces indicate the kinds of things that need to be happening, but don’t tell you how to do them - that’s the job of practices. When a practice has an activity (like Flow Review, Scrum Retrospective, Product Envisioning or Squad Healthcheck), they will belong in one or more Activity Spaces, but it’s the practice (like Scrum, Kanban, Scrum Scale or Spotify Model) that provides the detail, not Essense.
Подрядчик - это подальфа и стейкхолдеров, и команды. Ибо хотя подрядчик и внешний, но “играет за нас”. Помним также, что подрядчик и член команды - это тоже подальфы стейкхолдеров.
Это представление модели жизненного цикла хорошо показывает, что работы должны происходить не только с целевой системой и её описанием, но и с надсистемой и её системами создания (внешние проектные роли команд, создающих надсистему и подсистемы этой надсистемы), и с системой создания целевой системы (альфы работы, команды, метода). В проекте должны отслеживаться состояния всех альф, а не только двух, тратиться ресурсы на изменение всех альф, а не только двух, удерживаться внимание на всех альфах и подальфах, причём это внимание должно выходить за рамки жизненного цикла проекта и учитывать полный жизненный цикл (системное мышление требует собранности. Внимание нельзя терять ни к одному из предписываемых системным мышлением объектов! Моделируйте, и документируйте модели! Системного мышления “в уме” не бывает!).
Информационные технологии - они всего лишь про описания, ищите за ними физический мир, изменения в котором имеют значение! В проектах по разработке программ очень часто есть части по работе с людьми (обучение работе с программой: нужно “изготовить” те части людей, которые смогут делать что-то полезное с программой) и данными, с которыми будет работать программа. Не пропускайте эти части! Они физичны, их тоже нужно “проектировать”, а затем “изготавливать”: людей учить (и разрабатывать способы, которыми это будет происходить, и способы проверки научения), дополнительный софт настраивать (и проверять, всё ли настроилось). Как найти настоящую целевую систему, которую изготавливают программисты в конечном итоге? Ибо даже работающая программа оказывается часто работающей с описаниями и документированием описаний какой-то другой системы, нежели реальной системой, изменяющей физический мир! Тут просто: нужно смотреть не на саму программу, а на данные этой программы (часто они лежат в какой-нибудь базе данных). Эти данные описывают какую-то систему - чаще всего она и будет целевой системой в проекте! Именно это и будет воплощением системы, которым будут озабочены все окружающие разработку люди! Это срабатывает не в 100% случаев, но может быть хорошим стартом поиска целевой системы, когда вокруг много программистов. Если речь идёт о программе учёта командировок, то целевая система - то, что описывается её данными, и будет в результате работы программы изменяться (создаваться, уничтожаться). Это деловая поездка.
Примерно такие же рассуждения, что и рассуждения про компьютерные программы, можно проводить для обучения людей. Книги, видео - это только описания того, что хотелось бы получить после обучения. Целью обучения является работа части мозга человека, которая в момент попадания в целевое окружение включается по аналогии с компьютерной программой и производит те вычисления/мышление, на которые было направлено обучение. Мозг - это вычислитель, а прочтённые книги, просмотренные видео лишь задают описание того, что потребуется от мозга в плане протекания в нём физического процесса (со сменой состояний!) мышления в соответствии с результатами обучения. Но представление результата обучения как обученного для работы в целевых условиях участка мозга заставляет продумать и то, как выглядит это обучение в физическом мире (участок мозга должен в момент обучения быть же где-то расположен!) и как выглядит в физическом мире работа результата обучения как системы: должно быть соответствующее физическое окружение.
Проект - это множество самых разных дисциплин, каждая из которых поддерживает свои альфы. И все их знать в одной голове нельзя, поэтому командная работа, разделение труда, зон ответственности и интересов. Такой междисциплинарный подход даёт то, что каждая из дисциплин видит свои ошибки в проекте, укажет на них и даст свои решения. Поэтому будет “с первого раза правильно”, ошибок будет меньше, решения сразу будут более качественными. Дисциплина - она в головах членов команды. Но в организации есть технология: поддержанный необходимыми рабочими продуктами и инструментами способ работы (way of working). Практика = дисциплина + технология (метод = полный набор дисциплин и технологий для выполнения какой-то работы).
- Альфа “Внешние проектные роли” - дисциплины: конфликтология (“метод принципиальных переговоров” или “гарвардский метод”), чтобы снимать противоречия между требованиями различных стейкхолдеров; коммуникации (communications) для налаживания продуктивного диалога со стейкхолдерами. Особые техники представления стейкхолдеров.
- Альфа “Возможности” - дисциплины: маркетинг и продажи, стратегирование и предпринимательство - для установления user needs; управленческий (финансовый) учёт - для обоснования прибыльности.
- Альфа “Определение системы” - это инженерия требований, проектирование и конструирование (включающие работу с архитектурой системы).
- Альфа “Воплощение системы” - это производство (изготовление отдельных частей, сборка их, испытания).
- Альфа “Работа” - дисциплины: операционный менеджмент, управление цепочками поставок (supply chain management), управление проектами (project management), управление процессами (process management), ведение дел (case management), планирование и управление производством (planning and production management), логистика (logistics), операционная стратегия (operation strategy), управление сервисными операциями (management of service operations), улучшение производительности (performance improvement), планирование ресурсов предприятия (enterprise resource planning) и управление ресурсами (resource management), getting things done (GTD) - система персонального планирования, “как доводить дела до конца”.
Вот диаграмма, показывающая, что существует множество систем создания, которые на стадии своей эксплуатации (operations, использования) выполняют работы по обеспечению (enabling) той или иной стадии жизненного цикла целевой системы. Сама же целевая система на стадии своей эксплуатации работает в составе систем своего операционного окружения, выполняя свою функцию:
НАТО выделило четыре типа “систем систем”, отличающихся степенью их автономности:
- управляемые (directed), в которых есть назначенный архитектор, который может выдавать приказы составляющим системам и распоряжается ресурсами;
- подтверждённые (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать составляющие системы самоизмениться согласно разработанной им архитектуре;
- сотрудничающие (collaborative), в которых все системы договариваются друг с другом по каждому чиху, но архитектора, менеджера проекта или аналогичного выделенного органа управления нет;
- виртуальные (virtual), в которых системы вообще не знают друг о друге ничего и не влияют друг на друга явно.
Короткий список критических шагов (или критически выполненных условий) должен быть извлечён из кортекса супергероев и перенесён в экзокортекс (т.е. записан на бумажку или засунут в компьютер). Чеклисты - это одна из мер по повышению успешности решения сверхсложных задач не за счёт супертренинга супермозга супергроссмейстеров, а за счёт введения дисциплины коллективной деятельности и усиления кортекса в виде экзокортекса. Гроссмейстеры играют в уме, простые игроки играют за доской, “записывая” на ней результаты ходов - чтобы у обоих игроков не было ни малейших сомнений, что они играют одну и ту же партию, а не разные. Чеклисты позволяют синхронизировать командное понимание по поводу важнейших шагов деятельности, в разы и разы уменьшая количество ошибок.
Классические представления системной инженерии не слишком применимы к предпринятию: в силу самопринадлежности каждого человека, как основной организационной единицы, речь всегда идёт о системо-системной инженерии. Это означает, что можно сколь угодно тщательно определять предпринятие, но вот воплощение предпринятия может проходить с огромным трудом: совместные организационные изменения частей предпринятия с-людьми могут проходить не так легко и просто, как совместные изменения чисто технических систем, в состав которых не входят люди. Железка не разочаруется в жизни и не уйдёт в монастырь или к системе-конкуренту, а вот сотрудник, которого планировалось с его уникальными компетенциями использовать в каком-то определённом месте организационной “машины” - вот сотрудник это вполне может сделать. Несмотря на все оговорки про непохожесть человеческого коллектива в его смеси со зданиями, оборудованием, программами на “машину”, если инженер не определит (спроектирует) и затем надлежащим образом не воплотит такую систему-предпринятие, то вряд ли эта недоопределённая система-предпринятие сможет надлежащим образом выполнить свою функцию: толпа дикарей на острове не составит конструкторского бюро, разумное и глубокое разделение труда в этой толпе вряд ли проявится. И даже и толпа инженеров в центре мегаполиса тоже конструкторского бюро не составит: сначала нужно определить технологии проектирования, затем нужные для этой технологии квалификации людей, затем подготовить для них рабочие места, затем дообучить людей и/или нанять новых квалифицированных, затем организовать их (т.е. распределить полномочия согласно задуманному для реализации технологии разделению труда), и только потом можно ожидать выпуска продукции или оказания сервиса.
Предпринятие имеет жизненный цикл (но тут нужно обратить внимание на особенность: как барон Мюнгхаузен вытягивал себя за волосы, так и предпринятие обычно само себя протаскивает через жизненный цикл: оно само себе обеспечивающая система и целевая система: само себя проектирует/стратегирует, само себя строит, само себя эксплуатирует - но всё-таки различают производственную деятельность предпринятия и деятельность по развитию предпринятия).
Не меньше книг для руководителей, которые рассказывают о том, почему организации - это не самолёты, и для них не нужно бортмеханика - ведь они сделаны из людей, а самолёт - из железа, и “уговаривать” железные части самолёта сотрудничать много проще, чем обеспечивать лидерство (leadership), катализирующеее сотрудничество людей организации ради достижения поставленных пилотом-управленцем целей. От современного менеджера ждут, что он с одинаковой лёгкостью а) поставит чёткие цели и выработает стратегию их достижения (стратегирование); б) глаголом будет жечь сердца людей, чтобы они воспринимали эти цели как свои собственные (лидерство, катализация сотрудничества) и в) разработает и изготовит “производственный конвейер” (управление технологиями) и настроит его так, чтобы все работы выполнялись слаженно и успевались к срокам (операционное управление). Это непонимание разделения труда и разности ролей в чистом виде!
Ведение дел (case management) используется тогда, когда хочется отследить целенаправленную деятельность при невозможности заранее составить план (распределить работы во времени - то есть использовать проектное управление) и последовательность (какая цепочка работ, что раньше из них, что позже). Дело - ситуация, обстоятельства или начинание, которые требуют набора действий для получения приемлемого результата или достижения цели. Дело фокусируется на предмете, над которым производятся действия (например, человек, судебное дело, страховой случай), и ведётся постепенно появляющимися обстоятельствами дела. (Case. A situation, set of circumstances or initiative that requires a set of actions to achieve an acceptable outcome of objective. A case focuses on a subject that is the focus of the actions such as a person, a lawsuit or an insurance claim, and is driven by the evolving circumstances of the subject).
Системная схема проекта подразумевает, что все (функциональные! роли!) члены команды занимаются всеми альфами проекта, а не каждый только своей. Цель системного мышления - договориться об объектах коллективного сложного труда, цель практики методологии - скооперироваться и сотрудничать в коллективном сложном труде! Члены команды договариваются о том, что это за альфы (какие объекты в физическом мире им соответствуют) и о своих действиях по поводу этих альф, причём так, чтобы не было конфигурационных коллизий.
Организация/команда/коллектив проекта совместно обсуждает текущее состояние альф и подальф проекта и на основе этого обсуждения планирует шаги (работы по каким-то методам/практикам) по достижению следующих состояний, далее следует планам и отслеживает их выполнение. Команда договаривается о том, что такое в жизни эти альфы и каковы их состояния, а также сотрудничает в изменении состояний альф!
Три области важных характеристик/предметов интереса (area of concerns) группируют семь основных/essence альф как объектов внимания в проекте по трём укрупнённым группам характеристик, укрупнённым настолько, что их назвали “областями”. Важная характеристика/предмет интереса - это тема озабоченности роли, оформляемая каким-то методом описания/viewpoint, это не “чего хочется достичь”. “Чего хочется” это будет не сама характеристика, а предпочтения проектной роли для этой характеристики, сам интерес в предмете интереса - роли могут двигать целевые характеристики (их значения) в разные стороны, для этого они используют удобные для этого методы описания. И роли договариваются между собой по поводу реализации своих предпочтений в этих важных характеристиках.
- Область интереса надсистемы (customer area of concern). Это важные характеристики для внешних проектных ролей::альфа, которые дают организации::альфа коммерческую возможность::альфа выполнить проект. Надсистема и потребности - это подальфы альфы возможности, а ещё для возможности выполнения проекта важна ожидаемая от него прибыть (превышение дохода от проекта над затратами на него). Приёмка - это про удовлетворение потребностей, деньги внешние проектные роли проекту платят за удовлетворение потребностей, за улучшение работы надсистемы от работы в ней целевой системы, а не за просто работоспособность целевой системы!
- Область интересов создателя относится к выполняющей проект организации (оргзвена, выполняющего проект: команда, коллектив, “производственная кооперация” из нескольких предприятий, рабочая группа проекта и т.д.), работам и описаниям проекта (архитектура предприятия, включающая также описание метода работ как набора практик/деятельностей, достаточный для выполнения целей проекта). В проекте нужно управлять работами (операционный менеджмент), управлять жизненным циклом (определять метод: практики и способы назначения работ на практики, разворачивать и использовать технологии метода), организовывать и поддерживать сотрудничество компетентной инженерной организации (в OMG Essense она называется team, “команда”, ибо стандарт ориентирован на небольшие бригады разработчиков софта, но мы предпочитаем говорить “организация” или даже “проект” (как работы организации), или “организация проекта”, чтобы быть максимально безмасштабными. Организация - это группа людей и оборудования, в которой понятно как устроено распоряжение трудом и ресурсами).
Контрольные точки/milestones достижения очередного состояния каждой альфы по ходу жизненного цикла проекта (формулируются как вопросы чек-листа, положительный ответ на которые означает достижение этой контрольной точки) требуют набора практик для их достижения, а затем выполнения работ по их достижению.
Главное не забывать, что в обсуждениях состояния проекта участвуют главным образом альфы, функциональные объекты, мышление идёт с ними. Но работаем в проектах с конструктивными объектами, отражающими/свидетельствующими/evidence состояния альф, т.е. с документами и другими артефактами/рабочими продуктами. И уровень бюрократии (типовых решений, выполняемых с использованием стандартизированного набора рабочих продуктов) можно и нужно выбирать в зависимости от профиля рисков проекта. Рабочие продукты, свидетельствующие состояния альф (включая подальфы) проекта, можно делать проще или сложнее: методология должна быть легковесной, но она должна быть достаточной для снижения риска утери внимания за важным в проекте. Фундаментальные дисциплины, в том числе методология и использование системного подхода подразумевают письменную работу, мышление не всё в биологических головах! Кроме того, в проектах важно мышление организации/команды/коллектива/предприятия, оно требует коллективной памяти, что делается сегодня моделлерами!
Бизнесмена/коммерсанта/продавца интересуют внешние проектные роли и коммерческая возможность (он должен найти “рынок” - достаточное количество платёжеспособных агентов с потребностями, которые можно удовлетворить создаваемой в проекте системой). И поэтому его интересует трассировка/соотнесение требований с потребностями внешних проектных ролей, он контролирует сфокусированность инженерной команды на достижении целей проекта: создании успешного воплощения системы, то есть которое удовлетворит потребности (то есть не “наша система хорошо работает”, а “надсистема нашего клиента с нашей системой в её составе хорошо работает”).
Проектом (project) сегодня называют любое организованное (то есть с понятным распределением полномочий по распоряжению трудом и капиталом) усилие/endeavor какой-то команды (оргзвена) по достижению какой-то цели, в том числе цели ведения жизненного цикла (замысла, создания, эксплуатации, ликвидации) целевой системы.
Обычно продукт - это воплощение целевой системы в её окружении, а проект - система создания этого продукта, оргзвено (организованная на создание и модификацию продукта группа людей). Но есть вариант, когда продукт - это воплощение целевой системы в её окружении, а проект/design - это описание/system definition этого продукта.
Целевая система будет разрабатываться, изготавливаться, эксплуатироваться только в том случае, когда:
- она будет кому-то нужна, и за неё смогут заплатить - есть потребность, неудовлетворимая без целевой системы, и за неё готовы платить разумную плату;
- её кто-то сможет сделать за разумную плату - есть команда, которая готова сделать целевую систему. Если же люди работают, не требуя оплаты, то это просто означает, что они сами за это и платят (то есть находятся одновременно во внешних и внутренних проектных ролях, делают целевую систему сами для себя, для своей надсистемы - у меня это программа с Потапенко).
У некоторых агентов в этом мире будет интерес в том, чтобы вашей целевой системы не существовало; про потребности для этого случая тоже не забывайте - и помним, что интерес у агентов, а потребности описывают надсистему, так что “потребности внешних проектных ролей” - это кратко сказанное “описание принадлежащей внешним проектным ролям надсистемы на внешней границе надсистемы” в ситуации, когда в состав надсистемы входит во время эксплуатации целевая система и это описание удовлетворяет интересы внешних проектных ролей.
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design. Convey
- Команда основателей (система создания): инженерия инвестуры (надсистема), команды оргразвития и её метода (система создания). Разрабатывает для этого метод/набор практик/ролей для себя, выполняет работы.
- Команда оргразвития (система создания): инженерия команды создания целевой системы и её метода (система создания), команды продвижения и её метода (система создания). Имеет для этого метод/набор практик/ролей от команды основателей, выполняет работы.
- Команда продвижения (система создания): инженерия агентуры и её метода (система создания). Имеет метод, выполняет работы.
- Агентура (система создания): инженерия клиентуры и её метода (надсистема). Имеет метод, выполняет работы.
- Клиентура (надсистема): удовлетворение потребностей внешних ролей за счёт включения целевой системы в состав надсистемы в момент её эксплуатации. Имеет метод, выполняет работы.
- Команда создания целевой системы (система создания): инженерия целевой системы и её метода. Имеет метод, выполняет работы.
- Целевая система: входит в состав надсистемы в момент эксплуатации, удовлетворяет потребности пользователей. Выполняет работы.
DevOps - это разработка и строительство завода (конвейера/трубопровода/pipeline), непрерывное создание создателя, и эксплуатация создателя (заводские технологи, менеджеры и рабочие - операторы завода).
Системы с людьми - это системы систем в силу того, что люди обладают свойством самопринадлежности. Поэтому с системами с людьми в их составе нельзя работать простыми инженерными методами, в которых можно сконструировать простую механическую или механическую с элементами электроники систему, изготовить её части и собрать их в работоспособное целое. Нет, метафора часовщика с изготовлением деталей и их сборкой не работает. С людьми (как и любыми другими живыми системами) больше работают “сельскохозяйственные” метаофоры: в небольших системах систем - “садовника” (который имеет контроль над тем, что выращивает); в больших системах систем - “лесника” (который не имеет контроля над своим лесом, где какое дерево или кустик вырастет, но тем не менее лесник имеет достаточно влияния, чтобы предотвратить какие-то серьёзные негативные события - может предотвратить пожар, подкормить зимой животных, отогнать браконьеров).
Нужно помнить, что предприятие или даже команду нельзя проектировать, а потом изготавливать как компьютерный чип или водонапорную башню. Системы с людьми должны обсуждаться с использованием системного мышления, но вот замышлять их, создавать, эксплуатировать, ликвидировать их методами системной инженерии нельзя, там нужно использовать методы системного менеджмента.
Альфы системной схемы загружаются в голову как типы каких-то важных объектов внимания в проекте для ответа на вопрос “как работает проект”. А артефакты/рабочие продукты, играющие роль этих альф, можно найти в жизни. Основное умение умного человека - это знать альфы “внутри головы” как важные типы объектов и уметь оценить их состояние по артефактам/продуктам “в окружающей обстановке”, которые подходят по типу. Состояние альфы меняется в ходе проекта, и узнать об этом можно, поглядев на состояние рабочих продуктов. Рабочие продукты во всех проектах разны, а альфы остаются теми же.
Анализ/декомпозиция всегда только часть мышления! Опасайтесь проекта, где непонятно кто принимает решения по синтезу! Синтез меняет мир, анализ не меняет мир! Решения по синтезу меняют мир! Кто имеет право указать, что в ракете будут три ступени? Что в предприятии будут три подразделения? Что Вася Пупкин будет играть роль Принца Гамлета? Это точно не аналитики! Это инженеры!