5. Коллективная собранность в отслеживании выполнения работ

Диаграмма системного описания графов создателей

Выполнение работ означает два факта:

• Собственно затрату ресурсов на преобразование рабочих продуктов. Вася проработал два часа, забил сто гвоздей.

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

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

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

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

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

В руководстве по системному мышлению было введено понятие альфы как специального объекта, предназначенного для отслеживания состояний предмета метода. Особенностью альфы является то, что она игнорирует онтологический статус предмета метода. Скажем, альфа (воплощения) системы отслеживает состояния системы начиная с сырья, когда никакой системы ещё нет, но есть сырьё. Альфы служат для маршрутизации внимания в ходе отслеживания выполнения работ по их методу, они не отражают статическое онтологическое моделирование, когда каждый объект называется одинаково, независимо от его состояния по мере возможной сборки-разборки и даже прохождения проектирования как описаний «возможного будущего» (сама фраза «система существует в виде описания» формально-онтологически некорректна). Рассуждения об альфах поэтому полуформальны, моделирование альф тоже полуформально. Язык описания методов работ (по-другому — метод описания, задающий способ означкования для заданных типов понятий предметной области, viewpoint), основанный на альфах имеет уровень формальности псевдокода/pseudocode³. Псевдокод выражает какие-то алгоритмы (в том числе выражает алгоритмы через описание машины с конечным числом состояний, finite-state machine⁴) средствами, принятыми для описания алгоритмов, но итоговый записанный на псевдокоде алгоритм предназначен прежде всего для чтения человеком, но не для исполнения на классическом компьютере. Сейчас ситуация «чтения человеком» меняется довольно быстро, ибо чтение может быть и AI-агентом, задействующим большие языковые модели. Но в целом уровень формальности псевдокода меньше, чем уровень формальности классической алгоритмики или (помним об эквивалентности Curry-Howard) классической логики.

Итак, для того, чтобы отслеживать выполнение работ в проекте:

• Надо иметь метод описания состояний прежде всего предметов метода, например, использующий понятие альфы для моделирования этих изменяющихся состояний.

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

Стандарт OMG Essence⁵ предложил в качестве метода описания/viewpoint инженерных процессов (составляющих рабочих процессов) язык/language как набор понятий (онтологию, задающую типы моделируемых объектов) и средства графического и текстового «означкования» для записи моделей. Кроме языка моделирования в качестве примера для начала описания первые версии стандарта OMG Essence предложили также набор из семи основных/kernel (essence, существенный, основной, в самом стандарте эти семь альф названы kernel, но сам стандарт называется essence: «The kernel is a stripped-down, light-weight set of definitions that captures the essence of effective, scalable engineering in a practice independent way») альф проекта программной инженерии. Есть в стандарте и другие типы основных объектов — основные области интересов, основные работы, основные компетентности. Но мы пока будем использовать только основные альфы. Последующие версии стандарта объявили этот стандарт более общим, приложимым к системной инженерии в целом. Этими семью альфами как основными объектами внимания к предметам методов разработки были: коммерческая возможность, проектные роли, требования, воплощение системы, работа создателя, команда создателя, метод (way of working) работы создателя.

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

Этот набор семи основных альф был получен путём экспериментального ответа на вопрос: какие объекты внимания команды присутствуют в каждом проекте разработки? Было рассмотрено более 250 программистских проектов, и в основные альфы попали только те, которые встречались буквально в каждом проекте — это были работы примерно 2009-2014 годов в рамках инициативы SEMAT⁶.

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

Стандарт предлагал брать его язык/language (который вводил сам тип «альфа» как меняющий свои состояния объект внимания в проекте), но проводить его адаптацию в части набора основных/kernel альф. Стандарт по факту продолжает линию языков описания «инженерных процессов»/«методов разработки» (а ранее — «моделей жизненного цикла»), которые развивались в рамках ситуационной инженерии методов. Более ранние стандарты ситуационной инженерии методов предлагали какие-то свои варианты языков/language для описания объектов внимания в проекте, но они были ориентированы на методологов (SPEM, ISO 24744). OMG Essense был более продвинутым стандартом, ибо его главное отличие было заявлено как ориентация не на «удобную запись моделей методов», но «простое чтение метода» людьми-разработчиками как его пользователями, а не «далёких от народа» методологов. Поэтому стандарт сделал шаг работы «за методологов» и команда стандарта выполнила первый шаг моделирования разработки — предложила пример моделирования типами языка/language стандарта каких-то основных/kernel объектов внимания, прежде всего это набор из семи основных/kernel альф. Это отличало стандарты первого поколения ситуационной инженерии методов (они предлагали только language) от OMG Essence как стандарта второго поколения (language и пример kernel, который можно в простых случаях брать как первое приближение к важнейшим объектам внимания в проекте, сразу можно было отслеживать их состояния — в первом поколении стандартов инженерии методов этого не было).

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

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

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

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

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

На этой упрощённой диаграмме мы видим три области интереса:

• Область интереса надсистем, главным образом там рассматривается время продвижения, «чтобы узнали и использовали — причём заплатили за это». «Время» тут рассматривается в контексте «непрерывного всего», означая время работ по созданию клиентуры как множества клиентов. Продвижение — это работы по маркетингу, рекламе, продажам: чтобы проект состоялся, надо найти клиентов, которые готовы оплатить создание и развитие системы, и дальше убедиться, что клиент доволен: созданная и развиваемая система успешна. В OMG Essence это примерно соответствует customer area of concern, обычно на диаграммах это закрашивается мятным (оттенок зелёного) цветом⁸. Один из предметов интереса в этой области интереса — «внешние проектные роли»::альфа (то, что это альфа — означает, что в проекте будет отслеживаться смена состояний внешних проектных ролей, причём там указано, что этих ролей будет от 15 разных, то есть отслеживаться будет не просто эта альфа, а ещё и от 15 подальф этой альфы). Ещё один предмет интереса — «коммерческая возможность»::альфа, это сама возможность выполнить проект безубыточно. Альфа коммерческой возможности будет включать в себя подальфы надсистемы и потребностей (потребности — это ожидания внешних проектных ролей в поведении надсистемы, поэтому потребность может быть подальфой и внешней проектной роли: продвижение потребностей к удовлетворению продвигает и коммерческую возможность к моменту получения прибыли от проекта, но также и внешнюю проектную роль к состоянию удовлетворённости в использовании целевой системы) Для возможности выполнения проекта важна ожидаемая от него прибыль (превышение дохода от проекта над затратами на него), это тоже подальфа возможности. Если не отслеживать в ходе всего проекта альфы зоны/области интересов надсистемы, то результаты проекта могут оказаться никому не нужными, проект не будет оплачен — возможность выполнения проекта может исчезнуть в любой момент времени проекта, внешние проектные роли в любой момент могут перестать поддерживать организацию проекта материально, «продукт у нас есть, но его никто не покупает». Благотворительные проекты, которые оплачивают сами агенты-члены команды инженеров? Пожалуйста, тут разговор идёт о ролях, а не об агентах. Но если они не довольны тем, что сами же делают — проект прекратится за отсутствием возможности, хотя эту возможность и трудно будет назвать «коммерческой». Но ресурсов для разработки не будет, или ресурсы будут, они будут потрачены, но кто-то понесёт убытки — и это вопрос этичности: можно ли считать проект успешным, если внешние проектные роли несут убытки, а команда проекта получает оплату за не нужную никому работу, «нерациональную работу» в проекте.

• Область интереса целевой системы, в OMG Essence это solution area of concern, на диаграмме обычно жёлтого цвета. Эта область интересов относится главным образом ко времени использования. Мы видим там основные альфы kernel какой-либо системы — самой системы (в данном случае — целевой, физический двойник), её описания (в данном случае — цифровой двойник, нас ведь особо интересует время использования/эксплуатации, поэтому важно, чтобы описание включало в себя описание времени использования — акцент понятия цифрового двойника как раз на этом, «описание не только проекта/design, но и времени использования»), затем работа системы и функция/метод работы системы. Это то, чем в организации проекта будут заниматься самые разные инженеры целевой системы: их задача получить 1. воплощение системы, которое соответствует 2. описанию и 3. работает по выбранному 4. методу. Вот это всё и будет важными объектами внимания в проекте, и вот эти четыре основные альфы потом будут повторяться в самых разных областях интереса (тут их на диаграмме всего три, но в более сложных графах создателей их будет много больше).

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

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

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

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

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

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

Основных/kernel альф на диаграмме не четыре, а больше, ибо добавляются:

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

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

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

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

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

Всегда используйте текст (аутлайн) и таблицу вместо диаграмм

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

Вот пример записи альф из диаграммы в нашем примере в виде списка (первый уровень — это область интереса, второй уровень — альфы):

1. Надсистема целевой системы (время продвижения)

   1. Коммерческая возможность проекта создания целевой системы

   2. Внешние проектные роли

2. Целевая система (время использования)

   1. Воплощение целевой системы

   2. Цифровой двойник

   3. Методы/сервисы/функции работы целевой системы

   4. Работы (оperations) целевой системы

3. Создатель целевой системы (время создания и развития)

   1. Инженерная команда целевой системы

   2. Оргмодель инженерной команды

   3. Метод разработки целевой системы (инженерный процесс)

   4. Работы создания и развития целевой системы

Этот список в использовании для мониторинга состояния проекта имеет много преимуществ перед диаграммой:

• Занимает меньше места, на маленьком экране его легко окинуть взглядом.

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

• Список этот можно сделать в текстовом редакторе, не нужно долго рисовать картинки.

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

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

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

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

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

Даже необязательно объединять пустые ячейки таблицы, их можно просто оставлять пустыми. И необязательно использовать нумерацию. Если вы понимаете (удерживаете в голове, не упускаете из внимания) принципы, по которым устроена эта таблица, вам и вашим коллегам будет всё понятно. Мы ещё и добавили пример состояний для одной из альф, чтобы было понятно, что такое табличное описание легко расширять, и оно очень компактно — ещё и в качестве буллета использовали «птичку», как в чеклисте (это же всё такой витиеватый и необычный, но чеклист! Объекты внимания, состояния которых надо отслеживать!) и даже вставили словесный комментарий, разорвав список состояний альфы. Если вы понимаете, что такое «область интересов», «альфы», «подальфы», «состояния альфы» (это всё было в руководстве по системному мышлению), то вы легко разберётесь. Это просто примеры моделирования с использованием этого языка/language/онтологии/мета-мета-модели в качестве метода описания происходящего в проекте создания и развития системы. Опять немного поменяли имена (помним, что синонимов много, важно понимать смысл, а не запоминать слова). И, конечно, можно использовать как таблицы в Ворде, так и таблицы в Экселе, но ещё и в coda.io, notion.so, Obsidian и других редакторах текста и табличных процессорах, а также productivity tools:

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

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

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

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

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

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

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

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

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

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

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

По чеклистам как основному средству обеспечения коллективной собранности (мы предпочитаем современное написание «чеклист», а не «чек-лист» как в старых словарях) читаем книгу Atul Gawande, «The Checklist Manifesto», 2009 — и смело считаем эту книгу одним из самых интересных современных материалов по методологии, она подробно описывает, как появляется и поддерживается разделение труда (division of labor), то есть разложение методов работы на отдельные составляющие, поручение работ по этим методам отдельным агентам, которые оказываются играющими разные роли в проектах.

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

Задания: чеклисты

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

1. Прочтена книга Atul Gawande, «The Checklist Manifesto», 2009 (есть и русскоязычные переводы). В ходе чтения вы понимали, что речь идёт об альфах (объектах особого внимания в проектах, состояния которых оказываются крайне важны) и списках их состояний. Чеклисты позволяют удостовериться в достижении этих состояний. Чаще всего это состояние после закрытия какого-то кейса::работа.

2. Написан в порядке мышления письмом пост о том, что вы нашли контринтуитивным в прочитанной книге о чеклистах, то есть что было удивительно и с чем трудно было согласиться.

Области интересов надсистем, целевой системы, создателя

Области важных характеристик/предметов интереса (area of concerns) предложены в стандарте языка/language OMG Essence для группировки объектов внимания в проекте по укрупнённым характеристикам связи с какими-то системами. Они настолько укрупнены, что их было предложено называть не интересами, а областями интересов. В основных/kernel объектах из примера стандарта это были области интереса к объектам внимания, связанным с заказчиком/customer, системой»/system и проектом/начинанием/endeavor. Мы оставляем язык стандарта, сохраняем понятие «области интересов», но отказываемся от предложенного примера основных/kernel объектов в пользу более подходящего к нашему случаю примера не работы одной команды, а работы множества команд в графе создателей.

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

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

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

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

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

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

Если это группа агентов/оргзвеньев, которые играют какие-то роли (например, клиентура или просто «внешние проектные роли»), то будем создавать чеклисты для подальф, чтобы отслеживать изменения состояний отдельных агентов в группе. Подальфы важны, ибо часто нельзя сказать, что достигнуто какое-то состояние для альфы в целом, но можно — для подальф. Подальфы добавляют «разрешение»/resolution в модель, примерно так же, как добавка разрешения матричного экрана позволяет рассмотреть больше деталей изображения. Если у вас экран 8x8 пикселей, то вряд ли вы поймёте, что же у вас на нём изображено. Если же разрешение 4K UHD (3840 × 2160), то вы не только увидите, что изображено, но и увидите состояние того, что изображено. Например, на вопрос о том, в каком состоянии клиентура, вы могли бы отвечать «Клиенты 3, 5, 8 в процессе перезаключения договора, клиент 64 вчера отказался от наших услуг и мы проводим дополнительную с ним работу, от клиентов 39, 40 и 35 ожидаем оплаты, остальные обслуживаются». При этом у вас есть и альфа «клиентура», ибо если её нет, то что вы развиваете? Развиваете вы как раз клиентуру, наращиваете число клиентов в целом, увеличиваете лояльность, считаете показатели юнит-экономики¹⁰.

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

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

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

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

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

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

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

3. Убедитесь, что и описание метода, и результаты тестирования (замеры состояний) хранятся по возможности в самой системе, хотя тут могут быть и варианты. Это и есть «цифровой двойник», digital twin. Узнали про «убедитесь, что регламенты и чеклисты не в вашем софте, а в операционном софте сотрудника, который их исполняет»?

4. Проведите наладку — для этого в ходе разработки обязательно проведите испытания в самых разных режимах и обнаружьте несовпадение ваших моделей с реальностью. Исправьте ошибки по возможности до выхода в эксплуатацию. Инженерные обоснования (quality assurance) обязательны (подробнее — в руководстве по системной инженерии). Узнали «пройдите по чеклисту вместе с сотрудником»?

5. Не забывайте проверять, что там происходит с цифровым двойником, и как используются его данные для подстройки системы под условия использования. Узнали «организуйте надзор за честным заполнением чеклиста»?

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

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

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

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

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

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

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

Не бойтесь модифицировать приведённые в нашем руководстве основные альфы, наборы их подальф, контрольные вопросы чеклистов для состояний этих альф. Наоборот, бойтесь их не модифицировать. Хотя наши инженеры-менеджеры и говорят, что 75% примеров альф из нашего руководства можно использовать в проекте без модификации, вам может повезти сильно меньше. Только вы внутри проекта сможете сообразить, какие именно альфы и их подальфы вам нужно отслеживать, и только вы сможете сообразить, что можно взять для моделирования их чеклистов из нашего руководства, а что надо будет создать самим. Сам стандарт OMG Essence настаивает, чтобы чеклисты альф были адаптированы командой проекта: это даёт некоторую надежду, что команда понимает, что говорится в контрольных вопросах этих чеклистов.

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

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

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

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

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

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

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

Вам нужно предусмотреть это, когда будете адаптировать основные альфы для вашего проекта. Этим занимаются чаще всего исполнители ролей CTO/CIO (chief technology/information officer, в современном мире «станочный парк» стал во многом «парком» корпоративных информационных систем, «главный инженер» и «главный айтишник» — это одно и то же по их задачам), или выделенные ответственные за DevOps, и этих инженеров производственной платформы не надо путать с инженерами целевой системы: одни проектируют и эксплуатируют завод, а другие проектируют и эксплуатируют целевую систему, изготавливаемую и проверяемую на этом заводе.

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

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

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

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

TEST Область интересов, основные альфы

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

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

--- Целевой системы ### Нет, описание целевой системы и воплощение целевой системы — это область интересов целевой системы, а эти вопросы как раз обсуждались.

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

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

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

+++ С целевой системой ### Да, ничего из области инженерии целевой системы в перечне имеющегося опыта не упомянуто.

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

Менеджер проекта не спит, и думает о проекте. Какую систему проекта при этом он считает своей?

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

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

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

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

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

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

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

--- Работы целевой системы ### Нет, рассматривалось время создания. Время использования целевой системы не обсуждалось.

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

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

+++ Метод работы создателя ### Да, варианты изготовления — это про выбор варианта метода по его сигнатуре (изготовление::метод и корпус::«предмет метода»): штамповки или 3D печати высокого качества. Без выбора варианта метода нельзя даже будет сказать, что там за роли должны быть в команде инженеров: технологи штамповки или технологи 3D-печати!

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

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

--- Возможность ### Нет, про то, ради чего и почему делается устройство, выгодно ли вообще им заниматься — речь не идёт

--- Внешние проектные роли ### Ни о внешних, ни о внутренних ролях не говорилось.

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

--- Описание системы ### Нет, про описание целевой системы (информационные модели в 3D, расчёты и прочие описания, отражённые в инженерном софте) речь не идёт.

+++ Воплощение системы ### Да, речь про испытания реально изготовленного (то есть уже на полигоне) комплекса — это про воплощение.

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

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

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

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

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

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

--- Внешние проектные роли ### Нет, внешние проектные роли не были помянуты.

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

В ходе проекта обновления программного обеспечения компьютерного зрения в системе автоматической сортировки шкур животных в цеху кожевенной фабрики было определено, что сложные математические способы определения площади не подходят для решения задачи. Было принято решение использовать простой алгоритм умножения количества пикселей в изображении шкурки на коэффициент, определяемый при калибровке системы. Это изменение алгоритма было внесено программистом Виктором в коды системы сортировки шкур 12 мартобря 2018 года, 13 мартобря 2018 новая система была введена в эксплуатацию. О каких основных альфах идет речь?

+++ Воплощение системы ### Да, речь про обновление реально работающего ПО (программного обеспечения) в цеху — это про воплощение.

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

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

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

+++ Создатель ### Да, упомянут программист Виктор.

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

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

+++ Работы создателя ### Да, упомянута работа программиста Виктора.

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

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

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

--- Воплощение системы ### Нет, до воплощения системы в физическом мире дело пока не дошло.

+++ Описание системы ### Да, речь идёт о проектировании (работа над концепцией системы) — это обычно про описание целевой системы перед тем, как начать её воплощать/изготавливать.

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

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

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

--- Описание создателя ### Нет, никакие модели самого создателя не обсуждались.

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

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

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

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

На просьбу инвестора рассказать о проекте бизнесмен подробно рассказал о существующих клиентах, бизнес-модели, денежных потоках и команде проекта. Какие основные альфы и их подальфы совсем не затронул бизнесмен в своём рассказе?

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

+++ Описание системы ### Да, про описание целевой системы (информационные модели, расчёты и прочие описания, отражённые в инженерном софте) речь не зашла.

+++ Метод работы системы ### Да, способ, которым система выполняет свою работу, не обсуждался.

+++ Работы системы ### Да, работы системы не обсуждалось. Не обсуждались никакие альфы области интересов системы.

--- Создатель ### Нет, про команду было рассказано.

+++ Метод разработки ### Да, про инженерный процесс ничего не сказано.

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

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

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

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

+++ области интересов надсистем ### Да, ради возможности («коммерческость» тут весьма условна!) понравиться жениху и была девушкой сделана причёска (осуществлён проект по стрижке и укладке волос). Теперь коммерческая возможность отсутствует, внешняя проектная роль «жених» не может быть переведён в состояние «удовлетворён в использовании», так что и внешняя проектная роль «заказчик причёски» тоже не может быть переведена в состояние «удовлетворена в использовании».

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

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

--- области интересов культуры ### Нет такой зоны интересов в проекте.

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

+++ Возможность ### Да, цена — это про коммерческую возможность выполнения проекта. Если куксователь не готовы купить, то нет возможности выполнить проект.

+++ Внешние проектные роли ### Да, потенциальный заказчик — это внешняя проектная роль.

+++ Воплощение куксователя ### Да, речь идёт именно про реальный куксователь, с которым надо что-то делать — расположить вертикально и калибровать.

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

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

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

--- Описание организации проекта ### Нет, ничего про моделирование организации не говорилось, про оргпроект/оргмодель мы ничего не знаем.

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

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

Альфы — общий объект отслеживания для организации

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

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

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

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

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

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

• Информирование и общение (networking): готовы общаться, но не готовы ничего менять в своих планах и действиях. Если кто-то готов подстроиться под нас, то и хорошо. Но сами работаем, как работаем. Скажем, вывешиваем часы своей работы — но не готовы их менять даже когда кому-то очень надо.

• Координация (coordinated networking): готовы поменять какие-то свои планы и действия. Например, поглядеть на часы работы соседа и прийти в его рабочие часы. Заполнить форму, какую от меня требуют в той системе, в которой требуют, а не написать заявку в произвольном формате и отослать личным письмом.

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

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

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

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

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

Польза от системного и методологического мышления — поднять скорость и точность согласования своих работ в условиях коллективного сложного труда, скооперироваться и сотрудничать в коллективном сложном труде! Для этого агенты договариваются:

• Об инженерном процессе и составляющих его методах (в том числе методах менеджмента, например, метод операционного менеджмента).

• О том, какие роли в инженерном процессе кто из агентов будет играть.

• Какие предметы составляющих методов инженерного процесса будут менять свои состояния (альфы).

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

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

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

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

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

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

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

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

• Учтена (addressed), функции достаточно реализованы воплощением системы так, чтобы это было принято внешними проектными ролями как удовлетворение их потребностей.

• Удовлетворена (fulfilled), на текущий момент потребности внешних проектных ролей удовлетворены.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для какого-то записанного и обсуждённого состояния альф команда выбирает методы работы, планирует работы, выделяет ресурсы — и проводит работы.

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

TEST Роли и их ведущие альфы

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

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

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

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

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

--- Визионер ### Нет, визионер бы просто сказал «такой проект нам невыгоден».

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

--- Операционный менеджер ### Нет, операционный менеджер принимает решения работах, но не технические решения.

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

--- Владелец продукта ### Нет, такая роль вообще тут не участвует. И это очень похоже на должность, а не роль.

--- Визионер ### Нет, визионер бы просто сказал «такой проект нам невыгоден».

Альфа коммерческой возможности ведения проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Альфа коммерческой возможности в ходе проекта проходит следующие состояния (достижение которых можно считать milestones, «контрольными точками» для управления проектами), но их нужно понимать не только как контрольные точки в выпуске только первой версии системы (чаще всего это MPV, minimal viable product, минимальный жизнеспособный продукт), но и инкрементов в улучшениях — каких-то новых фич системы, каких-то модернизаций самой системы, улучшающих её способность удовлетворить потребности, быть аффордансом в нише, которой занимаются внешние проектные роли¹⁵:

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

• Нужно решение (solution needed): установлены потребности; определены проблемы и их причины, имеется концепция использования, целевая система/solution одобряется внешними проектными ролями как нужная, был предложен как минимум один вариант концепции системы, одобряемый внутренними проектными ролями.

• Польза установлена (value established): польза¹⁶ от реализации проекта была определена количественно; влияние решения/solution/целевой системы на внешние проектные роли понятно; польза системы внешними проектными ролями понимается; критерии успешности ясны; результаты ясны и выражены количественно.

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

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

• Извлекается выгода (benefit accrued): проект создания целевой системы принёс выгоду; возврат на инвестиции приемлем.

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

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

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

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

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

Альфа внешних проектных ролей

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

Команда (внутренние проектные роли) представлена отдельной альфой. Термин «stakeholder» имеет два значения:

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

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

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

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

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

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

Вот состояния с контрольными вопросами для определения их достижения для внешних проектных ролей (и помним, что речь может идти или о свежесозданном MVP, или какой-то версии/инкременте системы, или даже об отдельной фиче в составе системы):

• Признаны (recognized): внешние проектные роли выявлены; ключевые из них представлены; ответственности представителей/исполнителей проектных ролей определены.

• Представлены (represented): исполнители внешних проектных ролей согласились с ответственностью; представители каких-то оргзвеньев получили полномочия; подход к сотрудничеству согласован; инженерный процесс поддерживается и уважается.

• Вовлечены (involved): представители/исполнители внешних проектных ролей помогают команде; реагирование представителей на запросы своевременно, и они предлагают решения; изменения сообщаются вовремя.

• В согласии (in agreement): минимальные ожидания/предпочтения согласованы; представители/исполнители внешних проектных ролей довольны своим вовлечением; вклад внешних проектных ролей приносит пользу проекту; приоритеты ясны; перспективы команды и внешних проектных ролей сбалансированы.

• Удовлетворены для разворачивания (satisfied for deployment): имеется отклик/feedback от внешних проектных ролей; система готова для разворачивания в месте её эксплуатации.

• Удовлетворены в использовании (satisfied in use): отклик/feedback по использованию/эксплуатации системы доступен; система отвечает ожиданиям/предпочтениям.

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

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

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

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

Альфа системы

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

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

• В виде модели (as a model): «рабочка» (описание с точностью, достаточной для изготовления) готово для изготовления; BoM (bill of materials, сводно-заказная спецификация) готова для закупок, технология изготовления с инженерами внутренней платформы разработки согласована.

• В виде сырья (as a raw material): материалы для воплощения системы наличествуют и позволяют создать части системы с нужными характеристиками; оборудование для переработки материалов в детали наличествует; график производства и логистики частей системы согласован; возможны работы по изготовлению частей системы.

• В виде частей (as parts): части воплощения системы созданы и/или закуплены и проверены; график интеграции/сборки/монтажа/строительства из частей согласован; возможны работы по интеграции/сборке/монтажу/строительству.

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

• Готово (ready): функциональность испытана; уровни дефектов для внешних проектных ролей приемлемы; установочная и другая пользовательская и операторская документация доступна; представители/исполнители внешних проектных ролей удовлетворены системой; состав/конфигурация передаваемой системы известен; представители/исполнители внешних проектных ролей готовы эксплуатировать систему; эксплуатационная поддержка создателей наличествует; операторы и пользователи наличествуют; системное/рабочее окружение для критических интерфейсов готово.

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

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

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

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

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

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

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

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

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

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

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

• Сотрудничает (collaborating): команда работает как одно сплочённое оргзвено (распределённое лидерство); общение в команде открытое и честное; команда сфокусирована на реализацию стратегии (миссии/задания) команды; члены команды знают друг друга и сотрудничают.

• Производит (performing): команда постоянно выполняет обязательства; команда непрерывно адаптируется к изменяющемуся контексту; команда определяет и решает проблемы без внешней помощи; минимум возвращений к сделанному и переделок; работа команды рациональна и элегантна: работа впустую (waste) и причины для работы впустую постоянно устраняются.

• Распущена (adjourned): стратегия была реализована; обязанности были выполнены; члены команды доступны для участия в других командах.

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

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

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

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

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

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

Альфа описания системы

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

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

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

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

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

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

Описание системы (или её инкремента, фичи, опции) может иметь состояния:

• Замыслено (conceived): внешние проектные роли и команда согласны, что система будет сделана; методы описания системы согласованы; способ согласования частных описаний с внешними проектными ролями согласован; механизмы управления конфигурацией документации согласованы.

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

• Используется для изготовления (in use for manufacturing): изготавливающая систему часть команды считает, что описаний системы хватает для начала изготовления/производства; методы/технологии изготовления по этим описаниям системы сами описаны и документированы; возникающие при изготовлении системы проблемы приводят к доработке и актуализации описаний системы.

• Используется для инженерных обоснований воплощения (in use for assurance): есть все описания, нужные для инженерного обоснования успешности системы (assurance case); испытания/тесты, критерии их успешности и способ проведения определены; внешние проектные роли согласны с объёмом испытаний/тестов.

• Используется для эксплуатации (in use for operations): описание системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); описание системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации/развитии системы.

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

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

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

Оргмодель (или её инкремент для оргизменения) может иметь состояния:

• Замыслена (conceived): служба оргразвития согласна, что организация проекта будет создана; методы моделирования организации проекта согласованы; способ согласования оргмодели с внешними проектными ролями службы оргразвития согласован; механизмы управления конфигурацией оргмодели согласованы.

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

• Используется для лидерства (in use for leadership): служба оргразвития считает, что оргмодели хватает для начала создания организации проекта; методы оргразвития по этой оргмодели сами отмоделированы и документированы; возникающие при организации команды проекта проблемы приводят к доработке и актуализации оргмодели.

• Используется для работы (in use for operations): оргмодель используется для сбора операционной информации о состоянии проекта (цифровой двойник, digital twin); оргмодель наряду с операционной информацией цифрового двойника используется для принятия решений о совершенствовании (непрерывных улучшениях) и развитии.

• Используется для роспуска команды проекта (in use for adjourn): оргмодель используется для определения момента роспуска команды проекта или принятии решения о продолжении работы; демонстрирует отсутствие вредных эффектов (например, выполнение каких-то сервисов, до сих пор нужных для внешних по отношению к команде проекта оргзвеньев предприятия) при роспуске команды проекта; используется для планирования и проведения работ по роспуску или перепрофилированию.

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

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

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

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

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

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

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

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

Альфа метода/способа/культуры работы

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

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

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

• Правила установлены (principles established): команда активно поддерживает дисциплину/теорию/правила/принципы инженерного процесса; внешние проектные роли согласны с принципами; потребные для их поддержки инструменты/оборудование согласованы; рекомендации по выбранному варианту инженерного процесса доступны; рабочий контекст понимается; ограничения методов и выбранных для их выполнения инструментов известны.

• Основа положена (foundation established): ключевые методы работы инженерного процесса и их инструменты выбраны; методы, необходимые для того, чтобы начать работу, согласованы; методы, по которым не будет обсуждений и их инструментарий выявлены; разрыв между доступными и необходимыми оргвозможностями/capability определён; инженерный процесс, в котором все его методы удобно использовать, определён.

• Используется (in use): методы работы и их инструментарий используются; использование методов работы регулярно проверяется; методы адаптированы к обстоятельствам проекта; методы поддерживаются командой; механизмы получения откликов/feedback на методы работы работают; методы работы поддерживаются общением команды, команда сотрудничает в выполнении практик.

• Наличествует (in place): инженерный процесс используется всей командой; оргвозможности доступны всей команде; проверяются и адаптируются всей командой.

• Работает хорошо (working well): альфы проекта предсказуемо продвигаются по состояниям; методы применяются естественным образом без дополнительного обучения; инструменты естественным образом без дополнительной настройки поддерживают инженерный процесс работы; идёт постоянное совершенствование.

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

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

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

Альфа работы (works/operations/эксплуатации/использования) целевой системы

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

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

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

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

• Под контролем (under control): количество результатов работы растёт; незапланированная работа и расход ресурсов под контролем; риски под контролем; оценки производительности пересматриваются, чтобы отражать реальную производительность и расход ресурсов на работу системы; прогресс измеряется; необходимость повторного выполнения работы под контролем; обещания выполнения работ выполняются.

• Закончена (concluded): остались только координационные акты (извещения о завершении работы); результат работ был достигнут; внешние проектные роли приняли результаты работы.

• Закрыта (closed): метрики были сделаны доступными для других проектов; всё было задокументировано (digital twins); бюджет был сверен и закрыт; система была освобождена; нет незавершённых недоделанных работ.

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

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

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

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

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

• Подготовлена (prepared): обязательства приняты; цена и потребные усилия оценены; доступность ресурсов понимается; правила и процедуры контроля ясны; критерии приёмки определены и согласованы; работы разбиты на части в достаточной для начала работ мере; задачи (tasks) определены, приоритеты для них расставляются; наличествует правдоподобный план; финансирование работ наличествует; как минимум, один человек из команды готов начать работу; моменты интеграции результатов работы определены.

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

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

• Закончена (concluded): остались только административные задачи; результат работ был достигнут; внешние проектные роли приняли систему (или её инкремент/фичу).

• Закрыта (closed): метрики были сделаны доступными для других проектов; всё было заархивировано; бюджет был сверен и закрыт; команда была освобождена; нет незавершённых недоделанных задач.

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

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

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

Пример: альфа «культура» для сообществ

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

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

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

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

• Члена сообщества, который получает какой-то опыт/впечатления, проходя своё путешествие в это сообщество, нахождения в сообществе, ухода из сообщества. Это мы обсуждали в нашем руководстве: community member journey и community member experience.

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

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

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

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

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

Какие культуры надо рассматривать, когда мы говорим о сообществах? Чтобы системно описать изменения в ходе создания и развития сообществ, нам потребуется отслеживать альфы минимально в трёх областях интереса:

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

• Самого создаваемого и развиваемого сообщества как целевой системы.

• Отдельных членов сообщества как подсистем целевого сообщества-системы.

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

В каждой из областей интереса мы обычно выделяем четыре основные/kernel альфы как предметы метода, отслеживаемые в ходе проекта: воплощение системы, описание системы, метод работы системы, работы системы. Это означает, что для трёх упомянутых областей интереса мы сходу получаем 12 альф, которые надо бы отслеживать в ходе проекта, причём там сразу намечаются усложнения:

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

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

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

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

1. Культура члена сообщества. Её можно разложить на составляющие, которые можно отслеживать подальфами альфы «культура» в области/зоне/area интересов члена сообщества:

• Культура мышления (превращения проблем в задачи), определяемая общим интеллектом, получаемым образованием (подробней — в руководствах по инженерии личности и интеллект-стеку). Грубо говоря, члену сообщества надо быть образованным человеком или AI-агентом (интернет тем и хорош, что на другом конце мира с тобой может разговаривать не только человек — и это оказывается не так важно). Конечно, стая диких собак в городе — тоже сообщество, но всё-таки мы тут про другие сообщества, и вот сообщество (иногда само сообщество в таких случаях называют «культурой», поэтому повторим, что тип понятия лучше определять не по словам-терминам, а по контексту) дикого племени в амазонском лесу (tribal community) или сообщество физиков, интересующихся квантовой гравитацией (community of practice) всё-таки разные виды сообществ. Про то, как строятся детские сообщества, как они связаны с общим интеллектом и культурой развитой цивилизации, можно почитать в книге «The Lord of The Flies»²¹. Интеллект для участника сообщества лишним не бывает, для участия в людских сообществах нужно иметь минимальную культуру мышления. Впрочем, как показывают сообщества астрологической практики, сообщества арома/арт/танц/театр/чегоугоднотерапии от всех болезней, сообщества заговора причёсок на любовь и деньги, сообщества снятия порчи, сообщества конспирологов и т.д. — интеллект и в современном городе необязателен, сообщество можно найти себе для любой силы интеллекта. Детям сейчас нравится быть квадроберами²² и хоббихорсерами²³, родители оплачивают их увлечения, эти увлечения могут оставаться и во взрослом обществе. Но в любом случае — культура мышления какого-то уровня у члена сообщества должна быть, её надо обсуждать явно.

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

• Профильная культура сообщества. Конечно, тут возможны самые разные градации мастерства, но это ровно тот метод, работа по которому отличает членов одного сообщества от другого: кто-то инвестирует, кто-то покупает продукты, кто-то занимается конкретным видом спорта, кто-то «болеет» за спортивную команду. Дело тут не столько в «знании», во владении мастерством. Можно знать, но ничего не делать. Скажем, степени квалификации МИМ²⁴ предполагают переход от «специалиста», который может поговорить о предмете интереса сообщества организаторов работы к «практику», который что-то там умеет сам сделать, а дальше «мастеру», который будет носителем SoTA мастерства и будет практиковать профильную культуру (в том числе будет её проводником, будет обучать этой культуре), а дальше степень квалификации «реформатор» предполагает уже не просто практикование какой-то культуры, но и развитие культуры, smart mutations для этой культуры, и там можно стать ещё и «революционером», если удастся предложить какой-то крупный эволюционный сдвиг, выйти на новый уровень оптимизации. Грубо говоря, в сообществе композиторов я могу рассуждать о композиторстве (специалист), но сочинять могу не уметь. Могу иногда что-то такое сочинить на совсем любительском уровне (практик). Но могу практиковать образ жизни композитора, иметь композиторское мастерство, показывать образец того, что означает быть композитором — активно сочинять! Реформатор — это тот, кто развивает предмет, продвигает нестандартные методы композиции, содержательно продвигает культуру, устанавливает планку для мастерства композиции. Но «революционер» — это когда устанавливается новый уровень планки для мастерства композиции, скажем, Арнольд Шёнберг был революционером, он предложил новый метод музыкальной композиции, додекафонию²⁵. В сообществах, где надо просто жить вместе и не драться, профильная культура — это «культура общежития». В сообществах финансовой взаимопомощи — культура давать и брать деньги. В сообществе плоской Земли надо обычно просто хорошо разбираться в вопросе и популяризовать имеющиеся идеи, но неплохо бы и развивать теорию (скажем, вносить и развивать идеи вогнутой Земли, даже жизни внутри Земли²⁶), выходить на уровень квалификации реформатора. Во всех сообществах В мастерской инженеров-менеджеров слово «мастер» используется и как «агент с какой-то степенью мастерства в каком-то методе работы», и как «агент, у которого вполне определённая по заранее установленной шкале²⁷ степень мастерства в методах оргразвития», то есть «мастер оргразвития». Часто не обсуждают культуру/метод, а обсуждают «мастерство выполнения метода» у членов сообщества. Так что внимательно смотрим за контекстом, а омонимия для «мастера» («мастер своего дела» и «мастер оргразвития» как минимум) в наших руководствах указана. В сообществах обращают особое внимание на уровень владения мастерством какой-то культуры, социальный статус членов сообщества в сообществе во многом определяется именно мастерством выполнения работ по профильной культуре сообщества: член кружка вышивания крестиком оценивается по тому, как качественно и быстро он вышивает, танцор — по качеству его танцевания.

• Культура сотрудничества/collaboration и собственно «духа сообщества». В сообществах регулярно затеваются какие-то проекты. Для этого появляются наложенные/overlay (состоящие из членов сообщества) организации, в которых будет задействовано разделение ролей в достижении общих целей — участникам сообщества надо будет вписываться в какие-то проектные команды. Быть членом команды, имея достаточно собранности для удерживания роли — вот это оно и есть «культура сотрудничества». Давать обещания, выполнять обещания вовремя, удерживать ответственность не только за результат своего кусочка работы, но и за результат проекта в целом. Когда говорим о том, что каждый отдельный член сообщества занимается профильной культурой (например, покупает мотоциклы Харлей Дэвидсон и разъезжает на них, или печатает на 3D-принтере в maker community, или просто «является членом общежития» в какой-то коммуне), ему надо собственные дела как-то увязывать с делами остальных членов сообщества. Так, в сообществах практики надо помогать друг другу в обсуждении трудных проблем, в социальных танцах надо формировать пары и соблюдать правила поведения на вечеринках. В онлайн-сообществах надо совместно бороться со спамом, либо поощрять разговор матом («контркультура» — это тоже культура!), либо наоборот — не поощрять, соблюдать какие-то этические стандарты в своём поведении. В добровольческих (филантропия и меценатство, но не деньгами, а работой) проектах понимать, что «бесплатного обеда не бывает» и вся «бесплатность» мнимая, отслеживать поэтому траты своего времени на добровольную работу и ценить трату времени других членов — понимая, что там может и должно быть сделано бесплатно, а что кто-то должен оплатить. В организациях тут сразу идёт речь о «корпоративной культуре», которая главным образом и понимается как «культура сотрудничества» (хотя в широком смысле слова она включает не только методы, которыми достигается сотрудничество членов организации, но и все остальные методы работы — в том числе стили/методы/культуры инженерии, менеджмента, маркетинга и т.д.). В корпоративной (корпорация — сообщество сотрудников, на котором существует наложенная организация с понятными полномочиями по распоряжению ресурсами) культуре тоже довольно много обсуждается метод достижения приемлемой степени сотрудничества (например, core protocols²⁸). Когда обсуждают тематику сообществ в её «социальности», именно эта культура сотрудничества становится центральной: «своих не выдаём», «один за всех и все за одного» и прочие коммунистические слоганы, идеи колхоза и всяческих коммун именно тут, причём эти идеи борются с идеями рациональной организации какого-то труда. Собиратели марок, спортивные клубы, «кровавый энтерпрайз» разработки софта в крупных организациях, мафиозные организации — все они различаются способом, каким налаживают культуру сотрудничества, хотя не все эти сообщества можно назвать полноценными «организациями».

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

2. Культура создателя/менеджера/организатора/орга/builder/developer сообщества. Она может быть разложена на несколько составляющих её культур, которые можно отслеживать подальфами альфы «культура» в области интересов менеджера сообщества:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Культуры менеджера (организации или сообщества, тут не так важно) — роли орга/менеджера:

• менеджмент (и мы не разделяем тут менеджмент организаций и сообществ — всё это менеджмент, организационный или сообществ).

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

За чем следить в проекте

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

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

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

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

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

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

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

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

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

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

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

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

• «Совещание»::альфа

• «Помещение для совещания»::альфа — подальфа для «Совещания»::альфа (тип подальфы — тоже альфа!)

• «Тишина в комнате совещаний установлена»::«контрольный вопрос» альфы «Помещение для совещания»

• ««Тишина в комнате совещаний установлена» «к началу совещания (ожидается в 16 часов)»»::контрольная точка (сделана из контрольного вопроса составляющей состояния альфы и ожидаемого времени достижения)

• «Внешний шум отсечён»::«контрольный вопрос» второго уровня для «тишина в комнате совещаний установлена»::«контрольный вопрос»

• ««Внешний шум отсечён» «к началу совещания (ожидается в 16 часов)»»::контрольная точка (сделана из контрольного вопроса составляющей второго уровня контрольного вопроса к состоянию альфы и ожидаемого времени достижения)

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

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

• «Мобильники участников переведены в режим «без звука»»::«контрольный вопрос к альфе «тишина в комнате установлена»

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

• Закрытие двери заносится в issue tracker и назначается на секретаря совещания (и дальше выполнение этой работы проверяется «как обычно» — эта работа и факт её выполнения не потеряется, она тоже оказывается записанной).

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

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

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

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

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

При этом менеджер справедливо считает, что 200-300 работ на контроле — это очень много. Но у инженеров даже в небольшой команде за несколько месяцев разработки легко набегает 2-3 тысячи issues (проблемных вопросов), которые нужно отслеживать и как-то коллективно закрывать. Программисты и инженеры с этим справляются, а вот менеджеры теряются. Как решить эту проблему «чеклистов для огромного количества работ»? Нужно понимать, кто такие «менеджеры» по их ролям и зачем им нужно знать все работы.

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

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

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

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

• Всё записываем. Работаем с большими моделями, на мозг и устные договорённости не рассчитываем.

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

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

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

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

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

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

1.1. Альфа «команда» (ещё есть альфы описания команды, метода работы команды, работы команды, но вполне могут быть и другие альфы)

1.1.3. Состояние альфы «Сотрудничает» (это третье состояние в ряду «намечена, сформирована, сотрудничает, производит, распущена», поэтому сразу 1.1.3),

1.1.3.2. Контрольный вопрос про «общение в команде открытое и честное» (он второй в списке).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Состояния альфы и артефакты/рабочие продукты

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

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

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

Документирование по сравнению с чисто устной работой «с голоса» имеет:

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

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

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

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

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

Вот пример описания контрольных вопросов по достижению состояния «признаны» альфы «внешние проектные роли»:

Состояние «Внешние проектные роли признаны»

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

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

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

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

Рабочие продукты, свидетельствующие состояния альф (включая подальфы) проекта, можно делать проще или сложнее: инженерный процесс может быть самым разным по сложности, но он должен быть достаточным для снижения риска утери внимания за важным в проекте, опять-таки читайте книжку «Checklist manifesto» Atul Gawande.

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

Как работают с моделью графа создателей в форме чеклиста

Когда говорим о моделировании графа создателей, то имеем в виду прежде всего не диаграммное представление в разных «рисовалках» вроде MS Visio, Figma или даже yEd (мы готовили иллюстрации текущего раздела как раз с использованием «рисовалки для графов» yEd), не диаграммное представление в моделерах каких-то бизнес-процессов типа Business Studio или ArchiMate (они поддерживают строгую типизацию элементов диаграммы), а представление в разного сорта текстовых (аутлайны, но не представление аутлайна в виде MindMaps) и табличных моделерах. Современный операционный софт обычно ровно такой: он представляет богатые возможности редактирования длинных списков, представленных таблицами.

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

Самое простое использование модели графа создателей — это структурирование отчёта о ходе проекта (progress report). Нужно просто дать краткую содержательную характеристику состояния избранных вами альф избранных вами областей интереса в графе создателей. Progress report нужен для того, чтобы вся команда (и в порядке надзора/governance — её создатели) коллективно представляли, в каком состоянии каждая альфа, какие есть инженерные проблемы и что с ними можно сделать, какие риски несоблюдения сроков и бюджета есть в проекте.

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

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

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

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

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

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

• использовать компьютерную память для моделирования графа создателей в виде шаблонов чеклистов

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

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

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

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

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

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

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

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

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

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

Подальфы

Подальфы и их состояния порождаются командой по потребности, когда команда понимает, что внимания к ситуации на уровне альф не хватает, и нужно внимание к дополнительным объектам, от которых зависит продвижение альф по их состояниям. Подальфа так и определяется — это альфа, связанная с другой альфой отношением «если состояние подальфы продвигается, то и состояние её надальфы продвигается». Более того, у каждой альфы (в том числе у подальф, у которых тот же тип «альфа») могут быть свои подальфы, а одна подальфа может быть подальфой нескольких альф и подальф. Примеры этих подальф можно брать в самом стандарте OMG Essence, можно брать в разнообразной литературе. Прежде всего тут нужно указать на разработки Ivar Jacobson International, они предложили наборы альф с их состояниями и контрольные вопросы этих состояний для самых разных практик, особенно для гибких методологий⁴¹.

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

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

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

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

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

• Признан — обоснование аутсорсинга есть; концепция использования для подсистемы есть; ожидания к гарантийному обслуживанию и ремонтным работам есть; понимание по технологиям работы есть; сроки поставки определены; критерии приёмки результата есть; оценка возможной цены есть.

• Выбран — технико-коммерческие предложения получены; переговоры с кандидатами проведены; технико-коммерческие предложения оценены; подрядчик нами выбран.

• Привлечён — валютные, сроков поставки, качества и прочие риски оценены; договор с учтёнными рисками подписан; аванс перечислен; необходимая документация для начала работ передана; уведомление о начале работ получено; процедура коммуникации команды с исполнителями установлена.

• Работы идут — надзор за работами установлен; запросы обеих сторон учитываются; запросы обеих сторон своевременно решаются; график работ соблюдается; технология работ соответствует ожидаемой; коммуникация команды с исполнителем не прерывается.

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

• Работы закрыты — акт приёмки-сдачи подписан; деньги перечислены; никаких дел к подрядчику нет; гарантийные и сервисные работы производятся; документация архивирована.

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

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

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

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

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

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

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

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

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

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

Цифровая нить (digital thread) — это инструменты и метод федерирования-унификации-интеграции данных, обычно на основе так называемых семантических моделей данных (semantic data models), которых довольно много в инженерии, связывающая между собой все эти отдельные модели, а также цифровые двойники окружения и физического двойника. «Железный» инженер (машиностроитель или строитель) старой закалки скажет «интеграция данных жизненного цикла» и помянет множество PLM (а если это не машиностроение, а корпоративный софт, то может помянуть и «корпоративную шину данных»), менеджер новой закалки скажет «цифровая нить» и помянет PLM, ERP, EAM и даже CRM (и ещё довольно много «трёхбуквенных сокращений»⁴³). И, поскольку «цифровой — это новый информационный», то заметят, что для какого-нибудь здания или моста кроме BIM (building information model) цифровая нить добавит к цифровому двойнику данные дронов, сенсоры интернета вещей и какой-нибудь «искусственный интеллект» обнаружения аномалий для ремонта по состоянию. Инженеры старой закалки продолжают говорить «управление информацией» или «управление данными», их язык «цифровой нити» не увлекает, хотя менеджерам эта метафора очень нравится.

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

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

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

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

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

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

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

TEST Адаптация модели графа создателей

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

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

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

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

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

На вопрос «Как дела?» команда проекта рассказала, что они уже трижды достигали состояния «Готово» для альфы «Воплощение целевой системы», но потом откатывались к состоянию «Демонстрируема». Как это возможно?

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

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

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

Команда проекта договорилась, что, вместо отслеживания для альфы «Работа» состояний «Инициирована», «Подготовлена», «Начата», «Под контролем», «Закончена», она будет использовать другой набор, более привычный для менеджера проекта (он ссылается на стандарт проектного управления, в котором используются другие названия, и менеджер проекта собирается использовать этот стандарт, а не идеи из стандарта OMG Essence). Можно ли так делать?

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

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

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

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

На совещании команды развития и проекта оценили состояние команды проекта как уже «Сформирована», но ещё не «Сотрудничает». Что им нужно сделать, чтобы перейти в новое состояние?

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

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

Если подальфа продвинулась по её состояниям, или даже откатилась назад, что, скорее всего, произошло с её (над)альфой?

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

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

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

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