Разговор о «стадийности» жизненного цикла всё больше и больше становился условным, а не сущностным/содержательным. Работы и ресурсы обсуждать было продуктивно (операционный менеджмент!), а вот стадийность работ уже нет. И поэтому понятие жизненного цикла как набора стадий как «укрупнённых работ похожей направленности» стало не очень удобным в использовании.
Вот типичная картинка объяснения перехода к параллельной инженерии (и на ней хорошо видно, что сроки всех работ по созданию системы при этом существенно сокращаются)31:
Вторая проблема понимания жизненного цикла как последовательности крупных «тематических» работ: интерфейсы между работами обсуждались с точки зрения потока работ, операционного менеджмента, доступности ресурсов в проектном управлении. Результаты предыдущих работ/output становятся доступны для следующих в цепочке потока работ/input. Это было очень удобно, когда речь шла о точном ответе на вопросы стадии «как сделать работы»: «когда и кем будет выполняться работа, когда она будет закончена?». Но когда обсуждались функциональные вопросы (как вообще этот набор работ создаёт систему? Почему эти работы, а не другие?), как лучше в части технологии (а не как быстрее, то есть инженерный вопрос, а не менеджерский) выполнить работы, то понятий не хватало. Нужно было обсуждение того, как и зачем менять содержательно набор работ, а не оптимизировать время запуска каждой предварительно известной откуда-то работы или оптимизировать ресурсное снабжение каждой предопределённой кем-то работы информации категорически не хватало: нужна была информация о видах работ, назначении работ и их содержании, а не о самих работах и их ресурсах безотносительно их содержания.
⠀
Практики
⠀
Модульное/продуктное/конструктивное представление работ жизненного цикла «как в управлении проектами» очень нравилось менеджерам, а вот для инженеров оказывалось недостаточным, как это обычно и бывает в системном подходе: область интересов инженеров отличалась от области интересов менеджеров, занимавшихся операционным управлением. Для проектирования, «изготовления», «наладки» самой последовательности работ (то есть проектирования, изготовления, наладки создателей/оргзвеньев, выполняющих эти проектирования, изготовления, наладки работ) нужно было выходить на функциональное/ролевое представление, обсуждать виды работ с точки зрения их ролевого назначения/функций, а оргзвенья создателей рассматривать в их оргролях. Работы как поведение/«экземпляры сервисов ресурсов»/«конструктивных объектов»/оргзвеньев должны выполнять функции/практики функциональных/ролевых объектов/оргролей в создателях, удобных для обсуждения «как работают системы создания, чтобы целевая система меняла своё состояние в ходе жизненного цикла и становилась успешной». Что именно делает Вася Пупкин, не понимая его текущей роли всегда непонятно (он своей «работой» играет роль Отелло? Принца Гамлета? Офелии? Видно, что Вася Пупкин занят, работает. Но что и зачем он делает?!). Что делает та или иная работа для менеджера-проектировщика (который вроде как должен её запроектировать) непонятно, нужно смотреть на задаваемое прикладным инженером «содержание работы»/«способ работы»/метод/практику/«функциональную ипостась работы».
Рассмотрение поведения систем создания как функций оргролей/проектных ролей/деятельностных ролей в жизненном цикле произошло не сразу: ресурсы в системах создания ведь были конструктивными объектами, и как системы с их ведущим пониманием как именно функциональных объектов не воспринимались! Систем создания не было как систем, не было системного рассмотрения! «Оргроли» при этом это всё те же функциональные/ролевые объекты, которые играются оргзвеньями. «Орг» просто подчёркивает, что речь идёт об организации, то есть существует договорённость о том, кто может просить исполнителя роли выполнить работы этой роли. Проектная роль тут подчёркивается, что речь идёт о проекте. Деятельностная роль что речь идёт о множестве проектов и множестве организаций. Но в принципе это всё про одно и то же: это функциональные/ролевые объекты, которые выполняют содержательные действия в организационной системе как системе создания целевой системы (включая все цепочки создания, если это оказывается нужным). Об этой же оргсистеме говорилось и как о «системе ведения жизненного цикла целевой системы», а сейчас говорят как о «системе создания и развития целевой системы», то есть системе-создателе или даже просто создателе. Оргроли, проектные роли, деятельностные роли это всё роли в создателе.
Переход к диаграммам типа принципиальных/функциональных схем для систем создания произошёл постепенно (и помним, что во всех этих диаграммах было отражено не создание и последующее развитие/эволюция системы, а однократное прохождение «не жизненного не цикла» это «отрезки», а не «кольца/циклы»). После классических «колбасок» для стадий жизненного цикла поначалу появилось множество гибридных диаграмм, пытавшихся отразить сразу и конструктивную/логистическую и функциональную/назначения ипостаси жизненного цикла как поведения систем создания. И это не случайно: ключевые/концептуальные решения по устройству жизненного цикла это решения о том, какие оргроли будут выполняться какими оргзвеньями, а в другой формулировке какими работами будут выполнены те или иные практики/виды работы/деятельности. Это принятие решений по концепции жизненного цикла (по аналогии с концепцией системы) и организация выполнения этих решений стали называться управлением жизненным циклом (life cycle management, ср. work management/управление работами. В управлении работами нет концептуальных решений по жизненному циклу: не идёт речь о содержании и технологии работ, то есть о практиках, но только о длительности работ и потребных ресурсах безотносительно к «способу выполнения работ»/«way of working»/методу).
Одной из самых известных гибридных для управления жизненным циклом и управления работами диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP)32:
В этой диаграмме 1996 года уже видно, что кроме безымянных «итераций» как групп работ, по-старинке разбитых на «стадии» во времени, появился новый тип объекта, практика (practice, деятельность, род/вид работы, труд, инженерия как изменение чего-то в мире каким-то явным способом), именованная по её теоретической инженерной или менеджерской дисциплине (discipline, теория).
«Практика» и есть культурно-обусловленное функциональное/ролевое поведение создателей. Работы оргзвеньев выполняют роль тех или иных практик культурно-обусловленных оргролей, а жизненный цикл состоит как раз из работ по этим методам/практикам, называемых по их дисциплинам (а иногда слово «дисциплина» включает и собственно «теорию», и использование материалов и инструментов то есть отсылает к самому методу/деятельности/инженерии, а не только к теоретической их части).
⠀
Роли и практики, объекты и их поведение неразлучны, всегда вместе. Системный архитектор (роль) выполняет практику системной архитектуры (поведение роли). Авиапредприятие (роль) выполняет практику строительства самолётов (поведение роли). И не надо сочинять каждый раз роли и практики «с нуля», надо брать их из культуры, они культурно-обусловлены, они определяются успешно реплицирующимися (и при этом эволюционирующими) мемомами этих практик. Если раньше практика свидания включала шаблон «под часами» (хороший ориентир плюс возможность сверить время), то сейчас мобильная связь привела к тому, что шаблон не выжил свидание назначается в приблизительно условленном месте в более-менее приблизительное время, а «точная встреча» уже корректируется с учётом доступной технологии, практика свидания изменилась, эволюционировала. Поэтому культурная обусловленность:
Включает общеизвестность мемома практики: если кто-то что-то как-то делает, то он вряд ли придумал свой метод сам. «Взял из воздуха» это задействовал те мемы, которые у него уже были. Может быть, где-то уже есть мемы и получше, более современные. Но «изобрёл практику» это крайне редкая ситуация.
Привязана ко времени. Так, дисциплина Requirements в диаграмме 1996 года была очень и очень современной, культурно-обусловленной. А сейчас это воспринимается как анахронизм, привет из прошлого.
⠀
Как проверить культурную обусловленность? Обычно по культурно-обусловленным практикам есть учебники. А если это кулибинство/«я сам придумал!»33, то учебника обычно нет и дальше вам принимать решение: учебника нет, потому как речь идёт о фронтире, и учебник не успели написать, или учебника нет, потому как этот кривой свежесочинённый метод работы отражать в учебнике ни в коем случае нельзя, или просто не знаем об учебнике (но он в реальности был, а как выполнять практику мы подглядели у человека, который по этому учебнику учился. Но о том, что он учился по учебнику, мы даже не знаем). Методология не учит, что делать в этом случае, но заставляет удерживать во внимании практики работы и интересоваться их культурной обусловленностью.
Работы разных практик как-то распределены по времени жизненного цикла в его начальном (1.0) представлении как «последовательности работ». В RUP это работы по практикам организационного моделирования/business modeling (помним про перевод business как «организационный»), инженерии требований (уже устарела со времён популярности RUP), анализа и проектирования (анализ как отдельная подпрактика не рассматривается, он включается в проектирование), разработки (границы этой практики определяются сейчас по-другому), испытаний (сегодня это «инженерные обоснования»/quality assurance), разворачивания (но вот delivering нет как «введение в эксплуатацию»), управления конфигурацией и изменениями, управления проектом, работы с окружением. И это никак не закольцовано, хотя и выделены «порции работ по всем практикам вместе» как «итерации» но это просто «постепенное достижение конечного результата», а не создание и потом развитие, развитие, развитие, то есть не длительная эволюция без явного достижения заранее определённой цели. Нет, подразумевается, что «определили требования, повозились, удовлетворили требования всё, проекты жизненного цикла закончены, даже если этих проектов было несколько, всё развитие как продолжение работы над системами подобного класса за рамками жизненного цикла».
Эти работы делятся на стадии, а потом на более и более мелкие работы в классическом разбиении работ (work breakdown structure, WBS) из проектного управления, в то же время практики (названные на «горбатой диаграмме» по их дисциплинам) отражают разделение труда (division of labor).
Разделение труда (практик, деятельности, инженерии) на качественно различные виды не нужно путать с разделением работ, которое количественно. Разделение работ обсуждает, как много работы разбить по ресурсам (например, если нужно выполнить однородную работу вдвое быстрее, то нужно поставить вдвое больше людей, или использовать станок с большей производительностью), а вот разделение труда обсуждает, как практику для одного исполнителя с одной ролью разбить на подпрактики, у которых в качестве их исполнителей возможны разные агенты, которые будут играть по этим подпрактикам разные роли как подроли общей роли для начальной общей практики. Дальше исполнитель подпрактики может углубить своё мастерство, ибо он не должен тратить время на выполнение всей общей практики и может достичь уровней мастерства выше, чем по начальной практике без разделения труда.
Врач раньше занимался всеми дисциплинами, а потом прошло глубокое разделение врачебного труда, и врач-гинеколог начинает существенно отличаться по своей квалификации от врача-дантиста. Веб-мастер занимался всеми работами по небольшому вебсайту, а потом прошло глубокое разделение труда, и этими же работами занимаются программист бэк-энда, программист фронт-энда, дизайнер, контент-менеджер, редактор и ещё много других деятельностных ролей. Инженер раньше был «просто инженер», а сегодня без уточнения того, какой именно это инженер, сказать ничего нельзя. И так практически со всеми практиками. Там, где был один учебник одной дисциплины, появляется десять учебников по десяти дисциплинам.
Работы это про количество работы и её скорость, а труд/деятельность/практика это про назначение и разнообразие видов/родов/сортов/способов работы и их уместность/полезность/назначение/роль в проекте.
На горбатой диаграмме в строчке каждой практики показано, что интенсивность этих работ разная в разные моменты жизненного цикла (и это будет отражаться также и в ходе закольцовывания такой диаграммы или разбития её на поддиаграммы для множества команд, занимающихся развитием тех или иных фич системы в ходе её развития/эволюции, а не только однократного проектирования-изготовления-использования, как это подразумевается оригинальной линейной диаграммой): специализирующиеся на разных практиках роли то больше, то меньше задействованы для выполнения работ жизненного цикла в разные его моменты. Тем самым на графике зависимости интенсивности работ от времени появляются «горбы», отсюда и название «горбатая диаграмма». Напомним, что работы это взаимодействующие продукты/люди/оборудование/ресурсы, участвующие в выполнении сервиса/поведения оргзвена из жизненного цикла. Но работы выполняют какие-то практики (поведение взаимодействующих функциональных/ролевых единиц), они определяются этими практиками.
В 21 веке описания жизненного цикла перестали обсуждаться как описания только поделенных на стадии работ. Эти описания включили в себя и практики: основные (не все! Описания жизненного цикла обычно делаются на уровне концепции, а не детального проектирования) практики оргролей, которые выполняются как производимые оргзвеньями работы. Концепция создателя как концепция системы это не только функциональная/деятельностная/ролевая декомпозиция ролей как подсистем создателя, но и декомпозиция их поведений, то есть практик, а также не только конструктивный/продуктный/модульный синтез организации/оргзвеньев, но и синтез работ. Для полноценного системного рассмотрения создателей нужны и оргроли, и оргзвенья, и их поведения (практики/функции и работы/сервисы) и дальше размещения и стоимость. Упоминание жизненного цикла (линейного однократного «не цикла», или включающего развитие, «цикла, хотя и без размножения») это указание не столько на целевую систему, сколько на поведение систем создания, рассматриваемых и как организационные роли и практики этих ролей, и как назначенные на оргроли оргзвенья и выполняемые ими работы, реализующие практики этих ролей.
Жизненный цикл скворечника на вчера рассматривался как главным образом плотницкая практика, реализованная плотницкими работами, выполняемыми Фадеем (оргзвено) в оргроли плотника, а всего несколько лет назад он бы рассматривался как работы Фадея, и неважно по какой практике (плотницкая практика подразумевалась, но явно не обсуждалась). Сегодня понятие «жизненного цикла скворечника» было бы размыто, и больше бы говорили про программу создания и развития скворечника ибо ожидались бы какие-то непрерывные улучшения в конструкции и материалах скворечника, способах его изготовления, и ещё бы неявно в рассмотрение попал Фадей и его мастерство плотника.