2. Создание и развитие: не жизненный, не цикл

Биологический жизненный цикл, нулевая версия

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

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

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

В инженерии/деятельности/практике как создании систем самого разного масштаба всё не так (если игнорировать время эволюции/развития систем как вида):

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

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

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

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

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

Жизненный цикл системы 1.0: работы, меняющие состояния целевой системы

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

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

Назовём это понимание «жизненным циклом v1.0»², оно разрабатывалось где-то в 70-х годах прошлого века, и не только в системной инженерии, но и в менеджменте, который в те времена считался более-менее «психологической» особой дисциплиной, а не просто изводом системной инженерии для организационных систем. В системном подходе уже тогда признавали непосредственно выходящими из него не только системную инженерию, но и operations research/исследование операций³ — исследование работ/operations с целью принятия лучших решений по ускорению их прохождения. Исследование операций скоро перестало быть «аналитикой», то есть только исследованиями, и в его синтетической/управленческой ипостаси стало operations management (операционное управление, акцент не только на понимании и отчётах, но и на действиях на основе этих исследований — собственно управлении, изменении ситуации в части ускорения прохождения потока работ через производящие эти работы ресурсы).

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

Одна из самых популярных книжек по проектному управлению, вышедшая первым изданием ещё в июне 1979 года, это Harold Kerzner «Project Management: A Systems Approach to Planning, Scheduling, and Controlling». То есть управление проектами в момент его появления было применением системного подхода к планированию, построению графика работ и контролю выполнения работ. Это похоже на то, как понималась в те времена и классическая «железная» системная инженерия: применение системного подхода к инженерной работе.

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

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

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

Так что работа — это Анастасия забивает гвозди молотком в доски 16 мартобря 2028. Забивание гвоздей 16 мартобря — это и есть работа, которую она выполняет, а Анастасия, молоток, гвозди, доски — это всё ресурсы, которые должны провзаимодействовать в момент работы и поэтому должны наличествовать. Нет ресурсов — нет работы. Так что управление работами (work/operations management, операционное управление) сводится к тому, чтобы оптимально распорядиться ресурсами: выполнить максимальное количество работ с минимальными ресурсами. Как? Например, вы можете пригласить Анастасию забивать гвозди на один день — 16 мартобря 2028, заплатить за один день. А можете пригласить на месяц и договориться платить зарплату месяц, а задействовать только один день — 16 мартобря 2028. Можете закупить гвозди и доски за два года до планируемой работы, а можете закупить так, что они прибудут сразу 16 мартобря 2028 и даже не успеют попасть на склад, а будут выданы сразу «в монтаж» Анастасии. Операционное управление, цепочки поставок (supply chains), логистика, исследование операций — всё это методы максимизирования прохода/throughput работ и предметов метода по какому-то графу создателей за счёт снятия логистических (ресурсных, в том числе транспортных, то есть наличия ресурсов для работ вовремя) ограничений.

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

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

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

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

Если у вас сдельщина по результату работ — будет мало работы, много результатов. Если сдельщина по самой работе, то будет много работы, а результатов работы — мало, значительная часть работ будет бесполезной.

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

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

Операционный менеджмент и методология.

В общей теории систем фон Берталанфи предложил operations research как науку, изучающую работы/operations в части их производительности/скорости. Проход как раз замеряется в единицах скорости, первой производной чего-то по времени. Проход — это первая производная объёма выходной продукции по времени — штуки для дискретной продукции или объёмы для непрерывного производства (химическая промышленность) в малую единицу времени, dx/dt. Единица времени должна быть малой, чтобы это было настоящей производной. Если единица времени большая, то менеджмент, по большому счёту, невозможен. Если вы хотите выпустить 500 штук продукции в год — то сколько надо производить в день? Весь год ничего и брать кредиты, а потом в последний день 500 штук? Или каждый день по паре штук — и иметь даже запас на случай сбоев (хотя что там про выходные дни, сколько их будет)? Если равномерный выпуск и оплата, тогда и кредиты брать не надо. Замеры должны быть точными, это означает, что дискретизация замера прохода должна быть поменьше, вы должны знать «ускоряемся» или «тормозим» не раз в год.

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

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

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

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

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

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

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

Поясним это чуть подробней — но по-настоящему подробные наставления будут в руководстве по системному менеджменту. У операционного менеджера главный интерес — сделать рывок, то есть увеличить ускорение прохода (а проход — это скорость выпуска). Он должен постоянно (так и говорят: процесс непрерывных улучшений, POOGI, process of On-Going Improvement) поднимать throughput/«проход» как скорость выпуска целевой системы, замеряемую на выходе предприятия (включая склады, ибо непроданные системы нам не нужны, за них не будет заплачено). В одну сторону (от поставщиков сырья или исходной информации) текут потоки вещества, информации, работ и вытекают из фирмы к клиентам, а в другую встречным потоком текут деньги, из которых происходит оплата за каждый ресурс, проводящий обработку потока.

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

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

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

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

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

3. Дальше устраняем wait time, время пауз в работе. Устранение пауз в работе делается методами операционного менеджмента. Паузы в работе могут быть больше или меньше просто от того, что вы начинаете или пять работ в параллель и делаете их «вперемешку», или делаете все эти работы последовательно (мультитаскинг), запускаете работу «в последний момент» (поздний старт) или «как только будут наличествовать ресурсы» (ранний старт). Операционный менеджер минимизирует время пауз в работе путём рационального планирования. Терминология (например, «время ожидания», wait time) тут отличается от терминологии разговора об элегантности и разговора об управлении конфигурацией, ибо отличается набор понятий. Мы дальше берём терминологию метода операционного менеджмента TameFlow⁵, которая по большому счёту и отражает SoTA в операционном менеджменте, ибо кроме управления промышленным производством (manufacturing) имеет дело с управлением разработкой — это недавнее введение в операционном менеджменте. В этом третьем шаге речь идёт о собственно работе операционного менеджмента, а не о методологической работе, не инженерной работе. Без предыдущих двух пунктов методологической работы в «распожаризации» использование TameFlow или любых других видов метода операционного менеджмента будет вредным! Вы резко ускорите беспорядок! Будет не просто хаос и пожары на работе, а крайне быстрый, ускоренный хорошим операционным менеджментом хаос и пожары! Операционные менеджеры вредны, если они хорошо делают свою работу без предварительной работы инженеров целевой системы и инженеров предприятия, занимающихся методологией разработки. «Устранение времени пауз», предотвращение «пробок» в работе, поддержание стабильного скоростного потока — это и есть операционный менеджмент, работа с работами, а не методами работ. Логически это только третий шаг! Если вы занялись организационными реформами, то начинать надо с методологической работы, это уже даст резкое ускорение. И только потом можно говорить об ускорении работ за счёт собственно практик операционного менеджмента.

4. После того, как вы добились успеха в устранении времени пауз (там очень, очень много нюансов, для их понимания нужно читать специализированные учебники операционного менеджмента, в руководстве по системному менеджменту будет рассказано, какие учебники надо читать, и там не только литература по TameFlow), вам нужно опять обратиться к методологии: заняться уменьшением времени обработки рабочих продуктов на определённых операциях (touch time), которые будут вам даны по итогам предыдущего шага. Для этого вы должны выбрать новые методы работы, которые дадут вам сокращение времени обработки. Например, автоматизировать какие-то операции. Важно, что не нужно сокращать время любых производственных операций, а только находящихся на критических местах в потоке работ — вся арифметика для нахождения этих мест вами будет выполнена на предыдущих шагах. И это опять будет инженерная задача, которая потребует методологических (по изменению метода работы) решений по существу инженерного вопроса, а не чисто менеджерская задача по распределению работ по ресурсам и учёту выполнения этих работ. Именно тут требуется продемонстрировать, почему вы вдруг занялись новыми методами работы вот прямо сейчас: как это отразится на проходе/throughput? Если никак, то вы занимаетесь не той методологической работой!

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

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

За забивку гвоздей у нас ответственна Анастасия в должности «плотник» (не путать с оргролью «плотник»), и обычно она забивает 180 гвоздей за час. Обсуждаемая работа начинается в полдень 3 мартобря 2029 года, и планируемая её продолжительность — десять минут. За это время Анастасия как оргзвено «плотник» должна забить 20 гвоздей в четыре места на досках.

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

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

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

Жизненный цикл 1.0 — это работы создателей над создаваемой системой

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

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

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

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

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

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

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

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

Обратите внимание, что по факту «жизненный цикл системы X» ничего не говорит о самой целевой системе X и её состояниях. Он говорит про то, что делают системы создания X: работают-то они, а не целевая система. Целевая система пассивна, это предмет работ, в современном операционном менеджменте работы над каким-то изменяемым предметом работ называют case/дело (от «судебного дела», медицинской «болезни», case file — это папка «Дело №__» или в медицине папка «истории болезни», то есть описание работ дела/случая/ситуации/болезни). Запоминаем: кейс — это работы, только для этих работ не всегда известен план, а в самом начале этих работ часто известна сигнатура («вылечить больного», «раскрыть дело, наказать преступника»), но неизвестно ещё разложение метода, поэтому и планирование этих работ up front (перед проведением работ) невозможно, оно проводится после каждого шага работ. Судебные дела, лечения, исследования, отладка/troubleshooting/debug, проектирование — всё, что требует высказывания и проверки гипотез — ведётся «непрерывно открывающимися обстоятельствами», для планирования каждого шага работ используется свежеполученная от предыдущих шагов работы информация.

В кейсе/деле забивания гвоздей целевая система (в момент эксплуатации!) — это забитый гвоздь. Кейсом будут все работы для этого, а сам кейс::работа будет назван по его предмету — «гвоздь» (предмет этих работ, который нужно привести в конечное состояние «забит». Если предмет работ не гвозди, работы — «забивание гвоздей», а доски с работами по скреплению досок заранее непонятным методом, то кейс будет «доски», приводимые в состояние «скреплены»). Описывает вариант с заранее непонятным планом работ вид «операционного менеджмента»::метод, известный как case management. «Case management»::метод, в свою очередь, род для разных его видов, например adaptive/dynamic/advanced case management⁷, который в последнее время перестал быть в силу общей распространённости отдельным компактно излагаемым вариантом метода case management со специальным софтом его поддержки. Само операционное управление теперь связывается с case management — вплоть до того, что классическое проектное управление с up front планированием считается частным случаем кейс менеджмента (ибо редко бывает, что состав работ заранее известен и возможно составить качественный план), а управление работами по этому методу называется «проектное управление». Поддержка со стороны программного обеспечения перешла от специализированных систем проектного управления в системы с облегчённым программированием, универсальные моделеры, LowCode⁸. Так что сегодня «проектом» называют то, что ещё вчера было более-менее крупным кейсом (работы, названные по имени предмета кейса, предмета работ — то, что надо привести в какое-то конечное состояние). Значение слова «проект» окончательно оторвалось от классического «проектного управления».

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

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

Методология использует системное мышление и смотрит на оргзвенья/предприятия/команды/коллективы/организации::создатели точно так же, как смотрит на любые другие системы:

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

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

• Они занимают место в пространстве-времени.

• У них тоже есть полная стоимость владения.

• … и на них можно ещё смотреть очень по-разному, в зависимости от проекта.

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

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

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

Итак, Анастасия, предоставляющая сервис забивки гвоздей, берёт свой молоток и забивает выданный ей гвоздь №143 в доску #26, то есть выполняет работу. Жизненный цикл гвоздя в представлениях прошлого века (первое поколение, 1.0) состоит уже не из состояний гвоздя («лежит в коробке», «взят в руки», «нацелен», «забивается», «забит»), а происходящих с ним работ, которые, конечно, можно описывать и как конечные состояния гвоздя, но всё-таки это работы систем создания, сам гвоздь при этом ничего не делает, он пассивен. В не жизненном не цикле принят аналог «аристотелевской физики», где палец давит на стол, а стол не давит на палец. Работают создатели, а гвоздь в ответ не работает, он пассивный объект для систем создания, он просто меняет состояния по мере выполнения с ним работ, «претерпевает изменения».

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

• Обнаружение потребности в гвоздевом соединении. «Гвоздь запланирован» — но Так пишут реже, ведь это указание на работу, а не на гвоздь! Состояние «гвоздь запланирован» тут указывает на результат выполнения инженерами сервиса по формированию сводно-заказной спецификации, которая попала в службу закупок. Писать «гвоздь запланирован», упоминая смену состояния гвоздя как объекта кейса правильней, потому как легче проконтролировать результат работы, но так при документировании жизненного цикла в первом поколении представлений об этом цикле писали редко. Хотя именно так принято описывать основной результат работы в качестве имени работы в методологии управления проектами PRINCE2¹¹, это хорошая практика именования. Помним, что «большой кейс называют проектом», а уж связь кейс-менеджмента и проектного менеджмента будет рассказана подробней в руководстве по системному менеджменту. И обратите внимание: тут объект — не гвоздь, а соединение (гвоздевое соединение — надсистема, в состав которой входит и гвоздь, и те объекты, которые он соединяет).

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

• Выдача в монтаж. «Гвоздь доступен в месте забивки» — указание на работу по выдаче гвоздя в монтаж. Дальше мы просто не будем писать эти разъяснения, идея тут понятна).

• Нацеливание гвоздя. «Гвоздь нацелен».

• Вколачивание гвоздя. «Гвоздь вбит».

• Проверка крепости соединения. «Гвоздь держит крепко», но объект поменялся. Теперь это «соединение». Куколка стала бабочкой! Другой объект, по-другому называем. Но можно и «проверка удержания гвоздём».

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

• Вытаскивание гвоздя. «Гвоздь вытащен».

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

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

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

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

Моделирование: предметы кейса, их состояния, практики достижения состояний

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

Управление последовательностью работ

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

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

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

Конечно, чтобы работы были выполнены, надо ещё создать организационную возможность (capability):

• У оргзвена есть мастерство выполнения метода и все необходимые инструменты и материалы.

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

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

Конечно, в организационном контексте не так часто говорят слово «метод», но используют самые разные другие синонимы. Часто, например, говорят «практики» (practice), не менее часто используют и понятие «рабочие процессы» и даже кривой термин «бизнес-процессы» (в западных стандартах по IT рекомендуют business process менять на organizational или organization process в зависимости от того, что принято, на русском это «оргпроцессы» или «административные процессы»). Давайте предыдущий абзац про создание оргвозможностей повторим, заменив «метод» на синоним — «рабочий процесс».

«Конечно, чтобы работы были выполнены, надо ещё создать организационную возможность (capability):

• У оргзвена есть мастерство выполнения рабочего процесса и все необходимые инструменты и материалы.

• У оргзвена есть полномочия выполнять работы рабочего процесса (то есть выполнять оргроль).

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

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

Обсуждение оргзвеньев идёт как конструктивов:

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

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

• Как сделать так, чтобы сотрудничали: чтобы оргзвенья выполняли работы, а не артачились, задача лидера.

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

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

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

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

В подходе к описанию предприятий DEMO¹² (подробней будет в руководстве по системному менеджменту) каждая работа проходит следующий цикл взаимодействия оргзвеньев:

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

• Работа принята к исполнению оргзвеном-исполнителем, это тоже координационный акт.

• Работа выполняется оргзвеном-исполнителем. Это производственный акт (production act), реальное выполнение работы. Именно это учитывается в жизненном цикле целевой системы, над которой выполняется работа. В жизненном цикле обсуждаются только производственные акты, а не координационные акты! Учёт координационных актов и требуемых на них трат ресурсов и задержек времени на «согласование» и «выдачу поручения» (иногда нужно год интенсивно работать, чтобы получить разрешение на пятиминутную реальную работу) ещё ждёт адекватного отражения в методологии. Пока же это рассматривается в дисциплине рациональности как «рациональное принятие решений» на базе теории принятия решений¹³.

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

• Результаты работы приняты оргзвеном-инициатором работы, координационный акт.

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

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

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

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

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

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

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

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

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

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

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

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

Целевая система осталась только как «объект проекта», объект для группы работ, объединённых понятием «жизненный цикл объекта проекта»: указание того, над чем идут эти работы жизненного цикла. Иногда вместо проекта появлялись и более мелкие деления работы — кейс/case (из управления кейсами: аналог проектного управления, не требующий up front планирования, позволяющий планировать «на лету») или управления задачами/task (как правило, это то же самое, что управление кейсами, разница в нюансах).

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

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

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

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

Итак, жизненный цикл создаваемой системы в версии 1.0 означает просто последовательность работ, которые производят создатели этой системы.

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

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

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

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

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

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

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

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

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

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

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

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

• посетитель/зритель, любитель/отслеживающий, зашедший на вебсайт,

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

• lead — возможный клиент, можно передавать от службы маркетинга как сервис-провайдеру «ловли и уговоров» потенциального клиента службе продаж как сервис-провайдеру продажи. Служба продажи работает с

• prospect, потенциальный клиент — и доводит его до состояния платежа,

• customer — «платящий клиент». Далее воронка расширяется, ибо мы от одной продажи переходим для одного клиента ко множеству продаж: это будет

• «возвращающийся клиент» (repeating customer) и в конечном итоге

• «пропагандист торговой марки» (brand advocate).

Как можно было бы именовать стадии наших «колбасок»? По-разному:

• По названию предмета обработки в конце такта/фазы/стади обработки или по состоянию на начало такта/фазы/стадии. В примере воронки цифрового маркетинга мы видим картинку ровно такую.

• По названию характеристики предмета работ, которую мы хотим получить на выходе обработки. В примере воронки цифрового маркетинга мы это видим «на полях» — это awareness, consideration, conversion, loyalty, advocacy.

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

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

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

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

Но тут же мы забываем новый язык с термином «путешествия» и возвращаемся к привычному «циклу» покупки¹⁹:

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

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

Жизненный цикл проекта

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

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

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

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

Особо нужно отметить о времени жизненного цикла в его 1.0 понимании:

• Понятие жизненного цикла — всегда полные работы на всём протяжении от замысла до ликвидирования системы (это влияние системного мышления)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TEST Жизненный цикл 1.0

Какой список содержит стадии типичного жизненного цикла (без учёта развития)?

--- Итерация 1, итерация 2, итерация 3, ... итерация N, релиз ### Нет, это просто перечисление каких-то итераций (периодов времени, когда выполняются работы по различным методам).

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

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

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

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

Петя собирается поехать на тренинг из СПб в Москву на поезде. Он решает, что надёжнее будет положить билеты и паспорт в портмоне, а портмоне убрать в сумку. Однако в метро у него вытаскивают портмоне с документами, о чем Петя пока не знает. В какой стадии ЖЦ находится система хранения документов?

--- Диспозиции ### Нет такой стадии

--- Дислокации ### Нет такой стадии

+++ Использования ### Да, система хранения «портмоне в сумке» находится на стадии эксплуатации, хотя что-то уже пошло не так.

--- Находится между стадиями ### Нет, между стадиями обычно ничего не находится.

--- Испытаний ### Испытаний (часть инженерного обоснования) не было, сразу эксплуатация/использование.

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

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

Ольга делает ящик для кошки из органических материалов. Для этого она закупила дощечки из настоящего дерева, гвозди, молоток и мешок наполнителя. Домашние просят её показать ящик. Что она покажет?

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

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

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

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

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

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

+++ Самолёту МиГ-48 на стадии эксплуатации ### Да, проектные роли генералов имеют предметом интереса боевые характеристики самолёта.

--- Самолёту МиГ-48 в ходе его разработки ### Нет, проектные роли генералов не озабочены особенностями проектирования и производства самолёта, предмет их интереса — боевые качества самолёта на стадии эксплуатации.

--- Самолёту МиГ-48 на протяжении всего его жизненного цикла ### Нет, генералов не волнуют особенности производства, для принятия решения о заказе их волнуют характеристики самолёта на стадии эксплуатации.

--- Системам создания самолёта МиГ-48 на стадии эксплуатации ### Нет, генералов интересует самолёт в бою, а не службы его техобслуживания и ремонта.

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

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

--- Самолёте МиГ-48 на стадии эксплуатации ### Нет, семью сам самолёт не волнует.

--- Самолёт МиГ-48 на стадии выпуска ### Нет, семью сам самолёт не волнует.

--- Самолёт МиГ-48 на протяжении всего его жизненного цикла ### Нет, семью сам самолёт не волнует.

--- Системе создания самолёта МиГ-48 на стадии его эксплуатации. ### Нет, семью это не слишком волнует: эксплуатация самолёта ведётся не на принадлежащем семье авиазаводе.

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

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

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

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

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

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

--- Об описании звездолёта ### Нет, карта не территория, описание (и даже документация) звездолёта — не сам звездолёт.

Упоминание сепулькария как системы в каком-то проекте должно по умолчанию пониматься как относящееся к какой из стадий его жизненного цикла?

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

--- проектирование ### Нет, это не так. Сепулькария ещё нет в материальном мире, а системы представляются в момент их использования.

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

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

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

--- обслуживание и ремонт ### Нет, это не так. В этот момент сепулькарий не рассматривается как функционирующий в окружении.

--- модернизация ### Нет, это не так. В этот момент сепулькарий не рассматривается, как функционирующий.

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

Петя собирается в гипермаркет «Лента» за продуктами на неделю. Петя пользуется типовым алгоритмом при своих закупках: «Анализ содержимого холодильника» - «Анализ потребностей на неделю» - «Определение бюджета покупки» - «Составление списка продуктов» - «Закупка» - «Оптимизация списка закупок». Обычно Петя закупает продукты, хранит продукты в холодильнике, выкидывает просроченные покупки, и старается есть только качественные продукты. Алгоритм Пети является:

+++ Жизненным циклом проекта закупки продуктов питания ### Да, это он, перечисляются работы Пети с продуктами его питания, ограниченные временем закупки (ЖЦ проекта на неделю против ЖЦ системы, то есть создания и поддержания/развития набора продуктов на неопределённое время, «в цикле», «программа питания»).

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

--- Циклом повышения качества Шухарта-Деминга ### Нет, это не цикл Шухарта-Деминга (планируй-делай-изучай-корректируй).

--- Ничем из вышеперечисленного ### Нет, правильный ответ есть: это жизненный цикл проекта.

Проблемы с жизненным циклом 1.0

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

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

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

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

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

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

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

Вот типичная картинка объяснения перехода к параллельной/concurrent инженерии (и на ней хорошо видно, что сроки всех работ по созданию системы при этом существенно сокращаются)²⁴:

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

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

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

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

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

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

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

Это принятие решений по методам/способам верхнеуровневой росписи методов по работам (например, проектирование как метод работы будет только одной работой где-то ближе к началу проекта, или же оно будет длиться всё время проекта понемножку, даже и ближе к концу проекта тоже) стали называть управлением жизненным циклом (life cycle management, ср. work management/управление работами, а типовые решения на эту тему — моделями жизненного цикла (слово «модель» тут надо понимать в значении «образец для повторения»).

В управлении работами (операционном менеджменте) нет решений по методам работ создания и развития системы: не идёт речь о содержании работ, их технологии, то есть о методах/практиках/«видах инженерии», но только о длительности работ и потребных ресурсах безотносительно к «способу выполнения работ»/«way of working»/методу.

Одной из самых известных гибридных для управления жизненным циклом и управления работами диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP)²⁵, она представляет собой спектр разложения интенсивности работ по шкале методов создания системы, при этом каждое значение объёма работ ещё раскрыто в отдельный спектр по времени ведения проекта:

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

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

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

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

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

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

• Привязана ко времени. Так, дисциплина Requirements (полностью — requirements engineering, причём engineering тут тоже синоним «метода»: указывается «вид инженерии») в диаграмме 1996 года была очень и очень современной, культурно-обусловленной, SoTA. А сейчас это воспринимается как анахронизм, привет из прошлого.

Как проверить культурную обусловленность? Обычно по культурно-обусловленным методам работы есть учебники, курсы, монографии, статьи, посты в блоге, регламенты, руководства, инструкции, корпуса знаний (body of knowledge). А если это кулибинство/«я сам придумал!»²⁶, то учебника/руководства обычно нет — и дальше вам принимать решение: учебника нет, потому как речь идёт о фронтире, и учебник не успели написать, или учебника нет, потому как этот кривой свежесочинённый метод работы отражать в учебнике ни в коем случае нельзя, или просто не знаем об учебнике (но он в реальности был, а как работать по этому методу мы подглядели у человека, который по этому учебнику учился. Но о том, что он учился по учебнику, мы даже не знаем. Ну, или даже там устная традиция, как в восточных единоборствах, «секреты мастерства» передаются из поколения в поколение только устно. В литературе это было во времена до книгопечатания: былины и эпосы, с методами всё то же самое). Методология не учит, что делать в этом случае — понятно, что вы должны стратегировать (выбрать какой-то метод работы в ситуации, когда он вам вначале неизвестен), но методология заставляет удерживать во внимании методы работы и интересоваться их культурной обусловленностью, вы не можете уйти от осознанного выбора метода работы, осознанного стратегирования.

Работы по методам, описанным разными дисциплинами на «горбатой диаграмме» как-то распределены по времени жизненного цикла в его начальном (1.0) представлении («жизненный цикл — это последовательность работ»). В RUP это работы по практикам организационного моделирования (business modeling, помним про перевод business как «организационный»), инженерии требований (уже устарела со времён популярности RUP), анализа и проектирования (анализ как отдельный метод работы не рассматривается, он включается в проектирование), разработки (границы этой практики определяются сейчас по-другому, ведь диаграмме около 30 лет!), испытаний (сегодня это инженерные обоснования, quality assurance), разворачивания (но вот delivering как «введение в эксплуатацию» в RUP нет, это не считалось трудозатратным — «акт подписать»), управления конфигурацией и изменениями, управления проектом, работы с окружением/environment. И это никак не закольцовано, хотя и выделены «порции работ по всем методам создания и развития вместе» как «итерации» — но это просто отражение «постепенного достижения конечного результата», а не получение сначала MVP (создание), а затем развитие, развитие, развитие, то есть не длительная эволюция без явного достижения заранее определённой цели. Нет, подразумевается, что «определили требования, повозились с проектированием и изготовлением, убедились, что удовлетворили начальные требования — всё, проекты жизненного цикла закончены, даже если этих проектов было несколько, всё развитие как продолжение работы над системами подобного класса — за рамками жизненного цикла».

Деление работ на стадии/фазы/этапы, а потом на более и более мелкие работы в классическом разбиении работ (work breakdown structure, WBS) относят к методам проектного управления, в то же время методология обсуждает разложение методов работы создателей (названные на «горбатой диаграмме» по их дисциплинам) как разделение труда (division of labor). Виды труда — это один из синонимов «метода».

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

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

• выше мастерство — меньше новичковых ошибок,

• меньше ошибок — меньше надо их исправлять, что-то переделывать,

• меньше время переделок — меньше время выполнения проекта.

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

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

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

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

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

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

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

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

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

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

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

Cоздатель АЭС — это набор связанных разными видами соглашений организаций, так называемое расширенное предприятие, extended enterprise, поэтому говорим не просто про архитектуру, а организационную архитектуру.

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

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

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

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

• для клиники — предприятие (клиника::роль, предприятие::оргзвено);

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

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

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

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

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

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

Провал водопадной модели жизненного цикла

Недостаточность и ограниченность описания жизненного цикла как поведения создателей (view) через метод описания (viewpoint) последовательностей крупных работ как стадий жизненного цикла с каждым годом становилась очевидней. Назревала необходимость смены метода описания поведения создателей.

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

Наборы различных типовых последовательностей работ получили название модели жизненного цикла (life cycle model²⁹, вид/форма жизненного цикла, модель тут как образец/шаблон/паттерн).

Модели жизненного цикла грубо можно разместить между двух крайностей:

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

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

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

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

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

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

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

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

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

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

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

Эта ситуация известна как проблема «а чо такова?»³⁰, то есть проблема непринятия всерьёз логичных рассуждений, игнорирование важности соответствия жизни и описаний жизни. Это всё равно как знать, что суеверия — плод фантазии, но всё-таки следовать им. «Водопад» оказывается утопичен, фантазиен, но всё-таки люди считают, что он хорошо описывает проект и дальше пытаются ему следовать. Почему? Ответ обычно — «он же прост! Не надо усложнять». Ну, 2*2=3 тоже просто, но не работает. Но в этом случае почему-то ошибку исправляют, а в случае водопада — нет, менеджерам он выгоден, можно всегда обвинить инженеров в том, что они не справились.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жизненный цикл 2.0: от стадий работ к методам разработки

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

Этот спиральный жизненный цикл³¹ был предложен Barry Boehm в 1978 году на примере айтишных проектов, успешно реализован им 1981 и опубликован 1988 году — задолго до появления «горбатой диаграммы» в RUP (напомним, она появилась в 1996 году, и тоже у айтишников — пелетон в инженерии растягивается на десяток-другой лет). Вот один из поздних вариантов изображения этой «спирали»:

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

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

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

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

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

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

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

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

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

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

«Горбатая диаграмма» из RUP 1996 года как раз представляет собой гибридный вариант спиральной модели (выделены отдельно методы инженерии, введены «итерации» как повторения работ по всем методам инженерии) и водопадной модели (введена линейная ось времени, последовательные стадии жизненного цикла, хотя и признаётся, что на каждой стадии жизненного цикла будут работы всех инженерных методов, определяемых их дисциплинами).

Последний вариант спиральной модели жизненного цикла носит название «модель пошагового спирального выделения ресурсов» (Incremental Commitment Spiral Model). Эта модель жизненного цикла разрабатывалась Barry Boehm, Jo Ann Lane,‎ Supannika Koolmanojwong, Richard Turner в 2006-2014 годах как продолжение работ по развитию идей спирального вида жизненного цикла. Эта модель жизненного цикла используется в военных инженерных проектах США³².

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

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

Тем самым произошёл переход от

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

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

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

«Инженерный процесс»/«процесс инженерии»/«engineering process» — предпочтительный термин. Термин «процесс разработки»/«development process» используется в двух значениях:

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

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

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

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

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

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

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

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

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

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

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

• Затем надо рассматривать способ, которым это всё можно сделать, то есть метод инженерии, «инженерный процесс». В хорошем инженерном процессе предусмотрены и первые шаги по этой системной мантре.

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

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

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

Управление работами производят путём связи альфы с рабочими продуктами и кейсами, предметами которых будут рабочие продукты для этих альф. Кейсы отслеживаются в софте управления работами: управления кейсами/issue trackers, управления проектами, управления процессами, управления программами или просто в универсальных моделерах типа coda.io или notion.so, которые позволяют отмоделировать в том числе и метод инженерии. Подробней об управлении работами (операционный менеджмент) будет рассказано в руководстве по системному менеджменту. А вот как моделировать движение альф по их состояниям — предмет методологической работы, рассматривается в нашем руководстве. Прикладная методология заставит выбрать правильный метод, правильные предметы метода, состояния этих предметов метода. Но наше руководство по фундаментальной методологии расскажет, как это всё описать, а также какие ошибки не надо делать в ходе рационального выбора метода.

Часто на диаграммах инженерного процесса (жизненного цикла, метода разработки) приводят только методы работ. Эти диаграммы практически полностью будут функциональным описанием создателя системы как «прозрачного ящика», причём чаще всего без показа ролей, а только с показом функций/методов, выполняемых ролями и потоками предметов метода, проходящими обработки по этим методам. Гибридизация с представлением работ происходит сегодня много реже, ибо планирование работ в современных методах инженерии происходит «на лету», непонятно как показывать работы (разве что иногда показывают тип «работа/task» или «пакет работ»/ «work package»). Диаграммы работ не называют диаграммами инженерного процесса, процесса разработки, жизненного цикла, но называют диаграммами проектного управления (например, диаграммы Ганта³³), верный признак диаграмм работ — там физическое время, а не «логическое».

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

Время эксплуатации: пример человека

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

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

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

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

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

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

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

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

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

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

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

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

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

А как же развитие человека как системы, ведь говорим о создании и развитии? Тут несколько вариантов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вам нужно привести какой-то объект в какое-то состояние:

• Надо понять, каким методом вы это можете сделать: объект при этом будет предметом метода

• Надо понять, если ли у вас оргвозможность сделать (и создать эту оргвозможность, если её нет)

• Надо запланировать и выполнить работу с этим объектом как предметом работы.

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

Граф создателей

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

• вы делаете топор (топор — целевая система)?

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

• топор для вас одна из систем в окружении целевой для вас колоды, совместно с которой топор должен колоть дрова и свойства которого вы выясняете для того, чтобы спроектировать и изготовить правильную колоду³⁵?

С самого начала обсуждения жизненных циклов и далее инженерных процессов было понимание, что отдельные инженерные проекты по созданию систем связаны между собой через время эксплуатации/использования в разветвлённые графы создателей, ибо время эксплуатации создателя — это когда создатель участвует в работах по созданию и/или развитию какой-то очередной системы в графе создателей. Чтобы дойти в этом графе создателей до создания и развития целевой системы, может понадобиться несколько шагов (я заточил топор, нарубил дров и сделал из них костёр, добыл охотой дичь, запёк дичь в костре, накормил готовым обедом семью — и это очень простой граф создателей, целевая система в нём — семья, я выступаю как провайдер обеда, но чтобы произвести обработку семьи обедом мне требуется перед этим создать инструментарий: топор, костёр, а ещё создать дичь как сырьё для обеда, и дальше уже можно говорить, что сам обед — это результат «развития» дичи, а не развития топора или костра). Создатели — это необязательно предприятия, это могут быть и простые инструменты. В конце концов, это constructors из constructor theory David Deutsch и Chiara Marletto, а также это enabling systems (системы времени создания и развития, которые преобразуют сырьё, проводя его через разные состояния в итоговую целевую систему), это агенты в широком смысле, у которых есть важное отличие от многих других систем: они «нерасходуемы», то есть после выполнения какого-то сервиса (обработки какого-то предмета сервиса для перевода его в другое состояние) создатели не разрушаются, они опять готовы к работе. Это могут быть и молекулы катализатора, и станки, и люди, и роботы, включая роботов, умеющих самореплицироваться.

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

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

Недостатки упрощённой картинки являются продолжением её достоинств:

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

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

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

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

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

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

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

Давайте представим виды/типы/классы систем, которыми занимается предприятие/фирма («которыми занимается» — это ведь «работает по каким-то методам», то есть эти виды систем будут предметами методов работы предприятия/фирмы):

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

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

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

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

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

• Создатель агентуры, который создаст группу агентов по продажам (команда продвиженцев: маркетинг, реклама, продажи продуктов и/или сервисов фирмы)

• Создатель клиентуры (агентура, то есть группа агентов, которая будет вербовать клиентов)

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

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

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

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

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

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

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

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

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

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

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

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

• Сами нотации крайне трудны для сопровождения в ходе неминуемых изменений.

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

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

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

«Времена» рассмотрения системы

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

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

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

1. Время эксплуатации/использования/run-time/operations, оно в момент «разработки с нуля»/greenfield, а также разработки фич (модернизации, brownfield). Это время работы уже существующей готовой и работающей целевой системы. Оно в ходе проекта часто находится в будущем, и поэтому приходится думать о будущей системе как уже существующей и успешной (т.е. удовлетворяющей потребностям проектных ролей, а то и превосходящей их ожидания). Это время эксплуатации может быть очень небольшим, например, 20 миллисекунд для исполнения какого-нибудь софта или реализации взрыва. Это также может быть тремя минутами для танцевального перформанса, или восьмьюдесятью годами бесперебойной работы энергоблока атомной электростанции. В этот момент система уже создана и её экземпляр прошёл какое-то развитие. Экземпляр системы находится в физическом мире, настроен и работает, взаимодействует со своим окружением в составе надсистемы, нанося этому окружению непоправимую пользу. Взрыв крушит всё вокруг, софт перемалывает данные, танцевальный перформанс происходит и три минуты радует людей, энергоблок АЭС производит электричество. Ведущий аспект рассмотрения целевой системы тут — функциональный, система создания обычно не рассматривается (но может рассматриваться из неё оператор, который работает как раз в это время).

2. «Время создания и развития»/«design and construction time»/«development time» как время работы создателя целевой системы, состояние целевой системы при этом необязательно готовое для работы, она может быть вообще ещё в виде сырья или даже существовать только в форме идеи/замысла, то есть создаваемая система в это время может ещё и не существовать в физическом мире. Это design-time или development у айтишников (начиная с замысливания и включая «непрерывное всё»), но мы включаем сюда и время изготовления, наладки, испытаний, ввода в эксплуатацию, модернизации и техобслуживания для «железных систем», что часто в программной инженерии не рассматривается как отдельные работы. Софт контроллера в подушке безопасности автомобиля работает 20 миллисекунд, но время его создания и развития — три года разработки начальной версии и три года эксплуатации (где актуальное срабатывание — только 20 миллисекунд, остальное — время ожидания включения, но это ожидание включения — тоже время эксплуатации). Но длительность создания и развития контроллера в подушке безопасности будет всего не шесть лет, а много больше — ибо каждый год выходит новая улучшенная версия, и так продолжается уже двадцать пять лет, и непонятно, сколько ещё будет продолжаться («непрерывное всё» в технической эволюции может быть ограничено по времени, но в целом развитие жизни, включая техносферу, бесконечно по времени, и мы рассматриваем уже «систему как вид», эволюцию системы). Можно подразделять это время на создание MVP, развития/эволюции, можно выделять из времени развития ещё и время создания каждой очередной версии системы (время создания инкремента, время создания фичи), считая, что время развития состоит из времён создания множества инкрементов, но это уже детали. Главное, что речь идёт о рассмотрении работы систем создания и состояний целевой системы, которая ещё не работает. Ведущий аспект рассмотрения тут — рассмотрение не столько целевой системы, сколько методов работы и работ создателей из их графа.

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

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

Моделирование: время операционное, создания, методологическое

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

Задания: процесс инженерии и методологическое время

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

1. Написан пост, в котором вы даёте оценку процессу инженерии в вашей организации: насколько он далеко от «водопада».

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