Биологический жизненный цикл

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

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

В инженерии, менеджменте, предпринимательстве, культуре всё не так:

• целевые системы сами не растут и не проходят метаморфозы, их придумывают, проектируют, изготавливают, эксплуатируют, модернизируют, выводят из эксплуатации люди в обеспечивающих системах. Это означает, что в самих системах никакой жизни нет, жизненный цикл оказывается не жизненным.

• Целевые системы не несут яиц, не живородят, не размножаются вегетативно. Это означает, что жизненный цикл не замыкается, не повторяется. То есть это не цикл.

Жизненный цикл оказался для неживых систем не жизненным и не циклом, но сам термин остался, причём он постепенно менял своё значение.

 

Понятие жизненного цикла системы 1.0

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

Работы – это процессные (то есть разворачивающиеся в конкретный участок времени) модули. Эти модули составлены из 4D-модулей, называемых в данном случае ресурсами для этих работ.

Для планирования работ обычно составляется план, в котором прописываются ответственные за выполнение работ, и время, за которое эти работы должны быть сделаны. Часто в план прописывают и другие требуемые ресурсы.

Каждая работа проходит следующий цикл (это подробно обсуждается в подходе к архитектурному описанию предприятий DEMO):

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

• Работа принята к исполнению, это тоже координационный акт.

• Работа выполняется. Это производственный акт (production act), реальное выполнение работ.

• Работа предъявлена к приёмке, это координационный акт.

• Работа принята, координационный акт.

Деление на координационные и производственные акты важно, чтобы делать правильные оценки времени: от момента затребования работы до момента принятия работы на координационные акты может уходить до 40% времени, и только 60% времени на проведение самой работы. Как планировать работы – по полному времени координации+производства работ, или только по актуальному времени потребления ресурсов? Разные школы управления работами отвечают на этот вопрос по-разному.

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

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

Сама целевая система при этом просто была маркером, который позволял отметить все относящиеся к системе (как к воплощению системы, так и к определению системы) работы, кто бы их ни производил в самых разных предприятиях, которые занимались системой на всём протяжении жизненного цикла.

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

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

 

Изображение жизненного цикла как работ (1.0)

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

Вот примеры такого изображения жизненного цикла разных типов систем из стандарта ISO 15288:

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

Вот этот же жизненный цикл, но там уже используются не ломтики «колбаски», а «шеврончики», означающие «процесс» с последовательными стадиями:

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

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

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

По факту системное мышление и проектное мышление в этот момент слились: жизненным циклом называли происходящие по поводу целевой системы работы, которые являлись предметом проектного управления в разнообразных проектах по поводу целевой системы.

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

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

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

Попробуйте перестать рисовать целевую систему квадратиком или кружочком. Вместо этого рисуйте её жизненный цикл, обозначая его стрелочкой с засечками. Это будет напоминать не только о воплощении целевой системы, но и длительности работ с целевой системой, и о 4D предпринятиях, ведущих эти работы.

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

 

Проблемы с жизненным циклом 1.0

Но не успело новое понятие жизненного цикла как системы поделённых на стадии работ прижиться, как начались проблемы.

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

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

Вот типичная картинка объяснения перехода к параллельной инженерии (и на ней хорошо видно, что сроки работ существенно сокращаются):

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

Сейчас хорошо понятно, что так долго продолжаться не могло, и на передний план должно было выйти функциональное представление обеспечивающих систем – «как работает» (а не «из чего собрать») обсуждается именно по принципиальным схемам, функциональным диаграммам. Но это произошло не сразу, поначалу появилось множество гибридных диаграмм. Одной из самых известных таких гибридных диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP):

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

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

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

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

 

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

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

Наборы различных архитектурных решений по поводу отнесения практик к работам жизненного цикла получили название виды жизненного цикла (life cycle model, модели жизненного цикла).

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

Первый вид жизненного цикла (квинтэссенция подхода 1.0) получил название «водопад» (cascade, каскад).

Как и в водопаде, работы какой-то практики выполняются, созданные рабочие продукты передаются как ресурсы для следующих работ, и больше к этим практикам никакого возврата нет, выполняются работы последующих практик.

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

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

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

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

Менеджерам и особенно госчиновникам в военных проектах гейтовая схема была очень удобна, ибо она позволяла легко организовывать финансирование проектов, по их стадиям. Проектные управляющие до сих пор пользуются гейтовой схемой как основной для организации своей работы.

Но инженерам нужно было делать сами проекты, им нужно было содержательно преодолевать утопичность «водопада с гейтами».

Поэтому была предпринята радикальная попытка заменить модель жизненного цикла с приматом метода описания работ-стадий на прямо противоположную, функциональную, с приматом метода описания практик. Работы в этой модели учитывались как развёртка применения тех или иных практик работы во времени, а сама линия времени как символ выделения ресурсов для показанных практик была нарисована по спирали. Этот вид жизненного цикла был предложен Barry Boehm в 1978 году, успешно реализован им 1981 и опубликован 1988 году. Этот жизненный цикл получил название спирального:

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

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

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

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

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

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

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

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

 

Эксплуатация как выделенная стадия жизненного цикла

Эксплуатация (operations, функционирование, usage, использование) – это особая стадия жизненного цикла, поскольку именно на этой стадии у нас с определением и воплощением целевой системы имеют дело не обеспечивающие системы, а системы в операционном окружении.

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

Сам человек тут показан как 4D индивид. Это позволяет обсуждать изменение его состояний как полных темпоральных частей.

Его рожают (показана семья как обеспечивающая система), учат (школа/учительница как обеспечивающая система), и в этот момент, когда он ещё не вырос, и недоучен, он не является полностью дееспособным. Затем он эксплуатирует (сам себя! У него самопринадлежность), и обеспечивающие системы не показаны – вместо них мы находим множество систем в его операционном окружении. Да, в это же время идут «ремонты» (врачи) и «модернизации» (учёба, физподготовка), но чаще всего на диаграммах жизненного цикла это не отражается. А затем доктора его лечат, а микробы прекращают существование тела.

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

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

Вот пример, который показывает, как целые цепочки жизненных циклов связаны через стадию эксплуатации, ибо стадия эксплуатации обеспечивающей системы – это когда она участвует в работах жизненного цикла целевой системы, и это может распространяться на несколько уровней.

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

Есть более простой способ показывать диаграммы жизненного цикла обеспечивающих систем: жизненный цикл на них рисуется изображающими время стрелками с зарубками, отделяющими стадии жизненного цикла, а отрезки работы обеспечивающей системы над соответствующей целевой системой показываются фигурной скобочкой на линии времени:

На таких диаграммах удобно рассказывать истории типа «мы организуем стартап, который создаст САПР, при помощи которого мы затем спроектируем топор, при помощи которого мы потом будем колоть дрова» – и для каждой системы в такой диаграмме понятно, что она проходит довольно долгую жизнь перед тем, как быть использованной/проэксплуатированной.

Есть два разных понимания эксплуатации в части представления ремонтов (обслуживания, maintainance – конструкция и функциональность остаются прежними) и модернизации (modernization, частичное изменение функциональности и конструкции):

• Эксплуатация как стадия включает в себя все эти работы. Главные люди – операторы и пользователи. Ремонтники и инженеры по модернизации отдельно не учитываются.

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

Это лишний раз подчёркивает условность отнесения работ к разным стадиям.

 

Три времени жизненного цикла

В жизненном цикле есть три явно выделенных времени, которые нужно удерживать в сознании всё время работы с целевой системой:

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

2. Время самого жизненного цикла, которое включает кроме времени эксплуатации ещё и другие стадии – от замысла до прекращения существования воплощения системы.

3. Методологическое время, в котором мы думаем о всех этих временах. Это самое трудное время, но его легко понять, если вспомнить про 4D, в котором по определению у систем (целевой, обеспечивающих, в операционном окружении) нет ни «уже», ни «ещё», они все одновременно присутствуют. Но думаем мы обо всех этих временах как бы находясь вне этого времени.

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

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

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

 

Понятие практики

Как и для любых других определений системы, ключевым для определения обеспечивающих систем является её компонентное, функциональное определение, отвечающее на вопрос «как работает?». Компонентами/функциональными элементами обеспечивающих систем как систем человеческой деятельности являются практики (practices).

Сегодня часто кроме слова «практика» говорят и «процесс» (process) – за последние пять лет слово «процесс» перестало всегда означать развёртку во времени/работы и приобрело оттенок указания на функциональный аспект работ, а не только модульный/конструктивный в части управления процессами или управления проектами.

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

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

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

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

Формула для запоминания: «в практике дисциплина загружается в голову, а технология разворачивается на местности».

Практика прежде всего компонента обеспечивающей системы, это функциональный объект, а работа с функциональными объектами контринтуитивна.

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

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

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

Управление жизненным циклом (life cycle management) обсуждает управление конфигурацией, изменениями и логистику для работ, предназначенных для выполнения всех необходимых в ходе жизненного цикла практик (это архитектура предприятия, взятого в его деятельностной динамике). Это про гладкое прохождение производственных актов DEMO.

Архитектура предприятия (enterprise architecture) обсуждает главным образом распределение полномочий по использованию ресурсов труда (компетентные в исполнении работ практики исполнители) и технологии (задействование инструментария, сырья, других рабочих продуктов). Она обеспечивает гладкое прохождение координационных актов DEMO.

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

 

Дисциплина в составе практики

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

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

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

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

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

Есть ли какой инструментарий (технология) для системного мышления как дисциплины, технология? Да, конечно: это всевозможные моделеры, позволяющие делать модели самых разных систем. Тем самым системное мышление вполне возможно считать практикой: содержание её загружается в голову, а на местности необходимо развернуть инструментарий моделирования систем, поддерживающий частные описания (view), методы описаний (veiwpoints), управление конфигурацией полного описания (description).

Но именно дисциплина определяет, какой технологией она может быть поддержана, а не наоборот. Функциональную нагрузку в практике несёт именно дисциплинарная часть, и именно по дисциплине называют всю практику на конкретном предприятии.

Дисциплина в практике меняется относительно редко, чаще всего речь идёт о цикле изменений в 20 лет, а то и больше. Например, системный подход относительно стабилен, знания его текущей версии помогут пару десятков лет. А вот технологии меняются много чаще. Моделеры для того же системного подхода меняют свои поколения каждые 4—5 лет (средняя скорость смены поколений в информационных технологиях), но они при этом по факту поддерживают одну и ту же много медленней меняющуюся дисциплину.

Тем не менее, быть успокоенным владением какой-то дисциплиной нельзя. Так, состояние state-of-the-art (SoTA, лучшее известное на сегодняшний момент) дисциплины попадает в учебники лет через пять, ещё пять лет проходит в ВУЗе, и всего через десять лет работы можно обнаружить, что владеешь каким-то уже совсем антикварным пониманием дисциплины. Например, большинство сегодняшних инженеров, менеджеров, предпринимателей и даже спортсменов и танцоров если и знают хоть как-то системный подход, то устарелую его первую версию, в которой ещё нет стейкхолдеров, жизненный цикл означает только работы. Нельзя успокаиваться, нужно отслеживать не только относительно частые смены технологии в практике, но и относительно редкие изменения в дисциплине.

 

Технология в составе практики

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

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

Так, программы проектного управления могут поддерживать самые разные дисциплины проектного управления, самые разные наборы альф. Например, управление проектами может быть классическим с альфой «критический путь» (critical path) и по теории ограничений с альфой «критическая цепь» (critical chain) и управлением по заполнению буферов проекта. Если вы не понимаете связи между инструментами и дисциплинами, и купите просто «программу управления проектами», то вас может ожидать сюрприз.

В программе управления проектами на рисунке (Рис. 5) нет никаких буферов проекта, поэтому она не поддерживает мышления согласно дисциплине управления проектами теории ограничений.

А вот эта программа (Рис. 6) поддерживает, «светофоры» буферов хорошо видны на её скриншотах.

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

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

Развитие (development) предпринятия происходит тогда, когда меняется практика в части дисциплины и неминуемо происходит смена технологии для поддержки этой дисциплины.

При развитии люди образовываются (education, «как в ВУЗе») для освоения новой дисциплины мышления и обучаются/тренируются (training, часто на рабочем месте) в работе с новой технологией, новым инструментарием.

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

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

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

 

Практики жизненного цикла

Множество примеров практик, встречающихся на протяжении жизненного цикла системы (их часто так и называют – практики жизненного цикла, life cycle practices), можно встретить в различных инженерных стандартах и публичных документах, и наиболее типичны тут своды знаний (body of knowledge, корпус знаний), описывающие различные варианты практик какой-то более-менее крупной дисциплины.

Все эти стандарты и публичные документы используют для практик разные названия – практика (practice), способности (abilities), процессы (следуя традиции «функционального описания процессов», заложенной серией стандартов ISO 9000, в которых путались модульный/конструктивный «процесс как последовательность шагов/операций/работ во времени» и компонентный/функциональный «процесс как описание принципов, каким способом нужно достичь результатов»), методы (наборы практик, достаточных для решения какой-то содержательной задачи «под ключ»), и даже методологии (ISO 24744 предложил считать метод/method и методологию/methodology синонимами), иногда «область знаний» (knowledge area), с которой связывают какую-то «деятельность» (activity). Иногда и вообще не используют каких-то терминов – просто говорят, «что нужно делать», приводя название практик, но не используя сам термин.

• свод знаний по организационному анализу (business analysis body of knowledge, BABoK). Тут в главе 10 кратко охарактеризован набор из 50 практик, называемых «метод», начиная с 10.1 Acceptance and Evaluation Criteria (Определение критериев приемки и оценки), 10.2 Backlog Management (Управление бэклогом), 10.3 Balanced Scorecard (Сбалансированная система показателей, ССП), 10.4 Benchmarking and Market Analysis (Бенчмаркинг и Анализ рынка), 10.5 Brainstorming (Метод мозгового штурма), 10.6 Business Capability Analysis (Анализ бизнес-возможностей), 10.7 Business Cases (Бизнес-кейсы), …, 10.47 Use Cases and Scenarios (Сценарий использования и Сценарии), 10.48 User Stories (Пользовательские истории), 10.49 Vendor Assessment (Оценка поставщика), 10.50 Workshops (Воркшопы или Семинары)

• свод знаний по проектному управлению института проектного управления (Project Management Institute, project management body of knowledge, PMI PMBoK). Там практики называют «процесс», например, группа процессов планирования определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов, и т. д. (всего 47 процессов в актуальной 6 версии PMI PMBoK).

• свод знаний по системной инженерии (systems engineering body of knowledge, SEBoK). Сами практики тут не выведены явно, а рассыпаны по всему тексту. Это, скорее, «краткое оглавление для большой литературы по предмету системной инженерии», поделенное на «области знаний».

• … множество других BoK, это сегодня стандартная форма выражения знаний по практикам какой-то инженерной или менеджерской дисциплины.

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

Не уделяют они внимания и вопросам выбора варианта функционально одинаковых практик, оставляя этот выбор за человеком-актёром, готовящимся к выполнению какой-то стейкхолдерской роли. Например, есть набор практик проектного управления PMI PMBoK, но есть и альтернативый вариант, APM BoK – и нужно выбирать, каким набором практик пользоваться для изучения дисциплины. Абсолютно не исключено, что разные группы компетентных в той или иной практике людей будут рекомендовать использование своего варианта, несовместимого с другими, и без дополнительных исследований при выборе будет не обойтись.

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

Но и дальше может быть деление: например, в инженерии требований можно выделить практики выявления потребностей и требований, анализа требований, специфицирования (документирования) требований, управления требованиями.

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

 

Пример: практики жизненного цикла системной инженерии

Стандарт практик жизненного цикла системной инженерии ISO/IEC/IEEE 15288:2015 Systems and software engineering – System life cycle processes устанавливает общий подход к описанию практик для описания жизненного цикла систем, созданных людьми. Он определяет набор практик и связанную с ними терминологию в инженерном методе описания. Эти практики могут быть применены на любом уровне иерархии в структуре системы. Выбранный набор этих практик могут быть применены в ходе всего жизненного цикла для управления и выполнения всех стадий жизненного цикла системы. Это достигается через вовлечение всех стейкхолдеров, с главной целью достижения удовлетворения клиента (establishes a common framework of process descriptions for describing the life cycle of systems created by humans. It defines a set of processes and associated terminology from an engineering viewpoint. These processes can be applied at any level in the hierarchy of a system’s structure. Selected sets of these processes can be applied throughout the life cycle for managing and performing the stages of a system’s life cycle. This is accomplished through the involvement of all stakeholders, with the ultimate goal of achieving customer satisfaction).

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

Стандарт задуман так, чтобы проверять: если вы выполняете все эти практики, то вы занимаетесь системной инженерией. Если не выполняете – то это просто инженерия.

Но тут нужно предостеречь, что этот стандарт, как и все остальные всевозможные BoK, описывает отнюдь не минимум или оптимум использования разных практик для достижения результата какой-то конкретной деятельности в конкретном проекте, а, скорее возможный максимум в абстрактном проекте.

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

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

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

 

Методологии

Популярные методологии разработки (development process), т.е. разные варианты agile, «гибкая методология разработки»), обеспечения качества (six sigma), преодоления барьера между разработкой и эксплуатацией (DevOps и DataOps), и даже социализации в танце (социальные танцы – танго, кизомба, сальса, самба) оказываются все наборами практик жизненного цикла, разве что не всех стадий.

Методологии часто содержат в себе три части:

• Общее описание дисциплины для многих составляющих методологию практик. Эта дисциплина вводит альфы, а отдельные практики потом могут работать с подальфами этих альф. Например, agile-практики вводят альфу backlog как «список хотелок». Практики ТРИЗ-методологии используют понятие «идеального конечного результата», социальные танцы работают с понятием «коннекшн»

• практики как инструкции что и как нужно делать. Их обычно много разных, они могут вводить свои подальфы.

• указания на то, как сочетать практики с работами в ходе жизненного цикла, то есть выход на практики управления работами, прямые указания на управление жизненным циклом, вид жизненного цикла. Иногда даже слова «методология разработки» используют именно как указание на этот аспект (подменяя этим слова «вид/модель жизненного цикла»).

Сегодняшний тренд – это разборка крупных методологий на отдельные практики. Если ещё лет десять назад считалось, что нужно обязательно использовать в работе все описанные какой-то методологией практики, и без любой из описанных результат будет плохим, то сегодня такого уже нет. Для методологий разработки Ивар Якобсон (один из соавторов стандарта OMG Essence) призывает «освободить практики от методологий», ибо они являются отличными единицами накопления опыта – его доклад на SECR’17 так и называется: «Kill All Methods – Free the Practices».

Интересно, что это относится даже к танцевальным методологиям, повсеместно происходит переход к fusion dance (смеси разных практик танцевальных стилей, определяемых разными методологиями – и помним, что практика в танце поддерживается не только дисциплиной/теорией, но и инструментарием в виде тела и звучащей музыки, поэтому объединение практик танца из разных его стилей требует дополнительного развития тела).

Сами методологии тоже не ограничиваются практиками, взятыми из какой-то одной сферы человеческой деятельности. Так, agile-методологии появились как некоторый сплав (fusion) инженерных и менеджерских практик, хотя за последний десяток лет там практически не осталось инженерных практик, но только менеджерские, а методологии проектного управления всё больше и больше обращают внимание на инженерные аспекты разработки (в последние годы в них даже появляются отдельные практики инженерии требований, хотя и совершенно недостаточные для полноценной инженерной работы).

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