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

 

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

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

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

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

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

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

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

 

 

Системная схема проекта и основной жизненный цикл

 

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

 

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

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

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

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

 

 

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

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

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

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

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