Методология 2025 - читать онлайн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одна из самых популярных книжек по проектному управлению, вышедшая первым изданием ещё в июне 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) тут отличается от терминологии разговора об элегантности и разговора об управлении конфигурацией, ибо отличается набор понятий. Мы дальше берём терминологию метода операционного менеджмента TameFlow82, которая по большому счёту и отражает 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 – оргзвена, которое назначено на роли и имеет полномочия по выполнению работ по методам этих ролей и имеет все необходимые ресурсы для этого).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Нацеливание гвоздя (гвоздь нацелен).

• Вколачивание гвоздя (гвоздь вбит).

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

• Эксплуатация соединения (соединение держит и стабильно при нагрузках)

• Вытаскивание гвоздя (гвоздь вытащен).

• Ликвидация гвоздя (гвоздь выкинут – жизненный цикл всегда идёт до исчезновения объекта работ).

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

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

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

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

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

Жизненный цикл 1.0 – предмет управления работами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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