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

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

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

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

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

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

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

Популярные методологии разработки(development process), т.е. разные варианты agile 168 168 https://en.wikipedia.org/wiki/Agile_software_development , «гибкая методология разработки»), обеспечения качества (six sigma 169 169 https://en.wikipedia.org/wiki/Six_Sigma ), преодоления барьера между разработкой и эксплуатацией (DevOps 170 170 https://en.wikipedia.org/wiki/DevOps и DataOps 171 171 https://en.wikipedia.org/wiki/DataOps ), и даже социализации в танце (социальные танцы 172 172 https://en.wikipedia.org/wiki/Social_dance – танго, кизомба, сальса, самба) оказываются все наборами практик жизненного цикла, разве что не всех стадий.

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

• Общее описание дисциплины для многих составляющих методологию практик. Эта дисциплина вводит альфы, а отдельные практики потом могут работать с подальфами этих альф. Например, agile-практики вводят альфу backlog 173 173 https://www.agilealliance.org/glossary/backlog/ как «список хотелок». Практики ТРИЗ-методологии используют понятие «идеального конечного результата» 174 174 http://www.triz.natm.ru/trizz/triz2_01.htm , социальные танцы работают с понятием «коннекшн» 175 175 https://ailev.livejournal.com/1315064.html

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

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

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

Интересно, что это относится даже к танцевальным методологиям, повсеместно происходит переход к fusion dance 177 177 https://en.wikipedia.org/wiki/Fusion_dance , пример fusion кизомбы с разными другими стилями см. в https://ailev.livejournal.com/1373388.html (смеси разных практик танцевальных стилей, определяемых разными методологиями – и помним, что практика в танце поддерживается не только дисциплиной/теорией, но и инструментарием в виде тела и звучащей музыки, поэтому объединение практик танца из разных его стилей требует дополнительного развития тела).

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

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

Самым упрощённым, популярным и распространённым представлением жизненного цикла в его современном виде является V-диаграмма(V-diagram, Vee diagram), популяризованная в 1991 году Kevin Forsberg 179 179 Forsberg, K., Mooz, H., 1991, «The Relationship of System Engineering to the Project Cycle», Chattanooga, Tennessee: Proceedings of the National Council for Systems Engineering (NCOSE) Conference, pp. 57—65., http://ife2010.wikispaces.com/file/view/SE+%26Project+Cycle,+Forsberg%26Mooz,+1995.pdf :

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

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