Анатолий Левенчук - Методология 2022

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

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

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

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

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

Современный вариант спиральной модели жизненного цикла носит название « модель пошагового спирального выделения ресурсов» (Incremental Commitment Spiral Model, разрабатывалась Barry Boehm, Jo Ann Lane,‎ Supannika Koolmanojwong, Richard Turner в 2006—2014 годах как продолжение работ по развитию идей спирального вида жизненного цикла) и используется в военных инженерных проектах США 29 29 https://www.amazon.com/dp/0321808223/ .

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

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

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

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

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

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

Время в диаграммах жизненного цикла прежде всего «логическое», функциональное. Часто диаграммы жизненного цикла только функциональные с практиками (только один метод описания систем создания, функциональный), а конструктивные диаграммы даже не называют диаграммами жизненного цикла, а называют диаграммами проектного управления (например, диаграммы Ганта 30 30 https://ru.wikipedia.org/wiki/Диаграмма_Ганта , там физическое время).

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