Системное мышление 2019 Левенчук Анатолий

V-diagram

Самым упрощённым, популярным и распространённым представлением жизненного цикла в его современном виде является V-диаграмма (V-diagram, Vee diagram), популяризованная в 1991 году Kevin Forsberg179:

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

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

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

• Информация о системе, выраженная в требованиях, архитектуре и неархитектурной части проекта/design

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

Дальше линия времени делает перегиб, и логически начинается вторая стадия воплощения системы (system realization). Словосочетание «воплощение системы» тем самым тоже используется в двух значениях:

• Сама система как 4D индивид (как пространственно-временной экстент в физическом мире)

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

Сам излом V нужен для того, чтобы показать суть верификации и валидации: изготовление деталей (неделимых далее в проекте модулей) системы делается и проверяется (verification) в соответствии с проектом/design, стрелки верификации показывают именно этот факт. Ради показа этих стрелок проверки соответствия определения и воплощения и сделана сама V-диаграмма: она показывает способ работы, в котором воплощение/создание системы (system realization) происходит не путём проб и ошибок, сразу работы с материалом, а сначала путём размышлений и моделирования – определения системы (system definition). И созданная (изготовленная в виде деталей, а затем собранная из этих деталей) система проверяется на соответствие её предварительно разработанному определению – эти проверки изображаются стрелочками на диаграмме.

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

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

Стадию вывода из эксплуатации на V-диаграммах изображать так и не начали. Это отражает постепенное восприятие системного мышления инженерами: сначала идея жизненного цикла проекта разработки системы (то, чем занимаются системные инженеры в своём проекте), потом охват мышлением стадии эксплуатации, и только в самое последнее время (уже в 21 веке, начиная со стандарта ISO 15288, первая версия которого вышла в 2002 году) умолчанием является обязательное рассмотрение полного жизненного цикла – в том числе и (инвестиционный) замысел, и вывод из эксплуатации/уничтожение после использования.

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

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

Моделеориентированность в жизненном цикле

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

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

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

Мы не тратим силы на обсуждение и обработку ненужных деталей моделируемого объекта. Модели – это «правильные упрощения».

Формальную (на основе математики) модель можно относительно легко проверить на формальную правильность – вручную или даже компьютером. Это называется проверкой моделей (model checking). Так, в радиосхеме можно формально удостовериться, что все её компоненты соединены и нет неприсоединённых компонент, все соединения не имеют разрывов (то есть не идут откуда-то в никуда).

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

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

Формальную модель можно не делать руками, а породить (generate) компьютером – это решение проблемы сложности. Так, 21 миллиард транзисторов в современном микрочипе183 невозможно нарисовать руками на кремниевой пластине, и даже невозможно руками нарисовать принципиальную схему такого микрочипа. Но можно породить и принципиальную схему, и литографическую маску из моделей более высокого уровня на языке описания микросхем.

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

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

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

Иногда V-диаграмму c опорой на моделирование изображают так:

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

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

Есть два типа работы с моделями. Когда пара моделей связаны «через голову человека», то есть когда человек смотрит на одну модель и разрабатывает или проверяет другую модель, то это будет моделеориентированной (model-based) работой. Так, моделеориентированная системная инженерия (model-based systems engineering, MBSE) ориентируется на использование архитектурных языков и языков представления требований в определении системы. Но когда создаётся цепочка моделей, каждая из которых берёт данные логически предшествующих ей прямо в машиннообрабатываемой форме, без интерпретации этих данных человеком, это будет моделеуправляемой (model-driven)185 работой.

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

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

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

V-модели как модель декомпозиции системы

Ещё один вариант V-диаграммы показывает декомпозицию системы по системным уровням, определяемым отношениями часть-целое186:

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

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

Общий принцип «соответствие воплощения определению» тут показывается на каждом уровне – собранные и испытанные 4D-индивиды систем/подсистем/элементов каждого уровня удовлетворяют своим определениям.

Как и многие другие диаграммы системного мышления, V-диаграмма подразумевает рекурсивное применение, она применима на каждом системном уровне.

Гибридные модели жизненного цикла

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

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

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

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

Авторам диаграммы для объяснения того, как будет работать обеспечивающая система в капитальном строительстве, явно не хватает упоминания практик. На какой стадии они планируют использовать практику управления проектом? На всех! На какой стадии они будут учитывать практики работы с новыми материалами, методами, оборудованием? На всех! И поэтому авторы диаграммы пририсовывают плашки практик, расположенные по всей длине жизненного цикла.

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

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

Управление работами и управление жизненным циклом

Стадии жизненного цикла в водопадном виде жизненного цикла заканчивались предварительно запланированными гейтами, в которых независимыми экспертами оценивались собранные в единое целое результаты предыдущей стадии и принималось решение о продолжении проекта на следующей стадии (go/no-go). Если до заранее запланированного рассмотрения проекта независимыми экспертами в рамках прохождения гейта кто-то из разработчиков частей системы не успевал закончить разработку своей части и проверку того, насколько она не нарушает работу всей системы в целом, то весь проект ждал окончания работ этого разработчика. Гейты как раз и были задуманы, чтобы выявить системные риски появления конфигурационных коллизий, неочевидных системных эффектов, непредвиденных трудностей в разработке отдельных частей системы. И если не включить в рассмотрение результаты чьей-то частной работы, то появляется риск неучёта каких-то системных эффектов в целой работе.

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

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

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

Виды практик управления работами

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

Классическое управление проектами (project management, проектное управление) подразумевает одномоментное планирование перед началом всех работ для всех контрольных точек как сроков их достижения, так и работ по их достижению (то есть назначение ресурсов на работы происходит в момент планирования всех работ сразу, а не каждой отдельной работы).

По факту это означает составление плана-графика выполнения работ с назначением ресурсов на эти работы ещё до начала выполнения работ.

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

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

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

Если непонятно, какие могут быть контрольные точки больших кусков работы, то речь идёт об управлении программами (program management).

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

Управление программами отличается от остальных методов управления работами тем, что отношение часть-целое в них меняет тип управления работами, а в остальных методах нет: в программах обычно нет «подпрограмм», но есть «проекты».

В проектах же обычно подпроекты, в процессах подпроцессы, в кейсах подкейсы и т. д.

Если контрольные точки и ресурсы для их выполнения известны, но неизвестно, в какой момент происходит запуск большого числа однотипных работ, речь идёт о процессном управлении (process management).

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

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

Эти гибкие методологии считают относящимися к разновидностям спиральной модели.

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

Общее для всех этих гибких методологий/методов и соответствующих им видам жизненного цикла в том, что они используют в части управления работами управление кейсами (case management)189.

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

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

Тут могут быть использованы удобные для управления кейсами методы планирования, например, канбан (Kanban for development190 для управления кейсами прежде всего, для планирования производственных процессов используется обычно Kanban for manufacturing191). И даже тут жизнь контрольной точки в управлении кейсами не заканчивается, потому как в рамках управления изменениями конфигурации нужно сообщить участникам проекта, что кейс закрыт: состояние системы изменилось, и всем остальным нужно ориентироваться на новую ситуацию.

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

Конечно, если появляется возможность что-то спланировать, в управлении кейсами это делается.

Часто тут план – это просто опыт прохождения какого-то кейса, шаблон. Вот этот план и будет называться шаблоном (template).

Если шаблоны готовят не специально обученные программисты таких шаблонов, а сами участники команды проекта, то такое управление кейсами называют адаптивным (adaptive), а шаблоны – шаблонами сообщества (community template).

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

Вот схематическое изображение жизненного цикла одного из самых распространённых методов гибкой (agile) работы, SCRUM193:

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

Тренды в практиках управления работами

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

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

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

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

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

При указании варианта жизненного цикла команде не нужно говорить SCRUM, или DSDM195, или Open Kanban196, или приводить ещё какие-то названия больших методологий со многими практиками. Вряд ли сегодня какая-то команда использует эти методологии во всей их полноте. Но нужно явно и осознанно сказать, какие команда использует практики управления жизненным циклом и практики работы.

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

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

За пределами жизненного цикла

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

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

В последней версии ISO 15288:2015 даже появилась новая практика «6.4.1. Business or mission analysis process». Суть этой практики – понять, какую целевую систему берётся делать команда и определить, стоит ли её вообще делать, соответствует ли это стратегии компании.

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

В частности, можно указать на практику моделеориентированного концептуального проектирования (model-based conceptual design)197:

Интересы (perspective) замысла новой системы, то есть формирования нового проекта, оказывается предпринимательской (executives, высшие руководители), пересекающейся с определением соответствия стратегии, организационной (business management), потому как речь идёт о создании нового проекта (выделение организационных ресурсов на работы по проекту) и только отчасти архитектурно-инженерной (architect). При этом концептуальное проектирование пересекается с интересами моделеориентированной системной инженерии (model-based systems engineering), но уже не пересекается с использованием САПР (система автоматизации проектирования, CAD tools) для подготовки неархитектурной части проекта/design.

Окончание жизненного цикла системы тоже не всегда легко определяется. Система может ремонтироваться и модернизироваться так, что в её индивиде не останется уже ничего от предыдущей. Берём швабру, через некоторое время ломается ручка, меняем ручку, потом меняем перекладину – это та же швабра? Да, это та же швабра-система, только поменялись какие-то части. Швабра определяется по её функциональному описанию, если заменить наполнение конкретными модулями или даже поменять размещение, ничего страшного с системой не произойдёт.

Microsoft объявила, что Windows 10 будет её последней операционной системой, но непрерывно производит в ней изменения. Срок службы атомных электростанций сначала делали 60 лет, но сейчас продляют его до 80 лет. Жизненный цикл системы оказывается не содержащим чёткое заранее определённое число проектов перед выводом из эксплуатации/уничтожением после использования, и может не иметь чёткого срока окончания.

Жизненный цикл как архитектура деятельности

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

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

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

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

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

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

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

Системная схема проекта

Стандарт OMG Essence198 предложил набор семи основных (essence, существенный, основной) альф проекта программной инженерии. Мы немного доработали этот набор альф для более общего случая системной инженерии199, где информационные системы только один из многочисленных видов разрабатываемых систем. Эти альфы объединены в системную схему проекта (Рис. 8).

Оригинальный набор альф был получен путём экспериментального ответа на вопрос: какие объекты внимания команды присутствуют в каждом проекте разработки? Было рассмотрено более 250 проектов, и в системную схему попали только те из них, которые встречались буквально в каждом проекте.

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

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

Три области интересов (area of concerns) группируют эти семь альф по трём темам (помним, что «интерес» это интересующая разных стейкхолдеров тема, а не «чего хочется». «Чего хочется» это будет не сам интерес, а оценка/assesment интереса разными стейкхолдерами):

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

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

• Область интересов предпринятия (endeavor) относится к работам, технологии и команде – обеспечивающей системе. В проекте нужно управлять работами, управлять жизненным циклом (определять практики и способы назначения работ на практики), разворачивать и использовать технологии, поддерживать сотрудничество компетентной команды. Этим в команде занимаются операционные менеджеры (практики управления работами), CTO/CIO (chief technology/information officer, их прерогатива в отличие от системных инженеров и инженеров по специальностям работоспособность методологии разработки и производства, т.е. оргвозможности поставленных практик, особенно входящих в их состав технологий – практики технологического менеджмента), организаторы, управляющие талантами (практика поставки в команду компетентных в необходимых для практики дисциплинах сотрудников-актёров), лидеры (практики лидерства, обеспечения сотрудничества как качественного выполнения своих стейкхолдерских ролей членами команды).

Какая альфа главная на системной схеме проекта? С одной стороны, все альфы. Но с другой стороны – альфа воплощения системы, привязывающая все рассуждения по схеме к физической реальности (воплощение системы – 4D индивид). Это видно в том числе и по числу связей на диаграмме, воплощение системы имеет максимальное число связей: оно обеспечивает возможности, его используют стейкхолдеры (внешним стейкхолдерам нужно воплощение системы, это только инженерам нужно определение системы, чтобы с меньшим количеством проб и ошибок получить удовлетворяющее стейкхолдеров воплощение системы – и воплощение системы удовлетворяет этому определению системы), его в конечном итоге производит команда.

V-диаграмма и системная схема проекта

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

Вот, например, схема, полученная добавлением подальф определения и воплощения системы (Рис. 9).

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

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

На диаграмме хорошо видно, что возможности проекта определяются в том числе тем, как потребности стейкхолдеров фокусируют требования.

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

То же относится к системной архитектуре: она разрабатывается не любая, но её разработка сфокусирована на поддержке требований. И рабочая документация (non-architectural part of design, неархитектурная часть проекта/design, «рабочка») берётся не любая, её появление фокусируется архитектурой. Часто в инженерной документации требуют явно указать, какая архитектура вызвала те или иные инженерные решения в рабочей документации, какие требования вызвали те или иные архитектурные решения, какие потребности заставили сформулировать те или иные требования. Явное документирование этих связей называют трассировкой (trace). Трассировка помогает избежать типовых ошибок фокусирования, когда в проекте появляются лишние требования, или наоборот, недостаточно требований – какая-то потребность не ведёт ни к каким требованиям).

Члены команды выполняют практики жизненного цикла, работая с альфами проекта, продвигая их по состояниям к завершению проекта.

В приведённой диаграмме возможности, определение системы, стейкхолдеры и определение системы – это просто фрагмент основной схемы проекта, а все другие альфы к ним пририсованы.

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

Альфы – общий объект отслеживания команды

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

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

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

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

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