Жизненный цикл атомной станции на сегодня рассматривается как набор практик замысливания, проектирования, сооружения, эксплуатации, модернизации (увы, мы тут не можем говорить о развитии отрасль серьёзно зарегулирована), ликвидации, реализуемый работами, выполняемыми проектными, строительными, монтажными, эксплуатирующими организациями в самых разных организационных ролях: основателя компании, линейного/операционного менеджера, инженера в целевой предметной области. А всего несколько лет назад обсуждались бы прежде всего работы как «стадии», а не практики этих работ.
Жёсткие условия госрегулирования делают очень трудным разговор о развитии/эволюции атомной станции, поэтому вопрос развития даже не ставится: «модернизация» по факту идёт только как «продление срока службы энергоблоков» (по факту это ремонт, а не улучшение со smart mutations в проекте/design атомной станции) именно так понимается «управление жизненным циклом» на объектах атомной энергетики. В любом случае, обсуждаются (инженерами АЭС) по линии управления жизненным циклом прежде всего наборы практик, а не наборы работ работы обсуждаются по линии операционного менеджмента, управления работами.
Обсуждение практик при этом первично: если не знаешь, как ты будешь работать, то ничего про саму работу сказать нельзя. Скрепить две детали какая практика? Если не знаешь, сварка это, проклейка, болтовое соединение ничего сказать про работу нельзя. Поэтому практика (функциональное рассмотрение поведения) обсуждается всегда логически сначала, работа (конструктивное рассмотрение) всегда логически потом, и они итеративно утрясаются так, чтобы удовлетворять условиям доступности в проекте, экономической эффективности и прочим архитектурным характеристикам, которые должны быть удовлетворены системой создания. Ибо жизненный цикл даже энергоблока АЭС это разговор не столько про саму АЭС и её архитектуру, сколько про создателя АЭС (проектные и строительные организации, поставщики оборудования) и его орг-архитектуру (создатель АЭС это организация, поэтому говорим не просто про архитектуру, а организационную архитектуру).
Системы создания имеют первичные названия по основной функции/практике, по их организационной роли. Эти названия строятся как и названия любых других систем, вопрос подробно разбирался в курсе «Практическое системное мышление». Парикмахерская выполняет работы своего сервиса как оргзвено (например, как частный парикмахер Ольга, как предприятие ООО «Причешем», или подразделение холдинга Всёрежьчешиукладка), а практику выполнения причёсок выполняет как парикмахерская! Оргроль парикмахерской «парикмахерская», «делатель причёсок»! Увы, оргроли в бытовом языке не имеют своих специальных слов для названия. А проектные роли? Это они и есть.
В проектной роли может быть не только человек (на сегодня это самое маленькое оргзвено, агенты сегодня главным образом люди), но и любое другое оргзвено из группы людей и их оборудования. Главное тут не впадать в сверхобобщение, оргроль «клиника» или ещё более обобщённое «лечебное заведение» обычно не даёт возможности что-то содержательно обсуждать: лечебное заведение выполняет слишком много практик/деятельностей для целевых систем с самых разных системных уровней, и лучше бы такие «сверхроли» сразу дробить до ролей с более-менее понятными компетенциями, которые мог бы выполнять отдельный человек как оргзвено. Проектные роли не «клиника», а «врач» и «техник медицинской аппаратуры», а ещё лучше не «врач», а «гинеколог» и «дантист». Принцип почтальона хорошо бы соблюдать и с оргролями (они тоже функциональные части, только систем создания!), а не только с функциональными частями целевых систем: адрес предмета обсуждения лучше бы давать точно, без «на деревню дедушке Константину Макарычу».
А оргзвено? Для каждой более мелкой роли будет более мелкое оргзвено. Для клиники предприятие; для врача не слишком понятно, что (и это должно напрягать: модульный синтез будет трудным); для гинеколога человек, обладающий мастерством в/знающий дисциплину и владеющий инструментами/практикующий гинекологию и занимающий позицию в штатном расписании и распоряжающийся в силу этого необходимыми для его работы инструментами/оборудованием: оргзвено размером с одного человека. Является ли сообщество, или общество, или даже человечество оргзвеном? Вряд ли: «орг» тут означает организованность, то есть известность всем тех агентов, которые распоряжаются ресурсами оргзвена. С натяжкой можно говорить, что в социалистических диктатурах всеми ресурсами понятно кто распоряжается (диктатор, и дальше идёт какое-то делегирование полномочий диктатора «на места»), но это на больших масштабах оказывается крайне неэффективным в части распределения труда: потребности людей в масштабах общества учесть невозможно, организовать (наладить систему поручений что-то делать) труд так, чтобы число производимых шнурков как-то билось с числом производимых ботинок оказывается в масштабах общества нерешаемой задачей (до сих пор калькуляционный аргумент Мизеса, который это формулирует, не опровергнут34). Так что в нашем курсе мы ограничиваемся оргзвеньями минимально как отдельными личностями (существа как оргзвенья не подойдут, кошечек и слонов не организуешь, у компьютеров достаточного уровня интеллекта ждём), а максимально как компаниями/организациями со всеми их компьютерами, куда включены на нижних уровнях конструкции и компьютеры, и люди, и другое оборудование.
В системном менеджменте не ограничиваются обсуждением практик и работ. Сегодня там большое внимание уделяют понятию оргвозможности/capability для указания ресурсной доступности какой-то практики (то, что на выполнение практики-поведения назначено какое-то компетентное оргзвено, и ему выданы все полномочия по распоряжению ресурсами, нужными для выполнения этой практики. Компетентное это которое знает, как выполнять практику, включая компетенции отдельных людей и компетенции по объединению труда/деятельности этих людей, а ресурсы включают необходимое оборудование и материалы). По большому счёту, вас интересует не «теоретическая возможность выполнения работы» (все люди обучены, оборудование и материалы есть практика поставлена), а реальная организационная возможность (практика поставлена, ресурсы есть, плюс выдано полномочие работать по этой практике, тратить на это ресурсы). Переход от состояния организации «практика поставлена, по идее можно работать» до «а вот теперь и правда можно работать» может занимать много лет. Вы можете уметь пользоваться новейшим гвоздезабивальным автоматом, и этот автомат может быть уже закуплен и развёрнут, и закуплен запас специальных гвоздей для этого автомата, но команды им пользоваться не будет, не будет проявлена уже поминавшаяся в нашем курсе «политическая воля» и вы будете забивать обычные гвозди камнем или микроскопом. Молотка у вас тоже не будет, ибо «мы же только что купили гвоздезабивальный автомат! Он полностью заменяет молоток, и даже лучше!». Вот это типичная для организационного менеджмента ситуация, в которой мы должны отличать практику («как это обычно делается», описана в учебнике) от оргвозможности (как мы это будем делать у нас в проекте). Но повторим: когда мы говорим об оргзвене, чаще всего мы говорим об оргвозможности то есть это не «оргзвено, которое просто есть», а «оргзвено, которое вполне способно выполнять работы/сервис по известной ему практике, и имеет для этого все полномочия и ресурсы». Как сделать так, чтобы появилась оргвозможность это рассказывается в курсе «Системный менеджмент».
Жизненный цикл 2.0: практики, по которым выполняются работы
Недостаточность и ограниченность описания жизненного цикла как поведения создателей (view) через метод описания (viewpoint) последовательностей крупных работ как стадий жизненного цикла с каждым годом становилась очевидней. Назревала необходимость смены метода описания поведения создателей.
Во всё большем и большем числе проектов (начиная с айтишных проектов) признавали, что нельзя сделать никакого предварительного планирования отдельных работ. Разработка везде велась, как судебные дела, «непрерывно открывающимися обстоятельствами», и только производство/изготовление можно хоть как-то было планировать, ибо к этому моменту уже было хотя бы известно, что производить, и какие нормы производительности хотя бы примерно существуют. А нормы мыслительной деятельности и количество порождённых и раскритикованных гипотез в ходе разработки этого оценить нельзя. Инженеры на невозможности up-front/предварительного планирования и строго последовательного выполнения заведомо успешных мыслительных/знаниевых работ (knowledge works) настаивали, менеджерам это не нравилось, они требовали чётких планов, затем оценки инженеров по поводу планирования (гипотезы!) менеджеры объявляли обещаниями и считали их требованиями. То есть жизнь в проектах шла одним образом, но в учебниках продолжали писать, «как надо»: планировать постадийную работу!
Наборы различных концепций планирования выполнения практик в виде последовательностей работ получили название модели жизненного цикла (life cycle model35, вид/форма жизненного цикла). Концепция тут понимается примерно так же, как концепция системы: как увязаны функциональное и конструктивное понимание (а также размещение и оценки стоимости), но не частей системы, а поведения системы, причём не целевой, а системы-создателя.
Концепции/модели жизненного цикла грубо можно разместить между двух крайностей:
1. практики и работы-стадии совпадают и для их выражения хватает «колбаски» с интерфейсами между работами (обсуждается «видимость работ», как обычно в модульных диаграммах нельзя из работ одной стадии затребовать ресурсы соседней стадии),
2. практики и работы не совпадают и для их выражения нужны какие-то сложные структуры с акцентом на связь практик, т.е. даже внешне похожие на принципиальные схемы с их «логическим, а не физическим временем» и «потоками альф, меняющими по ходу этих потоков состояния», а не модульные диаграммы с их «видимостью интерфейсов».
Первый вид жизненного цикла (квинтэссенция подхода 1.0, «проектное управление с непересекающимися стадиями») получил название «водопад» (cascade, каскад). Работы практик жизненного цикла выполняются однократно, созданные рабочие продукты/артефакты как output передаются как input-ресурсы для следующих работ, и больше к этим практикам никакого возврата нет, выполняются работы последующих практик. Водопад/каскад течёт всегда сверху вниз, назад возвратов нет! Для более убедительной иллюстрации этого «невозвратного» хода работ традиционную «колбаску» начали рисовать как ступени настоящего водопада36:
Между стадиями осуществлялись действия по инженерным обоснованиям (проверки, приёмки, испытания, экспертные оценки) результатов предыдущих стадий, при этом принималось решение о продолжении работ, возврате на доработку или прекращении работ по всей системе. Эти инженерные обоснования с принятием решений между стадиями жизненного цикла для всей системы по итогам оценки рисков успешности проекта на разных стадиях его реализации получили название гейтов (gates, ворота не путать с milestones/вехами, которые не связаны с решениями о прекращении всего проекта в целом и служат лишь для контроля скорости его прохождения. Ворота могут быть закрыты, а вот вехи просто отмечаем глазами на обочине). Вообще-то решений в гейтах обычно не два типа (go no go), а три (доработать результат стадии и повторить гейт; переходить к следующей стадии; остановить проект):
Но данная концепция/модель жизненного цикла оказалась для проектов с существенной долей работ с новыми для разработчиков типами систем полной утопией, она более-менее выполнялась лишь в проектах, где можно было накопить огромный опыт сборки/изготовления многочисленных очень похожих систем «из вещества» (там небольшая вариативность), например, гражданское (жилищное) блочное строительство.
Во всех остальных случаях (и особенно ярко это проявлялось в айтишных проектах) после выполнения работ по любой из практик «водопадного жизненного цикла» (в те времена типично было, например, указание на инженерию требований в ходе стадии работ «формирование требований» понятно, что разработанные требования говорили «какая должна быть система, чтобы быть успешной», и дальше ожидалось, что можно просто спроектировать и изготовить такую систему для гарантированной успешности) после всех гейтов с их проверкой независимыми экспертами, после всех ожиданий, когда все рабочие продукты соберут по их состоянию готовности на конец стадии (скажем, если речь идёт о требованиях то это будут абсолютно все требования, и если не готово даже какое-то второстепенное требование, то его будут ждать), всё равно при попытке работы с этими результатами предыдущих стадий находятся ошибки и недоработки и приходится выполнять новые работы, выполняющие практики работ предыдущих стадий жизненного цикла. Требования постоянно оказывались не «долженствованием», а «мы чуток ошиблись, гипотеза не подтвердилась», «мы тут не уточнили, давайте сформулируем по-другому». Пробы и ошибки всё равно были, новые и новые переделки/reworks не позволяли хоть как-то соотносить запланированные стадии жизненного цикла и реально ведущиеся работы. «Водопад» был только на бумаге в учебниках инженеров и в мечтах менеджеров.
«Водопад» оказался утопией, типа менеджерского философского камня или эликсира бессмертия: очень привлекательно, но абсолютно нереалистично, нереализуемо. Проблема в том, что следование этой утопии в планировании и отслеживании планов во многих организациях происходит до сих пор! В договорах, планах и отчётах до сих пор можно найти именно «водопад», а то, что в жизни всё совсем не так, никак не влияет на эти документы, поэтому они не отражают реальную жизнь. Эта ситуация известна как проблема «а чо такова?», то есть проблема непринятия всерьёз логичных рассуждений, игнорирование важности соответствия жизни и описаний жизни. Это всё равно как знать, что суеверия плод фантазии, но всё-таки следовать им. «Водопад» оказывается утопичен, фантазиен, но всё-таки люди считают, что он хорошо описывает проект и дальше пытаются ему следовать.
Использующим «водопадную» концепцию жизненного цикла в своих проектах инженерам приходилось признавать, что с практиками приходится работать в ходе всего полного жизненного цикла (те же самые «утверждённые требования», которые и до сих пор используются, менять по многу раз в ходе проекта, иногда чуть ли не в момент окончания работ, чтобы получить приемлемые инженерные обоснования). Работы назначать (и выделять ресурсы для проведения этих работ) на практики приходилось независимо от «водопадной» модели жизненного цикла, каждая практика (особенно легко это объяснять на примерах управления работами/операционного менеджмента, управления конфигурацией и прочих «управлениях») встречается на всех стадиях «водопада», их принципиально непонятно как выносить на какую-то обособленную во времени стадию. Но это же верно и для всех остальных практик, есть только ложное убеждение, что «мы утвердим очередной рабочий продукт, например, архитектурное решение, и больше никогда к нему не вернёмся». Нет, так не получится. Непрерывное всё, придётся постоянно работать над изменениями. Так что деление на стадии при принятой концепции «водопада» в жизненном цикле отражается не столько на реальных работах (они идут как надо, а не как задокументировано в планах!), сколько на договорной документации и официальных документах, которые должны идти в архив. «Водопад» путает классических инженеров в части описания того, какими методами они работают, а менеджерам/«инженерам предприятия» даёт нереалистичные оценки как в части рациональной организации работ (архитектуры предприятия, облегчающей инженерию целевой системы), так и в части операционного менеджмента (работы оказываются совсем не такими, какие можно ожидать, и происходят они в неожиданные моменты предсказания модели «водопада» очень плохие).