Текст книги "Методология 2023"

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

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

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

В этот момент в самом системном мышлении не очень было принято думать о системах создания (в биологии этого не было, а в технических проектах инженеры «железных», программных и киберфизических систем редко думали о системах создания так же тщательно, как о целевых системах, предоставляя это менеджерам и основателям компаний/«предпринимателям»), поэтому проектное управление как менеджерское движение в 80х и 90х годах прошлого века довольно много сделало для того, чтобы в системном мышлении появились мысли не только об окружении, но и о системах создания, а методология из учения о методах познания стала вполне инженерной фундаментальной дисциплиной (в том числе появились методологические стандарты первой волны и понятия инженерии методов и ситуационной инженерии методов2929
  https://ailev.livejournal.com/750878.html


[Закрыть]).

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

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

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

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

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

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

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

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

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

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

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

Целевая система в её ближнем (подсистемы надсистемы, которые включают и целевую) и дальнем (системы из иерархии надсистем) окружении – это разбиение (иерархия по отношениям часть-целое) операционного окружения/operation environment, то есть времени работы/эксплуатации системы. Создатели – это системы создания/ «ведения жизненного цикла»/«ведения работ над целевой системой» – они из других разбиений, разбиений систем цепочек создания, они части совсем других систем в совсем другое время, и поскольку создатели часто ярко выражены как агенты (автономны! Это редко станки и компьютеры, чаще люди со станками и компьютерами, и даже организации людей!), то это обычно системы систем/system of systems/SoS, что делает их во много раз трудней в рассмотрении.

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

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

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

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

Первая проблема понимания жизненного цикла как последовательности крупных работ проекта: в реальных проектах по созданию систем массово начала вырождаться стадийность. Сначала в agile3030
  https://ru.wikipedia.org/wiki/Гибкая_методология_разработки


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

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

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

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

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

Вот типичная картинка объяснения перехода к параллельной инженерии (и на ней хорошо видно, что сроки всех работ по созданию системы при этом существенно сокращаются)3131
  https://www.isene.se/pppp/


[Закрыть]:

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

⠀