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