Читать книгу Методология 2022 - Анатолий Левенчук - Страница 14

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

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

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

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

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

Водопад/каскад течёт всегда сверху вниз. Для более убедительной иллюстрации этого «невозвратного» хода работ традиционную «колбаску» начали рисовать как ступени настоящего водопада27:

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

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

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

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

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

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

Была предпринята радикальная замена «конструктивной» модели жизненного цикла с приматом описания работ-стадий на «функциональную», с приматом описания практик. Работы в этой модели учитывались как развёртка во времени применения агентами тех или иных практик/деятельностей/discipline, а сама линия времени как символ выделения ресурсов для показанных практик была нарисована по спирали. Этот вид жизненного цикла был предложен Barry Boehm в 1978 году на примере айтишных проектов, успешно реализован им 1981 и опубликован 1988 году – задолго до появления «горбатой диаграммы» в RUP (напомним, она появилась в 1996 году, и тоже у айтишников). Этот жизненный цикл получил название спирального28:

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

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

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

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

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

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

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

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

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

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

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

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

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

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