Методология 2023

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

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

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

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

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

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

Практики

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

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

Переход к диаграммам типа принципиальных/функциональных схем для систем создания произошёл постепенно. После классических «колбасок» для стадий жизненного цикла поначалу появилось множество гибридных диаграмм, пытавшихся отразить сразу и конструктивную/логистическую и функциональную/назначения ипостаси жизненного цикла как поведения систем создания. И это не случайно: ключевые/архитектурные решения по устройству жизненного цикла – это решения о том, какие оргроли будут выполняться какими оргзвеньями, а в другой формулировке – какими работами будут выполнены те или иные практики/виды работы/деятельности. Это принятие архитектурных решений по устройству жизненного цикла и организация выполнения этих решений будет называться управлением жизненным циклом (life cycle management, ср. work management/управлением работами.

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

Одной из самых известных гибридных для управления жизненным циклом и управления работами диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP)[23 - https://en.wikipedia.org/wiki/Rational_Unified_Process (https://en.wikipedia.org/wiki/Rational_Unified_Process)]:

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

«Практика» и есть культурно-обусловленное функциональное/ролевое поведение создателей. Работы оргзвеньев выполняют роль тех или иных практик культурно-обусловленных оргролей, из которых и состоит жизненный цикл. Помним, что системный архитектор (роль) выполняет практику системной архитектуры (поведение роли). Авиапредприятие (роль) выполняет практику строительства самолётов (поведение роли). Как проверить культурную обусловленность? Обычно по культурно-обусловленным практикам есть учебники. А если это кулибинство/«я сам придумал!»[24 - https://vk.com/club45696675 (https://vk.com/club45696675)], то учебника обычно нет – и дальше вам принимать решение: учебника нет, потому как речь идёт о фронтире, и учебник не успели написать, или учебника нет, потому как этот кривой свежесочинённый метод работы отражать в учебнике ни в коем случае нельзя, или просто не знаем об учебнике (но он в реальности был, а как выполнять практику мы подглядели у человека, который по этому учебнику учился. Но о том, что он учился по учебнику, мы даже не знаем). Системное мышление не учит, что делать в этом случае, но заставляет удерживать во внимании практики работы и интересоваться их культурной обусловленностью.

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

Эти работы делятся на стадии, а потом на более и более мелкие работы в классическом разбиении работ (work breakdown structure, WBS) из проектного управления, в то же время практики (показанные на диаграмме как их дисциплины) отражают разделение труда (division of labor).

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

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

Работы – это про количество работы и её скорость, а труд/деятельность/практика – это про назначение и разнообразие видов/родов/сортов/способов работы и их уместность/полезность/назначение/роль в проекте.

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

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

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

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

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

А оргзвено? Для каждой более мелкой роли будет более мелкое оргзвено. Для клиники – предприятие; для врача – не слишком понятно, что (и это должно напрягать: модульный синтез будет трудным); для гинеколога – человек, обладающий мастерством в/знающий дисциплину и владеющий инструментами/практикующий гинекологию и занимающий позицию в штатном расписании и распоряжающийся в силу этого необходимыми для его работы инструментами/оборудованием: оргзвено размером с одного человека. Является ли сообщество, или общество, или даже человечество оргзвеном? Вряд ли: «орг» тут означает организованность, то есть известность всем тех агентов, которые распоряжаются ресурсами оргзвена. С натяжкой можно говорить, что в социалистических диктатурах всеми ресурсами понятно кто распоряжается (диктатор, и дальше идёт какое-то делегирование полномочий диктатора «на места»), но это на больших масштабах оказывается крайне неэффективным в части распределения труда: потребности людей в масштабах общества учесть невозможно, организовать (наладить систему поручений что-то делать) труд так, чтобы число производимых шнурков как-то билось с числом производимых ботинок оказывается в масштабах общества нерешаемой задачей (до сих пор калькуляционный аргумент Мизеса, который это формулирует, не опровергнут[25 - https://ru.wikipedia.org/wiki/Калькуляционный_аргумент (https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BB%D1%8C%D0%BA%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D1%80%D0%B3%D1%83%D0%BC%D0%B5%D0%BD%D1%82)]). Так что в нашем курсе мы ограничиваемся оргзвеньями минимально как отдельными личностями (существа как оргзвенья не подойдут, кошечек и слонов не организуешь), а максимально как компаниями/организациями.

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

Жизненный цикл 2.0

Недостаточность и ограниченность описания жизненного цикла как поведения систем создания через метод описания (viewpoint, все эти «поколения представления жизненного цикла» – это про смену ведущего метода описания) последовательностей крупных работ как стадий жизненного цикла с каждым годом становилась очевидней. Во всё большем и большем числе проектов (начиная с айтишных проектов) признавали, что никакого предварительного планирования отдельных работ достичь нельзя, а разработка везде велась, как судебные дела, «непрерывно открывающимися обстоятельствами». Наборы различных архитектурных решений по поводу планирования выполнения практик в виде последовательностей работ получили название модели жизненного цикла (life cycle model[26 - слово «модель» тут используется в смысле обозначения группы похожих жизненных циклов, «модельного ряда», а не в смысле «упрощённого объекта, сохраняющего лишь важнейшие свойства моделируемого объекта», поэтому при переводе мы иногда будем использовать и термин «вид жизненного цикла».], вид/форма жизненного цикла).

Эти наборы решений по связи практик и работ грубо можно разместить между двух крайностей:

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

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

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

Водопад/каскад течёт всегда сверху вниз. Для более убедительной иллюстрации этого «невозвратного» хода работ традиционную «колбаску» начали рисовать как ступени настоящего водопада[27 - http://www.managersystem.ru/geds-459-1.html (http://www.managersystem.ru/geds-459-1.html)]:

Между стадиями осуществлялась тщательная проверка и приёмка (verification and validation, V&V) рабочих продуктов-результатов предыдущих стадий, при этом принималось решение о продолжении работ, возврате на доработку или прекращении работ по всей системе. Эти проверки и приёмки с принятием решений между стадиями жизненного цикла для всей системы по итогам оценки рисков успешности проекта на разных стадиях его реализации получили название гейтов (gates, ворота – не путать с milestones/вехами, которые не связаны с решениями о прекращении всего проекта в целом и служат лишь для контроля скорости его прохождения. Ворота могут быть закрыты, а вот вехи просто отмечаем глазами на обочине). Вообще-то решений в гейтах обычно не два типа (go – no go), а три (доработать результат стадии и повторить гейт; переходить к следующей стадии; остановить проект):

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

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

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

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

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

Была предпринята радикальная замена «конструктивной» модели жизненного цикла с приматом описания работ-стадий на «функциональную», с приматом описания практик. Работы в этой модели учитывались как развёртка во времени применения агентами тех или иных практик/деятельностей/discipline, а сама линия времени как символ выделения ресурсов для показанных практик была нарисована по спирали. Этот вид жизненного цикла был предложен Barry Boehm в 1978 году на примере айтишных проектов, успешно реализован им 1981 и опубликован 1988 году – задолго до появления «горбатой диаграммы» в RUP (напомним, она появилась в 1996 году, и тоже у айтишников). Этот жизненный цикл получил название спирального[28 - http://www.sei.cmu.edu/reports/00sr008.pdf (http://www.sei.cmu.edu/reports/00sr008.pdf) и сравнение авторами водопадной и спиральной модели через десяток лет от этого момента https://resources.sei.cmu.edu/asset_files/SpecialReport/2000_003_001_13655.pdf]:

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

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

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

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

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

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

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

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

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

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