Читать онлайн Системное мышление – 2022 бесплатно

Разные мышления

Человечество вырвалось из царства природы. Масса всех людей сегодня составляет 300 миллионов тонн, это вдвое больше массы всех позвоночных, которые существовали на Земле до появления человеческой цивилизации. Техносфера (вещество, переработанное людьми под свои нужды) может быть оценена в 30 триллионов тонн, это больше 50кг на каждый квадратный метр поверхности земли3.

И всё это за счёт того, что человечество освоило мышление.

Есть два основных цивилизационных пути, условно называемых «восточным» и «западным».

Условная «восточность» состоит в признании непостижимой сложности мира, невыразимости и непередаваемости человеческого опыта в постижении этого мира.

Условная «западность» состоит в опоре на рациональность. Рациональность – происходит от латинского ratio, означающего «причину», «объяснение», но также и «отношение», т.е. ассоциируется с делением на части, анализом. Конечно, рациональное (рассудочное, неинтуитивное, не «восточного» типа) мышление в равной мере помогает и синтезу, объединению в целое аналитически разъятого на части. Но в западной культуре исторически придаётся большое значение основанной на логике «аналитике», т.е. формализации и моделированию. Можно наблюдать результаты этого «западного» пути развития цивилизации, давшей современные науку и инженерию, менеджмент, рынок ценных бумаг как инфраструктуру предпринимательства4.

Увы, рациональному и логическому мышлению, равно как и многим другим видам применимого ко многим ситуациям мышления, в школе и ВУЗе сейчас прямо не учат, равно как прямо не учат и ограничениям в его практической применимости.

Сегодня среди педагогов преобладает мнение, что какому-то «хорошему» мышлению можно научиться на основе углублённого знакомства с предметами так называемого STEM5:

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

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

• Инженерия (engineering) – ей учатся инженеры-механики, электрики и прочие инженеры, часто и software engineers (с не слишком большим упором на знание computer science и data modeling). Тут тоже работают не столько с общим для всех мышлением, сколько с узким предметным мышлением инженера, ограниченным его специальностью.

• Математика (mathematics, позволяет получить алгебраическую компетентность, включая линейную алгебру, геометрическую компетентность (наглядная геометрия, потом с выходом в работу с современными системами автоматизации проектирования, 3D САПР), статистическая (в том числе байесовская статистика) компетентность, математическая логика. И ещё тут учитываем компьютерную математику, а не только математическую работу карандашом по бумажке6. Это ближе всего к обучению мышлению, но тем не менее это больше не про то, как думать о мире, а как рассуждать с уже формализованными моделями мира. По большому счёту, математика включается только после того, как мышление подготовило материал для применения математики, поставило формальную задачу.

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

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

Требования к мышлению

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

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

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

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

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

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

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

Место системного мышления среди других мышлений

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

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

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

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

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

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

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

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

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

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

И обязательно нужно учитывать, что речь идёт о лучших на сегодняшний момент (state-of-the-art) приёмах мышления. Базовые приёмы мышления относительно стабильны, но в 21 веке и базовые приёмы за время длинной человеческой жизни могут немного меняться, так что тут нужно быть начеку и вовремя переучиваться.

Вот некоторый далеко неисчерпывающий список видов мыслительных компетенций, составляющих эту «цивилизационную мыслительную платформу»:

• Логические основания рационального мышления7. Именно логика порождает из себя как отдельные мыслительные дисциплины разные варианты мышления. Логика как дисциплина сама по себе неуловима: это про все отдельные логики вместе, и про логики по отдельности – аристотелева логика, логика Талмуда, темпоральная логика как самостоятельные логики. В этом смысле логика подобна геометрии – это и все геометрии вместе взятые, и отдельно риманова геометрия в её отличии от евклидовой. Очень часто говорится не о «логике», а о её предмете – правильных рассуждениях, как делать выводы (inference) или даже о рациональности в целом как таковой и способах избегать ошибок интуитивного мышления «восточного» типа.

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

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

• Вычислительное мышление (computational thinking9), это подход к тому, как думать о моделировании с использованием компьютеров (computer, «вычислитель»). В рамках вычислительного мышления выделяют и умение поставить задачу, и умение разбить её на более мелкие части, и алгоритмическую компетентность, связанную с умением строить планы, и умение использовать математические модели, выраженные в алгоритмах для анализа данных. Computer science тоже тут, включая обсуждение понятия «вычислимости» или «оценки», различные парадигмы программирования, но также и моделирование, в том числе и инженерное моделирование, обработка данных научного эксперимента.

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

• «Безмодельное» мышление (model-free): компетенции в области сочетания коннекционистских (connectionism) распределённых представлений (distributed representations) и символьных (symbolic) представлений11. Это как раз та самая область, в которой сейчас происходит «революция искусственного интеллекта». К ней можно относиться просто как к ещё одной бурно развивающейся подобласти «вычислительного мышления» в целом, но есть много разных оснований вывести эти компетенции осознанного отношения к коннекционистским моделям в отдельный раздел.

• Системное мышление: мыслительные приёмы, описанные в нашей книге.

Варианты системного мышления

Системное мышление (systems thinking) – это мышление с использованием основных положений и приёмов системного подхода (system approach). Уже разработано много разных вариантов системного подхода, существенно отличающихся друг от друга в степени проработанности, используемой ими терминологии и деталях, но совпадающих в своих основах. Но и сами основы системного подхода претерпели существенное развитие с момента предложения в 1937 году биологом Людвигом фон Берталанфи общей теории систем. Вообще, подход (approach) – это когда разработанные в рамках одной дисциплины, одной предметной области понятия, методы мышления, приёмы действия применяются затем к другим дисциплинам и предметным областям. Общая теория систем была разработана главным образом на биологическом материале, а уж затем было предложено применять её положения ко многим и многим предметным областям.

С момента появления общей теории систем в 30-х годах 20 века на базе системного подхода возникали и умирали целые дисциплины. Например, так родилась в 1948 году и затем в семидесятых была предана забвению кибернетика. Поэтому до сих пор можно встретить старинные варианты системного подхода, существенно переплетённые с кибернетикой и несущие в себе все её недостатки, прежде всего попытку свести понимание мира как работы поддерживающих гомеостаз (т.е. неизменность своего состояния) систем с обратными связями. Самый распространённый вариант кибернетического системного подхода отражён в способе моделирования «системная динамика» (system dynamics12) и сводится к нахождению и явному отражению в модели каких-то связей, которые могут замыкаться в циклы, приводя к появлению колебаний. Такое «кибернетическое моделирование» сверхупрощено и плохо отражает самые разные виды систем, совсем не похожие на «регулятор Уатта».

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

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

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

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

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

Системная инженерия

Наиболее активно после биологии и менеджмента системный подход разрабатывался в системной инженерии (systems engineering). В последние годы увеличилось количество русскоязычных переводов инженерной литературы, и слово engineering не удосуживаются перевести как «инженерия», так и оставляют «инжинирингом». Перевод «системный инжиниринг» уже начинает побеждать – это легко отследить по результатам сравнения в интернет-поисковых системах. Можно считать, что «системная инженерия» и «системный инжиниринг» синонимы, но есть маленькая проблема: в России почему-то в тех местах, где занимаются инженерным менеджментом, а не инженерией, называют его тоже «системным инжинирингом» – хотя при этом никаких инженерных (т.е. по изменению конструкции и характеристик системы) решений не принимается, речь идёт только об организации работ по созданию системы. Так что будем считать «инженерию» и «инжиниринг» синонимами, но в случае «инжиниринга» проверять на всякий случай, не менеджмент ли имеется в виду вместо чисто инженерной работы.

Самое современное определение системной инженерии дано в Guide to the Systems Engineering Body of Knowledge (руководство по корпусу знаний системной инженерии14). Короткое определение: системная инженерия – это междисциплинарный подход и способы обеспечения воплощения успешной системы (Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems15). В этом определении можно подчеркнуть:

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

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

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

• Слово «воплощение» (realization, «перевод в реальность») означает буквально это: создание материальной (физической, т.е. из вещества и полей) успешной системы.

По-английски «системная инженерия» – systems engineering, хотя более ранние написания были как system engineering. Правильная интерпретация (и правильный перевод) – именно «системная» (подразумевающая использование системного подхода) инженерия, а не инженерия систем (engineering of systems) – когда любой «объект» обзывается «системой», но не используется системный подход во всей его полноте. Под инженерией систем16 (например, control systems engineering, manufacturing systems engineering) понимаются обычные инженерные специальности, там легко выкинуть слово «система», которое лишь обозначает некий «научный лоск». Предметные (не системные) инженеры легко любой объект называют «системой», не задумываясь об осознанном использовании при этом системного мышления, не используя системный подход. В самом лучшем случае про систему предметные инженеры скажут, что «она состоит из взаимодействующих частей» – на этом обычно разговор про «систему» и «системность» заканчивается, он не длится больше двадцати секунд. Занимающиеся «инженерией систем» очень полезны и нужны, но они не системные инженеры.

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

Более длинное определение системной инженерии включает ещё одну фразу: «Она фокусируется на целостном и одновременном/параллельном понимании нужд стейкхолдеров; исследовании возможностей; документировании требований; и синтезировании, проверке, приёмке и постепенном появлении инженерных решений, в то время как в расчёт принимается полная проблема, от исследования концепции системы до вывода системы из эксплуатации»17.

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

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

Системная инженерия поначалу применялась главным образом для борьбы со сложностью аэрокосмических проектов, и она была там крайне эффективна. Для того, чтобы маленький проект уложился в срок и бюджет, нужно было на системную инженерию потратить 5% проекта, что предотвращало возможный рост затрат проекта на 18%. Для средних на системную инженерию оптимально тратить было уже 20% усилий всего проекта, но если не тратить – возможный рост затрат проекта был бы 38%. Для крупных и очень крупных проектов оптимальные затраты на системную инженерию оказались 33% и 37% соответственно, и это для того, чтобы предотвратить возможный рост затрат проекта 63% и 92% соответственно18.

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

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

В результате системным инженерам удалось выполнить сверхсложные проекты – например, они в 1969—1972 году отправили на орбиту вокруг Луны 24 космонавта, а по самой Луне пешком ходили 12 человек19. Да что там пешком, рекорд скорости по Луне на луномобиле составил 18.6 км/час, при этом люди уезжали от ракеты на Луне на расстояние больше 7 километров! Достижения современной космонавтики, думаю, тоже не нужно рекламировать, даже с учётом того, что инженерное развитие в этой области было существенно искажено военными проектами, а инженеры развращены государственным финансированием. Но сложность космических проектов не позволяла добиваться успехов «обычной инженерией». Так, советская школа инженерии не смогла повторить достижений лунной программы, не смогла повторить многих и многих достижений планетарных программ, которых достигли в NASA. Конечно, у отечественной космонавтики есть и отдельные достижения (например, удачные ракетные двигатели), но при росте сложности проекта в целом неудачи начинают резко перевешивать достижения – типа четырёх неудач лунного старта Н-120.

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

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

Подробней про системную инженерию и её вариант системноинженерного мышления можно прочесть в учебнике «Системноинженерное мышление»21. Наша же книга посвящена версии системного мышления, универсальной для инженеров, менеджеров, предпринимателей, людей творческих профессий.

Вдобавок к инженерам «железных» и программных систем, системным подходом и его стандартами заинтересовались инженеры и архитекторы предприятий (enterprise engineers и enterprise architects), они начали адаптировать применение системного подхода к задачам менеджмента, а потом и к задачам предпринимательства.

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

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

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

Наш вариант системного подхода

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

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

Наш вариант системного подхода опирается на следующие версии стандартов и публичных документов (этот список далеко не исчерпывающий, приведены лишь главные источники22):

• Стандарт ISO/IEC/IEEE 15288:2015 Systems and software engineering – System life cycle processes задаёт само понятие системы и жизненного цикла, различает целевую и обеспечивающую системы, вводит понятие практик жизненного цикла.

• Обобщенный с исключительно архитектурного до полного описания определения системы стандарт ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description привносит множественность описаний и деятельностный подход. Это «поворот мозгов» от редукционистского подхода одностороннего описания к системному подходу, подразумевающему множественность связанных описаний, находящихся в различных информационных системах.

• Обобщенный от программной до системной инженерии стандарт OMG Essence 1.1:2015 – Kernel and Language for Software Engineering Methods задаёт метод описания жизненного цикла и его практик. Этот стандарт также вводит в управление жизненным циклом практику чеклистов/контрольных вопросов.

• Стандарт ISO 81346—1:2009 Industrial systems, installations and equipment and industrial products – Structuring principles and reference designations – Part 1: Basic rules используется для минимально необходимого описания структуры и системы обозначения сложных инженерных объектов, задавая принципы кодирования систем и их частей. Это фундамент для управления конфигурацией в ходе жизненного цикла. Кроме того, этот стандарт различает три главных вида описаний: компонентное, модульное и размещений, хотя и в немного другой терминологии – функциональное (functional), продуктное (product) и мест (location).

• Стандарт ISO 15926—2:2003 Industrial automation systems and integration – Integration of life-cycle data for process plants including oil and gas production facilities – Part 2: Data model служит для моделирования данных развёрнутых (полных) описаний инженерных объектов. Обеспечивает интеграцию данных различных информационных систем жизненного цикла инженерных объектов.

• Стандарт OpenGroup ArchiMate 3.0 (2016) Enterprise Architecture Modeling Language даёт возможность моделировать предприятия, включая их бизнес-архитектуру, деятельность команды, а также поддерживающий эту деятельность корпоративный софт и разнообразное «железо» и компьютерные сети, необходимые для работы этого софта, а также другое оборудование предприятия.

• Публичный документ NIST PWG Cyber-Physical Systems (CPS) Framework Release 1.0 (2016) уточняет способы описания для киберфизических систем, вводит классификацию аспектов для стейкхолдерских интересов.

• Публичный документ Guide to the Systems Engineering Body of Knowledge (SEBoK) даёт нам определение успешной системы и множество других определений системного подхода.

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

Наша онтология системного подхода

Можно также сказать, что из инженерных стандартов мы взяли онтологию системного подхода.

Онтология – это и наука, отвечающая на вопрос «что есть в мире?» (по-русски иногда говорят «учение о бытии», «учение о сущем»), и конкретный вариант ответа на этот вопрос25. В этом она похожа на науку логику, по законам которой строятся и булева логика, и темпоральная логика, или на науку геометрию, в рамках которой развиваются теории евклидовой или римановой геометрий на основе разных наборов аксиом. Понимая законы онтологии, мы можем понять и 4D экстенсиональную онтологию26, и онтологию виртуальности С. Дацюка27, и христианскую онтологию, хотя они предполагают мир устроенным и описываемым принципиально по-разному.

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

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

Конкретная онтология (а не наука в целом!) – это один из вариантов ответа на вопрос «что есть в мире?». В общем-то, философы и логики придумали множество таких вариантов. Есть ли они вообще в мире объекты, процессы, отношения, вещи, поля? Если есть – то каковы они? Есть ли экскаваторы, торсионные поля, Гарри Поттер, философский камень, вещи, Сатана и боги греческого пантеона, биржевая котировка, благовоспитанность, справедливость, и даже философия и сама онтология? Существуют ли X=4, E=mc², гамильтониан и лагранжиан, метод конечных элементов, бит и байт, модуль упругости и его разные типы? Разные онтологии дают разные ответы на эти вопросы – а онтология как общая дисциплина изучает способы, которыми даются эти ответы.

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

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

Привязка к физическому миру – 4D экстенсионализм:

• 4D индивид, занимающий место в пространстве-времени

• Воплощение против описания индивидов

• Изменения (процессы, проекты, кейсы) как 4D индивид

• события как 3D индивид

• функциональный (ролевой) объект как индивид

• софт как 4D индивид (исходный код как описание софта-индивида)

• предпринятие как 4D индивид

• полная темпоральная часть индивида

• методологическое время против времени в 4D

• экстенсионализм: совпадение двух объектов в пространстве-времени – это один объект

• отношение состава (composition, «часть-целое») в 4D

• холоны (многоуровневая декомпозиция)

Деятельностная субъективность определения системы:

• деятельность (в отличие от действий – критерии культурной обусловленности, повторяемости, «ролевости»), театральная метафора

• стейкхолдер как действующее лицо (роль)

• стейкхолдерский интерес и аспекты

• успешная система

Холархия воплощения системы

• системы против систематики («система Линнея») и методологии («система Станиславского»)?

• холон (уровень системы)

• эмерджентность

• виды систем: целевая, подсистема, использующая, в системном окружении, обеспечивающая

• имя системы (по функции)

• чёрный и прозрачный ящики

• требования, потребности, ограничения, архитектура

• проверка и приёмка

Определение и описание системы

• определение (definition) системы

• рабочий продукт

• описание системы (description)

• потребности (стейкхолдеров)

• частное описание (view)

• метод описания (viewpoint)

• модель, мета-модель, мульти-модель, мегамодель

• прожекторный и синтетический подходы к описанию систем

Компоненты, модули, размещения

• разбиения: компонентные, модульные, размещения

• описания: компонентные, модулей, размещения

• компонента: порт, связи

• модуль: интерфейс, платформа

• размещение

• архитектурное решение, требование, описание

• архитектурный синтез (логической и физической архитектур)

Жизненный цикл 2.0

• жизненный цикл системы, проекта

• стадии жизненного цикла

• практика, метод/методология

• дисциплина

• технология

• вид жизненного цикла, водопад, спираль

• V-диаграмма

Системная схема проекта (модифицированный стандарт OMG Essence):

• альфа, подальфа

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

• зоны интересов: клиентская, инженерная, предпринятия

• состояния альфы как контрольные точки, контрольные вопросы

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

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

Любая онтология, определяющая, что есть в мире, должна быть как-то записана, выражена в каких-то знаках, какой-то терминологии, то есть, представлена как онтологическое описание. В обычной речи часто путают «онтологическое описание» мира и саму онтологию. Про описание (схему нарезки мира на объекты – карту) говорят как про онтологию (объекты, выделяемые в мире – территорию), опуская слово «описание». Разницу обычно можно понять из контекста, но в жизни очень часто путают вопросы «что означает знак X» и «что такое X». «Что такое насос?» – это спрашивают, что означает слово «насос», или спрашивают, что такое «быть насосом» в реальном мире? Пока нам достаточно научиться различать эти вопросы и помнить, что кроме обсуждения самих понятий, онтологии (ответ на вопрос «что такое X»), бывает обсуждение семантики – того, как мы связываем знаки/символы/термины с их значением/денотатом и смыслом. Так,

• строчка букв (или произносимые слова) «Королева Великобритании» – это знак;

• конкретная женщина, которая сейчас королева (и, кстати, имеет много других способов ее описать, кроме строчки букв «Королева Великобритании») – это значение/денотат;

• выражение «единственная женщина, которая сейчас королева Великобритании» – смысл строчки букв «Королева Великобритании».

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

Философы много веков составляли очень неформальные описания мира, их книги были метафоричны, многозначны и мутны. Andries van Renssen29 как-то заметил, что «философы прошлого недорабатывали по части строгости изложения своих философских трудов, задача получения строгого философского знания выпала на нашу долю». В 20 веке к онтологии проявили интерес разработчики программ искусственного интеллекта: их интересовало, как описывать мир настолько однозначно, чтобы даже компьютер мог интерпретировать эти описания. Они и сформулировали новое определение онтологии, чуть-чуть сдвинув акцент на важность онтологического описания: «онтология – это формальное описание/представление разделяемого набора понятий» («An ontology is a formal specification of a shared conceptualization», Tom Gruber30). Эта маленькая путаница привела к тому, что «настоящие онтологи» (которые обсуждают мир) не всегда считают людей, занимающихся компьютерными онтологиями «настоящими», ибо компьютерщики обсуждение вопроса «из чего состоит мир» часто заменяют вопросом «как описывается/специфицируется мир», т.е. обсуждают семантику вместо онтологии.

Терминология

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

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

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

Чтобы не пропасть в таких спорах и не бояться свободы использования разных вариантов терминов для одного и того же, важно научиться различать специальные группы людей – речевые сообщества (speech communities) и сообщества значений (semantic communities). Это различение подсказывает нам стандарт Semantics of Business Vocabulary and Rules (OMG SBVR)32.

Людей в речевом сообществе объединяют естественный язык (русский, японский, немецкий и т.д.) и специальное подмножество словаря этого языка – терминология конкретной предметной области. Специальная терминология чаще всего изучается по каким-то учебникам, осваивается в непосредственном общении, или берётся из словарика определений какого-то стандарта, предпочитаемого теми или иными профессионалами (например, инженеры могут настаивать на использовании терминологии из ГОСТ 34.320—96, ISO/IEC/IEEE 15288 и т.д.). Поскольку разных сообществ профессионалов много – инженеры (они тоже бывают самые разные: инженеры-строители, инженеры-программисты, биоинженеры и т.д.), менеджеры, юристы, кадровики, врачи, актёры, танцоры – речевых сообществ даже для одного естественного языка можно обнаружить множество. У всех есть свои предпочитаемые наборы терминов из разных стандартов или учебников, и достичь однозначного соглашения по терминологии даже в области общих интересов очень трудно.

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

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

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

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

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

Профессиональные сообщества часто являются и речевыми сообществами, однако терминология может существенно отличаться не только для разных профессий, но и для разных подпрофессий внутри одной профессии. То, что называется «программным средством» для системных аналитиков, работающих по ГОСТам, будет «приложением» для продавцов иностранного софта, или «софтиной» для разработчиков.

Если невозможность договориться о терминах становится реальной проблемой, мешающей реализации проекта – к её решению есть разные подходы:

• Терминологический фашизм, когда только один термин объявляется правильным, а все остальные – неправильными (сравните с «Grammar nazi»33). У этого подхода есть много вариантов – безусловно требовать единственности используемого термина (отсутствия синонимов для термина), требовать ещё и соответствия принятым стандартам (определённым ГОСТам, например, а не учебникам или другим ГОСТам), требовать использования отечественного корня в слове («мокроступы» вместо «галоши»), настаивать на соблюдении традиций («калоши», но никак не «галоши»), игнорировать современные нормы («кофе» только мужского рода, хотя уже давно даже по словарям можно и среднего).

• Терминологический пофигизм, когда на слова вообще не обращают внимания. Можно просто определять, как в математическом тексте, в начале каждого документа, «T – ниже будет означать то-то». Никаких «заведомо правильных вариантов» или ссылок на авторитетные источники. При этом, если значение слова меняется по ходу разговора, это часто вообще не отслеживается, речь оказывается «не строга».

• Строгость значений с разрешением синонимии разных терминов, обозначающих одно понятие. При таком подходе обычно очень долго договариваются, какое именно понятие имеется в виду, а затем уже используются любые слова-термины для указания на оговорённое понятие. При этом вполне допускается использование терминов, предпочитаемых разными профессиональными-речевыми сообществами. Более того, можно и не пользоваться точными терминами, если будет понятно значение. Так, при обсуждении автомобиля вполне можно обозвать его «самобеглой тележкой», и это не будет преступлением, если адресат сообщения поймёт, о чём речь.

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

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

Критика такого подхода тоже не редкость: «Как вы можете учить людей, когда одно и то же обозначаете разными словами? Вы должны выбрать один термин, и затем использовать в книге для обозначения какого-то понятия только его! Так всегда делают в учебниках!». Ответ на эту критику прост: в жизни вы имеете все шансы встретить людей, которые обозначают понятия не теми терминами, которые введены в книгах. Так что наша книга будет вас тренировать на различение понятий и терминов: обращайте внимание – вас не просто учат новым словам, не просто заставляют зубрить терминологию. Вам стараются дать знания о понятиях и их связях. Под какими бы словами-терминами эти понятия ни скрывались.

Наука традиционно порождала новые термины (обозначения для появляющихся новых понятий) двумя способами:

• Бралось обычное («бытовое») слово, и нагружалось специальным («научным») значением. «Работа» в физике – отнюдь не «работа» в бытовом значении этого слова. Это самый частый способ, но он легко приводит к путанице со словами из бытовой речи.

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

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

Вот пример из проекта «Архимейт по-русски»34, в котором переводилась на русский язык терминология стандарта OpenGroup ArchiMate 2.0. Архитектурные диаграммы для проектов информатизации бизнеса составляются айтишниками совместно с не-айтишниками (людьми из бизнеса), ибо именно не-айтишники должны решать – что в их деятельности должно быть поддержано или изменено в ходе проекта. Окончательные решения по финансированию проектов информатизации на основании архитектурных документов принимает директор-не-айтишник. Это означает, что при переводе лучше использовать слова/термины, понятные не-айтишной части сообщества значений, а айтишники, как речевое сообщество, к этому приспособятся. Поэтому software application стало «программой» (а не «приложением»), business actor – «людьми» (а не «бизнес-агентами» или «акторами», которых по незнанию можно и с программой перепутать). Профессиональные айтишники сначала возмущаются подобным «терминологическим произволом» (ибо это термины не их речевого сообщества), но после получения опыта обсуждений с менеджерами и клиентами с использованием «депрофессионализированной» терминологии говорят: «спасибо, такой перевод нам помог договориться».

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

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

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

Если какой-то процессный стандарт (например, системноинженерный ISO 15288) под словом process имеет в виду «практику» (характерной для процессов развёртки во времени в этом «процессе» из ISO 15288 нет, там перечисляются именно «практики жизненного цикла»), то в нашей книге это будет «практика», а не «процесс».

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

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

Например, Andries van Renssen выделил35 следующие часто используемые значения для термина «функция» (function):

• подтип активности (поведения), процесса или события;

• некая сущность, находящаяся в определённой роли или сделанная для определённой роли;

• сама роль сущности (обычно это роль физической вещи), участвующей в активности (поведении) [Играемая роль и сущность, играющая роль – это разное! Роль – Гамлет, сущность – Высоцкий];

• указание на корреляцию, обычно как на физическую связь между какими-то аспектами: «если высота растёт, то давление падает»;

• математическое отношение между числовыми объектами, определяющее их отображение друг на друга/mapping.

Ещё один пример – что может подразумеваться под часто встречающимся в информационном моделировании отношением «мета»? При обсуждении одного из языков моделирования данных (MOF, meta-object facility) было обнаружено, что слово «мета» (meta) используется в шести разных значениях, выражая шесть разных типов отношений36:

• экземпляризация (отношение типа и экземпляра);

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

• описание (отношение описания и описываемого объекта);

• применение/стереотип (отношение шаблона и его воплощения);

• варьирование (отношение основной модели и кастомизированной);

• реализация (отношение абстрактного синтаксиса и соответствующего ему выражения).

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

В этой книге не будет попыток дать точные определения и выбрать правильные термины. Мы постараемся передать понимание наиболее важных понятий и предложить разные слова, которыми их можно обозначать. На вопрос «сколько будет дважды два» будут приниматься ответы и IV, и 4, и «четыре», и four. Но не нужно обольщаться: ответы «горшок», 5, «per aspera ad astra» – приниматься не будут.

Формы мышления

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

Знание в отличие от «просто фактов» – это то, что можно использовать в разных ситуациях, что можно взять с собой из проекта в проект. Факты же могут характеризовать конкретные проекты и объекты в них. Знание о метрах как единицах измерения общее для всех проектов. Длина пути в каком-то проекте 14 метров – это нельзя применить к другим проектам, так что это не «знание», это просто «факт».

Мышление о мире с необходимостью включает в себя знание об объектах мира – эпистемология обсуждает, как это знание можно получить и насколько этому знанию можно верить, а онтология что-то может сказать о том, каковы эти объекты. Логика затем помогает как-то оперировать с этим знанием – и помним, что логика науки и инженерии совсем необязательно булева, она имеет вероятностную компоненту (опираясь при этом на байесово понимание вероятности, а не частотное!), и поэтому может использовать и эвристические («неформальные формализмы», неточные правила) рассуждения38.

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

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

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

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

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

1. По шаблонам – нешаблонное

1.1. «Культурное» мышление, следующее лучшим цивилизационным образцам, шаблонам (patterns), использующее накопленное человечеством знание и одновременно

1.2. нетронутое какой-либо культурой, шаблонами «дикое» мышление, которое приходит новыми путями к выводам, потенциально каких цивилизация ещё не знала, паттерны чего ещё не различала.

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

2. Знаковое-незнаковое (формальное-неформальное)

2.1. Формальное мышление (дискретное), опирающееся в своих приёмах на строго определённые дискретные объекты какой-то конкретной онтологии. Это мышление состоит в выражаемых знаками (symbols) классических логических рассуждениях. Но одновременно

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

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

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

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

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

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

Решение проблем путём формулирования и снятия противоречий (коллизий) присуще и теории ограничений Элияху Голдратта («грозовая туча»44), и методологии ТРИЗ Генриха Альтшуллера45, и системомыследеятельной методологии (школа Георгия Щедровицкого46). Все эти школы мысли утверждают, что они основаны на системном подходе, отсюда и общность мыслительных приёмов.

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

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

Есть и другие, менее распространённые специализации системного мышления. Например, есть специализация системного мышления для танцевальной импровизации Viewpoints47, на системном подходе также основан текст «Танцевальное мышление и его развитие»48.

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

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

Итого: системное мышление ничего не говорит про содержание мышления, только про его форму. Более того, развиваемые на его основе дисциплины (системная инженерия, менеджмент и т.д.) делают всё, чтобы и не нужно было много мыслить, а чтобы было можно просто применять в проекте уже известные технические, менеджерские, творческие решения. Мощь системного мышления будет проявляться в тот момент, когда известных типовых решений не будет и нужно будет делать первую из нового вида (first of a kind, FOAK) систему, или обходить какие-то жёсткие ограничения, которые не встречались раньше, или избегать каких-то часто встречающихся ошибок в деятельности – например, не забывать в суете выполнения какой-то работы подумать о чём-то важном, для чего нужно заранее знать – что именно является важным.

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

Можно ли научить мышлению?

Знания системного мышления в голову укладываются ступенечками, от простого к сложному. Как выделить такие ступеньки? Что нужно тренировать, какую непривычную мозгу мыслительную работу делать привычной?

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

Вот, посмотрел в окно – а там земля плоская. Когда нам говорят, что Земля круглая, что мы отвечаем? «Это неправда, посмотрите в окно». Нам отвечают: «вы что, Земля круглая, потому что если посмотреть за горизонт…», но мы упорствуем: «Вы рассказываете много всего лишнего, что там за горизонтом, но за горизонтом всем видно, что ничего нет. Не нужно говорить про далёкий горизонт и что за ним, давайте говорить про Землю, вот же она – Земля плоская». Вся жизненная интуиция показывает, что Земля плоская, люди по ней ногами ходят, и уж ноги-то точно знают, что Земля не круглая! Но каким-то людям, которых заботят масштабы не только 10 километров, но и 1000 километров, в голову откуда-то приходит мысль про «Земля – круглая», они начинают так мыслить. Через некоторое время выясняется, что кроме Земли ещё и Космос с его вакуумом есть, космические корабли там летают «всё время падая, но никогда не падая». Вот это уже непонятно, потому что при идее плоской Земли летание космических кораблей по кругу с достаточной скоростью, чтобы не падать никогда – это понять невозможно. Мысль о круглой земле контринтуитивна, она не соответствует «народной теории» (folk theory) плоской земли.

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

Гений почему-то, сам часто не осознавая, сделал что-то совсем не так, как все остальные, он просто начал что-то делать в противоречии с интуицией всех остальных, и у него начало получаться. А все остальные действуют интуитивно, «по-народному», «как все», и у них не получается. И пока на уровень сознания гения, или тех людей, которые пытаются отмоделировать мышление гения, не вышло, в чём именно эта контринтуитивность, вы не можете передать это знание другим людям, не можете никого этому знанию научить.

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

Пожелания «не стеснять свободу творчества шаблонами» тут не подходят: люди, массово выдумывающие мыслительные велосипеды, с большой вероятностью получат не самое лучшее решение. Аргументы «творчества вместо шаблонов» верны только для единичных гениев, в большинстве же других случаев шаблонные мыслительные решения обеспечивают качество при минимизации умственных усилий. Опять же, гением называют не всех «творцов», а только тех, которые предъявляют качество мышления лучше, чем по лучшим известным на текущим момент (state-of-the-art) мыслительным шаблонам – и дальше уже их решения становятся шаблонными. Эти вновь появляющиеся в цивилизации шаблоны хорошего мышления нужно сразу делать явными, документировать (желательно в форме учебных курсов как адекватной форме документирования мыслительных практик).

Как передаётся неотрефлексированное, неосознанное искусство или ремесло? Ученик смотрит на десятки, тысячи, сотни работ мастеров, научается понимать сленг профессионалов как научаются родному языку (без учебников и словарей, просто «из разговоров»), постоянно смотрит, как работают настоящие мастера и пытается это копировать – прямо по пословице «обезьянка видит, обезьянка делает» (monkey see, monkey do). Далее у трёх из десяти учеников в голове появляются какие-то правильные рельсы для трамваев их профессиональных мыслей, и они начинают мыслить быстро и делают мало ошибок. А у семи из десятка – не появляются, и они делают много ошибок. Обучение искусству или ремеслу – это не обучение в классическом смысле слова.

А нам надо, чтобы девять из десяти могли научиться (вполне можно представить, что будет один неспособный на десяток человек, но не семеро из десяти). Это означает, что мы должны взять для обучения такое контринтуитивное знание, которое само не может быстро прийти в голову ученикам, сделать его минимальное компактное и понятное описание, а затем его каким-то образом передать ученикам, чтобы оно встроилось им в голову. Вопрос: бывает ли такое в тех областях, которые традиционно считались «искусством», и которым считалось, нельзя научить рационально? Да, бывает, сплошь и рядом! Это и есть путь западной цивилизации: превращать «искусство» (в том числе искусство мышления) после его моделирования и рационализации в быстро передаваемое от человека человеку в ходе структурированного обучения мастерство.

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

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

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

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

Вот, в школе учили прыгать через планку «ножницами» – подбегаешь, и прыгаешь. Но если нужно прыгнуть очень высоко, то после разбега к планочке нужно поворачиваться спиной, и прыгать назад-вверх (Fosbury Flop, изобретение 1968 года49).

Это абсолютно неинтуитивно, но даёт возможность перелетать и через двухметровую планку. Нужно огромное доверие к тренеру, чтобы вы начали тренировать такой прыжок – ибо в этот момент кажется, что много-много тренировок дадут возможность преодолевать дополнительные десятки сантиметров «ножницами» или «перекатом», что совсем не так. А потом будет метанойя: вы будете не понимать, почему вообще через планку люди ещё где-то прыгают не техникой Дика Фосбери – даже если вы уже не помните, что начало таким прыжкам положил именно Дик Фосбери, и прыгать так люди начали всего на год раньше, чем высадились на Луну в 1969 году. И речь идёт о том, что люди делали тысячелетиями: прыжках в высоту! То же самое относится к бегу: позный (основанный на принятии специфической позы бегуна, что позволяет эффективно задействовать физические свойства тела) метод бега50 появился после исследований Николая Романова, которые он начал в 1977 году. До этого позным бегом занимались люди, чисто случайно натолкнувшиеся на эту технику – и, конечно, они не в состоянии были передать свой опыт другим людям, они просто неосознанно «хорошо бегали».

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

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

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

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

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

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

Так что в случае использования этих терминов нужно быть внимательным к контексту: когда говорится о 1. возможности легко повторить какое-то всем очевидное рассуждение (интуиция=тривиальность как лёгкость повторения другими, задействование «народной онтологии»), или когда говорится о том, что 2. рассуждения могут проходить в коннекционистской парадигме (интуиция=«чуйка», результат образного внелогического мыслительного акта с использованием нейронных сетей мозга, бессознательное рассуждение).

Стадии обучения мышлению

Обучение системному мышлению проходит через следующие стадии:

0. Заинтересованность: понимание, что системный подход вам зачем-то нужен. Это переход от неосознанной некомпетентности («я и не догадываюсь, что я не умею системно мыслить») к осознанной некомпетентности («я знаю, что я не умею системно мыслить»). Это самая трудная ступенька на пути к беглости мышления. Нет мотивации – не будет и вложений труда, не будет hard fun, никакой метанойи не случится. На коммерческие курсы люди приходят уже заинтересованные, и у них дальше всё получается. Студенты приходят обычно никак не заинтересованные – и не все из них становятся заинтересованными даже к концу курса. Но часто возвращаются поучиться второй раз (заинтересованность появляется уже после прохождения курса). Эту заинтересованность необходимо поддерживать всё время обучения (тут можно указать на то, что в педагогике ведущая дисциплина – лидерство, умение удержать человека в роли ученика51).

1. Начитанность: знакомство с каким-то фрагментом системной онтологии. Материал учебника (или даже нескольких) освоен на этой стадии в части знания значений слов, умения пересказать какой-то фрагмент учебника, воспроизвести какую-то диаграммку, поддержать разговор.

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

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

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

Пример такой задачи: «Пётр утверждает, что нужно уже начинать закупать компоненты системы, а Елена утверждает, что не компоненты, а модули. Кто из них прав? А) Пётр Б) Елена». Ответить на такую задачу можно, только если знать про различия модулей и компонент – для ответа недостаточно процитировать какое-то место из учебника. При решении тренажёрных задач как раз и формируются «рельсы в голове», по которым поедет мышление.

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

3. Приложимость: умение системно мыслить по потребности in the wild, в реальных проектах. Это совсем отдельное качество: уметь решать уже поставленные задачи (даже олимпиадного уровня сложности) и уметь ставить задачи, выделять эти задачи из запутанного, шумящего, быстро меняющегося окружающего мира. Приложимость системного мышления именно в этом, не в решении уже поставленных задач из задачника, а в постановке и последующем решении задач из жизни. Реальные проекты появляются только тут, и только тут тренируется главный навык системного мышления: выделение главного и игнорирование не главного для борьбы со сложностью реального мира.

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

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

Особенности решения учебных задач по системному мышлению

В онтологических рассуждениях, как и в жизни, обычно делается предположение об открытости мира54 (open world assumption): «что не сказано, то просто не сказано». Это существенно отличается от предположения о закрытости мира: «что не сказано, того просто нет». Тренажёрные задачи чаще всего составляются из предположения о закрытости мира.

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

Особое внимание нужно уделять тренажёрным задачам на начальных стадиях обучения – когда правильный ответ интуитивно не ясен, не является шаблонным. Когда студент материал знает плохо, он включает «смекалистый мозг». Он смотрит на 2*2 и начинает: «Это может быть любое число больше 1.0 и меньше 9.0, ибо мы же не знаем, насколько и как округлили исходные числа. И это может быть в ответе вообще что угодно, начинающееся и заканчивающееся на 2, ибо звёздочка не всегда означает знак умножения. Часто звёздочка означает любое количество символов. А ещё речь может идти о символьном умножении, поэтому ответом будет 22. И давай не будем разбирать ситуации, когда система счисления недесятичная, так и быть». Конечно, он достаточно смышлён, чтобы заподозрить в ответе 4, но и недостаточно уверен в этом ответе, чтобы не предположить дополнительных подвохов.

Двое из десятка изучающих системное мышление человек именно таковы – они материал не читали, но они хорошие инженеры или менеджеры, у них подвешен язык, они скептичны по отношению к материалу учебника (это ничего плохого, просто skeptic thinkers), и именно они обычно самые активные в группе. Их цель не столько поупражняться в системном мышлении и использовании его концептов, сколько попробовать «прогнуть» предлагаемые задачи вместе с системным мышлением, испытать их на прочность «здравого смысла». Этим людям хорошо работать Беспристрастными Свидетелями (Fair Witness) из Хайнлайна: «Энн стояла на трамплине. Джабл крикнул ей: – Тебе виден тот дом на горе? Какого он цвета? Энн посмотрела и сказала: – С нашей стороны белый. Джабл обернулся к Джилл: – Вот видишь, Энн не стала говорить, что дом белый целиком. И вся королевская рать не заставит ее сказать это до тех пор, пока она не пойдет и не посмотрит. Но даже и тогда она не сможет утверждать, что дом остался белым после того, как она ушла»55.

Как мы могли бы с этим бороться? Очевидный ответ – строго формализовать задачи, добиваясь однозначности правильного ответа. Но чем формальней будут поставлены задачи «из учебника», тем дальше они будут от реальной жизни.

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

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

Переход к использованию мышления

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

Основных идей системного подхода немного, каждая из этих идей довольно быстро понимается. Проблема в том, что все эти положения глубоко связаны друг с другом и крайне редко используются поодиночке. Так что требуется добиться некоторой беглости (fluency) в их одновременном и совместном применении – примерно в том же смысле, что и беглости пальцев в игре на рояле или наборе текста на клавиатуре, беглости в говорении на иностранном языке. Каждая клавиша на рояле или клавиатуре понятно нажимается, их всего не так много, проблема только в том, чтобы разные клавиши нажимать вовремя, быстро и такие, какие нужно для получения музыки. На освоение клавиатуры уходит несколько дней тренировки, на освоение рояльных клавиш уходит несколько лет. В освоении системного мышления, как и в освоении игры на рояле нет царских путей, кроме как бесчисленного числа повторений, выполнения многочисленных упражнений на использование этих положений, получение опыта применения в жизни. Это, увы, занимает время. Поэтому мышлению желательно учиться с детства. Вот из материалов Viewpoint Research Institute56:

Мы хотим помочь детям развить реальную беглость (fluency) во многих областях образования, включая мышление, математику и науки. Каждый из этих предметов не поддается «естественному обучению» (как учатся ходить и говорить). Довольно много времени и энергии нужно потратить, чтобы получить беглость выше пороговой. Тут интересное сходство с искусством, музыкой и спортом, для каждого из них также требуется довольно много времени и энергии, чтобы получить беглость. Эти искусства могли бы называться «тяжелое развлечение» (hard fun). Математики и ученые знают, что они занимаются искусством, равно как тяжелым развлечением. «Мышление» это более высокая категория, чем «просто» математика, наука и искусства. Оно представляет синтез интуитивного и аналитического подходов к пониманию мира и поведения в нем.

Peter Senge в книге «Пятая дисциплина»57 (1990) писал:

Недавно в ходе пятидневного вводного курса, проводимого Обучающим центром МТИ, одна женщина-менеджер из конструкторского отдела компании Ford лаконично сформулировала ситуацию: «Спустя пару дней, – сказала она, – я начинаю понимать, о чем вся эта история с системным мышлением и интеллектуальными моделями. Мне это напоминает время, когда я только начала знакомиться с высшей математикой. Сначала я чувствовала себя совершенно потерянной. Все это было мне совершенно чуждо. Но потом я начала „схватывать“ суть. Через год я уже вполне владела основами этого дела. Через пять лет это стало основой моей профессии». Потом она добавила: «Если бы высшую математику изобрели сегодня, ни одна из наших корпораций не смогла бы ею овладеть. Мы бы посылали каждого на трехдневные курсы. Затем каждый получал бы три месяца на то, чтобы посмотреть, работают ли „все эти штуки“. А когда выяснялось бы, что они не работают, мы бы начинали пробовать что-нибудь другое».

Если заниматься языками, то любой из них можно довести до уровня С1 (достаточный для поступления в европейский ВУЗ) за год, если интенсивно заниматься – для языка без флексий (английский, испанский) нужно на это потратить 600 часов, с флексиями (русский, немецкий) 1100 часов, для языков совсем другой структуры 2200 часов. Если заниматься год, то в день нужно тратить примерно 1.6, 3 и 6 часов соответственно, и в Сети можно найти достаточно примеров, как мотивированные люди выделяли примерно такое время в своём расписании и достигали успеха. Чтобы достичь в языке мастерства, нужно потратить порядка 10000 часов (хотя это и спорное утверждение, но порядок верный) – то есть заниматься языком несколько лет. И в случае иностранного языка это даже не «мыслить» и не узнать о каких-то новых вещах и их связях, это просто «переназвать известные уже вещи другими словами»! Системное мышление относится к того же сорта практике: его нужно практиковать, чтобы добиться беглости, а не «мыслить со словарём».

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

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

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

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

Воплощение, определение и описание системы

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

Это обеспечивается тем, что когда мы говорим о системе, то мы прежде всего имеем в виду воплощение системы (system realization – тот же корень, что real, реальный, буквально речь идёт о существовании в реальности, reality). Система понимается всегда как воплощение системы, как философский индивид – индивидуальный, уникальный физический объект, существующий в физическом мире. Например, это фирма Apple, топливный насос с серийным номером #12345, установленный на авиадвигателе #5678, исполнение танца «Барыня» на сцене Усть-Урюпинского театра вечером 24 октября 2015 года.

Как узнать, что система существует в физическом мире? Для этого есть множество философских критериев, и мы выберем самый «научный» из них. Мы будем считать, что в физическом мире присутствуют только те объекты, которые занимают место в пространстве-времени. Тем самым мы выбираем 4D-онтологию, подразумевающую существование мира в четырёхмерном пространстве-времени «по Эйнштейну».

Индивид в 4D имеет некую протяжённость в пространстве (то есть размер, длину, ширину, высоту, радиус) и во времени (то есть имеется момент, когда он начал существование, и момент, в который он закончил существовать). Место индивида в 4D называется экстент (extent, протяжённость в пространстве-времени). Поля или энергии мы тоже будем считать 4D объектами, физические тонкости такого подхода для нас пока не важны.

Тем самым мы чётко различаем воплощение системы (system realization) как индивид, который занимает экстент в пространстве-времени, и определения системы (system definition) – информацию о воплощении системы, об объекте-индивиде.

Информация не имеет места в реальном мире, нельзя сказать, что определяющее высоту в метрах индивида «Эйфелева башня» число «300» находится где-то в реальном мире и имеет собственную длину-ширину-высоту. Если вы укажете на вот это вот число «300» и скажете, что оно существует и имеет свой экстент – то вы укажете не на само число, а на носитель информации, который своей формой (частицами краски или прозрачностью материала или ещё как-то) кодирует это число. Тем самым место занимает не «300» как число, не часть определения Эфейлевой башни, а материальный объект кусочка описания (system description) Эйфелевой башни – информация определения, записанная на каком-то носителе информации.

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

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

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

Результат работы проектировщика атомной электростанции – в конечном итоге воплощение атомной электростанции, а не бумажная документация на её строительство или даже информационная модель. Результат работы хореографа – это в конечном итоге сам танец, а не листочек бумаги с описанием танца. И это несмотря на то, что проектировщик сам не строит атомные электростанции, а только их описывает, а «хореограф» в его изначальном значении тоже «описатель» танца (от др.-греч. χορεία – хороводная пляска, хоровод + γράφω – записывать, писать. Первоначальное значение хореографии – это отнюдь не сочинение и постановка танцев, а именно искусство записи танца).

Люди ходят не по карте, а по территории. Карта – это только описание территории, и это верно для всех описаний, не только для географических карт.

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

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

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

В случае карты можно постучать не по коктейлям, а по картинкам коктейлей, что совсем не то же самое. И картинки коктейля не выпьешь.

Абстрактные объекты

Объекты-индивиды как воплощения системы противопоставляются определениям, как абстрактным объектам. По абстрактным объектам нельзя постучать, на них нельзя указать пальцем – они не занимают места в пространстве. Они используются в мышлении, чтобы переносить знания между ситуациями. Абстрактные объекты можно выражать символами на каких-то носителях. Но символ и означаемое символом (например, символ доллара и доллар) – это совсем не одно и то же, равно как символ совсем не часть носителя информации, изменение структуры которого (краска, форма углублений) кодирует эти символы.

Множество – это абстрактный объект, не тождественный сумме входящих в него объектов-индивидов. Множество из одного автомобиля – это совсем не то же самое, что этот один автомобиль. Автомобиль имеет экстент, а множество экстента уже не имеет, это просто информация. Другое имя для множества – это тип, или класс. Все красные автомобили-индивиды материальны, а вот множество/тип/класс красных автомобилей – это определение красного автомобиля, оно идеально. Любой красный автомобиль-индивид определяется (defined) как входящий в это множество (классифицируется этим классом, принадлежит этому типу). Мышление ухватывает что-то общее во всех ситуациях, мышление происходит не для отдельных объектов-индивидов, о которых мы знаем разные факты. Мышление происходит для классов/типов/множеств индивидов/экземпляров.

4D экстенсионализм

Если один человек упомянул президента США, а другой – Барака Обаму, то они имели в виду одно и то же лицо? А если другие люди упомянули президента США и Джорджа Вашингтона – они имели в виду тех же лиц? В инженерии тоже нужна жёсткая логика для подобных рассуждений – описанный одним человеком насос P-101 на схеме трубопроводов, и описанный другим человеком насос модели ПДР-15-НШ-12 в монтажной спецификации – это один и тот же насос? А установленный в турбинном зале насос ПДР-15-НШ-12 с серийным номером RKS456/4 – как он соотносится с первыми двумя? Как описать это «в компьютере» так, чтобы и самому не запутаться, и других не запутать?

Ещё Декарт (1596—1650) задавался вопросом: а как вообще понять, что люди говорят об одном и том же объекте, если они видят в нём самые разные свойства (то есть относят его к самым разным классам)? Скажем, один инженер говорит о высокопроизводительной системе, другой – о взрывоопасной, менеджер – о прибыльной, а финансист – о дешёвой? Как тут понять, что речь идёт об одной системе? Ответ на такие онтологические вопросы был дан Декартом и сегодня его подход называют экстенсионализмом (extensionalism)59. В рамках экстенсионализма вслед за Декартом считают, что если экстенты, т.е. место в пространстве, у двух объектов совпадают, то это один и тот же объект. В XX веке к этому добавили ещё и протяжённость во времени, темпоральный/временно́й extent, и соответствующая теория получила название 4D экстенсионализма (4D extensionalism). Для экстенсионального подхода не важно, какие основные или вторичные свойства и сущности увидели разные люди в объекте, или для каких применений этот объект им нужен. Более того, для экстенсионального подхода не важно, одинаковые или разные имена у тех экстентов (мест в пространстве-времени), о которых говорят разные люди, имеющие разные интересы. Если речь идёт об одном и том же месте пространства-времени, значит речь идёт о том же самом индивиде, о том же самом воплощении системы. Если я говорю о пище, вы говорите о яблоке, она говорит о товаре, он говорит о зелёном физическом теле массой 150 грамм, и всем мы показываем на одно и то же место в пространстве-времени, то речь идёт об одном и том же индивиде. Если кто-то показывает в 4D на бабочку с крыльями и говорит «бабочка», а кто-то другой показывает в 4D на яйцо-гусеницу-куколку-бабочку-с-крыльями и говорит «бабочка», то у этих двоих есть шанс понять друг друга. Экстенсионализм позволяет самым разным людям договориться о мире.

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

Отношение состава

Главные отношения индивидов – это отношение «часть-целое» (part of), они же отношения состава/сборки (composition).

Инженеры часто говорят об этом как о разбиении (breakdown) системы. Крыло и фюзеляж – части самолёта, топливный насос – часть двигателя. Экстенты всех этих частей занимают какую-то часть экстента целого: крыло занимает часть всего объёма самолёта, часть занимаемого им пространства-времени, топливный насос занимает часть двигателя. Если принять, что все системы существуют не просто в 3D пространстве, а в 4D пространстве-времени, то можно говорить об их темпоральных (временны́х) частях. Если речь идёт о такой части 4D-индивида, что на протяжении какого-то промежутка времени этот индивид не имеет никаких других частей, то эта темпоральная часть называется полной темпоральной частью. Например, яйцо является полной темпоральной частью бабочки – пока бабочка проходит стадию «яйцо», никакой другой «бабочки» в мире нет. Это очень удобно для описания изменений: разные состояния системы становятся просто её разными темпоральными частями. С этими состояниями системы можно работать как с отдельными объектами, они могут получать отдельные имена. Бабочка на стадии «яйцо» называется «яйцо». Пётр Сидорович в состоянии болезни называется «пациент». Удобно представлять четырёхмерные объекты эдакими «червяками» во времени, в которых 3D объём проходит какую-то траекторию во времени, какую-то «развёртку во времени».

При таком подходе события – это трёхмерные «срезы» индивида на какой-то момент времени, эдакие трёхмерные фотографии. До события было одно состояние индивида, а после события – другое состояние индивида. Кроме того, сам индивид появляется в какой-то момент времени, а в какой-то момент времени он исчезает.

Спортсменка на фотографии проходит разные события (отрыв от земли, приземление), определяемые её позами в эти моменты времени.

Эти позы, как «трёхмерные фотографии» и есть события, разделяющие разные состояния «сальто», «подготовки к сальто», «выравнивание после приземления». Эти позы в выделенные точки во времени – события, до и после которых состояние индивида изменяется.

Например, в позном беге60 событием является «поза бега» – всё тело бегуна в определённый момент времени «Поза бега» является ключевой для правильного бега, весь бег оказывается основан на событии принятия правильной позы.

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

В онтологии 4D экстенсионализма мышление про объект-событие не отличается чем-то особенным: о событиях говорится просто как о частях системы, разве что событие не просто полная темпоральная часть (состояние) системы, но и имеет нулевую длину во времени. Более того, любые события являются сами по себе границами темпоральных частей индивидов – эти 3D-срезы разрезают индивиды на состояния, которые были до события и состояния, которые наступили после события.

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

Вот диаграмма пространства-времени (space-time map) из книги Chris Partridge «Business Objects: Re-Engineering for Re-Use»62, которая это иллюстрирует:

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

Событие «вторая мировая война» тоже длилось много лет, но при рассмотрении «предвоенного мира» и «послевоенного мира» это событие считается прошедшим «мгновенно» – это просто «фотография мира» в тот момент, когда там шла война.

Отверстия

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

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

Антракт – это темпоральная часть концерта или спектакля, когда отсутствует представление. Рассуждать об антракте можно так же, как и об инженерных отверстиях, но это будет не пространственная, а темпоральная часть спектакля или концерта.

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

Процессы и действия

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

Тем самым задать «процесс» – это просто перечислить все индивиды63, которые взаимодействуют в его ходе, «участвуют» в процессе. Это взаимодействие меняет эти индивиды, меняет их состояния. А «участие» (participation) – это просто специализация отношения состава (composition, part_of).

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

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

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

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

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

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

Мы часто будем приводить в качестве примера системы танец – танцы имеют процессную природу, они не такие тривиальные для мышления, как насосы или автомобили. Но танцы всё ещё много проще предприятия, поэтому думать о танцах проще, чем о предприятии. И совсем недаром одна из классических (год выпуска – 1999) книг Peter Senge по системному мышлению для предприятий называется «Танец перемен»65.

Компьютерные программы

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

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

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

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

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

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

Ещё одна ошибка – это считать программу отдельной системой, ибо регулярно в корпоративной разработке софта клиенты ожидают не столько корректную работу компьютера, сколько корректную работу той части организации, которую должен этот компьютер поддержать. Люди в организации должны вместе с программой сработать по какому-то организационному алгоритму. Такой совместный поток работы людей и компьютеров называется обычно workflow, хотя сейчас его чаще называют оргпроцессом. Чаще всего программа – это только часть этого оргпроцесса. Но для того, чтобы клиент смог получить результат оргпроцесса, эту программу нужно настроить, дать ей какие-то данные, научить с ней работать сотрудников и проверить не столько работу самой программы, сколько работу всего оргпроцесса в целом. Никого не волнует работа программы начисления зарплаты, волнует начисление зарплаты – и если начисления зарплаты не произойдёт, то программистам трудно будет объяснить, что с их программой всё в порядке, а неправы все остальные. Поэтому в проектах по разработке программ очень часто есть часть по работе с людьми и данными.

Ещё лет двадцать назад считалось, что мир захватят сложные алгоритмы, которые будут хитро перерабатывать относительно простые данные. Оказалось, что современное программное обеспечение сдвигается в сторону работы со сложными данными, при этом алгоритмы работы с этими данными относительно просты и единообразно устроены. А поскольку сложность из алгоритмов перемещается в данные, то системным подходом начинают интересоваться не только инженеры-программисты, но и инженеры данных. Никогда не нужно забывать, что данные – это в конечном итоге описания каких-то систем, но в момент их обработки какой-то программой они сами становятся частью системы этой программы, «вещью». То есть данные для обработки их программой тоже нужно «изготовить» из первичных описаний. И когда мы интересуемся, как получить из данных полезный результат, то как и в случае программ мы должны научиться их изготавливать из исходных данных – и мы по аналогии с DevOps будем говорить о DataOps67.

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

Функции

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

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

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

Системы именуются обычно по первичному их назначению, то есть по назначаемым им ролям, эти роли и определяют их поведение-функцию. Когда мы именуем микроскоп, то прежде всего имеем в виду то, что он позволяет «мелко смотреть» в тот момент, когда он полностью изготовлен и работает. Если бы мы считали, что микроскопом нужно гвозди заколачивать, назвали бы его молотком.

Физические и функциональные объекты

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

4D экстенсионализм позволяет это осмыслить: даже если какой-то предмет определяется интенсионально (intentional), то есть по чьему-то намерению (intent), указанием назначения, то всё равно можно выяснить, какое место в пространстве-времени относится к этому предмету, и дальше уже проводить обычные рассуждения для физического предмета. Когда кто-то выделяет в соответствии с ролью функциональный объект, можно дальше отождествить его с каким-то физическим объектом, находящимся на том же месте, и считать, что функциональный и физический объект на какой-то период времени – это один и тот же объект.

Например, я могу выделить в своей жизни четырёхмерный индивид «моя любимая игрушка» – это плюшевый мишка в период 40 лет назад, игрушечный самолётик в период 30 лет назад и планшетный компьютер сегодня. А в промежутках, может быть, мне было не до игр, и функциональный объект «моя любимая игрушка» в этот период вовсе не существовал. Физические индивиды, играющие роль функционального объекта «моя любимая игрушка» несколько раз менялись, а вот функция (поведение – участвовать в моих играх) оставалась той же. Моя любимая игрушка в тот момент, когда она существует, вполне занимает экстент – по ней можно постучать, её можно понюхать, о ней можно говорить как о физически существующем предмете.

Зачем нужны функциональные объекты? Удобно выделить объект «президент США» – это такой четырёхмерный функциональный объект, выделенный на основе своей функции, роли в государственном управлении США. Он существует с 30 апреля 1789 года по настоящий момент, а также во многих возможных версиях будущего. При этом с 22 февраля 1732 по 14 декабря 1799 существовал обычный «четырёхмерный» человек Джордж Вашингтон (физический объект-индивид). Что же происходило с 30 апреля 1789 по 4 марта 1797 года? В этот период два четырёхмерных индивида пересеклись в одном и том же экстенте, одном и том же месте пространства-времени. Полная темпоральная часть «президента США» совпадала с полной темпоральной частью «Джорджа Вашингтона». А потом они снова разошлись – следующая полная темпоральная часть «президента США» совпадала с полной темпоральной частью Джона Адамса, потом с полной темпоральной частью Томаса Джефферсона, и т. д. Иллюстрирующая диаграмма взята из книги Matthew West68 (Рис. 1).

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

Рис. 1

Вот, например, подумайте о замене насоса в установке первичной перегонке нефти или танцора в постановке балета «Спартак» – они абсолютно не отличается от схемы замены президента США: просто в функциональном объекте-роли меняют физический объект-исполнитель этой роли. Диаграммы будут идентичны.

Посмотрите на картинку (пример Matthew West) и сами разберите нарисованный на ней пример съёма двигателя с самолёта (Рис. 2).

Двигатель (с серийным номером) 329 (обычный индивид, физический объект) пересекается темпоральной частью с Самолётом 684 (обычный индивид).

Двигатель 329 (обычный индивид) совпадает темпоральной частью с темпоральный частью Левого двигателя самолёта 684 (функциональный индивид).

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

Рис. 2

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

Второе поколение системного подхода

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

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

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

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

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

Этот поворот от «объективности научного мира» к «субъективности деятельностного мира» и обращение к стейкхолдерам произошёл в мире примерно в 1975—1985 годах. В СССР как раз начались гласность и перестройка, из системных мыслителей на эту тему в те времена говорили представители системнометодологического движения (последователи Г.П.Щедровицкого), в их языке использовалось очень близкое к «стейкхолдеру» понятие «позиция» и они первые начали говорить о том, что привнесение деятельностной субъективности в системное движение через понятие стейкхолдера/позиционера означает появление нового, второго поколения системного подхода.

В современной терминологии можно было бы говорить о системном подходе 2.0.

Вот график частоты упоминания слова «стейкхолдер» в библиотеке англоязычных книг Гугля70, и это примерно отражает распространение системного подхода в его второй версии:

Стейкхолдер

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

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

Любая система определяется так, чтобы это определение (system definition) было удобно для деятельности стейкхолдера. Какого? В разных случаях разного: поэтому определение системы может существенно отличаться от стейкхолдера к стейхолдеру, речь может идти об абсолютно разных системах и может потребоваться огромная работа по согласованию этих определений.

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

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

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

Собаки лают, а караван идёт: собаки тут не стейкхолдеры. А вот если купец не оплатит проход каравана, то караван идти не будет. Купец – стейкхолдер, он занимает деятельностную активную позицию по отношению к каравану.

Театральная метафора

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

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

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

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

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

Программка в театре содержит важнейшую информацию: «действующие лица и исполнители»:

Действующие лица – это вдумчивый Принц Гамлет и безумная Офелия. У них есть своё назначение в пьесе, это функциональные объекты. Исполнители – это весёлый актёр-стажёр Вася Пупкин в утренних спектаклях и мрачный народный артист Василий Петрович Черезколеноногузадерищенский в вечерних спектаклях как Принц Гамлет, плюс педантичная Елена Ефимовна во всех спектаклях, и она не болеет и не замещается. Исполнители – физические объекты. Функциональные и физические объекты, которые занимают в пространстве-времени одно и то же место – это один и тот же объект. На момент исполнения роли Принц Гамлет и Вася Пупкин это одно и то же лицо. Но мы их не должны путать. И при этом мы говорим о Принце Гамлете как о существующем (но только в связи с его ролью! Когда Вася Пупкин чихает или звонит по телефону подруге – это не Принц Гамлет чихает и звонит по телефону, это Вася Пупкин в других ролях!).

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

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

Мышление о людях: прежде всего они стейкхолдеры

Конечно, в реальной жизни мы непосредственно видим в первую очередь исполнителей – конкретных актёров-людей, а не «роли». Но обсуждаем по ходу пьесы мы исключительно роли, если только речь не идёт о качестве исполнения!

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

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

Если мы этого не знаем, то мы не может оценить действия этих людей, спланировать свои действия, не можем сыграть свои роли в играемой ими пьесе – а без этого нас просто не поймут! И мы ни в коем случае не должны путать Принцев Гамлетов и Василиев Пупкиных! Мы не должны обращаться к Принцу Гамлету как к Офелии – исполнитель стейкхолдерской роли просто не будет знать, что делать!

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

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

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

1. «Исполнительское» обсуждение, в терминах персоналий:

– Иванов опять чертежи испортил! Он присылает их в формате. dwg и ссылается на Петрова! Сидорова не может работать!

– А что думает об этом «Красшефмонтаж»?

– Его не волнует, лишь бы «Заготбазарбаза» не возражала!

Всё ли вам понятно, если вы случайно попали на совещание? Можно ли задать какие-то уточняющие вопросы по непониманию – и какие? Если вы хорошо знаете всех действующих лиц, то можете ли вы предсказать хоть как-то их предполагаемые реакции в данной ситуации?

2. Стейкхолдерское обсуждение («действующих лиц», в терминах ролей):

– Конструктор опять чертежи испортил! Он присылает их в формате. dwg и ссылается на расчётчика! Архив не может работать!

– А что думает об этом технолог завода-изготовителя?

– Его не волнует, лишь бы поставщик корпусов не возражал!

Стало ли понятней, о чём идёт речь? Какие уточняющие вопросы вы бы задали?

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

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

Конечно, если Ельцин у нас долго играл роль президента, то некоторое время после смены играющего роль президента был осмыслен вопрос «А кто у нас сейчас за Ельцина?» – это, конечно, метонимия72 по отношению «назначен на роль».

Позиция

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

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

Можно и нужно занимать позицию осознанно: «сейчас займу вот с такой-то целью такую-то позицию» (выберу себе понятную роль в понятной пьесе, и буду придерживаться ее ценностей в самых разных делах, пока не передумаю). Такой осознанный выбор позиции обычно называется самоопределением.

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

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

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

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

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

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

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

Лидерство

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

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

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

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

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

Внешние и внутренние стейкхолдеры

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

Хороший анализ видов внешних стейкхолдеров при крупных продажах (например, инженерного оборудования – в отличие от розничной продажи игрушечной машинки) дан в книге Нила Рэкхема «Стратегия работы с клиентами в больших продажах»74. В этой книге говорится, что в крупной организации за простым словом «клиент» могут скрываться самые разные стейкхолдеры – и со всеми ними нужно работать по-разному. Так что «нашими клиентами являются поликлиники» говорить можно только в самых общих стартапных презентациях. В реальной жизни внутри этой поликлиники обнаруживается много разных стейкхолдеров – и врач, и медсестра, и менеджер, и айтишник, и лаборант, и пациент, и невидимый обычно инвестор-владелец. Когда вы говорили «нашими клиентами являются поликлиники», то кого из них вы имели в виду? Для каждого из них нужно уметь отвечать на разные вопросы, подавать материал на разном уровне детальности, хвалить систему за разное, по-разному отстраиваться от конкурентов, вести переговоры на разных стадиях продажи.

Часто внешние стейкхолдеры недоступны (например, у вас 10 тысяч пользователей коробочного софта, как стейкхолдеры они неразличимы. Ну, пока программа ещё не написана и ей не пользуются, то и пользователей нет). В таких случаях этих внешних стейкхолдеров поручают представлять членам команды. Поначалу для этого использовался метод персон, где моделировались не стейкхолдеры, а исполнители стейкхолдерских ролей, персонажи/персоны (persona)75. В этом методе предлагалось составить типовой портрет пользователя продукта, и кто-то из команды должен был играть его или её роль, как в театре. Например, «мать-одиночка, 32 лет, живущая на окраине небольшого городка, пользующаяся своим планшетом для ведения домашних финансов». Но в последние годы прошла волна критики такого моделирования, ибо фокус его был направлен не на собственно стейкхолдерский, функциональный анализ отношения к деятельности, а на вторичные характеристики исполнителя стейкхолдерской роли, которые слабо связаны с сутью дела. Это примерно как мы советовали бы представить Принца Гамлета, предлагая точнее описать его вес, рост, пищевые привычки, предпочтения в одежде и надеясь при этом, что это даст нам более точный ответ о его деятельностных предпочтениях в моменты, когда он задаёт свой стейкхолдерский вопрос «быть или не быть?». Понятно, что это психологически удобно (и это крайне важно, чтобы исполнители стейкхолдерских ролей в команде разрабатывали систему не как удобную «для себя», а как удобную «для других»), но содержательно это тупик.

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

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

Организационные места, ответственность, звания

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

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

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

Особенно часто путают стейкхолдеров и организационные места при взгляде на начальников – потому как возможности начальников по распоряжению ресурсами очень важны. Начальников по отношению к стейкхолдерам нужно рассматривать как карточных «джокеров»76, которые могут стать любой картой по желанию игрока. Начальник пытается заместить собой тех стейкхолдеров, которых он считает недостаточно представленными в проекте, или пытается выяснить ситуацию, чтобы поручить решение каких-то вопросов тем стейкхолдерам, которые в команде есть, но исполнители этих стейкхолдерских ролей не знают о том, что нужно решать какие-то проблемы, или даже просто не хотят заниматься лишней работой (тогда начальник решает проблему лидерства). В любом случае, за речью начальников нужно следить особо внимательно: их стейкхолдерские интересы обычно не определены, не предъявлены, и они их регулярно меняют в ходе разговора. Первые пять минут какой-нибудь «начальник цеха» будет как стейкхолдер менеджером, потом пару минут инженером, потом до конца разговора оператором станка с ЧПУ. Директор театра в пьесах не играет, а если и играет, то нельзя сказать по его должности, какую роль – вмешаться он может в исполнение любой роли, в любой момент. Директор театра – не Принц Гамлет, это просто должность в штатном расписании, и даже не актёрская.

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

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

Сколько всего стейкхолдеров

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

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

Один из менеджеров проекта нам рассказал, что после того, как он легко нашёл первых пятнадцать стейкхолдеров, он понял, на что незаметно уходило всё его время: 15 телефонных разговоров в день по 10 минут каждый и 10 минут подготовки к разговору и обработки результатов разговора сразу дают 5 часов просто на поддержку адекватного понимания! А если нужно решать какие-то проблемы проекта со стейкхолдерами, то 10 минут разговора явно не хватает. Поскольку стейкхолдеров никто в проекте явно не отслеживал, это время уходило «невидимо», оно тратилось неосознанно, в планах оно не отражалось, ресурсы менеджера на эту работу не выделялись и не учитывались.

Согласно ISO 42010 для инженерных проектов необходимо, как минимум, учитывать следующих стейкхолдеров: пользователей (users), операторов (operators), покупателей (acquirers) системы, собственников (owners), поставщиков (suppliers), разработчиков (developers), изготовителей (builders), эксплуатационный персонал (maintainers) системы. И это только минимальный список для целей этого стандарта!

Если проекты не чисто инженерные, список стейкхолдеров может быть совсем другим. Так для танца можно отдельно выделить:

• танцора,

• партнёра (но только в танцах, где они есть! В других танцах их может не быть, или наоборот, танец может быть в ансамбле со множеством танцоров, для lap dance это не столько «партнёр», сколько «клиент»),

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

• тренера/педагога (учит танцевать),

• музыкального редактора (подбор музыки),

• организатора танцевального мероприятия (вечеринки, баттла/соревнования, концерта, семинара/фестиваля и т.п.),

• часто в этот список включают фотографа (на вечеринках) или видеографа (для концертных выступлений и баттлов),

• для сценических танцев будет ещё художник по костюмам,

• нередко и гримёр/визажист.

И это тоже не полный список! Например, в спортивных танцах есть ещё

• судьи в жюри,

• судья-информатор.

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

И помните, что вы тоже в проекте стейкхолдер или даже несколько стейкхолдеров.

Не забывайте учесть себя.

Луковичная диаграмма

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

Обратите внимание, что на диаграмме отображают в том числе и «негативных» стейкхолдеров (все эти воры, взломщики, саботажники, и прочие «антиклиенты»). Интересное упражнение тут – найти на этой диаграмме себя и показать фактические частоту и интенсивность коммуникаций с другими стейкхолдерами линиями разной толщины. А потом сделать такую же диаграмму и показать желаемые частоту и интенсивность коммуникаций. Разница – это насколько вам приятней или неприятней общаться с Василием Пупкиным по сравнению с тем, насколько важно или неважно общаться с Принцем Гамлетом. Увы, но общаться вы должны со стейкхолдерами, а исполнители их ролей вас не должны от этого отвлекать. Это и есть системное мышление!

Интересы

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

Слово «интерес» в английском будет interest, это тот самый «коммерческий интерес», деятельный интерес, предмет заинтересованности. В системном мышлении просто договорились называть interest немного другим словом: concern79, что на русском в более точном переводе звучит как «озабоченность». Интересы – это предметы постоянного внимания стейкхолдеров. На темы своих интересов они постоянно задают вопросы, описывают систему так, чтобы иметь внятные ответы на эти вопросы и даже предпринимают действия, чтобы учесть свои предпочтения по теме интересов. Они действительно озабочены каким-то предметом, в их мышлении главенствуют эти деятельностные «озабоченности», concerns.

Интересом может быть всё что угодно. ISO 42010 даёт следующий (абсолютно неполный) примерный список интересов: функциональность, достижимость, использование, назначение системы, системные возможности, системные свойства, известные ограничения, структура, поведение, результативность/производительность, использование ресурсов, надёжность, защита, целостность и безопасность информации, сложность, способность эволюционировать, открытость, параллельность в выполнении, автономность, стоимость, план-график, качество обслуживания, гибкость в использовании, гибкость в разработке, возможность модификации, модульность, управление, межпроцессные коммуникации, взаимные блокировки, изменения состояния, интеграция подсистем, доступность данных, приватность, соответствие законодательству, обоснования, организационные цели и стратегии, пользовательский опыт, сопровождаемость, приемлемость по цене и простота вывода из эксплуатации и уничтожения (functionality, feasibility, usage, system purposes, system features, system properties, known limitations, structure, behavior, performance, resource utilization, reliability, security, information assurance, complexity, evolvability, openness, concurrency, autonomy, cost, schedule, quality of service, flexibility, agility, modifiability, modularity, control, inter-process communication, deadlock, state change, subsystem integration, data accessibility, privacy, compliance to regulation, assurance, business goals and strategies, customer experience, maintainability, affordability and disposability).

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

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

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

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

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

Вот пример диаграммы ArchiMate 3.0, увязывающей в одной схеме стейкхолдеров, интересы, оценки81:

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

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

В публичном документе CPS PWG Cyber-Physical Systems (CPS) Framework Release 1.082 приведена более полная, чем в ISO 42010 таблица интересов для киберфизических систем (то есть систем, в составе которых есть датчики, эффекторы и управляющий ими компьютер):

В этом документе ввиду большой длины списка интересов, они разбиты на группы интересов – аспекты: функциональный, организационный, человеческий, доверия, времени, данных, границ, состава, жизненного цикла (functional, business, human, trustworthiness, timing, data, boundaries, composition, lifecycle).

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

Кто участвовал в последнем совещании?

«Если на клетке слона прочтёшь надпись „буйвол“, не верь глазам своим»83. Этот афоризм Козьмы Пруткова полностью применим к стейкхолдерам: мы должны выявлять их по словам и действиям и не ориентироваться на официальные титулы. Иногда титулы, конечно, совпадают со стейкхолдерской позицией. Но часто – не совпадают. Если Принц Гамлет вдруг начинает спрашивать про «Молилась ли ты на ночь, Дездемона?», это уже не Принц Гамлет! Это Василий Пупкин, который переключился на другую роль. В этот момент очень полезно задать вопрос, почему это он поменял тему и стал другим стейкхолдером: вы можете узнать много интересных подробностей. Скорее всего это означает, что всплыл какой-то новый интерес, новая тема, Василий Пупкин что-то припомнил важное и переключил роли. Не забывайте задавать вопрос о причине смены темы, когда исполнители стейкхолдерских ролей в ваших проектах будут вдруг менять эти роли в ходе разговора.

Напомним основные ошибки, которые делают люди, определяя стейкхолдеров:

• Указывают исполнителя – конкретного человека (ФИО или название подразделения)

• Указывают «ответственного» (должность, позиция в штатном расписании)

• Указывают звание (учёную степень, воинское звание, категорию мастерства)

• Указывают тип организации, в которой много стейкхолдеров (клиника, завод)

• Считают, что один человек – это один стейкхолдер

• Считают, что пять стейкхолдеров – этого более чем достаточно

• Забывают учитывать себя в качестве стейкхолдера

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

А теперь вспомните последнее совещание, в котором вы участвовали. Укажите, кто в нём участвовал?

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

Мы рекомендуем заполнить для этого упражнения вот эту табличку (она позволит избежать сразу нескольких ошибок из приведённого списка):

Какие интересы обсуждались на совещании? Это ещё одна табличка:

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

Заявляли ли вы на этом совещании свои интересы, знали ли участники совещания, какой вы стейкхолдер?

Отвечали ли вы на интересы собравшихся стейкхолдеров?

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

Это и есть системное мышление, хотя и только его маленькая часть.

Не всё системы, что ими называют

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

Нюансы могут различаться, но вот деление на части присутствует во всех вариантах. Есть две трактовки:

• в трактовке 4D экстенсионализма слово «часть» и «целое» трактуются как части 4D индивидов, т.е. речь идёт о пространственно-временных объектах. Мы уже понимаем, что это может быть какое-то «место» как объём в пространстве, занимающий этот объём физический объект, функциональный объект, и даже процесс как 4D-целое из участвующих в нём (отношение участия/participation это специализация отношения состава/composition) частей. Иногда даже подчёркивают, что систему обязательно нужно понимать сначала как процесс – это некоторое разворачивающееся во времени взаимодействие частей системы, в результате которого система выполняет свою роль/функцию/назначение. Обсуждается именно физическое деление на части и физическое взаимодействие частей в ходе выполнения системой своей функции. Для абстрактных объектов (классов, типов, множеств и т.д.) речь о делении на части-экстенты/физические части невозможен, ибо они не имеют экстента. Эта трактовка деления системы на части и есть наш вариант системного подхода.

• В другой трактовке слово «часть» используется онтологически нестрого, и «целое» собирается из самых разных объектов, в том числе абстрактных и плохо определяемых в части их присутствия в физическом мире: слов, правил, физических предметов, настроений, намерений – всего чего угодно. В нашем варианте системного подхода мы не будем считать системами и их элементами абстрактные объекты.

Тем самым мы не признаём системами-из-системного-подхода разные системы знаний/правил – корпуса знаний, правила. Система Станиславского, система Монтессори, система Платона, политическая система, система «минус 60» (так называют один из наборов правил для похудения), законодательная система – это всё некоторые абстрактные целые, состоящие из каких-то абстрактных частей-элементов (знаний, правил), но эти системы не имеют экстента. Это не настоящие системы. Очень часто люди используют тут слово «система» просто для того, чтобы указать, что они как-то думали, когда собирали какие-то части этих знаний, как-то согласовывали эти знания и правила друг с другом. Но слово «часть» тут не обозначает 4D-индивида, это не часть экстента, а сами эти «части» обычно не составляют иерархии.

Ещё один класс систем-не-из-системного-подхода в силу их абстрактности (неприсутствия в мире, отсутствия экстента) – это систематики. В систематиках речь идёт о классификаторах: классах классов, которые классифицируют в чём-то похожие системы-индивиды. Это иерархии по отношению специализации (specialization, is_a, род-вид). Классификатор Ламарка (система Ламарка) состоит из классов в чём-то похожих животных, универсальный десятичный классификатор (УДК, система десятичной классификации) классифицирует книги, объединяя в своих классах чем-то похожие по содержанию книги, Общероссийский классификатор изделий и конструкторских документов ОК 012—93 (классификатор ЕСКД, единой системы конструкторской документации, которая сама система знаний/правил) – они все не настоящие системы-индивиды, они лишь классификаторы для классов систем и классов абстрактных объектов.

Понятие холона и холархии

В 1967 году84 Артур Кёстлер (Arthur Koestler) предложил понятие холона (от греческого слова «холос», целый) как нечто, что одновременно является целым для каких-то частей внутри него и частью для какого-то объемлющего целого. Система является холоном. Каждая часть в холоне тоже может быть холоном. И объемлющее целое тоже может быть холоном. Тем самым можно говорить о холархии: иерархии разбиения (breakdown) на части сверху вниз, или она же иерархия составления (composition) целого снизу вверх. Классическая такая холархия системного подхода – это пришедшая из биологии холархия атомов-молекул-клеток-органов-организмов-биосферы.

Обратите внимание, что на рисунке не показаны уровни биосферы и уровни атомов, но это не означает, что их нет: предположение открытого мира, «что не сказано, то просто не сказано». Можно вообразить, что речь идёт об огромном полном графе объектов и отношений между ними, где есть вся онтология, но только у нас из него на рисунок отображены буквально несколько объектов и отношений. А на следующем рисунке мы возьмём из этого полного графа какой-то другой кусочек. Так нужно подходить ко всем схемам, которые мы будем рассматривать в нашей книге: как фрагментам некоторой огромной суперсхемы-онтологии системного подхода.

Вы видите, что объекты обозначены кружочками, а стрелки-ромбики традиционно обозначают отношение состава, где целое со стороны ромбика. На рисунке видно, что клетки состоят из молекул, но сами части органов. Органы состоят из клеток, но сами части организмов. Это и есть холоны, а весь граф-дерево – это холархия.

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

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

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

Эмерджентность

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

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

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

Основная особенность систем – это то, что «всё со всем связано», элементы системы в системе ведут себя не так, как они же вне системы. Атомы вне молекулы ведут себя не так, как внутри молекулы. Клетки вне органа ведут себя не так, как внутри органа.

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

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

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

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

Именно этим системный подход отличается от редукционизма – подхода, который не имеет дела с холархиями из холонов-систем. Редукционисты не выделяют отдельных системных уровней, поэтому ведущую дисциплину какого-то стейкхолдерского уровня выпячивают как средство объяснения поведения всей системы в целом. Так, поведение человека редукционисты могут объяснять химическими и электрическими процессами, которые проходят в мозгу. Верно ли это? Да, это верно, но совершенно бесполезно! Точно так же можно объяснять поведение человека квантовохимическими процессами с участием электронов и элементарных частиц атомных ядер, которые лежат в основе химических процессов, или наоборот – клеточными процессами, для которых основой служат химические процессы с клеточными молекулами. Танец можно объяснять как набор химических процессов между молекулами клеток человека, или набор движений сотен мышц, или как очень сложный набор безусловных рефлексов – но эмерджентности в этом не будет, не будет обсуждения собственно танца, это будут редукционистские описания, сводящие эмерджентные свойства к свойствам частей системы. Системный подход появился как раз, чтобы преодолеть попытки описать поведение систем в целом хорошо разработанными методами описания частей этих систем.

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

Пять видов систем в холархии

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

На рисунке представлено три уровня холархии, целевая система показана как холон 2:

Система, в состав которой входит целевая система называется использующая (using) система. На рисунке это холон 1. Это инженерная точка зрения: какой-то инженер решил, что целевая система будет использована в составе использующей системы как её составная часть. Часы будут использующей системой для шестерёнки, молекула для атома. Целевая система имеет своё назначение в использующей системе, её функция (поведение) позволяет выполнить своё назначение использующей системе. Если целевая система шестерёнка, то шестерёнка используется в часах (входит в состав часов), её назначение/функция – передавать движение на стрелки так, чтобы использующая система «часы» могла показывать время, т.е. могла выполнять своё назначение/функционировать/выполнять свою функцию. Пользователя шестерёнки нет! Никто не пользуется (во время работы часов) шестерёнкой из стейкхолдеров, кроме конструкторов, которые (во время создания часов) используют шестерёнку в составе изделия! А вот у часов стейкхолдер-пользователь (во время работы системы) может быть, хотя и не у всех. Если часы электронные и внутри контроллера ракеты, то пользователя у часов нет. Но дизайнер интерьеров может использовать настенные часы в составе интерьера жилой квартиры (во время создания интерьера), а пользоваться ими (во время эксплуатации интерьера) будет пользователь, который в этой квартире живёт.

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

Все системы, в состав которых не входит целевая система, называются системами в операционном окружении (operation environment, рабочая/эксплуатационная среда).

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

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

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

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

Проблема в том, что целевой системой для разных стейкхолдеров может стать любой холон в холархии, который будет проявлять интересную для этих стейкхолдеров эмерджентность, нужный для них системный эффект. И тогда все остальные виды систем будут определяться по-другому. Это представлено на рисунке указанием в скобочках вида системы для каждого холона. Скажем, если целевой системой объявить холон 4, то холон 2 будет использующей системой.

Конечно, эти именования (как и любая терминология) более-менее условны. Так, в ТРИЗ использующая система называется надсистема, а системные инженеры обычно слово «надсистема» не говорят. В основополагающем стандарте системной инженерии ISO 15288 вообще не говорят обо всех этих видах систем, подчёркивая их одинаковость: различают только целевую систему (system-of-interest) как вершину холархии, а в её составе дальше всё будут только системы (если у них будут части) и элементы (elements, – это в отличие от холона какая-то часть целого, для которой мы не рассматриваем её собственные части).

А вот системы в операционном окружении (systems in operation environment) и обеспечивающие системы (enabling systems) в ISO 15288 определяются так же, как в нашей книге.

Рекурсивное применение системного мышления

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

Вот пример транспортной системы86:

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

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

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

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

Боинг 747—8 состоит из 6 миллионов независимых видов деталей, которые производят полмиллиона человек на 5400 фабрик, за один год заказывается 783 миллиона частей самолёта88:

В современных системах число отдельных элементов, которые нужно согласовать между собой (в проектировании), а часто и создать с нуля (в конструировании) достигает десятков миллионов в «железных» системах, а если речь идёт об электронных системах, то и десятков миллиардов: на одном серийно выпускаемом в 2017 году электронном чипе NVIDIA GV100 Volta число отдельных транзисторов – 21.1 млрд. штук. Без какого-то иерархического рассмотрения таких сложных объектов можно оставить надежду об их создании. Системное мышление через использование холархий как средства организации внимания позволяет справиться с такими огромными проектами, структурируя внимание.

Потребности, требования, ограничения

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

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

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

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

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

Если рассмотреть использующую систему как чёрный ящик, то её определение будет потребностями стейкхолдеров (stakeholder needs, нужды стейкхолдеров), хотя иногда и говорят о «требованиях стейкхолдеров» (stakeholder requirements). Не путайте требования стейкхолдеров с системными требованиями: это определения разных вложенных друг в друга систем! Так что люди во избежание путаницы предпочитают про требования стейкхолдеров говорить потребности/нужды/needs.

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

Примеры использования терминологии видов систем

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

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

Один из внешних стейкхолдеров – оператор (owner-operator) насосной станции. Потребность – бесперебойная работа насосной станции (обратите внимание, что потребность говорит не про насос как целевую систему, а про насосную станцию как использующую систему!). Требования: перекачка воды 10000 литров/час, наработка на отказ 5000 часов.

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

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

Другой пример: электроника с островками софта – наручные смарт-часы.

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

Тем самым мы с некоторой условностью можем считать использующей системой для смарт-часов самого владельца этих часов: часы будем считать буквально входящими в состав тела его владельца. Для многих личных предметов и инструментов это подтверждается и психологическими экспериментами: люди относятся к ним буквально как к продолжению их тела89, «экзотелу».

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

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

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

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

Системы в операционном окружении – рука, одежда (как минимум, рукав рубашки или пиджака), зарядное устройство. Подсистема – защитное стекло из Gorilla glass.

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

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

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

Использующая система – строительство. Один из внешних стейкхолдеров – это заказчик-застройщик, потребность которого – подконтрольность строительства. Функция дрона тем самым – делать фотографии высокого разрешения строительства с интересных заказчику-застройщику ракурсов. Требования: полётное время не менее 1 часа, изображение разрешением не менее 11 Мпикселей, зарядка между полётами не более 1 часа. Подсистема – фотокамера. Системы в операционном окружении: зарядка, стройка с её зданиями, сооружениями и оборудованием (краны), в воздухе они могут рассматриваться как препятствия (например, трос от крана).

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

Системы систем

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

• Имеет независимое управление её систем-элементов (нет, кому скомандовать и профинансировать общее развитие-модернизацию)

• Независимая работа элементов (нет, кому скомандовать работу в общем сервисе этой системы систем)

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

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

• Географическое распределение элементов

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

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

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

В ISO 15288:2015 выделено четыре типа систем систем, отличающихся степенью их автономности:

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

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

• сотрудничающие (collaborative), в которых все системы договариваются друг с другом по каждому чиху, но архитектора, менеджера проекта или аналогичного выделенного органа управления нет.

• виртуальные (virtual), в которых системы вообще не знают друг о друге ничего и не влияют друг на друга явно.

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

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

Люди в системах

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

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

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

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

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

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

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

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

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

Государственное строительство и госпроекты

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

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

У проекта системной инженерии всегда есть вполне определённые стейкхолдеры, которые платят за этот проект: заказчики. Кто заказчик в госстроительстве? Политики? Чиновники? «Народ» (например, опрос общественного мнения или фокус-группа)? «Элита» (и кто её определяет)? Группы экспертов (вариант «экспертократии» – но как выбрать из этих групп «правильную», все эксперты ведь говорят разное)? Нужно чётко понимать, что в случае госстроительства речь идёт о политике, а не о классических стейкхолдерах системноинженерного проекта. Не нужно себя обманывать, говоря, что «есть заказ, оплачивается он из бюджета, следовательно заказчиком является тот чиновник, который будет подписывать мне акт приёмки работ». Госстроительство – это прежде всего политика, в политике подобные рассуждения неприемлемы. Что для одного политического стейкхолдера успех, для другого будет полным провалом, и наоборот, и таких стейкхолдеров столько, сколько разных политических групп. Поэтому государственные проекты будут неуспешными по определению: в них никогда не будут учтены интересы всех стейкхолдеров, эти интересы нельзя будет определить честно и справедливо (напомним, что по определению системной инженерии успешная система – это которая учитывает интересы всех своих стейкхолдеров).

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

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

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

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

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

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

Будущее

Системное мышление даёт возможность понять, как думать о будущем.

Будущее физично – это просто весь мир как 4D индивид, только интересует его временной срез не прямо сейчас, а через некоторое время.

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

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

Что будут люди делать в будущем? Это описывается требованиями.

В каких системах это будет использоваться? Это описывается потребностями.

Мы узнаём будущее по описаниям его целевых и использующих систем – по требованиям и потребностям. «Будущеведение» тем самым – инженерия требований.

Предприниматели зарабатывают на том, что могут предвидеть будущее. Тем самым ведущая дисциплина предпринимательства – это инженерия требований (requirements engineering), которая занимается выявлением потребностей (stakeholder needs/requirements) и требований (system requirements).

Общность мышления по мере усложнения систем

В июне 2014 года INCOSE (International Council on Systems Engineering, Международный совет по системной инженерии95 выпустила публичный документ System Engineering Vision 202596, в котором описала в том числе и рейтинг систем по их сложности для инженерии.

Самые простые системы – это системы с механическими и электрическими элементами (mechanical and electrical elements), вроде велосипеда, насоса или холодильника. Более сложные – это в которых можно найти электронику, и контроллеры с программным обеспечением, управляющие логикой работы каких-то элементов системы (electronic, isolated islands of software), например, стиральная машина или современный автомобиль с двигателем внутреннего сгорания. Но вот уже реактивный самолёт или космический корабль с трудом попадает в эту категорию: логика их работы уже полностью определяется программным обеспечением, поэтому такие системы называют программоёмкими (software-intensive). Это граница применения классической инженерии, все учебники системной инженерии, все стандарты по факту описывают практики создания именно таких систем.

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

Ещё более сложные системы – это предпринятия, т.е. предприятия и другие системы с организационным надзором, в том числе децентрализованным (enterprise, organizational governance (decentralized)). Governance рекомендуем переводить как «поднадзорность», а не «управление»: governance означает, что подназорный субъект не выскальзывает из-под надзора, а продолжает выполнять свои обязательства исполнять поручения полномочного менеджера предпринятия. Созданием таких организационных систем занимаются не системные инженеры, а инженеры предприятий (которые, впрочем, с удовольствием пользуются учебниками и стандартами системного подхода и системной инженерии, равно как и менеджерскими учебниками, стандартами и публичными документами). В состав этих систем входят люди, поэтому в силу самопринадлежности людей предпринятия мы сразу говорим о нём как о системе систем. Но на этом уровне хотя бы есть поднадзорность/governance, то есть существуют стейкхолдеры, полномочные выдавать общие распоряжения по использованию ресурсов.

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

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

Сложность и меры сложности

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

1. Как трудно описать систему? Обычно это измеряется в битах, затрачиваемых на представление описания. Мерами сложности тут будут информация, энтропия, алгоритмическая сложность или алгоритмическое содержание информации, максимальная длина описания, информация Фишера (Fisher), энтропия Рени (Rényi), длина кода (беспрефиксного, Хаффмана, Шэннона-Фано, корректирующего ошибки, Хамминга), информация Чернова, размерность, фрактальная размерность, сложность Lempel-Ziv.

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

3. Какая степень организованности? Тут может быть два варианта:

а) «результирующая сложность» (effective complexity), трудность описания организационной структуры, неважно корпоративной, химической, клеточной. Приведём их по-английски: Metric Entropy; Fractal Dimension; Excess Entropy; Stochastic Complexity; Sophistication; Effective Measure Complexity; True Measure Complexity; Topological epsilon-machine size; Conditional Information; Conditional Algorithmic Information Content; Schema length; Ideal Complexity; Hierarchical Complexity; Tree subgraph diversity; Homogeneous Complexity; Grammatical Complexity.

б) количество информации, которой нужно обмениваться между частями системы из-за такой организационной структуры: Algorithmic Mutual Information; Channel Capacity; Correlation; Stored Information; Organization.

Есть и понятия, которые не являются понятиями сложности, но очень близки: Long – Range Order; Self – Organization; Complex Adaptive Systems; Edge of Chaos. Есть и совсем альтернативные меры сложности (например, основанные на скорости описания оцениваемых объектов, а не объёме этого описания99).

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

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

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

Сначала найти целевую систему

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

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

Целевая система определяется субъективно, «система в глазах смотрящего», поэтому вопрос определения «системы, которую вы хотите сделать» начинается с внимания к тому, кто такие «вы»: сколько вас, какие у вас интересы.

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

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

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

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

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

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

Система – это продукт, или сервис?

Целевая система раньше часто мыслилась как поставляемый продукт.

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

Клиент использует продукт двумя способами:

• в составе своей целевой системы

(например, ваши часы-продукт он устанавливает в

свой автомобиль-продукт, а затем продаёт автомобиль

своему клиенту)

• в составе своей обеспечивающей системы

(например, ваши часы-продукт он устанавливает в свой цех

на стену, чтобы рабочие могли следить за временем в ходе

сборки ими автомобиля – продаёт же клиенту автомобиль

без часов или с какими-то другими часами).

Альтернативное представление продукта – это представление его как целевой системы, принадлежащей клиенту.

Но что тогда делает команда проекта?

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

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

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

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

Переход в мышлении от поставки продуктов к оказанию сервисов оказался очень продуктивным и в современном языке называется сервис-ориентацией.

Например, традиционный продукт – чугунные чушки, «чугун серый литейный»:

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

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

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

Переход от «вещей» к «поведению», изменениям, динамике оказывается очень продуктивен, поэтому сервис-ориентация стремительно вытесняет ориентацию на продукт.

Операционная система Windows 10 уже рассматривается фирмой Microsoft не столько как продукт, но как сервис по её поддержанию. Магазин поставляет не продукт, а сервис по продаже продукта. Программы не нужно поставлять клиенту, ему нужно поставить сервис (внешнее поведение) этой программы – сама программа может остаться у компании, которая эту программу разрабатывает.

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

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

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

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

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

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

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

Ты – член команды

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

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

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

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

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

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

Команда проекта может быть и на пару тысяч человек сотрудников предприятия, а может состоять и из пары человек, и даже одного человека. Разделение на внешних стейкхолдеров и команду как внутренних стейкхолдеров может быть даже более дробным: внутренние стейкхолдеры предприятия (юрлица) и команда предпринятия (отдельного проекта внутри предприятия). Внутренние стейкхолдеры предприятия (например, финансисты, юристы, высшие менеджеры предприятия) заинтересованы в успехе целевой системы, но преследуют совсем иные интересы, нежели команда проекта. Если у вас появятся лишние $1000 в проекте – вы куда их потратите? Улучшите на эту сумму целевую систему, не увеличивая её стоимости – т.е. подарите клиенту? Улучшите ресурсы команды – наймёте более квалифицированных людей, закупите более дорогое оборудование? Отдадите на дивиденды владельцам предприятия? Интересы всех стейкхолдеров разные, критерии принятия ими решений разные.

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

Каждые пять минут менять то, что ты/вы называешь/называете целевой системой – это неправильно. Релятивизм (когда всё на свете считается субъективным и относительным, зыбким и неопределённым – заведомо отсутствует точка отсчёта) в мышлении не поможет. Договорённость по поводу целевой системы должна достигаться из каких-то Принципов, и на достаточно долгое время – желательно, не менять целевую систему во время всего проекта.

Признаки целевой системы

Целевая система определяется ситуативно, о ней договариваются командно, нет никакого алгоритма. Тем не менее, есть эвристики (правила, которые срабатывают часто, но не всегда103), которые помогают найти свою целевую систему среди многочисленных чужих систем в самых разных холархиях. Да, в системном мире царит хаос из совокупности самых разных субъективных мнений, но человек склонен упорядочивать хаос, наводить в нём структуру – символ хаоса совсем не случайно выглядит весьма структурированно:

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

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

Целевая система – это то, что делает (то есть полномочно меняет, а не «влияет на то, что кто-то другой поменяет») команда проекта. Если команда делает описание, по которому потом сделают систему – это непосредственное изменение мира, план этого изменения. Это не уговоры кого-то, чтобы он изменил свою систему. У команды есть какие-то полномочия по отношению к целевой системе, по отношению к другим системам полномочия команды сильно ограничены.

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

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

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

Принцип почтальона

Адреса составлены обычно так, чтобы разные уровни адресации позволяли чётко найти объект, объект уникален внутри какого-то уровня адресации, его легко найти – это и есть принцип почтальона (был предложен А. Нечипоренко в ходе одного из наших семинаров). Скажем, вот адрес пластиковой накладки на ножке стола: Вселенная, комплекс сверхскоплений Рыб-Кита104, Ланиакея105, сверхскопление Девы106, местная группа галактик107, Млечный Путь108, Рукав Ориона109, Солнечная система, планета Земля, Россия, Ростов-на-Дону, ул. Большая Садовая, дом 105, аудитория 323, первый стол от доски у окна, левая ножка стола, пластиковая накладка. Адрес «Вселенная, Солнечная система, Дом 105, пластиковая накладка» – это неправильный адрес целевой системы, неправильное указание на целевую систему.

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

• пропуск уровней, обычно заявляется слишком большой системный уровень, например, сразу использующая система, или даже система на несколько уровней холархии выше использующей. Типичный пример: я делаю автомобиль! После чего следует длинный рассказ о морозоустойчивых аккумуляторах. Почему? – Ну, меня интересуют морозоустойчивые аккумуляторы, они используются в автомобилях. – Могут ли использоваться, например, для гайковёртов? – Да, вполне. – А если гайковёрты в Якутии? Да, это много лучше автомобиля, для моих морозоустойчивых аккумуляторов это отличный рынок! Я занимаюсь гайковёртами! (после некоторых вопросов становится понятным, что и аккумулятор тоже не интересует, речь идёт о морозоустойчивом электролите).

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

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

Типовые ошибки определения целевой системы

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

Мы уже о них писали, но повторим ещё раз, чтобы под рукой был маленький чеклист:

• Описание системы как целевая система. Программисты считают, что их система – исходный код, а не программа в момент её выполнения для пользователя. Проектировщики и конструкторы считают, что это проектная и конструкторская документация (неважно, в электронной или бумажной форме). Сценарист считает, что это сценарий спектакля или фильма, а не сам спектакль или фильм в момент его просмотра. Хореограф считает, что это его тщательно продуманный набор движений, который он показывает танцорам, а не тот танец, который потом станцуют танцоры. Модельер данных – что это модель данных, а не данные, структурированные в соответствии с моделью (например, база данных). Нет, это всё описания целевых систем. Нам нужно доводить мысль до изменения реальности, а не до описания изменения реальности! Описать – не сделать! При этом недостаточно даже использовать «проектирование для изготовления» (design for manufacturing), хотя и это тоже нужно, тоже важно. Проектирование должно быть прежде всего озабочено эксплуатацией, изготовление тут только промежуточная стадия.

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

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

• Сверхобобщения (Принцип почтальона): это частая инженерная ошибка: игнорирование при определении целевой системы использующей системы. Маскируется словами «используется везде», или совершенно неопределённым адресом. « – Где используется ваш сверлильный станок? – В машиностроении!», «Какие танцы вы будете принимать к постановке? – Любые!».

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

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

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

Именование системы

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

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

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

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

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

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

Ещё можно указать на неоправданное использование слова «система» в названиях: «система ножниц по металлу» лучше сразу заменять на «ножницы по металлу».

Использующая система

Использующая система (обычно не говорят «надсистема», хотя в некоторых школах системной мысли используется и термин «надсистема», например, в движении ТРИЗ111) прежде всего должна проверяться на то, что целевая система является в момент эксплуатации (operation, работы) неотъемлемой частью этой системы, то есть буквально входит в её состав (composition). Увы, большинство ошибок происходят именно по невниманию к этому её признаку. Системная холархия – это иерархия по отношению состава/сборки/часть-целое, а не по каким-то другим отношениям. На ошибку выделения использующей и целевой системы указывают обнаружение между ними отношений вызова подпрограммы, классификации и специализации, принадлежности в части имущества, назначения на роль – ведь есть огромное количество других отношений, кроме предписанного для холархии отношения состава (composition, is_part_of, включения как физической части).

Например, рассмотрим мужчину и женщину. Один из студентов высказал мысль, что если женщина целевая система, то мужчина – это использующая система. С этим можно согласиться, но только если мужчина съел женщину! А как ещё женщина может быть составной частью (is_part_of) мужчины?

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

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

При определении использующей системы важно, чтобы это был ближайший уровень (Принцип почтальона), на котором ожидается эмерджентность/системный эффект от работы целевой системы в её составе. Верный способ найти использующую систему – это разобраться, с какими людьми приходится разговаривать, чтобы проект состоялся. Они обычно и есть владельцы использующей системы. Скажем, вы делаете «систему перевозки самолётов», используемую во время ремонтов самолёта. Использующая система – авиация страны, министерство промышленности? Нет, Принцип почтальона говорит, что это «правда, но бесполезная правда», с равным успехом можно говорить и о «человечестве» как использующей системе, и даже о «всей вселенной»! В данном случае довольно просто выясняется, что «системой перевозки самолётов» интересуются главным образом люди из эксплуатационной службы одного из авиапредприятий. Эксплуатационная служба этого авиапредприятия (и даже не всё авиапредприятие!) и является использующей системой. Именно у её команды (внешние стейкхолдеры по отношению к системе перевозки самолётов) есть потребности – им нужно ремонтировать самолёты, которые не летают. И поэтому у них есть какие-то требования к наземной системе перевозки самолётов (заведомо не летающих). Всё, с этого момента (система перевозки самолётов как часть эксплуатирующей службы авиапредприятия = целевая система как часть использующей системы) можно начинать обсуждать проект по созданию системы перевозки самолётов. Ход на выявление владельцев использующей системы (если только это не система систем) обычно крайне продуктивен: всё равно с этими владельцами нужно общаться, они важнейшие внешние стейкхолдеры в вашем проекте.

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

Холархия человеческого движения

Какая целевая система должна быть выбрана в человеке, чтобы заниматься его двигательным фитнесом (fitness, готовность к действию)? Чем танцует человек? Чем он бегает и прыгает? Ответ на этот вопрос так же не прост, как и ответ на вопрос «чем едет автомобиль» (двигателем? колёсами? Креслами и кондиционером в салоне? Заправочной станцией, ибо без неё тоже ведь никак?). Для ответа на вопрос о целевой системе нужно рассмотреть холархию, где на верхних уровнях всегда будет вселенная (туда входит всё на свете) и на нижних уровнях будут атомы (которые входят во всё на свете, ибо всё из них и состоит – кроме тех редких случаев, когда речь идёт о ядерных реакциях или существенными являются поля и энергия).

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

А вот пример нескольких уровней такой холархии для ответа на вопрос «чем двигается человек». Речь идёт о 4D объектах-холонах в пространстве-времени, но нас интересуют прежде всего полные темпоральные части всех этих систем/холонов каждого уровня на момент функционирования/«эксплуатации». Ещё помним, что ничего объективного в наших выборах нет (другие люди для каких-то других целей и проектов могут предложить другое описание), поэтому ориентируемся на всех уровнях на каких-то стейкхолдеров:

• Вселенная

•…

• Живая природа на Земле

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

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

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

• «Фитнес-движок», развитая и осознанная миофасциальная система112: анатомические поезда (ощущаются как некоторые «струны» внутри тренированного тела). Человеческое тело как структура сжатия-растяжения (тенсёгрити113). Двигательная платформа, «мачты для тела движения», работа нервной системы и мозга – виды ощущений и управление «струнами»: как из мышц, костей, фасции, психики/мозга говорить о работе тенсёгрити – добиваться работы или неработы отдельных мышц в миофасциальной системе (предыдущий уровень), обеспечивать постепенное исправление формы суставов и основных поз (осанки, баланса), как добиваться управления какими-то ощущениями и т. д. – вот тут работают тренеры системного фитнеса. Это уровень «общедвигательной», «телесной» (не общефизической!) подготовки, только маргинально известный сегодня в обществе114.

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

• Клетки

– Клеточные органеллы

• Молекулы

•…

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

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

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

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

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

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

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

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

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

Системный подход: для всех видов систем, не только для целевой

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

Как-то специально выделять целевую систему нужно главным образом из-за необходимости помнить, что является коллективной целью, для работы в каких-то командных проектах. Это новинка системного подхода в его втором поколении, деятельностное введение целевой системы/system-of-interest – деятельный интерес ведь всегда чей-то, это и подчёркивается. Но различать определение системы и воплощение системы нужно для всех видов систем. Функциональное задание системы по её назначению тоже проводится для всех видов систем, для всех уровней холархии.

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

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

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

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

• Что лично твоя целевая система?

• Что целевая система твоего клиента, команды?

• Что ты определяешь, на что только влияешь? Что определяет, на что влияет твой клиент, твоя команда?

• Какую систему ты называешь целевой для себя, когда думаешь? Твой клиент? Твоя команда?

• Когда вы общаетесь совместно с клиентом, командой, какую систему ты будешь называть целевой – свою собственную, или клиента, или команды? Помним при этом поговорку театралов: «как было на репетиции, так будет и на спектакле».

• Команда чья – твоя, или твоего клиента? Команда твоя внутри компании «против всех и клиента», или вся компания как команда «против клиента», и нет твоей «команды против компании»?

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

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

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

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

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

Междисциплинарность

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

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

Вот модификация диаграммы из стандарта IEC 81346—1, это иллюстрирующая:

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

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

Минимально в системном подходе нужно увидеть в системе три вида частей:

• Компоненты116 (components), или функциональные элементы, которые позволяют отвечать на вопрос о том, как взаимодействуют части системы, чтобы она выполняла свою функцию («как работает система»). На картинке нарисована принципиальная схема, на которой приведено описание компонент и их соединений (connectors). Компоненты выполняют свою функцию в системе через соединения с другими компонентами, меняя своё состояние от этого взаимодействия и меняя состояния других компонент. Если мы хотим понять, как идёт спектакль, в котором вот этот вот человек говорит своё «To-be-or-not-to-be», нам нужно понять играемую им роль в этом спектакле. Нам понятно, что в спектакле он Принц Гамлет (а не Василий Пупкин, который его играет, Василия при случае ведь и заменить можно на John Doe для пущей убедительности).

• Модули (modules), или конструктивные элементы, продукты, сборочные единицы, логистические единицы – этот вид частей позволяет отвечать на вопрос, из чего собрать и как соединить через интерфейсы (interface) части системы («как собрать систему»). Поведение модуля – это выполняемый им на интерфейсе с другими модулями сервис (service, услуга, служба). На картинке нарисована сборочная диаграмма, позволяющая понять, как собрать систему из частей-модулей – но при этом совершенно непонятно как эта система работает.

• Места (locations), или размещения (allocations), которые позволяют отвечать на вопрос, где можно найти части системы, как она скомпонована в пространстве. На картинке изображены отсеки, в которых ведётся монтаж системы и в которых она затем работает, но непонятно из чего система собрана и как она работает. Всё это ролевые части целой системы, изображённой кубиком с цветными гранями – и каждый стейкхолдер в силу специфики своих интересов видит частное определение системы как «прозрачного ящика», состоящее из интересующих его типов элементов, отвечающих на его интерес. Это «не единое» восприятие целостной системы нормально, так и должно быть! Единым в описаниях у разных стейкхолдеров может быть только единонемыслие (Салтыков-Щедрин). Реальное же единство обеспечивает 4D-экстенсионализм: воплощение системы занимает то же место в пространстве-времени, что и компоненты, модули, размещения. Это и даёт единство: это всё разные способы выделения частей одной и той же системы, разные способы организации внимания, выделения главного и отбрасывания второстепенного для стейкхолдеров. Все стейкхолдеры по-разному думают о системе, представляют её по-разному, а единство обеспечивается тем, что в реальном мире воплощение системы одно и то же – и это даёт возможность и даже требует от стейкхолдеров договорённостей по поводу системы.

У немецких инженеров-электротехников был подсмотрен приём: чтобы сразу было видно, о каком виде элемента говорится, части системы именуют с использованием специальных префиксов: компонентный префикс “=», модульный префикс “-», префикс размещения “+». А имена даются по соответствующей холархии. Так =S12=16 означает, что речь идёт о компоненте 16, входящей в состав (отношение composition, part_of) компоненты S12. Проектирование, конечно, ведётся в классах: это имя класса компонент, а не конкретной компоненты конкретной физической системы. Число уровней в таком имени неограничено. Такое имя компоненты часто называют тегом (tag).

Если имя —M87-K5, то речь идёт о модуле К5, который входит в состав модуля М87. Это тоже не конкретный физический объект с серийным номером, а класс этих объектов, продукт определённой модели.

Стандарт IEC 81346 закрепил такое именование, причём он определяет ещё и как давать коды вместо «нормальных» длинных имён. Действительно, если в каком-нибудь Boeing 787 есть 6 миллионов индивидуальных деталей, то это сразу означает, что у них даже больше имён – и лучше бы держать эти имена короткими, и каждое имя чтобы было понятно, к какой части самолёта относится.

Мы уже знакомились с ситуацией, когда Принц Гамлет и Василий Пупкин могут быть одним человеком, но называться по-разному в зависимости от того, что нам от него нужно – понять, какая фраза будет следующая в его пьесе, когда он планирует выучить новую роль в новом спектакле, или выяснить, есть ли у него дети. То же можно сказать и о системе: «измеритель давления», «манометр KLM-23 завода «Давижмимонтажавтоматика»» и «датчик в пятом ящике на третьей полке склада номер 4» вполне могут оказаться одним и тем же прибором – но разные имена свидетельствуют о том, что мы планируем совершенно разные действия с этим прибором, поэтому для нас один и тот же прибор выступает в разных ипостасях и имеет поэтому разные имена. Имя «Принц Гамлет – Василий Пупкин» вполне осмысленно, хотя на ней приведено сразу два имени отдельных ипостасей актёра: действующего лица и исполнителя роли. Так и имена систем в промышленности часто могут состоять из имён нескольких ипостасей, например, «=S12=16 —M87-K5». Обычно это относится к конкретному проекту, так же, как «Принц Гамлет – Василий Пупкин» относится к одному спектаклю, в другом спектакле распределение ролей будет другое. В силу 4D экстенсионализма все эти имена говорят о каком-то месте в пространстве, так что всегда можно разобраться.

Многерица: единонемыслие единого

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

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

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

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

Беглости подобного мышления «единого-ипостасного» тоже довольно долго учат, хотя идея понимается с первого предъявления.

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

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

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

• ISO 15926 – две основных: функциональные объекты, физические объекты. Остальные могут вводиться по потребности.

• IEC 81346 – «по меньшей мере» три (функция, продукт, место)

• Книга Paul Clements at al., Documenting Software Architectures: Views and Beyond (2nd edition), Addison-Wesley Professional, 2010117 – три стиля (компоненты, модули, размещения, и разные варианты внутри каждого стиля). Авторы этой книги тесно связаны с разработчиками ISO 42010, поэтому мы ориентируемся в нашем учебнике именно на эти названия – «компоненты, модули, места/размещения».

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

• СМД-методология – «по меньшей мере» пять (процессы, элементы и связи, внешние функции, морфология, материал)119

• … и так далее, в среднем 3—7 основных ипостасей (впрочем, «ипостаси» тоже называются везде по-разному) в разных школах системного мышления.

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

Для разных стейкхолдеров система будет представляться в своих аспектах-ипостасях мышления отдельных дисциплин совершенно по-разному – но при этом в системном мышлении она будет оставаться целостной/холистичной/целокупностью всех своих ипостасей/аспектов.

Многерица холархий

Системные холархии для разных стейкхолдеров оказываются тоже разными, ибо «система в глазах смотрящего»: каждая холархия удобна для ответа на вопросы какой-то одной деятельности, а не всех сразу.

Целевая система отличается тем, что для неё компонента, модуль и место совпадают, это одно и тот же экстент в пространстве.

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

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

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

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

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

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

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

Если делать ручки и ножевой блок отдельно как модули, а потом их как-то скреплять, то это будет плохое и ненадёжное инженерное решение.

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

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

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

В инженерных языках моделирования «железной» архитектуры, равно как и в языках моделирования предприятия, компоненты и модули имеют различные значки.

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

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

Компонентный анализ и модульный синтез

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

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

На рисунке из стандарта IEC 81346—1 (а этот стандарт взял этот рисунок из более раннего стандарта IEC 1392/09) «объект с функциональным аспектом» это компонента, «объект с продуктным аспектом» это модуль, а «объект как с продуктным, так и функциональным аспектом» – это модуль, сервис которого выполняет функцию компоненты.

Рассмотрим целевую систему, которую в начальный момент мы рассматриваем как компоненту А. Реализовать (realize) – это вынести «логический» объект-компоненту (роль) в физическую реальность модулей (исполнителей ролей). Первое что происходит – это функциональная декомпозиция: функция компоненты разбивается на более мелкие (на рисунке это B и другие четыре) и делается попытка выбрать для них модули, сервисы которых могут выполнить функции этих компонент. На рисунке видно, что на первом шаге декомпозиции это удаётся только для двух подфункций из шести. На следующем шаге это уже удаётся для всех подфункций, в то числе для подфункций компоненты B. Эта часть функциональной декомпозиции иногда называется функциональным анализом. Дальше мы должны из всех модулей, используя их интерфейсы для соединения, собрать целевую систему-модуль. Для сборки-модуля B на рисунке, реализующего функцию компоненты B это получается только в два шага – сначала собираются два промежуточных модуля, и только потом они объединяются. А на следующем шаге модуль B включается в состав модуля А, который реализует изначально задуманную функцию А. С этого момента функция и сервис совпадают, компонента и модуль совпадают. Эту часть проектирования системы как составления целой системы-модуля из её подмодулей называют модульный синтез.

Проблема в том, что обычно из имеющихся модулей трудно подобрать такие, которые в конструкции реализуют все необходимые компоненты с их функциями. Для этого приходится менять способ разбивки на функции (что эквивалентно предложению другого способа работы устройства, другого принципа работы), а модули приходится разрабатывать, если их нельзя купить готовые (купить – это ведь простейший способ эти модули реализовать/изготовить!). И всегда помним, что модульный синтез – это изобретательская деятельность: желательно научиться много функций навешивать на один модуль, уменьшая количество модулей в системе. ТРИЗ занимается именно этим.

Альфы и рабочие продукты

Стандарт OMG Essence120 предлагает предлагает особый вид компонент – альфа (ALPHA). Альфа – это функциональный объект, контроль за изменением состояния которого позволяет оценивать степень продвижения проекта в работе с этой альфой. Мышление о том, «как проект работает» посвящено альфам, ролевым объектам, они имеют функцию/назначение, вменённые им в проекте человеком.

Этот же стандарт OMG Essence для модулей, физической реализации альф предлагает имя рабочий продукт (work product, иногда используемый синоним – «артефакт», artifact, т.е. предмет искусственного происхождения) – это конструктивный объект: то, над чем работаем, из чего проект «собран», что можно обнаружить в окружающем мире.

Альфа отличается от ранее встречавшихся нам 4D-функциональных объектов тем, что она бывает и абстрактным объектом – каким-то определением системы: требованиями, архитектурой, неархитектурной частью проекта/design. В проекте приходится следить как за функциональной частью разных описаний системы (определениями), так и за функциональной частью воплощения системы (компонентами).

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

Альфы и рабочие продукты нельзя путать: альфы (роли!) существуют главным образом в голове (хотя о них мы и думаем как о реальных объектах), рабочие продукты в мире. В стандарте они изображаются разными значаками: альфа похожа на греческую α, а рабочий продукт на лист бумаги с загнутым уголком.

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

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

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

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

В реальном мире мы видим артефакты «яблоки» и определённые дела с этими артефактами, например, «съесть яблоки», «сосчитать яблоки». Альфы представляют собой те объекты, которые описываются дисциплиной (теорией) – «количество предметов» и «сосчитать предметы», если вернуться к примеру со счётом яблок. Альфа тут – «предмет», а не «яблоко»! Тут нужно привести байку про яблоки из задачи и из жизни, например, в таком варианте121:

Пришла в… школу учительница, которая начиталась работ о дидактической функции наглядных пособий и считала, что надо учить на наглядных пособиях. А проходили они в этот момент задачку на сложение: «3+5». И она принесла три яблока и ещё пять яблок, выложила их на стол и говорит: «Дети, вот вы видите здесь – раз—два—три – три яблока, а здесь вот – раз—два—три—четыре—пять – пять яблок. Вот я их соединяю, сколько получится всего яблок?» Дети пялятся на яблоки, слюни у них текут, но задачи не понимают. Второй день проходит, третий – рекорд: в таком классе обычно за день это проходили. Она приходит в учительскую, жалуется, что вот—де она применяет новые методы, наглядно все, а результата нет. И вот на пятый день с задней парты тянется рука, и ученик говорит: «Мэм, я теперь понял: эти яблоки, которые вы выложили на стол, не настоящие – это яблоки из задачи». – «Да, а что?» – «Ну тогда, мэм, совсем другое дело». И с этого момента, когда класс понял, что это не настоящие яблоки, а яблоки из задачи, все моментально пошло. Почему? Когда вы кладёте реальные яблоки – что с ними надо делать? Их надо есть. А чтобы считать, нужны рисуночки.

Вот ещё про то же самое122:

– Мы займёмся арифметикой… У вас в кармане два яблока…

Буратино хитро подмигнул:

– Врёте, ни одного…

– Я говорю, – терпеливо повторила девочка, – предположим, что у вас в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас осталось яблок?

– Два.

– Подумайте хорошенько.

Буратино сморщился, – так здорово подумал.

– Два…

– Почему?

– Я же не отдам Некту яблоко, хоть он дерись!

– У вас нет никаких способностей к математике, – с огорчением сказала девочка.

Про физическое тело мы знаем, что при наличии силы тяжести они летят по параболе. Ускорения и масса тоже у физических тел. Если кинуть камень и не суметь соотнести его с физическим телом, то нельзя сказать, что он полетит по параболе! Нет таких учебников, в которых описываются полёты именно камней! Ричард Фейнман в своих заметках по преподаванию физики ровно об этом сожалел: по всему миру ученики физики не могут сопоставить отличные знания из учебника явлениям окружающего мира123.

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

Обычно занимающиеся по нашей книге проходят следующие стадии при изучении системного мышления:

• Ничего не понимают, ибо неспособны соотнести материал книги с окружающим их миром. Действительно, в их инженерных, менеджерских, культурных проектах нет никаких альф. А в книге нет ничего, что есть в их проектах. Более того, каждый проект уникальный – в них ведь вообще нет ничего общего, а книга одна и та же для этих самых разных проектов! И эти проекты в книге не описаны, примеры из них не приведены.

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

• Всё понимают и про свои проекты, и про проекты коллег. Но ничего из понимаемого не делают, ибо системное мышление изучается не для того, чтобы его применять, а «для самообразования и развития», «для сдачи зачёта» и т. д. Применять знания мешают начальники, текучка, лень, отсутствие единомышленников, помогать применять знания некому.

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

Альфы

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

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

Альфы (alphas) – это функциональные (выполняющие определённую функцию, играющие определённую роль, идеальные) объекты, по которым мы судим о продвижении (progress, «как много мы уже сделали?») и здоровье (health, «в проекте всё идёт хорошо») проекта.

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

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

Например, учимся думать о «требованиях» – а применяем потом это мышление к конкретным рабочим продуктам, которые можно найти на производстве «в реале»: спецификациям требований, требованиям из текстов стандартов, user stories на карточках, записям в базе данных системы управления требованиями и т. д.

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

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

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

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

Формально (то есть в стандарте OMG Essence124) ALPHA – это аббревиатура, Abstract-Level Progress Health Attribute, но неформально это просто способ указать на функциональный элемент/компоненту проекта. Аббревиатура про health attribute была для альфы подобрана задним числом, а слово alpha пишут поэтому маленькими буквами.

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

Рабочий продукт/артефакт представляет (represent) собой альфу в реальном мире. Это «яблоко из жизни», «его едят» – рабочий продукт имеет в реальном мире какую-то пользу для проекта. Рабочие продукты – это спецификации, тесты, диаграммы и какие-то модели, базы данных и физические объекты.

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

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

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

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

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

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

Описание системы

(Полное) описание системы (system description) это рабочие продукты, реализующие альфы (полного) определения системы (system definition). Если система есть, то она обычно (полностью) определена: подразумевается, что есть её требования, есть её архитектура, есть неархитектурная часть проекта/design, их только нужно выявить и как-то записать – на бумаге или в электронном виде в базе данных тут неважно. Важно чётко различать всегда существующее определение системы-альфу (есть система – значит кто-то её выделил из окружающего мира, думает о ней. Думает – значит определяет, «система в глазах смотрящего») и не всегда существующее описание системы-рабочий продукт.

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

Стандарт ISO 42010 даёт рекомендации о том, как думать о (полном) описании системы. Сам стандарт говорит только об архитектурном описании, но его положения вполне применимы к любым описаниям. Вот задающее мышление об описаниях системы диаграмма из этого стандарта, модифицированная с использованием положений OMG Essence (Рис. 3).

Диаграмма начинается с уже знакомого нам различения воплощения (realization) и определения (definition) системы.

Каждая связь между объектами этой диаграммы может быть прочтена в двух направлениях: «воплощение системы удовлетворяет определению системы», «определение системы характеризует определение системы». «Определение системы выражается описанием системы», «описание системы документирует определение системы».

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

Вот схема на английском языке:

(Полное) описание системы (system description) состоит из частных описаний системы (view) – рабочих продуктов, которые отражают частные определения системы (на диаграмме не показаны).

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

Подальфы (sub-alpha) определяются по отношению к основной альфе как такие альфы, при продвижении которых к конечному их состоянию в проекте мы можем считать, что этим самым как-то продвигается и их основная альфа. Так, требования являются подальфой определения системы: чем более готовы требования, тем более готово и определение системы в целом. Архитектура это тоже подальфа определения системы: чем более готова архитектура, тем более определена система.

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

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

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

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

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

Модели и виды моделей

Само описание (view) состоит из множества отдельных моделей (models), которые можно трактовать как разные способы формального или неформального описания, отвечающие на ещё более частные вопросы. Например, полное описание системы включает в себя финансовое описание системы, но в финансовом описании можно выделить разные модели, нужные для ответа на разные вопросы интересующегося финансами стейкхолдера: баланс, отчёт о прибылях и убытках (profit and loss, P&L) и денежный поток (cash flow). Если у вас есть только баланс, то вы не ответите на вопрос о безубыточности работы предприятия, а если у вас отчёт о прибылях и убытках и даже баланс, то вы не сможете обсудить кассовый разрыв без наличия документов по денежному потоку. Одно описание, три разные модели.

Каждая из моделей отдельных (частных, тематических) описаний должна быть выполнена с использованием одного из вида моделей (model kinds), причем каждый из видов моделей устанавливает определенные язык, правила и приёмы моделирования (соглашения), используемые при разработке модели. Так же как отдельные модели (models) одной тематики объединяются в тематическое описание (view), так и виды моделей (model kinds), определяющие язык, правила и приёмы моделирования (соглашения), используемые при разработке тематического описания, объединяются в тематический метод описания (viewpoint).

Например, для финансового описания нужно прежде всего выбрать один из методов описания – РСБУ (Российские стандарты бухгалтерского учёта), МСФО (международные стандарты финансовой отчётности). При составлении баланса (одна модель финансового описания) и отчёта о прибыли и убытках (другая модель финансового описания) нужно использовать правила для этих видов моделей из одного метода описаний – либо РСБУ, либо МСФО.

Проще всего считать, что метод описания – это набор условных обозначений для многослойных карт-моделей, которые описывают территорию. Одно из следствий рассматриваемой схемы: нельзя делать описания, если в явном виде не рассматривается метод описания. Нельзя делать карты, если неизвестна легенда карты и методы картографирования. Эти карты потом нельзя сопоставлять друг с другом. Нельзя делать карту, используя слои, подготовленные согласно разным методам картографирования – нельзя брать подготовленную геодезистами карту водных ресурсов города и подготовленную службами метрополитена карту-схему станций метро и просто накладывать их друг на друга. Нельзя брать баланс по РСБУ, а отчёт о прибылях и убытках делать в МСФО. Все модели (models) из описания (view) должны быть подготовлены с использованием видов моделей (model kinds) из одного метода описания (viewpoint).

Метод описания чаще всего бывает библиотечным (library), это означает просто, что вместо его содержания приводят просто ссылку на литературу по этому методу. Это всё равно как вместо легенды карты можно было бы просто дать ссылку на книгу, где рассматриваются условные значки для изображения деталей рельефа, флоры, фауны, полезных ископаемых, плотности населения и т. д. Но если пришлось описывать что-то таким способом, который до сих пор не использовался, то вместо этой ссылки придётся к описанию приложить и документированный метод описания. Главное – это запомнить: любое описание – это описание системы, любое описание системы сделано с использованием метода описания (даже если описывающий этого не осознаёт).

Метод описания оформляет (frame) интерес (concern) стейкхолдера. Одно из следствий рассматриваемой схемы: если у стейкхолдера нет соответствующего интереса, то описание не делается. И наоборот: если у стейкхолдера обнаруживается интерес, то описание делается обязательно (документируется! Речь не идёт об устных ответах на вопросы! На бумаге, или в базе данных, но описание должно быть!).

Описания (views) могут быть двух видов: прожекторные (projective) и синтетические (synthetic).

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

Синтетические описания – это когда наоборот: исходные описания даны в виде отдельных моделей, причём каждая модель – это не просто часть одной общей для всех моделей базы данных, а отдельный бумажный или электронный документ. Между этими автономными моделями устанавливаются правила соответствия (correspondence rules, «этот элемент этой модели – это вон тот элемент той модели»), и общая модель тем самым получается синтетически. Рассуждения про полное и частичные описания системы при этом не меняются от того, как собираются эти описания из моделей – сразу (прожекторный подход к описаниям) или после создания отдельных моделей (синтетический подход).

Мультимодель и междисциплинарность

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

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

Бывают и мета-мета-модели, ибо одни описания могут моделировать другие. Так, холодильник моделируется для инженера-ремонтника его принципиальной схемой. Принципиальная схема тут модель холодильника, а вот её обозначения (легенда) будут мета-моделью холодильника. Но когда мы говорим о том, как в компьютерном редакторе принципиальных схем моделируются обозначения для принципиальных схем холодильников, речь идёт уже о мета-мета-модели холодильника. Моделирование многоуровнево, и для компьютерных структурных125 моделей обычно бывает три-четыре уровня мета-моделирования.

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

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

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

Да, человек состоит из атомов, это правда – но это неправильный системный уровень для объяснения того, чем человек отличается от роботов и кошек. Если захочется отремонтировать экскаватор, то моделирование экскаватора из атомов для обеспечения этих ремонтных работ будет крайне неверным решением. Модели должны быть удобны для деятельности, а не абстрактно «научно правильными». И их должно быть много, ибо с системами связано множество разных деятельностей.

Метод описания и мега-модель

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

Частные описания системы (views) состоят из моделей, определяемых методами описания (viewpoints), в свою очередь состоящих из мета-моделей, задающих виды моделей (model kinds).

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

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

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

Если вы даёте кому-то описание системы, то вы обязаны также сообщить, как вы получили это описание.

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

Компонентные описания: принципиальные схемы

У очень и очень многих стейкхолдеров в проекте есть интерес к тому, как система работает в ходе её эксплуатации.

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

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

Вот несколько типичных примеров принципиальных схем:

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

Компоненты физичны, они выбраны так, чтобы удобно было объяснять работу системы в ходе её эксплуатации/функционирования (run time, operations). Соединения – это логические/ролевые/функциональные связи, но в 4D всегда можно найти физический объект, которые своей темпоральной частью реализует эту связь, через которую компоненты взаимно влияют друг на друга.

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

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

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

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

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

Модульные описания

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

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

Интерфейс обычно описывается каким-то стандартом, описывающим как свойства соединения, так и происходящее в ходе взаимодействия модулей через соединение. Интерфейсы модулей похожи на порты компонент в том плане, что это именно места присоединения, они не конструктивные элементы, они не занимают объёма в пространстве, хотя у них и может быть форма. Вилка и штепсель, гнездо и штеккер: интерфейс – это то, что между ними. А сама физическая вилка? Это интерфейсный модуль, главное назначение которого – обеспечить какой-то интерфейс. И у этого модуля два интерфейса: один целевой, а другой – присоединяющий его к какому-то модулю, для которого нужен целевой интерфейс. Вот пример такого интерфейсного модуля (который в просторечии называют USB-интерфейс, что неверно – у него есть ещё и сигнальный интерфейс к плате, и отдельный интерфейс к питанию и даже интерфейс к человеку: светодиод, который мигает, когда идёт передача данных и кнопка включения, а ещё есть механический интерфейс крепления к корпусу или другой плате):

А как же соединения, которые нужны для работы – все эти трубы, кабели, волноводы? Это тоже модули, и у них есть свои интерфейсы: они находятся между ними и теми модулями, которые они соединяют. Что проходит через эти интерфейсы и как оно связано с работой всей системы?! Неизвестно, ибо речь идёт о конструктивных единицах: функции тут не определить, для этого нужно выходить за пределы модульного описания. Единственное, что важно, это наличие соединения: монтажник должен убедиться, что соединение установлено, модуль сможет выполнять свой сервис.

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

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

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

Обратите внимание, сколько тут упоминается разных стандартов: GPS, HSPDA, DDR, Bluetooth – перечисление интерфейсов обычно для модульных описаний. Ведь вся суть модулей – это замена реализации какой-то функции путём простой замены модуля на стандартном интерфейсе.

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

Платформы и технологические стеки

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

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

Основной вопрос при обсуждении платформ – это так называемая видимость интерфейсов. Интерфейсы какого-то низкого системного уровня не должны быть видны снаружи модуля, то есть невозможно соединение модулей иначе, чем через предусмотренные в нём интерфейсы. Грубо говоря, если у вас коробочка с каким-то разъёмом, то нельзя воткнуть внешнее устройство не в этот разъём, а куда-нибудь внутрь коробочки, мимо этого разъёма. Для обсуждения видимости интерфейсов используется диаграмма модульных уровней, диаграмма холархии системных уровней. Каждый уровень отделён от другого уровня каким-то интерфейсом. Реализации нижестоящих уровней тем самым могут быть сменены так, что использующая система этого не заметит. А итоговую холархию называют платформенным стеком или технологическим стеком (stack, стопка – диаграммы похожи на стопку подносов в столовой или стопку листов бумаги в пачке). Вот пример различных технологических стеков для организации связи126:

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

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

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

Часто оба этих способа перемешивают, получая гибридную диаграмму. Вот, например, модульная диаграмма компилятора искусственных нейронных сетей, где верхние строки – наименования программных модулей-пакетов реализации нейронных сетей (например, пакет MXNet), а нижние – интерфейсных стандартов для какой-то аппаратуры (например, стандарт OpenCL)128:

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

Деньги обычно приходят от удачного и массового использования верхнего, прикладного уровня. Но вот «перетряхивание» всего технологического/платформенного стека, перестройка всех рынков идут тогда, когда меняется принцип реализации самого нижнего уровня модулей, меняется платформа нижнего уровня. Например, когда в компьютерах поменялись механические или пневматические элементы на лампы, компьютеры стали масштабируемы и они начали напоминать уже функционально современные компьютеры, а не калькуляторы прошлых лет. Замена ламп на дискретную полупроводниковую технику позволила наладить массовый выпуск компьютеров и это разительно изменило компьютерную технику. Замена дискретной электроники на большие полупроводниковые интегральные схемы опять перевернуло весь компьютерный рынок со всеми надстройками программного обеспечения. Замена CPU на GPU перевернула рынок искусственного интеллекта. Замена людей-исполнителей на роботов-исполнителей переворачивает все промышленные предприятия. Эта особенность делает технологические/платформенные/модульные стеки удобными для обсуждения стратегии компании – обсуждается, что из модулей будет компания делать сама, а что закупать вовне, какие стандарты интерфейсов для этих модулей она будет устанавливать сама, а какие брать уже готовыми129.

Важность функциональных рассмотрений целевой системы

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

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

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

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

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

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

Теперь представим инженера, которому маркетологи говорят, что ему нужно будет решить задачу химического синтеза, но непонятно ещё какую. И они когда-нибудь потом, но вот не прямо сейчас наймут химика, который всё уточнит. Инженер соглашается и берётся за дело: ему сразу понятно, что нужны будут реакторы и трубы. Реакторов непонятно сколько, ибо непонятно, сколько там в синтезе будет химических реакций. Поэтому лучше бы этих реакторов было побольше. Он выбирает цифру 4, как «не очень мало, но и ещё не очень дорого», догадывается, что в этом синтезе может быть хитрая эндотермическая реакция, но сам он для такой реакции реактор вряд ли спроектирует. Так что этот «хитрый реактор» он отдаёт проектировать внешним контракторам и честно об этом пишет. Хотя контракторы и спрашивали, что там с массами и температурой, ответ пока никто не может дать, поэтому контракт планируется без разговора о требованиях – но контрактор, разумеется, от заказа не отказывается и говорит, что «сделаю любой реактор». Слово «любой» никого не отпугивает, ибо нет химика, который бы сказал, что же будет в этом реакторе происходить. Есть только инженеры по железу, хорошо разбирающиеся в марках стали и сварке, и маркетологи, беседующие с врачами и фармацевтами.

В случае железа реактора и труб всё тут очевидно: вероятность выпуска чистого диметилфторидметилхлорпентилбензолтитана в этой ситуации равна нулю. Но в случае софта почему-то кажется, что задачу так решать можно. И вот пишут про «сервера» и «базы данных», но каким образом там будет происходить обработка какой информации, и с чего бы эта обработка вдруг оказалась даже не лучше конкурентов, а вообще возможной, этого вопроса не возникает. Ровно как в предыдущей задаче, где нет химика, есть только сварщики и спецы по корпусам высокого давления. Они точно сделают софтверный «универсальный реактор», но вот что там с чистотой «информационного вещества» или даже просто запуском нужной «информационной реакции» (слова «обработка информации» или «расчёт» так и пишутся, без малейших уточнений, какой именно), и получить исходные данные (или исходную информацию? данные! ибо информация что-то означает, а данные тут как сырьё – можно игнорировать их содержание) – это не к ним. А поскольку в проекте получения чистого диметилфторидметилхлорпентилбензолтитана химика пока нет, про химию разговор поддержать некому, равно как сообразить, как же эта химия влияет на примеси, а примеси на здоровье пациента. За разговорами про реакторы и трубы к этому моменту уже можно забыть, что задачка про медицину, потребности тут в здоровье пациента. А делать приходится железную конструкцию. И нужно протянуть строгую логическую цепочку от одного к другому – через химические реакции, которые описывают функциональную структуру целевой системы, через ведущие к появлению вредных примесей отклонения от режимов проведения этих реакций. При этом предметная область функциональных (химических) рассмотрений – по факту клиентская, а итоговые модульные (труб и реакторов) рассмотрения – предметная область разработчика-контрактора.

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

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

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

Мыслить только про конструкции нельзя. Отсутствие мышления о функциональности нужно как-то осознавать и исправлять. А это отсутствие мышления о функциональности заметно только в случае наличия системного мышления – оно позволяет заметить то, о чём вы забыли подумать, управляет вашим вниманием.

Предпринятия

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

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

Необходимость хорошей модульности

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

Вот компьютерная симуляция зависимости от числа попыток улучшений падения стоимости разработки при улучшении n отдельных модулей, при d связей каждого из них130:

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

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

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

Есть множество методов, которые помогают уменьшать связность модулей в создаваемой системе. Одним из наиболее известных таких методов является DSM (design/dependency structure matrix)132.

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

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

Борьба со сложностью в мышлении

Edsger Dijkstra в 1974 году ввёл133 понятие разделения интересов (separation of concerns) как способ упорядочивания человеческих мыслей о каком-то предмете. Этот принцип гласит, что нужно обсуждать сложные ситуации по одному интересу за раз, удерживая внимание на каком-то одном аспекте, одной ипостаси этой ситуации. Это не значит, что игнорируются все остальные. Просто это удерживание во внимании одного аспекта проблемы и одновременно всей проблемы. По словам Edsger Dijkstra про такое мышление, «It is being one – and multiple-track minded simultaneously».

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

Сложность обсуждения системы тем самым падает по двум направлениям:

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

• деление полного обсуждения каждого холона на обсуждение отдельных ипостасей этого холона как прозрачного ящика: принципов организации взаимодействия и структуры частей холона. Важнейшие из этих определений – это архитектура (architecture), а все остальные определения с точностью, достаточной для изготовления – это неархитектурная часть проекта (non-architectural part of design).

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

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

Но как договориться о том, как склеивать все эти самые разные частные описания самых разных частей системы в одно целое? Как договориться всем этим людям? Это можно сделать на основании 4D экстенсионализма. Все эти описания можно совместить, если понимать, что они описывают одно и то же место в пространстве-времени, относятся к одному и тому же воплощению системы. Без системного подхода сложные проекты с задействованием большого количества разных специалистов выполнить в срок и вовремя невозможно.

Требования как часть определения системы

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

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

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

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

Два понимания требований

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

1. Требования (requirements) – это часть определения системы, определяющая систему как «чёрный ящик», т.е. что делает система по отношению к её системному окружению, без описания внутренней структуры системы, происходящих внутри системы взаимодействий частей системы. Прежде всего тут важно поведение системы, выполнение ей своего назначения, функции в использующей системе. Поэтому основные требования называют функциональными требованиями. Нефункциональных требований не бывает, хотя в литературе этот термин регулярно встречается, но он считается некорректным: все требования описывают какое-то поведение системы, ожидания этого поведения. Но речь не всегда идёт о поведении в использующей системе. Требования качества в отличие от функциональных, относятся прежде всего к поведению в обеспечивающих системах, в том числе обслуживающих уже готовую систему: по-английски их иногда называют – ilities (reliability, accessability и т.п.), а по-русски – ости (надёжность, доступность, и т.п.).

Требования отличают от потребностей (stakeholder needs, stakeholder requirments) как требований внешних стейкхолдеров к использующей системе. Если мы выходим за пределы инженерии, то у требований могут быть другие имена. Например, для организаций речь может идти о стратегии – но суть тут будет та же самая: описание того, что хотелось бы получить от организации. Требования, взятые вместе со временем их выполнения, называют контрольными точками (milestone). Если требование – это «помидор красный», то «помидор красный, 10 мартобря 2019 года» будет контрольной точкой. Очень часто на контроле стоят не сами требования, а контрольные точки: «дорога ложка к обеду».

2. Альтернативное понимание требования уже не имеет отношения к системному подходу, не связано с границами системы. Это просто любое утверждение, данное в деонтической модальности. Любое высказывание из описания системы (например, «X=10») невозможно как-то понять по отношению к деятельности без указания на модальность (modality)134: то, как нужно понимать значения высказывания. Скажем, «в системе [существует] X=10» это алетическая (aletic) модальность, модальность существования. «Я верю, что в системе X=10» – это модальность доксическая (doxastic), веры. Деонтическая (deontic) модальность говорит о долженствовании, разрешении, рекомендации135: «Я требую, чтобы X=10». В этом втором понимании требований можно потребовать что угодно – и оно станет требованием, даже если речь идёт не о чёрном ящике. Например, «в автомобиле должен быть корпус из углепластика», «в смартфоне должны быть использованы отечественные микропроцессоры» относятся к «прозрачному ящику», но слова «должен» и «должны» указывают на деонтическую модальность.

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

Требования и холархия

Стандарт описания требований ISO/IEC 29148:2011 подчёркивает то, что требования есть у каждого холона в холархии. Вот пример из этого стандарта:

Чтобы лучше понять этот пример, нужно «перевести с айтишного» слово business.

Стандарт ISO/IEC 29148:2011 даёт чёткое указание, что слово бизнес (business) тут просто условный термин, обозначающий просто организацию (organization): «The term business is used even though it could apply to not-for-profit organizations such as in the public sector. Users of this standard may replace each occurrence of the term business with the term organization or organizational depending on the users’ environment».

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

Картинка очень неподробно и схематично показывает холархию какой-то организации, в которой внутри организационного окружения (organization environment) находится вся работающая организация (business operation), в которой содержится какая-то часть организации, работающая с системой (system operation), в которой есть система (system), в которой есть элемент системы (system element), в котором есть программное обеспечение (software). Каждый из указанных холонов в холархии имеет какие-то описания «чёрного ящика», называемые требованиями – и на картинке некоторые из них показаны зелёными стрелками, указывающими на границы соответствующих вложенных друг в друга систем-холонов.

Целевой системой тут является «система» (system), требования к ней так и называются: системные требования (system requirements).

Требования к использующей системе будут называться требования стейкхолдеров (stakeholder requirements) или потребности/нужды стейкхолдеров (stakeholder needs). Их не перепутать: они описывают разные системы на их границах (как «чёрный ящик», без подробностей про внутреннее устройство каждой из систем), на картинке это чётко видно.

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

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

Целеориентированная инженерия требований

Идея о том, что требования не «объективны», а их субъективно задают стейкхолдеры для того, чтобы достичь каких-то целей, не так уж стара.

В 1986 году Ивар Якобсон предложил технику выявления требований, при которой рассматриваются варианты использования (use cases)136.

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

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

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

Вот типичная диаграмма вариантов использования137:

В 1995 году появился подход к моделированию требований, называемый i*138, и он продолжил идею взаимодействия актёров и системы для достижения своих целей. Упор был сделан не только на варианты использования системы актёрами, но и на описания взаимодействий самих актёров, а весь подход получил название целеориентированной инженерии требований (goal-oriented requirements engineering). В философии тех, кто может иметь свои цели, принято называть агентами (agents) – независимо от живой или неживой (например, системы искусственного интеллекта) природы этих агентов.

В i* приняли, что требования отражают цели, убеждения, возможности и договорённости агентов, окончательно признав социальную природу требований, их «необъективность»: «Agents attribute intentional properties (such as goals, beliefs, abilities, commitments) to each other and reason about strategic relationships. Dependencies between agents give rise to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a qualitative reasoning approach. Agents consider alternative configurations of dependencies to assess their strategic positioning in a social context».

Был предложен язык для записи взаимодействий актёров, преследующих свои цели:

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

В 2008 году международный союз телекоммуникаций принял стандарт ITU-T Z.151139, в котором для моделирования требований предлагался целеориентированный язык требований подхода i* (Goal-oriented Requirements Language) и карты вариантов использования (Use Case Maps). В простейшем случае вариант целеориентированной системной инженерии предполагает написание коротких пользовательских историй (user story), в которых актёр сведён до обычной стейкхолдерской роли. Пример формата таких историй140: «Я как _стейкхолдер_ хочу, чтобы _целевая-система_ _формулировка требования _, для того чтобы _потребности-для-использующей-системы_».

Проверка и приёмка

Проверка и приёмка (verification and validation, V&V, верификация и валидация) служат для того, чтобы убедиться в работоспособности системы. По сути, это просто тщательное тестирование системы, проведение испытаний, обоснование успешности системы. Успешность – это соответствие ожиданиям стейкхолдеров. Стейкхолдеров же у нас два набора:

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

• и внутренние, которых волнует работоспособность целевой системы – работает ли целевая система как задумано, удовлетворяет ли системным требованиям?

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

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

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

Понятие архитектуры

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

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

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

ISO 42010 даёт следующее определение архитектуры: «Архитектура (системы) – основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития»142. Обратите внимание, что в этом определении нет никакого упоминания структуры системы. Ибо для такой системы как интернет нельзя указать на структуру системы: в интернете никто не знает, что входит в структуру интернета в каждый конкретный момент, какие есть связи между элементами этой системы, непрерывно появляются и исчезают новые узлы интернета и между ними непрерывно появляются и исчезают новые каналы связи. Но определение от этого не стало понятней.

Вот другое определение архитектуры, от части авторов того же ISO 42010, но данное ими в книге про документирование системных архитектур143: «Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений»144. Там наоборот, дан акцент на структуры.

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

Мы будем придерживаться неформального простого и понятного определения архитектуры, которое дал Ralf Johnson: «Архитектура – это обо всём важном. Что бы это ни было.»146.

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

Если принято решение сделать какой-то винтик не с левой резьбой, а с правой, то вряд ли это приведёт к переделке всего изделия. Будет переделан лишь этот винтик и резьба в связанной с ним гайке. Такое решение не архитектурное. Весь проект/design тем самым делится на две части: архитектура и неархитектурная часть проекта (non-architectural part of design).

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

Более сложные формы архитектурных описаний включают в себя компонентные, модульные диаграммы, трассировку компонент и их функций к модулям, размещения и компоновки. То есть архитектурное описание это совсем необязательно список принятых решений: решения могут быть документированы и в других формах. Главное, чтобы они не оказались устными. Интересно, что в советской устной архитектурной традиции, когда архитектурных описаний практически не было, всё важное обозначалось словами «заделы», «опыт», «наработки». Архитектуры были, но их нельзя было предъявить, обсудить, передать, развить иным способом, кроме как задействовав ту команду, которая имела тот самый «опыт» и «заделы» в голове.

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

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

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

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

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

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

• компоненты + модули + размещения (только важные, верхнеуровневые), или оно же как

• принципиальная схема + заказная спецификация + компоновка (только важные, верхнеуровневые), или оно же как

• логическая архитектура + физическая архитектура (при учёте возражения о недопустимости «частных архитектур»), или оно же как

• список важнейших принятых конструкторских/проектных/постановочных решений

Понятие конфигурации

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

В ходе разработки инженерной системы обычно рассматривают самые разные варианты требований, архитектуры, неархитектурной части проекта/design. И эти описания ещё и изменяются каждое по нескольку раз. Как определить, какие из этих описаний должны быть использованы изготовителями системы? А если часть изготовителей изменили систему так, что она уже не соответствует этим описаниям, а часть изготовителей работает «как договаривались» – можно ли быть уверенным, что из изготовленных частей можно будет собрать работающую систему? Конечно, нет. Ошибки, связанные с тем, что некоторые части системы и их описания не известны, или даже известны, но не соответствуют друг другу, весьма распространены.

Конфигурация системы – это сами части системы и их описания. Сама конфигурация может быть определена (defined) и, соответственно, описана (described). Описание конфигурации (configuration description, иногда говорят и «конфигурационное описание») в речи часто сокращают до просто «конфигурация» – и разницу между конфигурацией (составом самой системы) и описанием конфигурации нужно определять из контекста так же, как разницу между архитектурой и архитектурным описанием, когда для обоих используют слово «архитектура».

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

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

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

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

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

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

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

Инженерия предприятия

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

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

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

Биологический жизненный цикл

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

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

В инженерии, менеджменте, предпринимательстве, культуре всё не так:

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

• Целевые системы не несут яиц, не живородят, не размножаются вегетативно. Это означает, что жизненный цикл не замыкается, не повторяется. То есть это не цикл.

Жизненный цикл оказался для неживых систем не жизненным и не циклом, но сам термин остался, причём он постепенно менял своё значение.

Понятие жизненного цикла системы 1.0

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

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

Для планирования работ обычно составляется план, в котором прописываются ответственные за выполнение работ, и время, за которое эти работы должны быть сделаны. Часто в план прописывают и другие требуемые ресурсы.

Каждая работа проходит следующий цикл (это подробно обсуждается в подходе к архитектурному описанию предприятий DEMO149):

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

• Работа принята к исполнению, это тоже координационный акт.

• Работа выполняется. Это производственный акт (production act), реальное выполнение работ.

• Работа предъявлена к приёмке, это координационный акт.

• Работа принята, координационный акт.

Деление на координационные и производственные акты важно, чтобы делать правильные оценки времени: от момента затребования работы до момента принятия работы на координационные акты может уходить до 40% времени, и только 60% времени на проведение самой работы. Как планировать работы – по полному времени координации+производства работ, или только по актуальному времени потребления ресурсов? Разные школы управления работами отвечают на этот вопрос по-разному.

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

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

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

Когда говорили «жизненный цикл АЭС», то имели ввиду разбитые на стадии все работы, которые выполняли многочисленные предприятия от момента замысла АЭС до момента вывода её из эксплуатации с получением после этого зелёной площадки.

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

Изображение жизненного цикла как работ (1.0)

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

Вот примеры такого изображения жизненного цикла разных типов систем из стандарта ISO 15288:

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

Вот этот же жизненный цикл, но там уже используются не ломтики «колбаски», а «шеврончики», означающие «процесс» с последовательными стадиями:

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

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

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

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

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

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

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

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

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

Проблемы с жизненным циклом 1.0

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

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

Затем появилась вообще параллельная инженерия (concurrent engineering), в которой намеренно в параллель/одновременно выполнялись работы, ранее считавшиеся строго разнесёнными по разным последовательным стадиям жизненного цикла: одновременно и велось проектирование, и изготовление системы, а какие-то неполные версии системы ещё и начинали эксплуатировать. Разговор о «стадийности» жизненного цикла всё больше и больше становился условным, а не сущностным.

Вот типичная картинка объяснения перехода к параллельной инженерии (и на ней хорошо видно, что сроки работ существенно сокращаются)150:

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

Сейчас хорошо понятно, что так долго продолжаться не могло, и на передний план должно было выйти функциональное представление обеспечивающих систем – «как работает» (а не «из чего собрать») обсуждается именно по принципиальным схемам, функциональным диаграммам. Но это произошло не сразу, поначалу появилось множество гибридных диаграмм. Одной из самых известных таких гибридных диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP)151:

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

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

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

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

Жизненный цикл 2.0

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

Наборы различных архитектурных решений по поводу отнесения практик к работам жизненного цикла получили название виды жизненного цикла (life cycle model152, модели жизненного цикла).

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

Первый вид жизненного цикла (квинтэссенция подхода 1.0) получил название «водопад» (cascade, каскад).

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

Для более убедительной иллюстрации этого «невозвратного» хода работ традиционную «колбаску» начали рисовать как ступеньки настоящего водопада153:

Между стадиями осуществлялась тщательная проверка и приёмка (verification and validation, V&V) рабочих продуктов-результатов предыдущих стадий, при этом принималось решение о продолжении работ, возврате на доработку или прекращении работ. Эти проверки и приёмки с принятием решений между стадиями жизненного цикла получили название гейтов (gates, ворота):

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

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

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

Но инженерам нужно было делать сами проекты, им нужно было содержательно преодолевать утопичность «водопада с гейтами».

Поэтому была предпринята радикальная попытка заменить модель жизненного цикла с приматом метода описания работ-стадий на прямо противоположную, функциональную, с приматом метода описания практик. Работы в этой модели учитывались как развёртка применения тех или иных практик работы во времени, а сама линия времени как символ выделения ресурсов для показанных практик была нарисована по спирали. Этот вид жизненного цикла был предложен Barry Boehm в 1978 году, успешно реализован им 1981 и опубликован 1988 году. Этот жизненный цикл получил название спирального154:

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

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

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

Современный вариант спиральной модели жизненного цикла носит название «модель пошагового спирального выделения ресурсов» (Incremental Commitment Spiral Model, разрабатывалась Barry Boehm, Jo Ann Lane,‎ Supannika Koolmanojwong, Richard Turner в 2006—2014 годах как продолжение работ по развитию идей спирального вида жизненного цикла) и используется в военных инженерных проектах США155.

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

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

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

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

Эксплуатация как выделенная стадия жизненного цикла

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

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

Сам человек тут показан как 4D индивид. Это позволяет обсуждать изменение его состояний как полных темпоральных частей.

Его рожают (показана семья как обеспечивающая система), учат (школа/учительница как обеспечивающая система), и в этот момент, когда он ещё не вырос, и недоучен, он не является полностью дееспособным. Затем он эксплуатирует (сам себя! У него самопринадлежность), и обеспечивающие системы не показаны – вместо них мы находим множество систем в его операционном окружении. Да, в это же время идут «ремонты» (врачи) и «модернизации» (учёба, физподготовка), но чаще всего на диаграммах жизненного цикла это не отражается. А затем доктора его лечат, а микробы прекращают существование тела.

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

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

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

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

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

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

Есть два разных понимания эксплуатации в части представления ремонтов (обслуживания, maintainance – конструкция и функциональность остаются прежними) и модернизации (modernization, частичное изменение функциональности и конструкции):

• Эксплуатация как стадия включает в себя все эти работы. Главные люди – операторы и пользователи. Ремонтники и инженеры по модернизации отдельно не учитываются.

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

Это лишний раз подчёркивает условность отнесения работ к разным стадиям.

Три времени жизненного цикла

В жизненном цикле есть три явно выделенных времени, которые нужно удерживать в сознании всё время работы с целевой системой:

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

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

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

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

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

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

Понятие практики

Как и для любых других определений системы, ключевым для определения обеспечивающих систем является её компонентное, функциональное определение, отвечающее на вопрос «как работает?». Компонентами/функциональными элементами обеспечивающих систем как систем человеческой деятельности являются практики (practices).

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

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

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

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

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

Формула для запоминания: «в практике дисциплина загружается в голову, а технология разворачивается на местности».

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

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

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

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

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

Архитектура предприятия (enterprise architecture) обсуждает главным образом распределение полномочий по использованию ресурсов труда (компетентные в исполнении работ практики исполнители) и технологии (задействование инструментария, сырья, других рабочих продуктов). Она обеспечивает гладкое прохождение координационных актов DEMO.

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

Дисциплина в составе практики

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

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

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

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

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

Есть ли какой инструментарий (технология) для системного мышления как дисциплины, технология? Да, конечно: это всевозможные моделеры, позволяющие делать модели самых разных систем. Тем самым системное мышление вполне возможно считать практикой: содержание её загружается в голову, а на местности необходимо развернуть инструментарий моделирования систем, поддерживающий частные описания (view), методы описаний (veiwpoints), управление конфигурацией полного описания (description)158.

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

Дисциплина в практике меняется относительно редко, чаще всего речь идёт о цикле изменений в 20 лет, а то и больше. Например, системный подход относительно стабилен, знания его текущей версии помогут пару десятков лет. А вот технологии меняются много чаще. Моделеры для того же системного подхода меняют свои поколения каждые 4—5 лет (средняя скорость смены поколений в информационных технологиях), но они при этом по факту поддерживают одну и ту же много медленней меняющуюся дисциплину.

Тем не менее, быть успокоенным владением какой-то дисциплиной нельзя. Так, состояние state-of-the-art (SoTA, лучшее известное на сегодняшний момент) дисциплины попадает в учебники лет через пять, ещё пять лет проходит в ВУЗе, и всего через десять лет работы можно обнаружить, что владеешь каким-то уже совсем антикварным пониманием дисциплины. Например, большинство сегодняшних инженеров, менеджеров, предпринимателей и даже спортсменов и танцоров если и знают хоть как-то системный подход, то устарелую его первую версию, в которой ещё нет стейкхолдеров, жизненный цикл означает только работы. Нельзя успокаиваться, нужно отслеживать не только относительно частые смены технологии в практике, но и относительно редкие изменения в дисциплине.

Технология в составе практики

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

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

Так, программы проектного управления могут поддерживать самые разные дисциплины проектного управления, самые разные наборы альф. Например, управление проектами может быть классическим с альфой «критический путь» (critical path) и по теории ограничений с альфой «критическая цепь» (critical chain)159 и управлением по заполнению буферов проекта160. Если вы не понимаете связи между инструментами и дисциплинами, и купите просто «программу управления проектами», то вас может ожидать сюрприз.

В программе управления проектами на рисунке (Рис. 5) нет никаких буферов проекта, поэтому она не поддерживает мышления согласно дисциплине управления проектами теории ограничений.

А вот эта программа (Рис. 6) поддерживает, «светофоры» буферов хорошо видны на её скриншотах.

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

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

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

При развитии люди образовываются (education, «как в ВУЗе») для освоения новой дисциплины мышления и обучаются/тренируются (training, часто на рабочем месте) в работе с новой технологией, новым инструментарием.

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

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

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

Практики жизненного цикла

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

Все эти стандарты и публичные документы используют для практик разные названия – практика (practice), способности (abilities), процессы (следуя традиции «функционального описания процессов», заложенной серией стандартов ISO 9000, в которых путались модульный/конструктивный «процесс как последовательность шагов/операций/работ во времени» и компонентный/функциональный «процесс как описание принципов, каким способом нужно достичь результатов»), методы (наборы практик, достаточных для решения какой-то содержательной задачи «под ключ»), и даже методологии (ISO 24744 предложил считать метод/method и методологию/methodology синонимами), иногда «область знаний» (knowledge area), с которой связывают какую-то «деятельность» (activity). Иногда и вообще не используют каких-то терминов – просто говорят, «что нужно делать», приводя название практик, но не используя сам термин.

• свод знаний по организационному анализу (business analysis body of knowledge, BABoK)162. Тут в главе 10 кратко охарактеризован набор из 50 практик, называемых «метод», начиная с 10.1 Acceptance and Evaluation Criteria (Определение критериев приемки и оценки), 10.2 Backlog Management (Управление бэклогом), 10.3 Balanced Scorecard (Сбалансированная система показателей, ССП), 10.4 Benchmarking and Market Analysis (Бенчмаркинг и Анализ рынка), 10.5 Brainstorming (Метод мозгового штурма), 10.6 Business Capability Analysis (Анализ бизнес-возможностей), 10.7 Business Cases (Бизнес-кейсы), …, 10.47 Use Cases and Scenarios (Сценарий использования и Сценарии), 10.48 User Stories (Пользовательские истории), 10.49 Vendor Assessment (Оценка поставщика), 10.50 Workshops (Воркшопы или Семинары)

• свод знаний по проектному управлению института проектного управления (Project Management Institute, project management body of knowledge, PMI PMBoK)163. Там практики называют «процесс», например, группа процессов планирования определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов, и т. д. (всего 47 процессов в актуальной 6 версии PMI PMBoK).

• свод знаний по системной инженерии (systems engineering body of knowledge, SEBoK)164. Сами практики тут не выведены явно, а рассыпаны по всему тексту. Это, скорее, «краткое оглавление для большой литературы по предмету системной инженерии», поделенное на «области знаний».

• … множество других BoK, это сегодня стандартная форма выражения знаний по практикам какой-то инженерной или менеджерской дисциплины.

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

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

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

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

И даже на этом уровне могут быть самые разные варианты. Например, при развитии ТРИЗ за последние двадцать лет тамошние практики инженерии системной архитектуры были дополнены практиками инженерии требований. Так что для выявления требований можно или использовать методы/практики ТРИЗ166 (включая технологию: моделеры специфических для этого диаграмм ТРИЗ), или альтернативных других практик, например вариантов/сценариев использования (use cases, включая технологию: моделеры специфических диаграмм use cases).

Пример: практики жизненного цикла системной инженерии

Стандарт практик жизненного цикла системной инженерии 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.

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

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

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

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 интересуют практики инженерии требований, в том числе поддержка какой-то выбранной дисциплины инженерии требований каким-то моделером требований, системой управления требованиями.

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

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

Альфа возможности

Из V-диаграммы с подальфами хорошо видно, что потребности/требования стейкхолдеров это подальфы возможности, а не подальфы определения системы.

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

• Она будет кому-то нужна, и за неё смогут заплатить

• Её кто-то сможет сделать за разумную плату.

Это ведёт к следующим возможным подальфам возможностей:

• Потребности стейкхолдеров (нет потребностей – нет возможности сделать проект, никто не заплатит).

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

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

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

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

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

Альфа возможности в ходе проекта проходит следующие состояния/контрольные точки (в формулировках в том числе подчёркивается связь состояния этой альфы с состояниями других альф)201:

• Выявлена (identified): найдена идея; найден как минимум один стейкхолдер, желающий сделать инвестицию в понимание возможности; определены другие стейкхолдеры.

• Нужно решение (solution needed): выявлено инженерное и/или культурное решение; установлены потребности стейкхолдеров; определены проблемы и их причины, подтверждено, что стейкхолдерам это решение нужно; было предложено как минимум одно архитектурное решение.

• Польза установлена (value established): польза возможности была определена количественно; влияние решения на стейкхолдеров понятно; польза системы стейкхолдерами понимается; критерии успешности ясны; результаты ясны и выражены количественно.

• Жизнеспособна (viable): решение обрисовано в общих чертах; решение возможно с учётом ограничений; риски приемлемы и управляемы; решение выгодно; причины для разработки решения понимаются; ясно, что реализация возможности жизнеспособна.

• Реализована (addressed): возможность реализована; решение достойно воплощения; стейкхолдеры удовлетворены;

• Извлекается выгода (benefit accrued): решение приносит выгоду; возврат на инвестиции приемлем.

Альфа стейкхолдеров

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

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

Хорошей практикой является сразу разделение альфы «стейкхолдеры» на отдельные подальфы «стейкхолдер» и раздельный учёт состояния этих подальф.

Вот состояния/контрольные точки для стейкхолдеров:

• Признаны (recognized): группы стейкхолдеров выявлены; ключевые группы стейкхолдеров представлены; ответственности представителей стейкхолдеров определены.

• Представлены (represented): стейкхолдеры согласились с ответственностью; представители получили полномочия; подход к сотрудничеству согласован; практики работы поддерживаются и уважаются.

• Вовлечены (involved): представители помогают команде; реагирование представителей на запросы своевременно и они предлагают решения; изменения сообщаются вовремя.

• В согласии (in agreement): минимальные ожидания согласованы; представители стейкхолдеров довольны своим вовлечением; вклад стейкхолдеров приносит пользу; вклад команды приносит пользу; приоритеты ясны и перспективы команды и стейкхолдеров сбалансированы.

• Удовлетворены для разворачивания (satisfied for deployment): имеется отклик/feedback стейкхолдеров; система готова для разворачивания.

• Удовлетворены в использовании (satisfied in use): отклик/feedback по использованию системы доступен; система отвечает ожиданиям.

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

Альфа определения системы

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

В оригинальном OMG Essence в числе основных альф нет определения системы, но зато есть альфа «требования». Доработанный для системной инженерии вариант включает в себя все подальфы определения системы – и требования, и архитектуру, и неархитектурную часть проекта/design (рабочку).

Состояния альфы определения системы тут даётся очень обобщённое для «железной системы», рекомендуется для разных систем адаптировать эти состояния:

• Замыслено (concieved): стейкхолдеры согласны, что система будет сделана; методы описания системы согласованы; способ согласования описаний со стейкхолдерами согласован; механизмы управления конфигурацией описаний согласованы.

• Непротиворечиво (coherent): определения системы документированы, и описания доступны команде и стейкхолдерам; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда понимает описания и соглашается их воплотить; соответствующая описаниям система принимается стейкхолдерами как заслуживающая воплощения.

• Используется для изготовления (in use for manufacturing): изготавливающая систему часть команды считает, что описаний хватает для начала изготовления; технологии изготовления определены и описаны; возникающие при изготовлении системы проблемы приводят к доработке и актуализации определения системы.

• Используется для проверки и приёмки воплощения (in use for V&V): есть все описания, нужные для проверки и приёмки; проверки, критерии их успешности и способ проведения определены; стейкхолдеры согласны с объёмом проверок.

• Используется для эксплуатации (in use for operations): определение системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); определение системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации.

• Используется для вывода из эксплуатации (in use for retirement): используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.

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

Альфа воплощения системы

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

• В виде сырья (as a raw material): материалы для воплощения системы наличествуют и позволяют создать части системы с нужными характеристиками; оборудование для переработки материалов в детали наличествует; график производства и логистики частей системы согласован; возможны работы по изготовлению частей.

• В виде частей (as a parts): части воплощения системы созданы и/или закуплены и проверены; график интеграции (сборки, монтажа, строительства) из частей согласован; возможны работы по интеграции (сборке, монтажу, строительству).

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

• Готово (ready): функциональность протестирована; уровни дефектов для стейкхолдеров приемлемы; установочная и другая пользовательская документация доступна; представители стейкхолдеров удовлетворены системой; состав передаваемой системы известен; представители стейкхолдеров готовы эксплуатировать систему; эксплуатационная поддержка наличествует.

• Эксплуатируется (operational): доступна стейкхолдерам для эксплуатации в рабочем окружении; есть как минимум один пример работающей системы; поддерживается на согласованном уровне сервиса.

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

Альфа работы

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

• Инициирована (initiated): требуемый результат работ ясен; ограничения ясны; известен стейкхолдер, который платит за работы; инициатор выявлен; принимающие работу стейкхолдеры известны; источник денег ясен; приоритеты ясны.

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

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

• Под контролем (under control): количество завершённых задач растёт; незапланированная работа под контролем; риски под контролем; оценки пересматриваются, чтобы отражать реальную производительность команды; прогресс измеряется; переделки под контролем; обещания выполнения работ выполняются.

• Закончена (concluded): остались только административные задачи; результат работ был достигнут; стейкхолдеры приняли результирующую систему.

• Закрыта (closed): метрики были сделаны доступными для других проектов; всё было заархивировано; бюджет был сверен и закрыт; команда была освобождена; нет незавершённых недоделанных задач.

Альфа команды

Альфа команда представляет собой тех сотрудников, которые охотно и качественно выполняют роли внутренних стейкхолдеров. Ведущие дисциплины тут – управление персоналом (human resources management), управление талантами (talent management, занимающиеся обеспечением организации сотрудниками-актёрами и их подготовкой к выполнению внутренних стейкхолдерских ролей в командах проектов, а также практика лидерства (leadership), занимающаяся обеспечением сотрудничества в команде, т.е. качественного отыгрывания стейкхолдерских ролей и продуктивного взаимодействия с другими членами команды.

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

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

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

• Сотрудничает (collaborating): команда работает как одно сплочённое подразделение; общение в команде открытое и честное; команда сфокусирована на достижение миссии команды; члены команды знают друг друга.

• Производит (performing): команда постоянно выполняет обязательства; команда непрерывно адаптируется к изменяющемуся контексту; команда определяет и решает проблемы без внешней помощи; минимум возвращений к сделанному и переделок; работа впустую (waste) и причины для работы впустую постоянно устраняются.

• Распущена (adjourned): обязанности были выполнены; члены команды доступны для участия в других командах; миссия завершена.

Альфа технологии

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

Поэтому мы приняли решение для way of working говорить о том, что осталось от практики и разворачивается на самом предприятии – о технологии, но рекомендуем при этом не забывать о практике в целом, и это отражено в формулировках состояний альфы/контрольных точек. Конечно, говорить сразу о всех практиках и всех их технологиях не получится – поэтому лучше всего будет отслеживать в проекте связанные с технологиями подальфы отдельных практик/способов работы/технологий, а то и дробить их дальше на подальфы инструментов и отдельных рабочих продуктов.

Вот состояния/контрольные точки основной альфы «технологии»:

• Дисциплина установлена (principles established): команда активно поддерживает дисциплину/теорию/принципы; стейкхолдеры согласны с принципами; потребные для их поддержки инструменты согласованы; рекомендации по выбранному подходу доступны; рабочий контекст понимается; ограничения практики и выбранных в её составе инструментов известны.

• Основа положена (foundation established): ключевые практики и их инструменты выбраны; практики, необходимые для того, чтобы начать работу, согласованы; практики, по которым не будет обсуждений и их инструменты выявлены; разрыв между доступными и необходимыми оргвозможностями/capability определён; способ работы, в котором все практики удобно использовать, определён.

• Используется (in use): практики и их инструменты используются; использование практик и их инструментов регулярно проверяется; практики и их инструменты адаптированы к контексту; практики и их инструменты поддерживаются командой; механизмы получения откликов/feedback на практики и их инструменты работают; практики и их инструменты поддерживают общение команды и сотрудничество.

• Наличествует (in place): практики и их инструменты используются всей командой; оргвозможности доступны всей команде; проверяются и адаптируются всей командой.

• Работает хорошо (working well): делается предсказуемый прогресс; практики применяются естественным образом; инструменты естественным образом поддерживают принятую дисциплину работы; идёт постоянное совершенствование/подстройки.

• Вышла из употребления (retired): больше не используется; уроки использования практики опубликованы для использования в будущем.

За чем следить в проекте

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

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

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

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

Формулировки контрольных точек в Essence намеренно «мутные», неопределённые и расплывчатые. Авторы стандарта говорят, что это поощряет команду провести обсуждение этих контрольных точек, чтобы адаптировать формулировки к индивидуальным особенностям проекта, и получить явное соглашение команды о том, что все члены команды одинаково понимают эти контрольные точки.

Всего семи объектов внимания в проекте не будет хватать – тем более в больших проектах. Поэтому команде необходимо уделять внимание не только альфам, но и подальфам, на что мы обратили внимание, когда описывали основные альфы.

Но часто команда будет брать эти подальфы из дисциплин/теорий/принципов принятых ими практик. Например, в практике управления проектами методом критической цепи вводят альфу «буфер проекта» (project buffer) и отслеживают затем её состояние – сначала этот буфер проекта создаётся, потом потихоньку расходуется в ходе проекта. Essence предлагает, чтобы все эти подальфы обязательно были подальфами либо основных альф, либо друг друга (подальфы представляют собой направленный граф, в том числе подальфа может быть подальфой сразу нескольких основных альф или других подальф). Так, альфа «буфер проекта» может быть подальфой «работы». И ответ на вопрос «в каком состоянии работы проекта?» может включать в себя отдельный рассказ про состояние «буфера проекта».

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

Состояния альфы и рабочие продукты

Состояния альф можно узнать не сами по себе, «умозрительно», а посмотрев на состояние связанных с ними рабочих продуктов. С альфами происходит мышление, с рабочими продуктами происходит работа. Конечно, для описания (view, набор моделей) состояния альфы в рабочем продукте должен быть использован какой-то метод описания (viewpoint, метамодель и принципы создания модели, методические указания по моделированию предметной области интереса/concern). Поэтому в реальной обстановке обсуждение ведётся не только альф, но и рабочих продуктов.

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

«Стейкхолдеры признаны»

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

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

Как работают с системной схемой проекта

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

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

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

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

Подальфы

Подальфы и их состояния порождаются командой по потребности, когда команда понимает, что уровня контроля не хватает, и нужно внимание к частям ситуации, определяемой альфой. Подальфа – это просто альфа, только она не «верхнего уровня», не основная (essence), не из системной схемы проекта. Более того, у каждой альфы (в том числе у подальф) могут быть свои подальфы, а одна подальфа может быть подальфой нескольких альф и подальф. Примеры этих подальф можно брать в самом стандарте OMG Essence, можно брать в разнообразной литературе (прежде всего тут нужно указать на разработки Ivar Jacobson International по разработке альф для самых разных практик, особенно для гибких методологий203).

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

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

• Выбран – технико-коммерческие предложения получены; переговоры с кандидатами проведены; технико-коммерческие предложения оценены; подрядчик нами выбран.

• Привлечён – валютные, сроков поставки, качества и прочие риски оценены; договор с учтёнными рисками подписан; аванс перечислен; необходимая документация для начала работ передана; уведомление о начале работ получено; процедура коммуникации команды с исполнителями установлена.

• Работы идут – надзор за работами установлен; запросы обоих сторон учитываются; запросы обоих сторон своевременно решаются; график работ соблюдается; технология работ соответствует ожидаемой; коммуникация команды с исполнителем не прерывается.

• Работы приняты – уведомление об окончании работ получено; испытания проведены; претензий к качеству работ нет (претензии сформулированы и устранены); акты проведения успешных испытаний подписан; результаты работ доставлены на место; документация передана; монтажные работы произведены; пуско-наладочные работы проведены.

• Работы закрыты – акт приёмки-сдачи подписан; деньги перечислены; никаких дел к подрядчику нет; гарантийные и сервисные работы производятся; документация архивирована.

Регулярная проверка того, что сделано и что не сделано по такому чеклисту существенно снижает риски.

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

Как пользоваться постоянно раздувающимся списком подальф с их контрольными вопросами для прохождения контрольных точек может помочь практик работы с чеклистами, описанная в книге Атула Гаванде «Чеклист. Как избежать глупых ошибок, ведущих к фатальным последствиям».204

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

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

Основной жизненный цикл

Горбатая диаграмма, использовавшаяся в RUP, получила своё развитие: в более современных версиях (например, из enterprise unified process, EUP, 2013) приводится другой набор практик и другой (полный, а не только стадии разработки и перехода к эксплуатации) набор стадий205:

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

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

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

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

Модели зрелости и модели готовности технологий

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

Например, для ISO 15288 (стандарта практик жизненного цикла системной инженерии) штатно предполагается использование модели зрелостей из ISO 1504 (стандарт проверки соответствия используемых практик описанным международными стандартами практик). Соответствие предполагает некоторые уровни, и вот эти уровни и есть «модель зрелости» (maturity model). Модели зрелости часто изображаются в виде «ступенек», по которым нужно «идти вверх»:

Модели готовности технологий (technology readiness) затрагивают как раз предыдущие по отношению стадиям модели зрелости группе стадий жизненного цикла технологии: о разработке. Например, Technology Readiness Level, разработанная 35 лет назад для аэрокосмоса, а затем распространившаяся в машиностроении нефтегазовой промышленности, где ступеньки-уровни для технологии ближе к классическому жизненному циклу в варианте 1.0, только речь идёт именно об инструментарии, «технологии»206:

• TRL 1. Сформулирована фундаментальная концепция технологии и обоснование её полезности.

• TRL 2. Определены целевые области применения технологии и её критические элементы.

• TRL 3. Получен макетный образец и продемонстрированы его ключевые характеристики.

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

• TRL 5. Изготовлен и испытан экспериментальный образец в реальном масштабе по полупромышленной технологии, проведена эмуляция основных внешних условий.

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

• TRL 7. Прототип системы продемонстрирован в составе системы в реальных условиях эксплуатации.

• TRL 8. Окончательное подтверждение работоспособности образца. Разработка. функционирующей реальной системы завершена.

• TRL 9. Изделие удовлетворяет всем требованиям: инженерным, производственным, эксплуатационным, по качеству и надёжности. Возможна модификация по снижению себестоимости, развитию и эволюции системы. Функционирующая реальная система подтверждена в ходе реальной эксплуатации через успешное выполнение испытательных заданий.

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

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

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

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

Системные практики

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

Системное мышление не даёт однозначный «объективный» ответ, оно требует организации коллективного мышления разных стейкхолдеров.

Системное мышление не похоже на алгоритм, гарантирующий превосходный результат проекта.

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

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

На протяжении всей книги мы учились только «как думать», если рассматривать мир состоящим из систем. Мы не учились ничего делать.

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

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

Но зачем тогда нужно системное мышление, если всем практикам нужно учиться отдельно?

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

Итоговое эссе

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

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

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

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

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

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

Тем не менее, вот требования к содержанию эссе (но не к его форме):

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

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

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

Обратите внимание, что при описании нужно кратко характеризовать состояние альфы. Так, команда интересует не только на предмет закрываемых ей стейкхолдерских ролей (требуемых компетенций), но интересен вопрос – сотрудничает ли она? Продуктивна ли она? Помним про лидерство: как у вас с ним? Работы характеризуются прежде всего тем, как вы ими управляете: список работ тут бесполезен, он же будет меняться каждый день. Как вы определяете, какую работу из большого списка работ нужно делать прямо сейчас? Есть ли у вас какие-то ожидания по срокам окончания работ, по требуемым для этого ресурсам? Какие работы лежат на критическом пути, критической цепи? В каком состоянии буферы проекта? Технологии обязательно указывайте как поддерживающие какую-то дисциплину. Не знаете дисциплины? А что тогда поддерживают ваши технологии – работу по наитию?!

В ходе описания альфы «технология» не забудьте привести краткую характеристику жизненного цикла целевой системы (а если вы делаете сервис, то и обеспечивающей), выбранного вида жизненного цикла проекта (помните, чем отличается жизненный цикл системы от жизненного цикла проекта?), практик управления жизненным циклом (как вы назначаете работы на практики? Как управляете конфигурацией и изменениями?). Дайте краткую характеристику используемых практик технологического предпринимательства, системной инженерии, операционного менеджмента. Проблемы, рекомендации по их устранению. Особое внимание должно быть уделено вопросу насколько планы управления работами и финансовые планы отражают архитектуру системы и особенности её жизненного цикла, а также насколько вид жизненного цикла помогает удовлетворить стейкхолдеров.

4. Рефлексия: случилась ли метанойя (помните материал первого раздела?) и по каким именно темам, что осталось непонятным в материале курса?

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

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

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

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

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

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

Что дальше

Поздравляем, на этом учебник системного мышления закончен. Что делать дальше?

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

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

• Решайте задачи по системному мышлению (например, пройти курс на Coursera, где есть возможность решать эти задачи в интерактивном режиме, или курс в Школе системного менеджмента207, где практикуется решение этих задач). При решении задач вы лучше поймёте значения разных понятий системного мышления.

• Если вы занимаетесь инженерией, то прочтите учебник «Системноинженерное мышление»208, в нём много дополнительного материала по системному мышлению, адаптированному именно для инженеров.

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

• Практикуйте системное мышление в каждой жизненной ситуации, в каждом своём проекте. Например, научитесь видеть в людях стейкхолдеров; начните сначала структурированно отслеживать внешнее окружение, а не сразу разбираться с внутренним устройством попадающих к вам в руки систем; ответы на самые разные вопросы самых разных людей делать только после уточнений «а какой стейкхолдер это сейчас спрашивает, и зачем это ему нужно?». И это будет только началом приобретения беглости в использовании системного мышления в вашей жизни.

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

Вы поняли, что слово «практический» в последней фразе сразу отсылает к какой-то дисциплине и поддерживающим её инструментам и рабочим продуктам? Это означает, что вы прочли учебник не зря. Осталось только использовать это знание в жизни.