Системное мышление

Стандарт практик жизненного цикла системной инженерии ISO/IEC/IEEE 15288:2015167 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), т.е. разные варианты agile168, «гибкая методология разработки»), обеспечения качества (six sigma169), преодоления барьера между разработкой и эксплуатацией (DevOps170 и DataOps171), и даже социализации в танце (социальные танцы172 – танго, кизомба, сальса, самба) оказываются все наборами практик жизненного цикла, разве что не всех стадий.

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

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

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

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

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