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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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