Жизненный цикл 2.0: практики, по которым выполняются работы ​

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

Во всё большем и большем числе проектов (начиная с айтишных проектов) признавали, что нельзя сделать никакого предварительного планирования отдельных работ. Разработка везде велась, как судебные дела, «непрерывно открывающимися обстоятельствами», и только производство/изготовление можно хоть как-то было планировать, ибо к этому моменту уже было хотя бы известно, что производить, и какие нормы производительности хотя бы примерно существуют. А нормы мыслительной деятельности и количество порождённых и раскритикованных гипотез в ходе разработки --- этого оценить нельзя. Инженеры на невозможности up-front/предварительного планирования и строго последовательного выполнения заведомо успешных мыслительных/знаниевых работ (knowledge works) настаивали, менеджерам это не нравилось, они требовали чётких планов, затем оценки инженеров по поводу планирования (гипотезы!) менеджеры объявляли обещаниями и считали их требованиями. То есть жизнь в проектах шла одним образом, но в учебниках продолжали писать, «как надо»: планировать постадийную работу!

Наборы различных концепций планирования выполнения практик в виде последовательностей работ получили название модели жизненногоцикла (life cycle model^[1], вид/форма жизненного цикла). Концепция тут понимается примерно так же, как концепция системы: как увязаны функциональное и конструктивное понимание (а также размещение и оценки стоимости), но не частей системы, а поведения системы, причём не целевой, а системы-создателя.

Концепции/модели жизненного цикла грубо можно разместить между двух крайностей:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот один из типичных вариантов «спирали», в которой укрупнённые инженерные практики (конечно, они носят старинные названия) раскладываются по линии времени:

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

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

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

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

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

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

Время в диаграммах «концепции ведения работ», «процесса разработки»/«метода инженерии»/«модели жизненного цикла» прежде всего «логическое», функциональное, форма представления произвольная. Но всё чаще и чаще вместо подобных диаграмм производят табличное моделирование проекта, включающее прежде всего модели альф с их состояниями --- и дальше выходят на практики/методы, которые двигают альфы от состояния к состоянию. Управление работами производят путём связи альфы с рабочими продуктами и кейсами, предметами которых будут рабочие продукты для этих альф. Кейсы отслеживаются в софте управления работами: управления кейсами/issue trackers, управления проектами, управления процессами, управления программами или просто в универсальных моделерах типа coda.io или notion.so, которые позволяют отмоделировать в том числе и метод инженерии. Подробней об этом рассказывается в курсе системного менеджмента.

Часто на диаграммах жизненного цикла/метода разработки приводят только практики (только один аспект/viewpoint описания систем создания, функциональный), а диаграммы работ даже не называют диаграммами жизненного цикла, а называют диаграммами проектного управления (например, диаграммы Ганта^[5], там физическое время).

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