А.

Левенчук

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

Системное мышление помогает бороться со сложностью в самых разных проектах:

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

уже человечеству ошибок при попадании в реально сложные ситуации. Учебник

прокладывает для мышления определённые «рельсы», которые позволяют после
некоторой тренировки быстро и автоматически оценивать ситуацию в реальных
коллективных проектах. Системное мышление позволяет лишний раз не
«изобретать велосипед» по борьбе со сложностью, вместо трудного и медленного
«мыслительного бездорожья» происходит лёгкое и быстрое «мышление по
рельсам», беглое задействование лучших придуманных цивилизацией приёмов
мышления. Часть того, что для других людей кажется творчеством, для системно
мыслящего человека — беглое применение мыслительных шаблонов, экономящее
время для неизбежного реального творчества в ситуациях, когда человечество ещё
не придумало, как решать какой-то класс задач. Как математики не изобретают
каждый раз идею интеграла, так и системные мыслители не изобретают каждый раз
идею различия потребностей и требований, идею жизненного цикла.
Основная задача учебника — компактно собрать в одном тексте «мыслительный
минимум» по системному мышлению, обычно рассыпанный по самым разным
источникам знания. Специфика этого учебника в том, что его содержание
базируется не столько на традиционной академической литературе по общей
теории систем или традиционных учебниках для менеджеров, сколько на
международных стандартах и публичных документах системной инженерии и
инженерии предприятий, разработанных или обновлённых за последние пять-шесть
лет. Это прежде всего ISO 15288, ISO 42010, ISO 15926, IEC 81346, OMG Essence,
OpenGroup ArchiMate.
Учебник написан на основе шестилетнего опыта преподавания системного
мышления как в многочисленных вузах, так и в системах повышения квалификации
инженеров и менеджеров, в том числе и особенно в Школе системного
менеджмента1, где автор является научным руководителем. Изложение системного
подхода в учебнике универсально для менеджеров, инженеров, предпринимателей,
и самых разных других деятельностных ролей.
В то же время в учебнике отсутствуют материалы по системной инженерии и
инженерии предприятий. Интересующимся этими материалами мы рекомендуем
обращаться ко второй версии предыдущего учебника автора «Системноинженерное
мышление», вышедшей 2 апреля 2015г.
(http://techinvestlab.ru/systems_engineering_thinking/). Тем, кто знакомился с
системным мышлением по учебнику «Системноинженерное мышление», будет
интересно посмотреть на новый вариант универсального изложения, текст был
фактически переписан заново. Текущий текст учебника представляет собой
существенно переработанный (упрощена основная терминология и вписано
порядка 30% пояснений и примеров) текст предыдущего издания, книги
«Системное мышление» 2, вышедшей в феврале 2018 года в Ridero. Конечно, мы
рекомендуем пользоваться текущим вариантом 2019 года, в него было вписано
порядка 120 новых страниц — поэтому книгу будет интересно перечитать и тем, кто
знакомился с системным мышлениям по предыдущим версиям (в том числе по
материалам курса «Системное мышление» на Coursera3, этот курс тоже вышел в
феврале 2018 года и базировался на предыдущем варианте книги). В то же время
каких-то коренных концептуальных отличий от изложения в варианте 2018 года в

1
http://system-school.ru/
2
https://ridero.ru/books/sistemnoe_myshlenie/
3
http://systemsthinkingcourse.ru/
 3

книге нет. Но терминологические отличия существенны 4.

Учебник предназначен для использования в коротких и интенсивных курсах
(обычно это семестровый курс в вузах, или двух-трёхдневный тренинг с решениями
задач в системе дополнительного образования, или двухмесячный онлайн-курс), но
вряд ли он пригоден для самообразования. Предлагаемая последовательность
обучения такова:
1. Внимательное чтение материала книги, понимание содержания. Это даст
состояние «я прочёл учебник по езде на велосипеде, наверное, могу ездить».
2. Решение тренажёрных заданий5. Тут мы рассчитываем на использование flip
teaching — «перевёрнутого обучения», когда преподаватель/консультант не
читает лекции и не объясняет новый материал, зато помогает выполнять
«домашние задания» — даёт пояснения по решению задач. Это даст
начальную беглость мышления в части использования отдельных понятий
при решении уже поставленных и сформулированных задач, но не при
столкновении с реальными проектами, в которых задачи для системного
мышления сначала нужно поставить и явно сформулировать, и только потом
уже решать.
3. Опыт отождествления материала книги и реальной жизни, т.е. тренинг
постановки и решения собственных задач на «живых» (рабочих, а не
учебных) проектах участников учебной группы.
В этой последовательности обучения мы опираемся на концепцию смешанного
обучения (blended learning), в которой чередуются самостоятельная работа
обучающихся с видеолекциями и учебниками, решение задач на компьютерных
тренажёрах, а также очная работа с преподавателем/консультантом над
возникающими вопросами, в том числе и обсуждение рабочих (не учебных!)
проектов.
Обычно решение задач и живое обсуждение проектов с
преподавателем/консультантом приводят к желанию повторно прочесть нашу
книгу, в том числе заглядывая в дополнительную литературу, на которую дано
много ссылок. Однако и повторного прочтения (даже с решением задач на
компьютерных тренажёрах!) обычно оказывается мало для полноценного освоения
материала и умения применить его на практике.
Прорыв в понимании получается тогда, когда для освоения системного мышления
каждый участник группы в обязательном порядке пишет эссе6 по приложению
материала книги к своему рабочему проекту по созданию какой-то системы. Это
заставляет по-настоящему продумать все разделы книги в их взаимосвязи между
собой и с жизнью.
Если организуется двухсеместровый курс (например, первый семестр — «системное
мышление», а второй семестр идут кругозорные курсы «практики системной
инженерии», или «практики системного менеджмента», или «практики
предпринимательства», или даже «практики современной хореографии»), то в ходе
второго семестра эссе дополняется результатами применения практик, изучаемых

4
Обзор терминологических изменений можно найти в докладе https://ailev.livejournal.com/1478510.html
5
На момент выхода книги к учебнику имелось более 200 задач (объем задач с решениями составляет около
200 книжных страниц!). Эти задачи доступны в курсах, которые организованы с использованием нашего
учебника.
6
Никакого «шаблона эссе» при этом не предлагается, https://ailev.livejournal.com/1387943.html
 4

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

связи с системным мышлением. Это образование исследователя, в данном

случае методолога (системным мышлением занимаются методологи,
специалисты по описанию человеческой деятельности).
Активное участие в подготовке материала книги приняли преподаватели,
аспиранты и студенты межвузовской магистратуры технологического
предпринимательства eNano, преподаватели и курсанты Школы системного
менеджмента. Без их активного участия вряд ли эта книга была бы написана.
Большое спасибо за принципиальные вопросы, получившие отражение в книге,
учебным программам по системной инженерии в УрФУ, МФТИ, МИФИ, МИРЭА-РТУ.
Материалы книги неоднократно обсуждались на заседаниях Русских отделений
INCOSE и SEMAT, автор выражает благодарность членам этих международных
организаций за многочисленные замечания и предложения. Много ценных
замечаний было представлено читателями блога автора (http://ailev.ru), учтены
замечания десятков бета-тестеров.
Ваши замечания и предложения по поводу следующих версий книги присылайте
Анатолию Левенчуку (ailev@asmp.msk.su).
Новости по книге будут появляться в блоге http://ailev.ru

Оглавление
1. О мышлении ...................................................................................................................................... 9
Перед тем, как заняться системным мышлением............................................................................ 9
Разные мышления ........................................................................................................................... 10
Требования к мышлению ................................................................................................................ 12
Место системного мышления среди других мышлений ................................................................ 13
Готовность к (мыслительному) действию ................................................................................. 14
Варианты системного мышления ................................................................................................... 16
Системная инженерия..................................................................................................................... 17
Системность и систематичность ..................................................................................................... 21
Наш вариант системного подхода .................................................................................................. 22
Концепты системного подхода ....................................................................................................... 24
Терминология.................................................................................................................................. 26
Слова-термины важны и не важны................................................................................................. 28
Как выбирались термины для нашей книги ................................................................................... 31
Формальность системного мышления ........................................................................................... 33
Системное творчество ..................................................................................................................... 36
Предметные специализации системного мышления .................................................................... 36
Можно ли научить мышлению?...................................................................................................... 38
Стадии обучения мышлению .......................................................................................................... 42
Особенности решения учебных задач по системному мышлению ............................................... 45
Переход к использованию мышления............................................................................................ 47
 6

2. Воплощение и описание системы................................................................................................... 50

Воплощение, описание и документация системы ......................................................................... 50
Описания ......................................................................................................................................... 53
Как договориться: не обобщать, а конкретизировать .................................................................... 54
Отношение состава ......................................................................................................................... 55
Отверстия ........................................................................................................................................ 57
Работы и действия........................................................................................................................... 58
Компьютерные программы ............................................................................................................ 60
3. Роли ................................................................................................................................................. 64
Роли и действия............................................................................................................................... 64
Физические и функциональные объекты ....................................................................................... 65
Второе поколение системного подхода ......................................................................................... 67
Театральная метафора. ................................................................................................................... 73
Мышление о людях: прежде всего они исполнители ролей ......................................................... 75
Интересы и предпочтения .............................................................................................................. 78
Позиция ........................................................................................................................................... 83
Лидерство ........................................................................................................................................ 86
Внешние и внутренние роли/стейкхолдеры .................................................................................. 87
Организационные места, оргзвенья ............................................................................................... 89
Звание и компетенция .................................................................................................................... 92
Сколько всего стейкхолдеров ......................................................................................................... 93
Кто участвовал в последнем совещании? ...................................................................................... 94
4. Системные уровни........................................................................................................................... 96
Не всё системы, что ими называют................................................................................................. 96
Системное разбиение ..................................................................................................................... 98
Эмерджентность и метасистемный переход.................................................................................. 99
Редукционизм и синергия............................................................................................................. 102
Целевая система и коллективное системное мышление ............................................................ 103
Обеспечение и наша система ....................................................................................................... 109
Рекурсивное применение системного мышления. ...................................................................... 111
Потребности, требования, ограничения....................................................................................... 114
Примеры системной терминологии ............................................................................................. 117
Разделение труда и системные уровни ........................................................................................ 121
Системы систем ............................................................................................................................. 122
Люди в системах............................................................................................................................ 124
Государственное строительство и госпроекты ............................................................................. 126
Будущее и ведущая дисциплина предпринимательства ............................................................. 128
 7

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

Сложность и меры сложности....................................................................................................... 131
5. Целевая система и её надсистема ................................................................................................ 132
Сначала найти целевую систему ................................................................................................... 132
Система — это продукт, или сервис? ............................................................................................ 135
Сервис-ориентация ....................................................................................................................... 138
Примеры сервисов ........................................................................................................................ 140
Ты — член команды ...................................................................................................................... 143
Признаки целевой системы .......................................................................................................... 145
Принцип почтальона ..................................................................................................................... 148
Типовые ошибки определения целевой системы........................................................................ 150
Именование системы .................................................................................................................... 152
Надсистема: её тоже нужно найти! .............................................................................................. 153
Системный подход: для всех видов систем, не только для целевой ........................................... 155
6. Как описывать системы ................................................................................................................. 158
Трансдисциплинарность ............................................................................................................... 158
Три основных описания разбиения системы ............................................................................... 159
Функциональный анализ и модульный синтез ............................................................................ 161
Одна система — множество описаний, множество имён............................................................ 162
Альтернативные варианты разбиения системы на части ............................................................ 163
Несовпадение разных системных разбиений .............................................................................. 164
Создание архитектуры: функциональный анализ и модульный синтез...................................... 167
Альфы и артефакты/продукты ...................................................................................................... 169
Яблоки из жизни, яблоки из задачи ............................................................................................. 171
Альфы ............................................................................................................................................ 173
Системное описание ..................................................................................................................... 177
Подальфы ...................................................................................................................................... 181
Отличия интереса от метода описания ........................................................................................ 183
7. Системное моделирование .......................................................................................................... 184
Описания и методы описания, модели и мета-модели ............................................................... 184
Мультимодель и междисциплинарность ..................................................................................... 186
Метод описания и мега-модель ................................................................................................... 188
Понятие конфигурации ................................................................................................................. 189
Функциональные описания: принципиальные схемы и сценарии .............................................. 191
Модульные описания.................................................................................................................... 196
Платформы и технологические стеки ........................................................................................... 198
Важность функциональных рассмотрений целевой системы...................................................... 203
 8

Оргзвенья ...................................................................................................................................... 207

Необходимость хорошей модульности ........................................................................................ 208
Борьба со сложностью в мышлении ............................................................................................. 210
Инженерия предприятия .............................................................................................................. 211
8. Требования и архитектура ............................................................................................................ 212
Требования как часть определения системы ............................................................................... 212
Два понимания требований.......................................................................................................... 213
Требования и системное разбиение ............................................................................................ 214
Целеориентированная инженерия требований........................................................................... 216
Проверка и приёмка...................................................................................................................... 218
Понятие архитектуры .................................................................................................................... 219
9. Не жизненный не цикл.................................................................................................................. 222
Биологический жизненный цикл .................................................................................................. 222
Жизненный цикл системы 1.0 — работы, меняющие состояния целевой системы ................... 223
Выполнение работ оргзвеньями................................................................................................... 227
Изображение жизненного цикла как работ (ЖЦ 1.0) ................................................................... 229
Жизненный цикл проекта ............................................................................................................. 231
Проблемы с жизненным циклом 1.0 ............................................................................................ 233
Практики ........................................................................................................................................ 235
Жизненный цикл 2.0 ..................................................................................................................... 238
Эксплуатация как выделенная стадия жизненного цикла ........................................................... 242
Цепочки обеспечения ................................................................................................................... 244
Три времени жизненного цикла ................................................................................................... 245
Понятие практики .......................................................................................................................... 246
Управление жизненным циклом, архитектура предприятия и операционный менеджмент .... 248
Дисциплина практики ................................................................................................................... 249
Технология поддержки практики ................................................................................................. 251
Совершенствование и развитие.................................................................................................... 253
Практики жизненного цикла ......................................................................................................... 254
Пример: практики жизненного цикла системной инженерии..................................................... 256
Методологии ................................................................................................................................. 258
10. Вид жизненного цикла ................................................................................................................ 260
V-диаграмма.................................................................................................................................. 260
Моделеориентированность в жизненном цикле ......................................................................... 262
V-модели как модель декомпозиции системы ............................................................................ 267
Гибридные модели жизненного цикла ........................................................................................ 268
Уход от «водопадов» с гейтами .................................................................................................... 270
 9

Управление работами и управление жизненным циклом .......................................................... 271

Виды практик управления работами ............................................................................................ 272
Гибкие методологии управления жизненным циклом и управление кейсами для управления
работами. ...................................................................................................................................... 273
Тренды в практиках управления работами .................................................................................. 276
За пределами жизненного цикла ................................................................................................. 277
Жизненный цикл как архитектура деятельности ......................................................................... 279
11. Системная схема проекта............................................................................................................ 281
Диаграмма системной схемы проекта ......................................................................................... 281
Современное понятие проекта ..................................................................................................... 282
Предпринимательская, инженерная, менеджерская области интересов .................................. 283
V-диаграмма и системная схема проекта ..................................................................................... 285
Альфы — общий объект отслеживания команды ........................................................................ 286
Альфа возможности ...................................................................................................................... 288
Альфа внешних проектных ролей ................................................................................................. 290
Альфа описания системы .............................................................................................................. 291
Альфа воплощения системы ......................................................................................................... 292
Альфа работы ................................................................................................................................ 293
Альфа команды ............................................................................................................................. 294
Альфа метод .................................................................................................................................. 295
За чем следить в проекте .............................................................................................................. 296
Состояния альфы и артефакты/рабочие продукты ...................................................................... 298
Как работают с системной схемой проекта .................................................................................. 299
Подальфы ...................................................................................................................................... 300
Диаграмма основного жизненного цикла .................................................................................... 301
Модели зрелости и модели готовности технологий .................................................................... 304
Системные практики ..................................................................................................................... 306
Итоговое эссе................................................................................................................................. 308
Что дальше .................................................................................................................................... 312

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

триллионов тонн, это больше 50кг на каждый квадратный метр поверхности земли7.
И всё это за счёт того, что человечество освоило мышление.
Системное мышление — это только один из многих видов мышления. Перед тем, как
заняться его изучением, нужно понять общие требования к мышлению (не только
системному!), а затем рассмотреть место системного мышления в ряду других
мышлений. Также нужно ответить на вопрос: чем отличается системность и
систематичность. А ещё в мире существует много вариантов системного мышления,
и нужно понять, какой вариант выбран для нашей книги.
Дальше будет некоторое количество замечаний, как относиться к терминологии в
нашей книге (слова-термины важны, и не важны!), понять уровень формальности
системного мышления, и понять, не мешает ли системное мышление творчеству (в
учебнике же приведены шаблоны эффективного мышления, которые отлично
работают, но может ли быть «творчество по шаблону»?).
Ещё нужно ответить на вопрос: можно ли научить мышлению и какие стадии
обучения мышлению? Сразу скажем, что наша книга как учебник езды на
велосипеде: чтение книги многое вам расскажет про системное мышление, но не
факт, что после прочтения книги вы станете системным мыслителем. Нужна
практика! Даже решение задач по системному мышлению имеет свои особенности.
А после обучения нужно ещё и перейти к использованию мышления в реальной
жизни.
И только после рассказа обо всём этом в следующей главе мы начнём изучать
основные понятия системного подхода.

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

7
Zalasiewicz и др., «Scale and diversity of the physical technosphere», Zalasiewicz и др.,
http://journals.sagepub.com/doi/full/10.1177/2053019616677743
8
Подробней про преимущества рациональности перед восточным упованием на интуицию и
«непосредственное знание» см. в текстах А.Левенчука «Об членораздельное и голографическое в
социологии» http://ailev.livejournal.com/1281819.html и «Об интуицию и чуйку»
http://ailev.livejournal.com/1295595.html.
 11

Сегодня среди педагогов преобладает мнение, что какому-то «хорошему»

мышлению можно научиться на основе углублённого знакомства с предметами так
называемого STEM9:
• наука (science, т.е. естественные науки: классические физика, химия,
биология и т.д., редко computer science, но и её сюда иногда включают). Тут
в части общеупотребимого для самых разных ситуаций мышления важна
физическая компетентность, понимаемая как знакомство с математическим
выражением закономерностей физического мира. Остальное (химия,
биология и т.д.) в «науке» обычно даётся «для эрудиции» и оказывается
важным уже только при специализации мышления в рамках какой-то из
отдельных наук, а не для мышления в целом.
• Технология (technology), которая чаще всего понимается как умение работать
на «станочках» — типовые уроки труда, когда готовятся не инженеры, а
только «техники». Успешное образование в области технологии может
означать то, что «руки из правильного места растут», т.е. к традиционно
понимаемому мышлению не относится.
• Инженерия (engineering) — ей учатся инженеры-механики, электрики и
прочие инженеры, часто и software engineers (с не слишком большим упором
на знание computer science и data modeling). Тут тоже работают не столько с
общим для всех мышлением, сколько с узким предметным мышлением
инженера, ограниченным его специальностью.
• Математика (mathematics, позволяет получить алгебраическую
компетентность, включая линейную алгебру, геометрическую
компетентность (наглядная геометрия, потом с выходом в работу с
современными системами автоматизации проектирования, 3D САПР),
статистическая (с небольшой долей байесовской) компетентность,
математическая логика. И ещё тут учитываем компьютерную математику, а
не только математическую работу карандашом по бумажке10. Это ближе всего
к обучению мышлению, но тем не менее это больше не про то, как думать о
мире, а как рассуждать с уже формализованными моделями мира. По
большому счёту, математика включается только после того, как мышление
подготовило материал для применения математики, поставило формальную
задачу.
К сожалению, предположения педагогов о косвенном обучении мышлению через
обучение предметам STEM не оправдываются, каждому виду мышления нужно учить
прямо, а не косвенно11.
Например, если нужно учить логике, то нужно учить прямо ней, а не через
информатику и геометрию, а то в школьных курсах логика осталась только в рамках

9
Определение STEM: https://en.wikipedia.org/wiki/Science,_technology,_engineering,_and_mathematics
10
Подробней про необходимость обучения детей математике с использованием современных
компьютерных математических программ типа Mathematica см. в
https://www.ted.com/talks/conrad_wolfram_teaching_kids_real_math_with_computers/transcript?language=ru
11
Лей Бао и др. показали, что умение рассуждать и тренинг в мышлении на базе какого-то набора
концептов это не одно и то же, http://arxiv.org/ftp/arxiv/papers/0807/0807.2061.pdf. Изучение физики
оказывается не таким уж "выправляющим мозги" — A historically held belief among educators and researchers
is that training in physics, which has a beautiful structure of logical and mathematical relations, would in general
improve students’ abilities in conducting reasoning that is intellectually challenging. However, the result from this
study suggests that training in physics content knowledge in the traditional format alone is not enough to improve
students’ general reasoning abilities).
 12

изучения логических выражений при обучении программированию и в курсе

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

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

Рациональность — это возможность провести рассуждение по правилам,

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

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

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

Аналогично рациональное мышление лежит в основе системного мышления. Без его

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

Готовность к (мыслительному) действию

Освоение высокоуровневых мыслительных компетенций обычно требует
определённого уровня владения более низкоуровневым мышлением. Едва
ползающему человеку прыжки и танцы не будут доступны, нужно сначала накачать
мышцы и освоить контроль тела, подготовить его к действию. И только после
получения готовности тела к действию можно учить какие-то паттерны сложных
спортивных и танцевальных движений. Образование устроено так же. Арифметика
изучается перед интегралами, без знания таблицы умножения высшей математики
не освоишь — арифметика тут пререквизит для высшей математики. Сначала
готовность и автоматизмы/беглость в мышлении для более базовых мыслительных
навыков, а затем готовность и автоматизмы/беглость на более прикладных уровнях
мышления — и так на нескольких уровнях.
Есть легенда, что талант к мышлению (какого бы вида оно ни было) врождённый.
Да, генетическая предрасположенность к какому-то виду мышления бывает, как у
спортсменов к какому-то виду спорта. Но мышлению нужно учиться: сами приёмы
мышления не заложены в мозге, они должны быть усвоены и натренированы. Это
означает, что натренированный «не талант» легко обойдёт в том или ином виде
мышления нетренированного «самородка», который так и останется «вечно
подающим надежды», он просто не будет знать, как мыслить правильно. Выученный
волками потенциально гениальный Маугли не будет уметь даже разговаривать, не
то что правильно мыслить.
Можно сказать, что существует некоторая «цивилизационная мыслительная
платформа» как набор лучших на сегодняшний момент в нашей
цивилизации (state-of-the-art) принятых по поводу мышления решений. Эти
решения о выборе тех или иных приёмов мышления как раз и направлены на то,
чтобы думать абстрактно, адекватно, осознанно, рационально, а не «дикарски», с
игнорированием всего накопленного цивилизацией мыслительного опыта.
 15

Насколько окультуренное цивилизацией мышление сдерживает или наоборот,

стимулирует творчество по сравнению с живым «дикарским» мышлением?
Цивилизация показывает, что образованные и мыслительно тренированные люди
обычно выигрывают в массе своей у неучей, а гениальные самоучки-дикари
(«Кулибины») чрезвычайно редки. При этом на поверку «самоучки-дикари»
оказываются часто более чем начитаны и образованы, разве что их образование не
было связано с каким-то официальным учебным заведением, а паттерны своего
«гениального самородного мышления» они тоже брали из литературы и
подхватывали у своих вполне образованных учителей, а не изобретали по ходу
дела.
Цивилизационную мыслительную платформу, куда входит и системное мышление,
в порядке самообразования нужно «накачать» и «разработать» так же, как мышцы
и суставы для готовности тела к движению — мозг ведь тоже тренируем, он
пластичен и в буквальном смысле слова изменяется в ходе тренировки. И именно
поэтому тренировки мышления не быстры. Как и с обычными мышцами, быстрых
результатов за одну-две тренировки мышления не получишь, нужны месяцы и годы,
ибо при этом задействуются медленные биологические процессы в мозге.
Продолжительное фундаментальное образование нужно, чтобы дальше иметь
возможность не просто цивилизованно мыслить, но и мыслить бегло.
Натренированные паттерны мышления дают возможность как по проложенным в
мозгу рельсам быстро проводить типовые абстрактные, рациональные, адекватные,
осознанные рассуждения, не затрачивая на это мыслительных усилий, практически
интуитивно. И только если эти «рельсы мышления» оказываются вдруг
где-то не проложены, только при столкновении с чем-то действительно
новым, можно переходить на затратное «просто мышление»,
задействовать какие-то иные, поисковые механизмы мышления.
Эти ускоряющие мышление взятые из культуры паттерны, которые заодно
позволяют не допускать грубых мыслительных ошибок, используются как в самых
базовых видах мышления (логические рассуждения общего вида), так и в
основанных на них более сложных (системное мышление, вычислительное
мышление/computational thinking), так и в быстро меняющихся ещё более
специализированных и сложных вариантах инженерного, менеджерского,
предпринимательского или даже танцевального и спортивного мышления в их
многочисленных видах и вариантах. И беглости мышления нужно добиваться во
всех них, все эти виды мышления нужно тренировать.
Для «образованного человека» нужно освоить одно и то же компактное мышление
«цивилизационной платформы», которое пригодится ему для самых разных
деятельностей и проектов. Ведь человеку придётся в жизни играть много самых
разных деятельностных ролей, начиная с ролей инженера, менеджера,
технологического предпринимателя, но не ограничиваясь ими. Каждая из этих
ролей потребует своего мышления, а базовые виды мышления «цивилизационной
платформы» нужны будут для всех них.
И обязательно нужно учитывать, что речь идёт о лучших на сегодняшний момент
(state-of-the-art) приёмах мышления. Базовые приёмы мышления относительно
стабильны, но в 21 веке и базовые приёмы за время длинной человеческой жизни
могут немного меняться, так что тут нужно быть начеку и вовремя переучиваться.
 16

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

Системное мышление (systems thinking) — это мышление с использованием
основных положений и приёмов системного подхода (system approach). Уже
разработано много разных вариантов системного подхода, существенно
отличающихся друг от друга в степени проработанности, используемой ими
терминологии и деталях, но совпадающих в своих основах. Но и сами основы
системного подхода претерпели существенное развитие с момента предложения в
1937 году биологом Людвигом фон Берталанфи общей теории систем. Вообще,
подход (approach) — это когда разработанные в рамках одной дисциплины, одной
предметной области понятия, методы мышления, приёмы действия применяются
затем к другим дисциплинам и предметным областям. Общая теория систем была
разработана главным образом на биологическом материале, а уж затем было
предложено применять её положения ко многим и многим предметным областям.
С момента появления общей теории систем в 30-х годах 20 века на базе системного
подхода возникали и умирали целые дисциплины. Например, так родилась в 1948
году и затем в семидесятых была предана забвению кибернетика. Поэтому до сих
пор можно встретить старинные варианты системного подхода, существенно
переплетённые с кибернетикой и несущие в себе все её недостатки, прежде всего
попытку свести понимание мира как работы поддерживающих гомеостаз (т.е.
неизменность своего состояния) систем с обратными связями. Самый
распространённый вариант кибернетического системного подхода отражён в
способе моделирования «системная динамика» (system dynamics12) и сводится к
нахождению и явному отражению в модели каких-то связей, которые могут
замыкаться в циклы, приводя к появлению колебаний. Такое «кибернетическое
моделирование» сверхупрощено и плохо отражает самые разные виды систем,
совсем не похожие на «регулятор Уатта».
Системный подход уже получил широкое распространение в инженерии и
менеджменте. В инженерии в пятидесятые-шестидесятые годы превалировало
«математическое» понимание системного подхода, которое по факту сводилось
просто к активному использованию математического моделирования при решении
инженерных проблем. «Системность» заключалась в том, что модели при этом
набирались из разных дисциплин для разного уровня структуры системы, и
описание тех или иных систем проводилось с использованием многочисленных
моделей, отражающих разные интересующие инженеров и учёных свойства систем
в различных ситуациях. Такое моделирование противопоставлялось так
называемому редукционизму (сведению к простому), для которого было
характерно выделение одной главной точки зрения, одной дисциплины для какого-
то уровня структуры объекта или предмета исследования, один метод
моделирования — скажем, человек рассматривался на уровне молекул (т.е.
биохимическом уровне), и из этого пытались выводиться все знания о человеческой
природе: в том числе и его мышление, и социальное поведение объяснялось как
сложное сочетание биохимических процессов. Системный подход преодолевал
очевидную бессмысленность такого упрощенчества и поэтому стал очень
популярен.
Слово «система» в конце семидесятых годов стало респектабельным, и его стали
использовать в том числе и те люди, которые были совсем незнакомы с системным

12
https://en.wikipedia.org/wiki/System_dynamics
 17

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

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

13
Например, это прописано в статье русскоязычной Википедии: https://ru.wikipedia.org/wiki/Тектология
 18

об организации работ по созданию системы. Так что будем считать «инженерию» и

«инжиниринг» синонимами, но в случае «инжиниринга» проверять на всякий
случай, не менеджмент ли имеется в виду вместо чисто инженерной работы.
Самое современное определение системной инженерии дано в Guide to the Systems
Engineering Body of Knowledge (руководство по корпусу знаний системной
инженерии14). Короткое определение: системная инженерия — это
междисциплинарный подход и способы обеспечения воплощения успешной системы
(Systems engineering is an interdisciplinary approach and means to enable the realization
of successful systems15). В этом определении можно подчеркнуть:
• Успешные системы — это то, чем занимается системная инженерия. Слово
«успешные» тут крайне важно и означает, что результирующая система
проекта учитывает ролевые потребности затрагивающих систему и её проект
людей, равно как и потребности затрагиваемых системой и её проектом
людей. Если интересы все этих людей-в-ролях заказчиков, плательщиков,
пользователей и других учтены, то это и есть «успех». Тем самым успех тут
определяется не бытовым, а специальным образом: через приемлемость
результата проекта для множества людей-в-ролях.
• Слово «системы» используется в очень специальном значении: это
«системы» из системного подхода, термин. Для системной инженерии слово
«система» примерно то же, что «физическое тело» для ньютоновской
механики — если вы сказали про компьютер «физическое тело», то это
автоматически влечёт за собой разговор про массу, потенциальную энергию,
модуль упругости, температуру и т.д. Если вы сказали «система» про
компьютер, то это автоматически влечёт за собой разговор про роли и их
интересы, требования и архитектуру, жизненный цикл и его обеспечение, и
т.д. Все эти понятия будут подробно рассмотрены в нашей книге.
• Междисциплинарный подход — системная инженерия претендует на то, что
она работает со всеми остальными предметными инженерными
специальностями (впрочем, не только инженерными). Впрочем, более
современные определения используют другое слово:
трансдисциплинарность (transdisciplinary), что означает внешнесть,
«потустороннесть» по отношению к самым разным другим дисциплинам, а не
нахождение в одном ряду, «между» другими дисциплинами.
Трансдисциплинарность — это очень сильное заявление, оно означает, что
системная инженерия может в одну упряжку впрячь коня и трепетную лань
(например, людей в ролях инженеров-механиков, баллистиков,
криогенщиков, психологов, медиков, астрономов, программистов и т.д. в
проектах пилотируемой космонавтики).
• Слово «воплощение» (realization, «перевод в реальность») означает
буквально это: создание материальной (физической, т.е. из вещества и
полей) успешной системы.
По-английски «системная инженерия» — systems engineering, хотя более ранние
написания были как system engineering. Правильная интерпретация (и правильный
перевод) — именно «системная» (подразумевающая использование системного
подхода) инженерия, а не инженерия систем (engineering of systems) — когда
любой «объект» обзывается «системой», но не используется системный подход во
14
http://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_%28SEBoK%29
15
http://sebokwiki.org/wiki/Systems_Engineering_%28glossary%29
 19

всей его полноте. Под инженерией систем16 (например, control systems engineering,
manufacturing systems engineering) понимаются обычные инженерные
специальности, там легко выкинуть слово «система», которое лишь обозначает
некий «научный лоск». Предметные (не системные) инженеры легко любой объект
называют «системой», не задумываясь об осознанном использовании при этом
системного мышления, не используя системный подход. В самом лучшем случае про
систему предметные инженеры скажут, что «она состоит из взаимодействующих
частей» — на этом обычно разговор про «систему» и «системность» заканчивается,
он не длится больше двадцати секунд. Занимающиеся «инженерией систем» очень
полезны и нужны, но они не системные инженеры.
А вот из системной инженерии квалификатор «системный» без изменения смысла
понятия выкинуть нельзя. Неформально определяемая системная инженерия —
это инженерия с системным мышлением в голове (а не любая инженерия,
занимающаяся объектами, торжественно поименованными системами просто для
добавления указания о сложности этих объектов и научности в их описании).
Целостность (полнота охвата всех частей целевой системы согласованным их
целым), междисциплинарность (полнота охвата всех дисциплин) — это ключевое,
что отличает системную инженерию от всех остальных инженерных дисциплин.
Роль системного инженера отличают по тому, что человек в этой роли занимается
всей системой в целом, а не отдельными частями системы или не отдельными
инженерными или менеджерскими дисциплинами.
Более длинное определение системной инженерии включает ещё одну фразу: «Она
фокусируется на целостном и одновременном/параллельном понимании
потребностей проектных ролей; исследовании возможностей; документировании
требований; и синтезировании, проверке, приёмке и постепенном появлении
инженерных решений, в то время как в расчёт принимается полная проблема, от
исследования концепции системы до вывода системы из эксплуатации»17.
Системная инженерия поначалу применялась главным образом для борьбы со
сложностью аэрокосмических проектов, и она была там крайне эффективна. Для
того, чтобы маленький проект уложился в срок и бюджет, нужно было на системную
инженерию потратить 5% проекта, что предотвращало возможный рост затрат
проекта на 18%. Для средних проектов на системную инженерию оптимально
тратить было уже 20% усилий всего проекта, но если не тратить — возможный рост
затрат проекта был бы 38%. Для крупных и очень крупных проектов оптимальные
затраты на системную инженерию оказались 33% и 37% соответственно, и это для
того, чтобы предотвратить возможный рост затрат проекта на всяческие переделки
плохо продуманного 63% и 92% соответственно18.
Как и можно ожидать, системная инженерия в простых небольших проектах почти
не даёт эффекта (там всё хорошо продумывается «в уме» и не требует особых
мыслительных практик), но оказывается ключевой в сложных и очень крупных
проектах: без системного мышления в них допускаются ошибки, которые потом
16
см. проф. Derek Hitchins, «Systems Engineering vs. Engineering of Systems — Semantics?",
http://www.hitchins.net/profs-stuff/profsblog/systems-engineering-vs.html
17
Вторая фраза в определении системной инженерии из SEBoK: It focuses on holistically and concurrently
understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying,
validating, and evolving solutions while considering the complete problem, from system concept exploration
through system disposal.
18
Цифры из http://csse.usc.edu/TECHRPTS/2008/usc-csse-2008-808/usc-csse-2008-808.pdf
 20

оказывается очень дорого переделывать. Без системного мышления сталкиваться

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

19
https://en.wikipedia.org/wiki/Apollo_program
20
https://ru.wikipedia.org/wiki/Н-1
 21

эффективность на деле. Он не имеет авторства (ибо в его создании участвовало

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

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

21
http://techinvestlab.ru/systems_engineering_thinking/
 22

этом систематичность вовсе не подразумевает системности. Можно систематично

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

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

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

22
http://incoseonline.org.uk/Normal_Files/WhatIs/Systems_Engineering.aspx?CatID=What_Is_SE,
https://www.researchgate.net/publication/327073164_Envisioning_Systems_Engineering_as_a_Transdisciplinary_
Venture
23
Цепочка текстов «Системный фитнес», https://ailev.livejournal.com/1429126.html
 23

именно для стандартов), а служат для других целей — информирования, обучения,

предложения терминологии, распространения знаний.
Наш вариант системного подхода опирается на следующие версии стандартов и
публичных документов (этот список далеко не исчерпывающий, приведены лишь
главные источники24):
• Стандарт 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 даёт возможность моделировать предприятия, включая

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

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

деятельность корпоративный софт, разнообразное «железо» и
компьютерные сети, необходимые для работы этого софта, а также другое
оборудование предприятия.
• Публичный документ NIST PWG Cyber-Physical Systems (CPS)
Framework Release 1.0 (2016) уточняет способы описания для
киберфизических систем, вводит классификацию аспектов для
стейкхолдерских интересов.
• Публичный документ Guide to the Systems Engineering Body of
Knowledge (SEBoK) даёт нам определение успешной системы и множество
других определений системного подхода.
Мы гарантировали универсальность нашего варианта системного мышления тем,
что на деле использовали его в самых разных проектах — инженерных,
менеджерских, предпринимательских, педагогических, культурных, искусственного
интеллекта, и т.д.

Концепты системного подхода

Вот основные концепты (понятия) системного подхода, описываемого в нашем
учебнике. Конечно, мы не будем давать тут определений, они подробно будут
описаны в последующих разделах:
Привязка к физическому миру (эти понятия не системного мышления, они взяты
из онтологики25, но необходимы для понимания системного мышления):
• Физический объект, занимающий место в пространстве-времени
• Воплощение (физические объекты) против их описаний и документов
• Изменения (процессы, проекты, кейсы) как физические объекты
• события как физические объекты
• ролевой/функциональный объект и его физичность
• софт как физический объект (исходный код как описание софта)
• предприятие/оргзвено как физические объекты
• части во времени
• методологическое время против времени жизни системы
• совпадение места/объема двух объектов в пространстве-времени — это
один объект
• отношение состава (composition, «часть-целое») физических объектов
Деятельностная субъективность описания системы:
• деятельность, театральная метафора
• проектная роль/стейкхолдер: внешняя, внутренняя/командная.
Деятельностная роль, оргроль.
• ролевые: интерес, предпочтение, намерение
• успешная система
Системное разбиение
• системы против систематики («система Линнея») и методологии («система
Станиславского»)?
• Система, системный уровень, системное разбиение
25
https://drive.google.com/file/d/1igXg-hvJ1tPXx_xJL5748i2pCxrxaHsU/view
 25

• Эмерджентность/системный эффект
• виды систем: целевая, наша, подсистема, надсистема, окружение
(системы в окружении), обеспечение (системы в обеспечении)
• имя системы (по роли/функции)
• чёрный и прозрачный ящики
• требования, потребности, ограничения, архитектура
• проверка и приёмка
Описание и документация системы
• описание (definition) системы
• документация системы (description)
• потребности (внешних ролей/стейкхолдеров)
• ролевое/частное описание (view)
• ролевой метод описания (viewpoint)
• модель, мета-модель, мульти-модель, мега-модель
• прожекторный и синтетический подходы к описанию систем
Функциональные и конструктивные части системы, размещения
• разбиения: функциональные, модульные/продуктные,
размещения/пространственные
• функциональная часть: порт, потоки/связи
• конструктивная часть: интерфейс, платформа
• пространственная часть/размещение
• архитектурное решение, требование, документация
• архитектурный синтез (логической и физической архитектур)
Жизненный цикл 2.0
• жизненный цикл системы, проекта
• работы, стадии жизненного цикла
• практика, метод/методология
• дисциплина
• технология
• модель/вид жизненного цикла, водопад, спираль
• V-диаграмма
Системная схема проекта (модифицированный стандарт OMG Essence):
• альфа, подальфа
• основные альфы: внешние проектные роли, возможности, воплощение
системы, описание системы, работы, команда, метод
• зоны интересов: предпринимательская, инженерная, менеджерская
• состояния альфы как контрольные точки, чеклисты (контрольные
вопросы) к состояниям альф
Этот набор концептов системного подхода удивительно компактен: сложнейший
мир самых разных ситуаций представляется относительно небольшим числом
понятий, а сам набор этих понятий выбран так, чтобы мир представлялся менее
сложным, чтобы о мире было проще мыслить. Учебник в последующих разделах
подробно описывает эти концепты и связи между ними, особенности проведения
рассуждений об этих сущностях и их связях. Именно на эти концепты опирается
инженерное, менеджерское и другое предметное мышление, когда говорят об его
опоре на системный подход.
 26

Терминология
Терминология26 — это дисциплина о словах, которыми обозначают концепты
(concepts, понятия для нашего учебника вполне могут выступать термином-
синонимом, хотя в некоторых научных школах слова «концепт» и «понятие»
означают разное). Это дисциплина не о самих концептах, а именно об обозначениях
концептов словами, о терминах. В каждом языке сформировались (или
продолжают формироваться) наборы терминов для разных областей человеческой
деятельности. И в этих областях термины приобретают значения, т.е. обозначают
(они ведь «знаки», поэтому «обозначают») какие-то находящиеся в реальном мире,
а не мире знаков, объекты и их отношения. Термин — это всегда только слово.
Слова нам нужны только для того, чтобы договориться о концептах, сами слова
не важны. Так, совершенно неважно, используете ли вы термин «концепт» или
термин «понятие», если имеете ввиду одно и то же: значение того, что
обозначается термином. Диалектов много, споры о том, какой из диалектов и есть
«настоящий язык» — они бесплодны, в этих спорах не договориться.
Так что часто споры между людьми по самым важным вопросам жизни и смерти
оказываются всего-навсего «спорами о терминах»: один и тот же объект называется
по-разному в разных диалектах и люди считают, что речь идёт о разных объектах
(в философской литературе приводится пример Венеры: в одних странах её
называют «утренняя звезда», а в других — «вечерняя звезда»), или наоборот —
одинаковые слова означают совсем разные объекты («косил косой с косой косой
косой на косе»).
В таких «спорах о терминах» важно уметь их распознать, а затем формулировать в
речи свои представления о мире как ожидаемые наблюдения, а не через
терминологию из вашего любимого диалекта, даже если она берётся из вашего
любимого стандарта или словаря. У вашего собеседника может оказаться любимым
другой стандарт или словарь, он может говорить на другом неведомом вам
диалекте — и вы не договоритесь по существу вопроса, просто застрянете на
обсуждении слов.
Использование самих терминов, если о них ещё не договорились, будет
бесполезным. Если вы чувствуете, что не можете договориться по какому-то
простому термину, попробуйте табуировать его употребление, то есть продолжайте
разговор без использования этого термина, просто чтобы не путаться. Когда
разберётесь, просто назовите разные объекты, которые вы называли с вашим
собеседником одним термином, разными словами, и продолжайте разговор —
«споров о терминах» больше не будет.
Использование каких-то определённых терминов для определённых понятий
(например, «car», и никогда «автомобиль») означает принадлежность к какому-то
определённому сообществу, предпочитающему использовать именно эти термины,
говорящем на своём диалекте. Но есть и другие сообщества, для этого же концепта
использующие другие термины. Важно договориться, а термины не важны. В
системном мышлении, которое трансдисциплинарно этому уделяется огромное
внимание: мышление идёт в концептах, а не в словах.
Никогда не видевшие автомобиль люди племени мумба-юмба вообще не знают
понятия, обозначаемого словом «автомобиль». Но знающие про существование

26
https://ru.wikipedia.org/wiki/Терминология
 27

автомобилей и не знающие терминов друг друга люди не смогут договориться, если

один будет требовать «car», а второй — предлагать не понимаемый собеседником
«автомобиль». Но тут хотя бы будет подозрение, что проблема в разных языках. Но
вот когда один требует тачку, а ему дают садовую тачку, а не ожидаемый им
автомобиль — и настаивают, то вот тогда в реальных проектах появляется
проблема.
Терминология преходяща, концепты выживают дольше. Во времена СССР
компьютер назывался ЭВМ (электронно-вычислительная машина), а теперь уже
«компьютер». Значение не поменялось, поменялась речь — то есть поменялся
термин, слово-обозначение. И речь-слова меняются много быстрей, чем
означаемые ими предметы-значения: слово «тачка» уже выходит из моды для
значения «автомобиль» как «недостаточно сленговое» в определённых кругах и
постепенно заменяется там словом «тачило».
Терминология может существенно отличаться не только для разных профессий, но
и для разных подпрофессий внутри одной профессии. То, что называется
«программным средством» для системных аналитиков, работающих по ГОСТам,
будет «приложением» для продавцов иностранного софта, или «софтиной» для
разработчиков.
Если невозможность договориться о терминах становится реальной проблемой,
мешающей реализации проекта — к её решению есть разные подходы:
● Терминологический фашизм, когда только один термин объявляется кем-то
правильным, а все остальные — неправильными (сравните с «Grammar
nazi»27). У этого подхода есть много вариантов — безусловно требовать
единственности используемого термина (отсутствия синонимов для термина),
требовать ещё и соответствия принятым стандартам (определённым ГОСТам,
например, а не учебникам или другим ГОСТам), требовать использования
отечественного корня в слове («мокроступы» вместо «галоши»), настаивать
на соблюдении традиций («калоши», но никак не «галоши»), игнорировать
современные нормы («кофе» только мужского рода, хотя уже давно даже по
словарям можно и среднего).
● Терминологический пофигизм, когда на слова и их значения вообще не
обращают внимания. Никаких «заведомо правильных вариантов» или ссылок
на авторитетные источники. При этом, если значение слова меняется по ходу
разговора, это часто вообще не отслеживается, речь оказывается «не
строга».
● Строгость значений с разрешением самых разных терминов-синонимов,
обозначающих одно понятие. При таком подходе обычно очень долго
договариваются, какое именно понятие имеется в виду, а затем уже
используются любые слова-термины для указания на оговорённое понятие.
При этом вполне допускается использование терминов, предпочитаемых
разными профессиональными-речевыми сообществами. Более того, можно и
не пользоваться точными терминами, если будет понятно значение. Так, при
обсуждении автомобиля вполне можно обозвать его «самобеглой тележкой»,
и это не будет преступлением, если адресат сообщения поймёт, о чём речь.
В нашей книге будет использоваться подход, добивающийся строгости понимания

27
http://lurkmore.to/Grammar_nazi
 28

значений, при возможном использовании обозначений-синонимов. Назови хоть

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

Слова-термины важны и не важны

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

28
Подробней про пространство смыслов, концепты и термины см. в книге «Визуальное мышление»,
https://ridero.ru/books/vizualnoe_myshlenie/
 29

Переспросите его, чтобы понять, как он употребляет этот термин в своём

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

Мир если не изменится, то можно не волноваться, прекратить спорить и разойтись

сразу. Если мир от результатов спора изменится (договорились оба о действиях),
продолжаем спорить и договариваться о следующих шагах.
при описании малопонятного идите не к более общим понятиям (путь «словарного
определения»), а «заземляйтесь»: описывайте физический мир. Уход в более общие
понятия и описание непонятного как специализаций (аристотелевские определения
"X это Y с такими-то особенностями") — тупик. Чтобы договориться, нужно
конкретизировать, а не абстрагировать — не сводить к известому спорщикам
общему, а сводить к известному спорщикам физичному (даже не частному! Ибо для
частного подразумевается противостоящее ему плохо определимое общее, а для
физичного — плохо определимая «роль», тот самый спорный «термин», который
нельзя «пощупать». Абстрактные понятия — это чаще всего роли, функциональные
объекты, отсылают к какому-то поведению. Поведение обсуждать всегда сложней,
чем статичные вещи).
на время разговоров сам термин табуируйте29 (всё равно его использование не
ведёт к пониманию, и только замедляет дискуссию), вместо него давайте
развёрнутые формулировки. Если вам нужно продолжать разговор, а слово
собеседнику явно непонятно, то продолжайте дискуссию без этого термина! В
дискуссиях не про термины, а про дело термины нужны просто для того, чтобы
компактнее было обсуждать — а спор о терминах убирает все преимущества
использования термина, без него оказывается проще. Если спор превращается в
спор о терминах (про «истину», а не про «что делаем»), то это тревожный симптом
бесплодного спора, немедленно прекращайте спорить и выходите из разговора.
Тут ещё про объяснения незнакомых понятий через другие незнакомые понятия
помогает понимание "понятийных расстояний"30. Эти расстояния обычно короткими
не бывают: попробуйте объяснить третьекласснику как строить вольт-амперную
характеристику для тиристора. Расскажите ему про вольт, ампер, характеристику и
что такое тиристор. С третьеклассником все всё понимают, но два профи часто свои
"тиристоры" и прочие сепульки пытаются всё-таки «определить» в трёх фразах —
разница в возрасте ведь небольшая, и кажется, что объяснить можно. Но нет.
Сколько определений не давай, пользы от них не будет. Бойтесь, бойтесь
определений — это то лекарство, которое оказывается болезнью чаще, чем лечит.
Георгий Петрович Щедровицкий любил повторять: "Определение — это гробик для
уснувшей мысли".
В нашей книге нет никакой опоры на определения, нет глоссария (толку с него?!).
Жирным шрифтом выделены термины в тех местах текста, где много об этом
концепте говорится, в том числе есть какие-то фразы, похожие на определения (но
нельзя считать их именно определениями!). А потом через три-четыре предложения
другие фразы, тоже похожие на определения. А потом ещё и ещё раз. На
распознавание этих концептов, обозначаемых какими-то словами-терминами
тренируется ваша нейронная сеть, в пространстве смыслов всё чётче и чётче
определяется место понятия, скрывающегося за термином и его синонимами (ещё
ведь и синонимы! Термины из других теорий, с другими оттенками значений и
другими ассоциациями!). Но это всё не определения, нет. Результат такой
понятийной работы по тренингу нейронной сетки живого мозга развёрнутыми

29
https://lesswrong.ru/wiki/Табуирование
30
https://lesswrong.ru/w/Ожидая_короткие_понятийные_расстояния
 31

текстами с использованием слов (по Витгенштейну: смысл слов определяется их

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

Как выбирались термины для нашей книги

Наука традиционно порождала новые термины (обозначения для появляющихся
новых понятий) двумя способами:
● Бралось обычное (“бытовое”) слово, и нагружалось специальным (“научным”)
значением. «Работа» в физике — отнюдь не «работа» в бытовом значении
этого слова. Это самый частый способ, но он легко приводит к путанице со
словами из бытовой речи.
● Чтобы сделать речь точнее, термином делалось слово, для которого в
бытовой речи не было известных значений. Для этого необычное для родного
уха слово бралось из иностранного языка (чаще всего — с греческим или
латинским корнем) и нагружалось специальным значением. Сегодня в
русском языке прихватываемым словом может быть английское слово, а не
латинское или греческое — в русском-то оно бытового значения не имеет.
У нас в книге термины выбраны (в том числе при переводе иноязычных текстов —
стандартов, методик, учебников) для максимизации понятности их употребления в
деятельности. При выборе терминов учитывалось: кто поймёт это слово, из какого
 32

он профессионального сообщества, на каком диалекте предпочитает говорить? Это

другой принцип, нежели «взять термины из близкого авторам стандарта и
игнорировать все другие варианты».
Например, мы легко можем использовать жаргонные слова. Скажем, «айтишник», а
не «программист» — ибо нас заботит не только красота речи и привычные термины,
но как можно более точное указание на значения терминов в реальном мире. Ведь
«программист» более узкий термин, чем «айтишник». Администратор базы данных,
модельер данных и инженер данных, системный администратор, IT-архитектор,
электронщик — все они не программисты, но айтишники. Можно было бы слово
«айтишник» заменить словом «компьютерщик» — кому-то это было бы ещё
понятней, но кто-то стал бы возмущаться. С учётом всего этого мы могли бы
написать программист/айтишник/компьютерщик — чтобы никому не было обидно и
было бы понятней, какое значение всех этих терминов мы имеем в виду.
Бывает и так, что определённый термин, значение которого очень легко понять
неправильно, уже закрепился в языке узкой профессиональной группы. Например,
таков перевод «управление» для термина governance. В таких случаях в данном
курсе будет использоваться наш собственный вариант, который ведёт к меньшему
числу ошибок понимания. Например, governance будет переводиться как
«подконтрольность» или «поднадзорность», и никакие словари и стандарты тут не
указ. Если какой-то «процессный стандарт» (например, системноинженерный ISO
15288) под словом process имеет в виду концепт, в различных других местах
обозначаемый как практика/practice (характерной для процессов развёртки во
времени в этом «процессе» из ISO 15288 нет, там перечисляются именно «практики
жизненного цикла»), то в нашей книге это будет «практика», а не «процесс». Если
вы попали в сообщество людей, исповедующих «процессный подхода» и говорящий
на диалекте, используемом в этом сообществе, смело используйте слово «процесс»
вместо слова «практика» — но знайте, что при этом вы теряете информацию по
различению процессов (с пошаговой развёрткой во времени) и практик (без такой
развёртки), и речь ваша будет время от времени вызывать недоумение.
Очень часто за одним и тем же термином даже в одном речевом сообществе
оказывается закреплено множество разных значений, поэтому уточнить значение
даже очень распространённого термина никогда не бывает лишним. Например,
Andries van Renssen выделил31 следующие часто используемые сообществом
айтишников значения для термина «функция» (function):
● подтип активности (поведения), процесса или события;
● некая сущность, находящаяся в определённой роли или сделанная для
определённой роли;
● сама роль сущности (обычно это роль физической вещи), участвующей в
активности (поведении) [Играемая роль и сущность, играющая роль — это
разное! Роль - Гамлет, сущность - Высоцкий];
● указание на корреляцию/зависимость, обычно как на физическую связь
между какими-то аспектами: «если высота растёт, то давление падает»;
● математическое отношение между числовыми объектами, определяющее их

31
стр. 79 в http://repository.tudelft.nl/assets/uuid:de26132b-6f03-41b9-b882-
c74b7e34a07d/its_renssen_20050914.pdf
 33

отображение друг на друга/mapping.

Это означает, что часто вместо слова «функция» можно использовать слово
«действие», или «роль», или «зависимость» — и разговор от этого станет точнее!
Часто встречающий термин «мета» (meta) используется в шести разных
значениях, выражая шесть разных типов отношений 32:
● экземпляризация (отношение типа и экземпляра);
● группирование (отношение типа и подтипа), оно же категоризация
(философская, а не из теории категорий, термин «категория» любим самыми
разными речевыми сообществами, и обозначает в них разное!);
● описание (отношение описания и описываемого объекта);
● применение/стереотип (отношение шаблона и его воплощения);
● варьирование (отношение основной модели и кастомизированной);
● реализация (отношение абстрактного синтаксиса и соответствующего ему
выражения).
Поэтому каждый раз, встречая слово «мета» нужно разбираться, что именно из этих
шести значений имелось в виду.
Никогда не зацикливайтесь на выбранных другими конкретных словах-
терминах, слова как цепочки букв никогда не выражают истину. Каждый
раз пытайтесь понять, о чем в действительности идёт речь, какое
значение слова имелось в виду в каждом конкретном случае, добирайтесь
до концепта. Использование терминов из стандартов не гарантирует
однозначного понимания собеседником, но и использование
многозначных слов не обязательно ведёт к сложностям.
В этой книге не будет попыток дать точные определения и выбрать правильные
термины. Мы постараемся передать понимание наиболее важных понятий и
предложить разные слова, которыми их можно обозначать. На вопрос «сколько
будет дважды два?» будут приниматься ответы и IV, и 4, и «четыре», и four. Но не
нужно обольщаться: ответы «горшок», 5, «per aspera ad astra» — приниматься не
будут.

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

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

32
слайд 8 в подробной презентации http://jtc1sc32.org/doc/N1751-1800/32N1764-WG2-Tutorial-OnMOF-
forSC32.ppt
 34

(«неформальные формализмы», неточные правила) рассуждения33.

Обязательно ли формально (выражено в символической форме, доступной для
строгого логического вывода) системное мышление, или оно неформально, т.е.
образно и интуитивно?
Главное, что нужно тут обсудить — это наличие и важность полностью
неформального, интуитивного и невыразимого словами и иными знаками знания, в
том числе знания о системах. Тем более что сегодня такое знание могут иметь не
только люди, но и компьютеры, запрограммированные для работы в рамках
коннекционистской парадигмы. Современные достижения искусственного
интеллекта связаны с развитием именно «компьютерной чуйки» (а не развития
логических языков программирования) в рамках машинного обучения в целом и
направления глубокого обучения (deep learning) в частности.
В коннекционистской (connectionism) парадигме34 знание представляется
существующим не как набор связанных какими-то отношениями понятий, а как
распределённое по множеству определённых простых однородных элементов
(часто нейронов в нейронных сетях как искусственных, так и естественных).
Человеческий мозг для мышления использует нейронную сеть, а не логический
вычислитель, действующий по законам аристотелевой логики. Современные
системы машинного обучения тоже начинают использовать для своей работы
похожие принципы, и к ним применяются отнюдь не традиционные наработки для
знаний, понимаемых как формальные модели. Объединение методов формальной,
«научной» работы со знаниями и методов «неформальной» интуитивной работы в
нейронных сетях (искусственных или естественных, в мозгу человека — это тут
неважно) представляет собой научный и технический фронтир, мы не будем
касаться этих вопросов в нашей книге. Подробности на тему использования в
мышлении формальных и неформальных рассуждений можно найти в книге
«Визуальное мышление. Доклад о том, почему им нельзя обольщаться»35.
Мы в нашей книге исходим из того, что мышление «бибинарно»36 (би — это
умножающая приставка от латинского bis, «дважды»), т.е. дважды двойное:
1. По шаблонам — нешаблонное
1.1. «Культурное» мышление, следующее лучшим цивилизационным
образцам, шаблонам (patterns), использующее накопленное
человечеством знание и одновременно
1.2. нетронутое какой-либо культурой, шаблонами «дикое» мышление,
которое приходит новыми путями к выводам, потенциально каких
цивилизация ещё не знала, паттерны чего ещё не различала.
В нашей книге мы делаем упор на культурную часть системного
мышления, пытаемся взять в нём самое важное, отмоделировать и
передать пытающимся освоить его людям. При этом мы понимаем, что
в реальной жизни приходится всё время выходить за рамки
имеющегося знания, давать ответы на вопросы, которые в учебниках
(в том числе и нашей книге), стандартах, публичных документах и даже

33
См. литературу в пунктах 1 и 2 http://ailev.livejournal.com/1311261.html.
34
См. подробнее в http://ailev.livejournal.com/1228029.html.
35
https://ridero.ru/books/vizualnoe_myshlenie/
36
http://ailev.livejournal.com/1305176.html
 35

научных статьях ещё не рассматривались.

2. Знаковое-незнаковое (формальное-неформальное)
2.1. Формальное мышление (дискретное), опирающееся в своих
приёмах на строго определённые дискретные объекты и выражаемые
знаками (symbols) классических логических рассуждениях. Но
одновременно
2.2. мышление непрерывное, коннекционистское, опирающееся на
объекты, определённые лишь статистически, вероятностно, без их
знакового выражения и интуитивно проводимое эвристическое (т.е.
необязательно формально верное, но применимое в большинстве
случаев, хотя и не во всех) рассуждение. Правила такого рассуждения
тоже могут быть не формализованы.
В нашей книге мы делаем упор на формальное системное мышление,
дискретные знаковые представления о системах, но понимаем, что в
реальной жизни приходится в существенной мере опираться на
автоматизмы мышления, использующие интуитивные непрерывные
представления, и это зачастую даёт огромные преимущества.
Например, формальные (дискретная логика) рассуждения для разных
наборов понятий из формальных дисциплин принципиально (т.е.
формально-логически) несопоставимы, но их можно как-то объединять
в коннекционистских (непрерывных) представлениях.
Даниэль Канеман утверждает37, что у человека есть два механизма мышления:
быстрое малозатратное интуитивное и медленное трудоёмкое, включающееся при
появлении каких-то проблем при использовании «быстрого» интуитивного
мышления.
По факту речь идёт о целом спектре мышления от интуитивного неформального
через вероятностное (с какими-то оценками этих байесовских вероятностей по
самым разным источникам априорных свидетельств и данных эксперимента) к
классическому формальному на основе математической логики. Вот схема Прапион
Гайбарян, иллюстрирующая этот полный спектр:

37
Даниэль Канеман, «Думай медленно… Решай быстро»,
https://ru.wikipedia.org/wiki/Думай_медленно..._решай_быстро
 36

Обычно интуитивные догадки на уровне «ощущений» вытаскиваются в качестве

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

Системное творчество
Медленное, «формальное», рассудочное мышление при всех его достоинствах
может испытывать содержательные проблемы, даже когда люди готовы тратить на
него достаточно времени. Хорошо сформулированная проблема обычно содержит в
себе явное формальное противоречие, которое необходимо «снять» — только в
этот момент включается творческое мышление, только в этот момент нужно
«сесть и подумать» (а не «вспомнить и применить», рутинное, автоматическое
мышление). Иногда говорят, что мышление появляется тогда, когда нужно
«перевести проблемы в задачи», т.е. создать список работ, которые понятно, как
выполнять, и которые вместе решают проблему, снимают противоречие, убирают
коллизии.
Решение проблем путём формулирования и снятия противоречий
(коллизий) присуще и теории ограничений Элияху Голдратта («грозовая туча»38), и
методологии ТРИЗ Генриха Альтшуллера39, и системомыследеятельной методологии
(школа Георгия Щедровицкого40). Все эти школы мысли утверждают, что они
основаны на системном подходе, отсюда и общность мыслительных приёмов.
Системное мышление ничего не говорит про то, как снимать противоречия. В нашей
книге нет никаких «методов творческого мышления», таблиц решений, способов
проводить мозговые штурмы, приёмов развития воображения. Чудес не бывает,
думать тут приходится не меньше и не больше, чем в любых других школах мысли.
Системное мышление позволяет удерживать ви́ дение всей системы в целом при
решении проблем, не терять за деревьями леса, не терять за листьями дерева.
Системное мышление позволяет целенаправленным образом находить
противоречия, требовать их решения, документировать эти решения. Подвести к
важному противоречию, не пропустить его, не дать проигнорировать — вот задача
системного мышления. А дальше нужно брать голову в руки и думать, используя
разные другие методы.

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

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

38
https://en.wikipedia.org/wiki/Evaporating_Cloud
39
https://ru.wikipedia.org/wiki/Теория_решения_изобретательских_задач
40
http://www.fondgp.ru/
 37

Есть и другие, менее распространённые специализации системного мышления.

Например, есть специализация системного мышления для танцевальной
импровизации Viewpoints41, на системном подходе также основан текст
«Танцевальное мышление и его развитие»42.
Во всех этих многочисленных специализациях системного мышления
накапливаются знания по типовым инженерным, менеджерским, танцевальным и
т.п. решениям, поощряется задействование опыта этих инженерных, менеджерских
или танцевальных решений. Но когда вам нужно что-то делать впервые в мире (как
когда-то летели на Луну, а сейчас в SpaceX делают первые возвращаемые на Землю
повторно используемые ракетные системы), то есть два варианта — изобретать что-
то беспорядочно, «по интуиции», или мыслить системно, чтобы как-то
последовательно ставить и решать проблемы, находить и решать противоречия,
снижать риск забыть что-то важное в многолетнем проекте, выполняемом сотнями
и тысячами человек.
Системное мышление помогает поделить решение проблемы между разными
людьми в команде (более того, часто решение принципиально не может быть
найдено одним гениальным человеком, требуется работа больших коллективов).
Для этого системные инженеры, менеджеры, предприниматели, танцоры43 и другие
члены команды явно обсуждают метод своей работы. При этом они не просто
«генерируют основные инженерные, менеджерские, творческие решения», а
«создают архитектуру системы»: основанный на системном подходе
профессиональный язык системных инженеров, менеджеров и даже танцоров,
позволяет быстрее, чем на бытовом языке, договариваться о том, что в каком
порядке делать при постановке и решении многочисленных задач в ходе создания
самых разных систем — космических кораблей, организаций, танцев, т.е. всего того,
что делают люди.
Итого: системное мышление ничего не говорит про содержание
мышления, только про его форму — использование концептов системного
подхода при мышлении.
Более того, развиваемые на его основе дисциплины (системная инженерия,
системный менеджмент и т.д.) делают всё, чтобы и не нужно было много мыслить,
а чтобы было можно просто применять в проекте уже известные технические,
менеджерские, творческие решения. Мощь системного мышления будет
проявляться в тот момент, когда известных типовых решений не будет и нужно
будет делать первую из нового вида (first of a kind, FOAK) систему, или обходить
какие-то жёсткие ограничения, которые не встречались раньше, или избегать
каких-то часто встречающихся ошибок в деятельности — например, не забывать в
суете выполнения какой-то работы подумать о чём-то важном, для чего нужно
заранее знать — что именно является важным.
В нашей книге обсуждается только форма для мышления: взятые из стандартов и
публичных документов и только слегка авторски доработанные понятия системного
мышления. Но в книге ничего не говорится про содержание мышления, оно
уникально для каждого проекта. И даже если вы второй раз будете делать какой-то

41
https://en.wikipedia.org/wiki/Viewpoints
42
http://ailev.livejournal.com/1332624.html
43
Пример такого танцевального проекта, использующего системное мышление – буфф, «всё лучшее в
социальных танцах», https://vk.com/buffdance
 38

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

вы получите какой-то опыт выполнения проекта, у вас будут какие-то новые
мыслительные интуиции.

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

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

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

вышло, в чём именно эта контринтуитивность, вы не можете передать это знание
другим людям, не можете никого этому знанию научить.
Вы не можете научить системного инженера, системного менеджера и даже
танцора, если вы не знаете на уровне сознания, что он должен делать в ходе своей
деятельности, что он должен думать. Вы не можете человека научить стать
просветлённым за определённое время, если вы не понимаете, в чём именно
содержание просветления. Чем отличается искусство от технологии? В искусстве —
один раз свезло, вдохновение было, получился шедевр. Другой раз не свезло,
вдохновения нет, не будет шедевра. В инженерии («железной», программной,
предприятия, и даже танцев) мы так не можем, нам нужно работать, нам нужны
практики мышления, дающие неизменно превосходный результат.
Пожелания «не стеснять свободу творчества шаблонами» тут не
подходят: люди, массово выдумывающие мыслительные велосипеды, с
большой вероятностью получат не самое лучшее решение. Аргументы
«творчества вместо шаблонов» верны только для единичных гениев, в
большинстве же других случаев шаблонные мыслительные решения
обеспечивают качество при минимизации умственных усилий.
Опять же, гением называют не всех «творцов», а только тех, которые предъявляют
качество мышления лучше, чем по лучшим известным на текущим момент (state-of-
the-art) мыслительным шаблонам — и дальше уже их решения становятся
шаблонными. Эти вновь появляющиеся в цивилизации шаблоны хорошего
мышления нужно сразу делать явными, документировать (желательно в форме
учебных курсов как адекватной форме документирования мыслительных практик).
Как передаётся неотрефлексированное, неосознанное искусство или ремесло?
Ученик смотрит на десятки, тысячи, сотни работ мастеров, научается понимать
сленг профессионалов как научаются родному языку (без учебников и словарей,
просто «из разговоров»), постоянно смотрит, как работают настоящие мастера и
пытается это копировать — прямо по пословице «обезьянка видит, обезьянка
делает» (monkey see, monkey do). Далее у трёх из десяти учеников в голове
появляются какие-то правильные рельсы для трамваев их профессиональных
мыслей, и они начинают мыслить быстро и делают мало ошибок. А у семи из
десятка — не появляются, и они делают много ошибок. Обучение искусству или
ремеслу — это не обучение в классическом смысле слова.
А нам надо, чтобы девять из десяти могли научиться (вполне можно представить,
что будет один неспособный на десяток человек, но не семеро из десяти). Это
означает, что мы должны взять для обучения такое контринтуитивное знание,
которое само не может быстро прийти в голову ученикам, сделать его минимальное
компактное и понятное описание, а затем его каким-то образом передать ученикам,
чтобы оно встроилось им в голову. Вопрос: бывает ли такое в тех областях, которые
традиционно считались «искусством», и которым считалось, нельзя научить
рационально? Да, бывает, сплошь и рядом! Это и есть путь западной
цивилизации: превращать «искусство» (в том числе искусство
мышления) после его моделирования и рационализации в быстро
передаваемое от человека человеку в ходе структурированного обучения
мастерство.
Когда вы находите правильные объекты и правильные мыслительные операции, и
 40

правильные упражнения — то ученики после обучения даже не будут понимать, что

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

как-то документированной модели целевого мышления, организованной в учебный

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

Это абсолютно неинтуитивно, но даёт возможность перелетать и через

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

44
https://en.wikipedia.org/wiki/Fosbury_Flop
45
http://grushnitskiy.ru/literature/books/Poznyi_774_metod_bega_-_Nikolai_774_Romanov_2013.pdf
 42

такой же набор придуманных разными людьми специфических

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

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

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

ученика46).
1. Начитанность: знакомство с каким-то фрагментом набора понятий
системного подхода. Материал учебника (или даже нескольких) освоен на
этой стадии в части знания значений слов, умения пересказать какой-то
фрагмент учебника, воспроизвести какую-то диаграммку, поддержать
разговор про содержание учебника.
Правильно думать о стадии «начитанность» как о начитанности учебником
по езде на велосипеде. Начитанный, но ни разу не ездивший человек может
долго вам рассказывать о равновесии, о необходимости крутить педали. Но
продемонстрировать езду он не сможет.
Начитанность для мышления нужна, но для беглости в мышлении её
совершенно недостаточно. Чтобы обеспечить «правильную для последующей
тренировки беглости начитанность» как раз и написана наша книга-учебник,
в которой структурировано системное мышление. Однако начитанность — это
даже ещё не переход к осознанной компетентности, когда можно
самостоятельно и осознанно провести какое-то рассуждение в рамках
предлагаемого культурой и документированного в учебнике лучшего способа
это делать.
2. Понимание: понимание того, что означают термины системного подхода
в их многочисленных вариантах разных школ, понимание как использовать
понятия системного мышления при обсуждении ситуаций. Кроме памяти тут
уже появляются некоторые мыслительные интуиции. И это делается
«сержантским методом»47, то есть путём решения простых и похожих друг
на друга, многочисленных тренажёрных задач, которые формулируют
авторы курса для тренировки, а не для контроля знаний 48.
Пример такой задачи: «Пётр утверждает, что нужно уже начинать закупать
функциональные части системы, а Елена утверждает, что не функциональные
части, а конструктивные части. Кто из них прав? А) Пётр Б) Елена». Ответить
на такую задачу можно, только если знать про различия функциональных и
конструктивных частей системы — для ответа нужно хоть как-то сопоставить
ситуацию в задаче с местом из учебника, где говорится о таком различии.
После нескольких таких задач ответ будет самоочевидным, никаких отсылок
к учебнику не потребуется. При решении тренажёрных задач как раз и
формируются «рельсы в голове», по которым поедет мышление.
Важно, что в задачах специально тренируется контринтуитивность, отличие
предлагаемого способа мышления от использования народных/бытовых
интуиций/здравого смысла, это делается через использование практики
понятийной описи49 (conceptual inventory). Суть этой практики заключается
в том, чтобы предлагать в задачах ответы-ловушки, соответствующие
«народному мышлению». Это было предложено в физике, чтобы проверять

46
http://ailev.livejournal.com/1316601.html
47
Подробней о «сержантском методе» можно почитать по ссылкам в
http://ailev.livejournal.com/1287293.html.
48
К нашему учебнику есть порядка 200 задач с автоматизированной проверкой решения, вы можете найти
эти задачи в онлайн-курсе или решать эти задачи на семинарах Школы системного менеджмента
http://system-school.ru/
49
http://modeling.asu.edu/R&E/Notes_on_Modeling_Theory.pdf
 44

понимание ньютоновской физики по сравнению с «народной»

аристотелевской. В аристотелевской физике палец давит на стол (он же
живой!), а стол не давит на палец (он же не живой!). В ньютоновской они
давят друг на друга с одинаковой силой, что контринтуитивно, не
соответствует «здравому смыслу» (зато соответствует ньютоновской
физике). Задачи, составленные по принципам понятийной описи,
проверяют — что на эту тему после прохождения курса физики думает
выпускник. И если оказывается, что он решает задачи на третий закон
ньютона с правильным применением формул, но при этом считает, что стол
не давит на палец, то что-то в обучении пошло не так, и нужно доучиваться.
Задачи по курсу системного мышления составлены таким же образом, они
проверяют системность в мышлении, правильность рассуждений с
контринтуитивными понятиями системного мышления, отход от бытового и
привычного мышления «здравого смысла». Опять же, «понимание» в какой-
то предметной области ещё не даёт общей способности к мышлению50.
3. Приложимость: умение системно мыслить по потребности in the wild, то
есть в реальных проектах. Это совсем отдельное качество: уметь решать уже
поставленные задачи (даже олимпиадного уровня сложности) из задачника
против умения ставить задачи. Ставить задачи — это выделять из
запутанного, шумящего, быстро меняющегося окружающего мира с огромным
числом незначимых и кричащих о себе деталей правильные объекты,
сопоставляя их с объектами, описанными в учебнике. После этого можно
решать задачу, которая сформулирована уже в терминах изучаемой
предметной области. В жизни нет задач из учебника, нет даже слов из
учебника, их нужно выявить, обнаружить, т.е. поставить задачу,
«приложить» книжное знание к жизни. А потом можно уже в привычных
терминах из учебника решить поставленную задачку. Если нужно узнать,
сколько яблок в двух кучках, нужно догадаться, что яблоки — это ровно те
счётные объекты из учебника арифметики. Если вы хотите узнать про
потребности для разрабатываемого вами супер-пупер-продукта, то нужно
выявить, какие объекты в мире являются для него надсистемой, и какие роли
людей заинтересованы в этой системе, что люди в этих ролях от этой
надсистемы (а не от вашего супер-пупер-продукта!) хотят. Реальные проекты
в учебном курсе появляются только тут, и только тут тренируется главный
навык системного мышления: выделение главного и игнорирование не
главного для борьбы со сложностью реального мира.
В составленных какими-то авторами тренажёрных задачах тепличные
условия, так как ничто не отвлекает от применения материала из учебника —
ни обилие незначимых деталей, ни отсутствие важной информации, которую
ещё нужно найти, ни эмоциональное вовлечение в ситуацию (попробуй
сообрази, в какой роли на тебя орёт начальник! А ведь нужно сообразить,
прямо по ходу очень нервного разговора!). А ещё у тренажёрных задач
заведомо есть решение, в жизни же существование приемлемого решения —

50
Появились материалы, обсуждающие beyond concept inventories towards measuring how students think —
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2830154/ (concerns about measuring student thinking as opposed
to student knowledge, но все эти попытки плохо технологизируются по сравнению с concept inventory).
Больше на эту тему в тексте "Заметки к "Заметкам по теории моделирования" Давида Хестенеса" —
https://ailev.livejournal.com/1197467.html.
 45

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

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

В инженерной, менеджерской и предпринимательской жизни обычно делается
предположение об открытости мира51 (open world assumption): «что не
сказано, то просто не сказано». Это существенно отличается от предположения
о закрытости мира в задачах из учебников: «что не сказано, того просто нет».
Тренажёрные задачи чаще всего составляются из предположения о закрытости
мира, опытные инженеры и менеджеры в предположении об открытости мира при
решении задач начинают придумывать всё более и более необычные и
маловероятные обстоятельства, логично ведущие к неправильным ответам — и
даже часто добиваются успеха («вот если речь идёт о Юпитере, и пилот ракеты не
боится огромной силы тяжести и играет на саксофоне в метановой атмосфере, то
ваш правильный ответ будет неправильным, а мой неправильный правильным»).
Действительно, маленькая вероятность обстоятельств к чисто формальной
правильности ответа отношения не имеет (даже исчезающе маловероятное событие
может быть формально верным, «логичным» в аристотелевой логике) и формально
«математически» ученик может быть прав. Но в жизни (а не в идеальном мире
математики!) генерирование таких дополнительных маловероятных условий исходя
из посылки открытого мира не помогает решать тренажёрные задачи, а только
мешает это делать.
Особое внимание нужно уделять тренажёрным задачам на начальных стадиях
обучения — когда правильный ответ интуитивно не ясен, не является шаблонным.
Когда студент материал знает плохо, он включает «смекалистый мозг». Он смотрит
на 2*2 и начинает: «Это может быть любое число больше 1.0 и меньше 9.0, ибо мы
же не знаем, насколько и как округлили исходные числа. И это может быть в ответе
вообще что угодно, начинающееся и заканчивающееся на 2, ибо звёздочка не
всегда означает знак умножения. Часто звёздочка означает любое количество
символов. А ещё речь может идти о символьном умножении, поэтому ответом будет
22. И давай не будем разбирать ситуации, когда система счисления недесятичная,
так и быть». Конечно, он достаточно смышлён, чтобы заподозрить в ответе 4, но и
недостаточно уверен в этом ответе, чтобы не предположить дополнительных
подвохов.
Двое из десятка изучающих системное мышление человек именно таковы — они
материал не читали, но они хорошие инженеры или менеджеры, у них подвешен
язык, они скептичны по отношению к материалу учебника (это ничего плохого,

51
https://en.wikipedia.org/wiki/Open-world_assumption
 46

просто skeptic thinkers), и именно они обычно самые активные в группе.

Их цель не столько поупражняться в системном мышлении и использовании его

концептов, сколько попробовать «прогнуть» предлагаемые задачи вместе с
системным мышлением, испытать их на прочность формально-логичного «здравого
смысла». Этим людям хорошо работать Беспристрастными Свидетелями (Fair
Witness) из Хайнлайна: «Энн стояла на трамплине. Джабл крикнул ей: - Тебе виден
тот дом на горе? Какого он цвета? Энн посмотрела и сказала: - С нашей стороны
белый. Джабл обернулся к Джилл: - Вот видишь, Энн не стала говорить, что дом
белый целиком. И вся королевская рать не заставит ее сказать это до тех пор, пока
она не пойдет и не посмотрит. Но даже и тогда она не сможет утверждать, что дом
остался белым после того, как она ушла»52.
Как мы могли бы с этим бороться? Очевидный ответ — строго формализовать
задачи, добиваясь однозначности правильного ответа. Но чем формальней будут
поставлены задачи «из учебника», тем дальше они будут от реальной жизни! Жизнь
не формально-логична, жизнь вероятностна! Интересуют общие закономерности,
наиболее часто встречающиеся случаи, а не маловероятные исключения и особые
ситуации! Если рассмотреть задачу о том, чем забивать гвоздь — молотком, камнем,
подушкой, рукой, микроскопом, то ответ тут должен быть «молотком» (а не
«молотком, камнем, микроскопом, и ещё рукой, потому что рука может быть в
стальной перчатке от кольчуги»). Но если задача «чем забивать гвоздь, если вы
оказались в дороге, и молотка нет?» будет иметь другие ответы! Задачи
ситуационны, они не абсолютны, их решения вероятностны.
Ещё важно понимать, что все эти задачи тренажёрные, а не
экзаменационные. Они дают лишь повод осознать и обсудить материал учебника,

52
https://ru.wikipedia.org/wiki/Чужак_в_чужой_стране
 47

формализм «единственно правильного ответа» для них непринципиален. Один из

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

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

Чтения учебника недостаточно — это как читать учебник по езде на велосипеде, не
сильно помогает. Решения задач недостаточно — это как ездить на велосипеде
только по прямой, на специально оборудованной дорожке. Нужно будет потом
долго тренироваться в постановке задач, в применении системного мышления в
ваших рабочих проектах (ездить на велосипеде по бездорожью в горах) — и только
тогда цветущая сложность начинает отступать и поддаваться тренированному в
системном мышлении мозгу.
Основных идей системного подхода немного, каждая из этих идей довольно быстро
понимается. Если выразить системный подход одной фразой, то получится что-то
типа «для удовлетворения внешних ролевых потребностей нужно понять
функционирование и возможную конструкцию надсистемы и тем самым
сформулировать функциональные и интерфейсные требования к целевой системе.
Затем выполнить эти требования, для чего разработать архитектуру и затем
воплотить в жизнь конструкцию целевой системы. А для этого нужно применить
практики обеспечения жизненного цикла целевой системы, организовав
компетентную команду и снабдив эту команду всеми нужными технологиями. И всё
это нужно делать рекурсивно, для всех подсистем целевой системы».
Проблема даже не в том, что эти предложения сплошь состоят из терминов,
значения которых нужно знать. Все эти положения глубоко связаны друг с другом
и крайне редко используются поодиночке. Так что требуется добиться некоторой
беглости (fluency) в их одновременном и совместном применении — примерно в
том же смысле, что и беглости пальцев в игре на рояле или наборе текста на
клавиатуре, беглости в говорении на иностранном языке. Каждая клавиша на рояле
или клавиатуре понятно нажимается, их всего не так много, проблема только в том,
чтобы разные клавиши нажимать вовремя, быстро и такие, какие нужно для
получения музыки. На освоение компьютерной клавиатуры уходит несколько дней
 48

тренировки, но на освоение рояльных клавиш уходит несколько лет. В освоении

системного мышления, как и в освоении игры на рояле, нет царских путей, кроме
как бесчисленного числа повторений, выполнения многочисленных упражнений на
использование этих положений, получение опыта применения в жизни. Это, увы,
занимает время. Поэтому мышлению желательно учиться с детства. Вот из
материалов Viewpoint Research Institute53:
Мы хотим помочь детям развить реальную беглость (fluency) во многих
областях образования, включая мышление, математику и науки. Каждый из
этих предметов не поддается «естественному обучению» (как учатся ходить
и говорить). Довольно много времени и энергии нужно потратить, чтобы
получить беглость выше пороговой. Тут интересное сходство с искусством,
музыкой и спортом, для каждого из них также требуется довольно много
времени и энергии, чтобы получить беглость. Эти искусства могли бы
называться «тяжелое развлечение» (hard fun). Математики и ученые знают,
что они занимаются искусством, равно как тяжелым развлечением.
«Мышление» — это более высокая категория, чем «просто» математика,
наука и искусства. Оно представляет синтез интуитивного и аналитического
подходов к пониманию мира и поведения в нем.
Peter Senge в книге «Пятая дисциплина»54 (1990) писал:
Недавно в ходе пятидневного вводного курса, проводимого Обучающим
центром МТИ, одна женщина-менеджер из конструкторского отдела компании
Ford лаконично сформулировала ситуацию: «Спустя пару дней, — сказала
она, — я начинаю понимать, о чем вся эта история с системным мышлением
и интеллектуальными моделями. Мне это напоминает время, когда я только
начала знакомиться с высшей математикой. Сначала я чувствовала себя
совершенно потерянной. Все это было мне совершенно чуждо. Но потом я
начала «схватывать» суть. Через год я уже вполне владела основами этого
дела. Через пять лет это стало основой моей профессии». Потом она
добавила: «Если бы высшую математику изобрели сегодня, ни одна из наших
корпораций не смогла бы ею овладеть. Мы бы посылали каждого на
трехдневные курсы. Затем каждый получал бы три месяца на то, чтобы
посмотреть, работают ли «все эти штуки». А когда выяснялось бы, что они не
работают, мы бы начинали пробовать что-нибудь другое».
Если заниматься языками, то любой из них можно довести до уровня С1
(достаточный для поступления в европейский ВУЗ) за год, если интенсивно
заниматься — для языка без флексий (английский, испанский) нужно на это
потратить 600 часов, с флексиями (русский, немецкий) 1100 часов, для языков
совсем другой структуры 2200 часов. Если заниматься год, то в день нужно тратить
примерно 1.6, 3 и 6 часов соответственно, и в Сети можно найти достаточно
примеров, как мотивированные люди выделяли примерно такое время в своём
расписании и достигали успеха. Чтобы достичь в языке мастерства, нужно
потратить порядка 10000 часов (хотя это и спорное утверждение, но порядок
верный) — то есть заниматься языком несколько лет. И в случае иностранного
языка это даже не «мыслить» и не узнать о каких-то новых вещах и их связях, это
просто «переназвать известные уже вещи другими словами»! Системное мышление

53
http://vpri.org/
54
https://en.wikipedia.org/wiki/The_Fifth_Discipline
 49

относится к того же сорта практике: его нужно практиковать, чтобы добиться

беглости использования в жизни, а не «мыслить со словарём» в тех случаях, когда
«решили, что в этом случае нужно применить системное мышление».
Оценки для получения начальной беглости в системном мышлении — это примерно
12 тренинговых и менторинговых дней с преподавателем (один день раз в пару
недель), и самостоятельная работа между этими днями по 3-4 часа в день на
протяжении примерно полугода (чтение книг, решение задач, работа с
собственными проектами в части приложения системного мышления).
Но системное мышление — это не единственный мыслительный навык по
методологическим дисциплинам (онтологика, системное мышление, научное
мышление, вычислительное мышление и т.д.) который нужно ставить современному
взрослому человеку. Поэтому сразу целимся на вдвое больший объём — 24
тренинговых дня при описанной в предыдущем абзаце интенсивности. Это год
работы. А ещё когнитивистские дисциплины, т.е. постановка под сознательный
контроль собственной психики и тела (телесное мышление, прокрастинатология,
ролевое мастерство и др.). Если грубо и с добавкой недостающего
деятельностного кругозора (системная инженерия, менеджмент,
предпринимательство и др.) то это ещё год, 48 тренинговых дней. И вот это уже
очень сравнимо по срокам с традиционным вузовским бакалавриатом (хотя два года
— это меньше традиционных бакалавриатских трёх-четырёх лет). Но содержание
образования получается другое55. Курс каждой дисциплины в среднем получается
где-то четыре тренинговых дня — это примерно по объёму соответствует
семестровому университетскому курсу, "небольшой учебник/лекции, стопка
дополнительной литературы к ним и семинары плюс домашние задания и итоговая
работа". То есть это примерно (примерно! не точно!) 12 дисциплин на пару лет,
вполне обозримо, и вполне сравнимо с университетской нагрузкой — шесть
дисциплин в год, три дисциплины в семестр, одна дисциплина проходится за пару
месяцев плотной работы. Приемлемо по временным затратам даже для занятий,
совмещаемых с работой. Системное мышление, безусловно, входит в программу
подобного «второго бакалавриата» 56.
Речь идёт по факту об изменении образа жизни — откуда-то эти несколько часов
нужно взять, как-то переустроить своё типичное дневное расписание. Это как
поступить в очную или заочную физматшколу: тяжело работать несколько лет,
чтобы получить другие жизненные возможности. Обучение вообще-то
неблагодарное занятие: если вы учились целые выходные с утра до вечера, то вас
похвалить будет некому — это не работа, которую можно существенно продвинуть
за пару дней и это всем будет заметно. Нет, придётся потратить много дней без
немедленных наград. Зато это позволит потом претендовать на другие работы и
другой уровень наград.

55
Эскиз учебной программы для системного развития личности — https://ailev.livejournal.com/1443837.html.
Эту программу реализует Школа системного менеджмента http://system-school.ru/, где автор работает
научным руководителем. Подробности можно прочесть в цепочке текстов «второй бакалавриат»,
https://ailev.livejournal.com/1453126.html
56
Второе высшее образование обычно получается как «вторая магистратура», а мы тут говорим об обучении
менее специализированным, чем в магистратуре дисциплинам – это обычно происходит в бакалавриате.
Необязательно речь идёт именно о втором бакалавриате. Это может быть и «первый бакалавриат»,
подробней в «как перепрыгнуть из семейной среды в деловую: первый бакалавриат»,
https://ailev.livejournal.com/1470949.html
 50

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

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

2. Воплощение и описание системы

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

57
В философии эту привязку фактов к реальности описывают как grounding —
http://www.hollowayquarterly.com/2015/04/what-is-metaphysical-grounding.html,
https://plato.stanford.edu/entries/grounding/
 51

из них. Мы будем считать, что в физическом мире присутствуют только те объекты,

которые занимают какое-то место, объём какой-то причудливой формы в нашем
пространстве-времени, принимая идею Эйнштейна про существование
физического мира в четырёхмерном пространстве-времени.
Тем самым конкретная система имеет некую протяжённость в пространстве (то есть
размер, длину, ширину, высоту, радиус) и во времени (то есть имеется момент,
когда она начала существование, и момент, в который она закончит существовать).
Для полей или энергии тоже можно определить место в пространстве-времени,
физические тонкости такого подхода для нас пока не важны.
Тем самым мы чётко различаем воплощение системы (system realization)
занимающее объем в физическом пространстве-времени, и описания системы
(system definition, часто называются ещё и определениями системы, не путайте со
«словарными определениями»!) — информацию о воплощении системы.
Информация не имеет места в реальном мире, нельзя сказать, что определяющее
высоту в метрах (воплощения) системы «Эйфелева башня» число «300» находится
где-то в реальном мире и имеет собственную длину-ширину-высоту. Если вы
укажете на вот это вот число «300» и скажете, что оно существует и имеет свой
объём — то вы укажете не на само число, а на носитель информации, который
своей формой (частицами краски или прозрачностью материала или ещё как-то)
кодирует это число. Тем самым место занимает не «300» как число, не часть
описания Эфейлевой башни (число 300 описывает Эйфелеву башню), а
материальный объект кусочка документации (system description) Эйфелевой
башни, т.е. носитель с записанной на нём информацией/описанием.
Документация — это описание, записанное на каком-то носителе
информации.
Экран или бумага фотографии, или даже компьютерная память с файлом
фотографии — это носители информации, не сама «фотография» как информация
на ней! Порвать бумажную фотографию (документацию системы) — это не порвать
человека, изображённого на фотографии (воплощение системы), и даже не порвать
изображение человека на этой фотографии (описание системы), ибо оно может
сохраниться на сотнях других носителей. Абсолютно такое же действие —
выключить экран с фотографией, или стереть файл с фотографией (это не так
символично, как порвать бумажную фотографию, но по сути — то же самое.
Абстрактные объекты не горят, представление их на носителях обычно легко
копировать, и уничтожение документа, а хоть и электронного — это не уничтожение
описываемого документом объекта, а часто это и не исчезновение
документированного описания, доступного на многих копиях документа).
Описания системы легко отличить от воплощений системы и документов системы —
они не занимают места в физическом мире, у них нет объёма и координат в этом
мире, они абстрактны, «идеальны», нематериальны как противоположность
материальному/физическому. Системы и системные документы (документы о
системах) материальны, они занимают место в физическом мире.
Людей в конечном итоге интересуют воплощения системы, а описания и
документация системы их интересуют ровно постольку, поскольку без них
воплощение системы трудно сделать, особенно когда речь идёт о системах,
создаваемых многими людьми.
Различение воплощения, описания, документации системы нужны в том числе и для
 52

того, чтобы предотвращать распространённые ошибки людей, играющих роли

разработчиков в проектах по созданию систем:
• Когда люди даже и не думают создавать систему, а пишут очередную
«концепцию». Нужно проверить, описывает ли концепция что-то
существующее в реальности, а не просто описывает создание документации
и избегает описания воплощения системы.
• Когда разработчики документации считают, что их целевая система —
документация. Нет, их целевая система — воплощение системы, без
воплощения системы не стоит и заводиться с её описанием,
документированием этого описания. Без намерения сделать систему речь
идёт о «художественных описаниях», в них могут быть любые ошибки.
• Разработчики исходного кода программ (это тоже описание воплощения
системы) тоже считают, что их обязанности заканчиваются тогда, когда они
сделали документацию (исходный код с любым количеством ошибок) в
систему хранения версии (носитель — внешняя память компьютера хранения
версии). Нет, и нет: их целевая система — работающая программа, а не
исходный код на любых его носителях.
• Менеджер, разработавший план мероприятий (описание системы работ,
существующее в виде документации системы в программе проектного
управления), воплощением системы для него будет система работ, а не этот
план (а целевой системой, скорее всего — та система, которая получается в
ходе этих работ).
• … и таких ошибок «описания вместо созидания» множество, на них нужно
всегда обращать внимание.
Результат работы проектировщика атомной электростанции — в конечном итоге
воплощение атомной электростанции, а не бумажная документация на её
строительство или даже информационная модель атомной станции в компьютере.
Результат работы хореографа — это в конечном итоге сам танец (исполняемый в
конкретное время в конкретном физическом месте во вселенной), а не описание
танца, или даже документ о танце как листочек бумаги с описанием танца. И это
несмотря на то, что проектировщик сам не строит атомные электростанции, а
только их описывает, а «хореограф» в его изначальном значении тоже «описатель»
танца (от др.-греч. χορεία — хороводная пляска, хоровод + γράφω — записывать,
писать. Первоначальное значение хореографии — это отнюдь не сочинение и
постановка танцев, а именно искусство записи танца).
Люди ходят не по карте, а по территории. Карта — это только описание территории,
которое может быть представлено в разных документах (электронных или
бумажных, или пластиковых), и это верно для всех описаний/документов, не только
для географических карт.
Карта коктейлей — это не коктейли, её не пьют. Карта находится в мире
информации, даже если на ней изображены картинки настоящих коктейлей.
Информация не занимает пространства-времени, она абстрактный объект, а не
конкретный, даже если её нельзя представить без носителя. Карта не занимает
пространства-времени. По ней нельзя «постучать», на неё нельзя «показать
пальцем», как нельзя постучать по «числу 300», но можно постучать только по
«изображению числа 300» на каком-то носителе.
Если же говорят, что карта занимает место/объём в пространство-времени, то речь
 53

идёт не о самой карте как информационном, абстрактном объекте, а о

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

А вот сами коктейли, документируемые картой/описываемые информацией на

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

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

Мышление происходит для классов/типов/множеств/видов

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

Как договориться: не обобщать, а конкретизировать

Если один человек упомянул президента США, а другой — Дональда Трампа, то они
имели в виду одно и то же лицо? А если другие люди упомянули президента США и
Джорджа Вашингтона — они имели в виду тех же лиц? В инженерии тоже нужна
жёсткая логика для подобных рассуждений — описанный одним человеком насос P-
101 на схеме трубопроводов, и описанный другим человеком насос модели ПДР-15-
НШ-12 в монтажной спецификации — это один и тот же насос? А установленный в
турбинном зале насос ПДР-15-НШ-12 с серийным номером RKS456/4 — как он
соотносится с первыми двумя? Как описать это «в компьютере» так, чтобы и самому
не запутаться, и других не запутать?
Ещё Декарт (1596-1650) задавался вопросом: а как вообще понять, что люди
говорят об одном и том же объекте, если они видят в нём самые разные свойства
(то есть относят его к самым разным классам)? Скажем, один инженер говорит о
высокопроизводительной системе, другой — о взрывоопасной, менеджер — о
прибыльной, а финансист — о дешёвой? Как тут понять, что речь идёт об одной
системе? Ответ Декарта на такие вопросы используют до сих пор58: если места в
пространстве (а сегодня говорят не только о пространстве, но и пространстве-
времени, учитывая протяжённость и во времени тоже, как «декартову
координату»), у двух объектов совпадают, то это один и тот же объект. Не важно,
какие основные или вторичные свойства и сущности увидели разные люди в
объекте/системе, или для каких применений этот объект/система им нужна. Не
важно, одинаковые или разные имена у тех мест в пространстве-времени, о которых
говорят разные люди с разными ролевыми интересами в той или иной ситуации.
Если речь идёт об одном и том же месте пространства-времени, значит речь идёт о
том же самом воплощении системы. Если я говорю о пище, вы говорите о яблоке,
она говорит о товаре, он говорит о зелёном физическом теле массой 150 грамм, и
всем мы показываем на одно и то же место в пространстве-времени, то речь идёт
об одном и том же объекте. Если кто-то показывает в физическом мире (в
пространстве-времени!) на бабочку с крыльями и говорит «бабочка», а кто-то
другой показывает в физическом мире на яйцо-гусеницу-куколку-бабочку-с-
крыльями и говорит «бабочка», то у этих двоих есть шанс понять друг друга.
Важно, что «ход на понимание» тут на конкретику (воплощение системы,
физический мир), а не на «определение» (то есть отнесение какого рода объектов
к их виду — «определение по Аристотелю»). Выдача определений и
требование определений обычно затуманивает понимание в сложных
ситуациях, а проясняют примеры воплощений из физического мира — все
споры о терминах прекращают именно такие примеры.
Если не требовать, чтобы все рассуждения, все описания систем, которые делают
люди, в конечном счёте привязывались бы к воплощениям систем, то мы не имели
бы возможность проверить, об одном и том же говорят люди, или о разном. Более

58
Подробней эта история и многие другие положения этого раздела рассказаны в книге Chris Partridge
«Business Objects: Re-Engineering for Re-Use», http://www.brunel.ac.uk/~cssrcsp/BusObj.pdf
 55

того, были бы огромные проблемы с проверкой того, говорят ли люди о реальном

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

Отношение состава
Главные отношения в системах (воплощениях систем) — это отношение «часть-
целое» (part of), они же отношения состава/сборки (composition). Инженеры
часто говорят об этом как о разбиении (breakdown) системы.
Крыло и фюзеляж — части самолёта, топливный насос — часть двигателя. Крыло
(все молекулы крыла) занимают часть всего объёма самолёта, то есть часть
занимаемого им места в физическом мире/пространстве-времени, топливный насос
занимает часть двигателя (все молекулы топливного насоса являются частью
молекул двигателя — молекулы же определяются как такие маленькие места в
физическом мире. Если речь пойдёт о каких-нибудь нанопокрытиях толщиной в
пару молекул, можно повторить рассуждение, перейдя к каким-нибудь кваркам —
нюансы с квантовой неопределённостью тут неважны, важен принцип
рассуждения).
Если принять, что все системы существуют не просто в физическом пространстве,
но в пространстве-времени, то весь разговор о разных состояниях системы или её
разных ролях превращается в разговор о частях во времени. Например, яйцо
является просто частью бабочки во времени — пока бабочка проходит стадию
«яйцо», никакой другой «бабочки» в мире, которая занимает место яйца в
физическом мире, нет.
Тем самым с состояниями системы или её ролями (те состояния/периоды времени,
когда система выполняет какую-то роль) можно работать как с отдельными
объектами, они могут получать отдельные имена. Бабочка на стадии «яйцо»
называется «яйцо». Пётр Сидорович в состоянии болезни называется «пациент». И
«пациент» тут просто роль/состояние Петра Сидоровича.
Удобно представлять воплощения системы эдакими «червяками» во времени, в
которых их место в физическом мире проходит какую-то траекторию во
времени/«развёртку во времени».
 56

При таком подходе события — это трёхмерные «срезы» системы на какой-то момент
времени, эдакие трёхмерные фотографии. До события было одно состояние/роль
системы, а после события — другое состояние/роль. Кроме того, сама система
появляется в какой-то момент времени, а в какой-то момент времени она
исчезает. Спортсменка на фотографии проходит разные события (отрыв от земли,
приземление), определяемые её позами в эти моменты времени. Эти позы, как
«трёхмерные фотографии» и есть события, разделяющие разные состояния
«сальто», «подготовки к сальто», «выравнивание после приземления».
Например, в позном беге59событием является «поза бега» — всё тело бегуна в
определённый момент времени. «Поза бега» является ключевой для правильного
бега, весь бег оказывается основан на событии принятия правильной позы.

Описания очень сложных систем (от микропроцессоров с их диаграммами состояний

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

59
http://grushnitskiy.ru/literature/books/Poznyi_774_metod_bega_-_Nikolai_774_Romanov_2013.pdf
60
https://en.wikipedia.org/wiki/Event_Storming
 57

то рассматривают их в контексте таких больших отрезков времени, на которых

длительностью самого сложного события можно пренебречь. Так, говоря о
созревании помидоров, можно выделить сам помидор как целое, и три его полных
части во времени/состояния — зелёный помидор, событие покраснения
(превращения зелёного помидора в красный) и красный помидор. В большинстве
случаев при разговоре про помидор можно пренебречь временем события
покраснения помидора и всеми промежуточными при этом состояниями, оно тут
просто не принимается в расчёт: нас интересует зелёное и красное состояния
помидора, объекты «зелёный помидор» и «красный помидор», а вот
«промежуточный помидор» нас не интересует, поэтому мы считаем это просто
событием.
Вот диаграмма пространства-времени (space-time map) из книги Chris Partridge
«Business Objects: Re-Engineering for Re-Use»61, которая это иллюстрирует:

Все три измерения пространства на этой диаграмме показывают на одной оси, а

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

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

61
http://www.brunel.ac.uk/~cssrcsp/BusObj.pdf
 58

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

Работы и действия
Состояния системы меняются, и рассмотрение частей и целых материальных
объектов даёт возможность говорить об изменениях — то есть обсуждать
изменения/действия/процессы/работы/процедуры/activities просто как наборы
взаимодействующих систем/воплощений_систем/вещей-в-физическом-мире в
качестве частей целого изменения/процесса. Процесс называется обычно глаголом
или отглагольным существительным (тут много нюансов, но мы обсудим это во
второй половине книжки). «Забивание гвоздя» при этом легко представить просто
как перечисление предметов,
участвующих/взаимодействующих/взаимоизменяющих свои характеристики в
период времени, соответствующий этому забиванию — т.е. «Забивание гвоздя
состоит из гвоздя, молотка, доски, плотника». А отношение участия (participation)
в изменениях/действиях/процессах/процедурах/activities — это просто
специализация отношения состава (composition, part_of).
Очень трудно обнаружить «процесс забивания гвоздя», но очень легко обнаружить
гвоздь, молоток, доску, плотника. Чуть сложней обнаружить их, если роль молотка
исполняет камень, а роль доски играет стена, а роль плотника играете вы сами (и
 59

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

.
Во многих графических языках моделирования стрелочки с ромбиками на конце
как раз означают отношение состава, причём целое там, где ромбик, а часть — где
ромбика нет. Жёлтый «шеврон вбок» это стилизованная стрелка, означает, что что-
то меняется во времени, им обозначен «процесс». А голубые кружочки означают
физические предметы, участвующие в этом процессе. Голубые кружочки — это
части процесса.
Так, конкретное исполнение (экземпляр, процесс) "танца" в какой-то момент
времени начинает существовать, а в какой-то момент времени прекращает
существование — процессы не вечны, как и любые физические объекты. Танец тут
является целой системой и включает в себя на время его исполнения всех танцоров
(людей, исполняющих роль танцора, в состоянии «танцор» от начала до конца
танца), поддерживающий их фрагмент четырёхмерного пола (доски, играющие роль
пола на время существования помещения), и ещё объем воздуха с колебаниями в
нём, ибо в этих колебаниях — музыка для танца. Так что инженер, который думает
о танце таким образом, может подумать и об источнике колебаний воздуха, и
включить в состав танца плеер (смартфон в роли плеера) и аудиосистему (роль
аудиосистемы может играть или стационарные усилители и аудиоколонки клуба,
или портативная акустика).
Танец — это процесс/действие/activity, но мы можем думать о нём примерно так же,
как о «станке», «автомобиле», «отверстии». И уточнять, что такое «танец» можно,
давая примеры его воплощений, а не обращаясь к определениям (что часто
приводит к длительным и бесплодным «спорам о терминах»). О самых разных
предметах (включая процессы!) можно думать более-менее одинаково, и это сильно
экономит мышление.
По танцу тем самым, как и любой другой системе можно условно «постучать», его
можно «положить в тачку», на него можно условно «показать пальцем» — просто
это происходит с физическими вещами-частями танца, в нём участвующими.
Условность заключается в том, что физические объекты в системах могут быть
недоступны, слишком маленькими, слишком горячими — это неважно, речь идёт
просто о том, что мы говорим о физическом мире, обсуждаем что-то воплощённое,
а не абстрактное/идеальное/информационное. Условность с процессами тут в том,
что в нём участвует много самых разных частей, и трудно представить, как вы
«стучите» по ним всем в ходе их взаимодействия. Просто нужно понимать, что все
 60

эти самые разные меняющиеся физические/материальные объекты присутствуют в

физическом мире, это не описания и не документация. Процессы физичны, а
системы-процессы мало отличаются в их рассмотрении от систем-вещей (и
наоборот тоже верно: системы-вещи мало отличаются в их рассмотрении от систем-
процессов, они же себя как-то ведут в их взаимодействии со своим окружением, или
в них как-то себя ведут их части во взаимодействии друг с другом).
Даже по деятельности предприятия можно «постучать». Хотя деятельность
предприятия много сложней танца, но по большому счёту не так уж от танца и
отличается, там взаимодействуют в ходе этой деятельности люди, оборудование,
здания и сооружения, сырьё и полуфабрикаты. Вот по ним и можно постучать.
Предприятие существует в нашем мире. Несмотря на его процессный характер,
можно с ним работать как с «вещью», хотя и состоящей из очень многих других
вещей, участвующих в его деятельности.
Системы (в том числе процессы, в том числе и работы) какого-то предприятия, и в
том числе оргпроцессы62 предприятия тем самым становятся вполне
«физичными», неабстрактными, имеющими пространственно-временную
протяжённость, их легко представить, их легко обнаружить по их описаниям, их
легко описывать. Для начала нужно просто перечислить входящие в оргпроцесс
физические объекты — и сразу станет понятно, одинаково ли вы понимаете этот
оргпроцесс с другими людьми на предприятии. Но нельзя «подводить под
определение», нельзя определять оргпроцессы через задание для них каких-то
классов операций/процедур, это только приведёт к спору о терминах. И нельзя
считать регламенты оргпроцессов ими самими: регламенты только описывают
процесс! «Постучать» по регламенту (на экране, или бумаге, или даже по
компьютерной памяти) нельзя, но можно постучать по регламенту-на-носителе, по
документу регламента, процессной документации. И это постучать по совсем
другому объекту, чем оргпроцесс/работа, определяемые регламентом.
Мы часто будем приводить в качестве примера системы танец — танцы имеют
процессную природу, они не такие тривиальные для мышления, как насосы или
автомобили. Но танцы всё ещё много проще предприятия, поэтому думать о танцах
проще, чем о предприятии. И совсем недаром одна из классических (год выпуска —
1999) книг Peter Senge по системному мышлению для предприятий называется
«Танец перемен»63.

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

62
Мы вслед за ISO 29148 рекомендуем говорить не «бизнес-процессы» (business process), а
«организационные процессы» (organizational processes), оргпроцессы.
63
https://www.ozon.ru/context/detail/id/1378492/
 61

вычисления. Эти процессы в компьютере занимают какое-то место в физическом

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

Ещё раз подчеркнём: программу следует считать воплощением системы только в

тот момент, когда она реально запущена на исполнение и работает, делает то, ради
чего она была написана. Это довольно контринтуитивно, но исходный код
программы — это не программа, но только описание программы;
исходный код программы в системе управления версиями или просто в
файле на носителе — это только документация программы. Программа —
это то, что отражает состояние программы в момент её исполнения.
Поэтому программисты, которые считают, что их инженерная работа закончена в
момент написания исходного кода — эти программисты глубоко неправы, и это
типичная ошибка. Из признания этой ошибки появилось целое движение
DevOps64 — программисты признали, что они должны выполнять роль не только
разработчиков кода программы (Development), но и сопровождением работы
программы на рабочих серверах (Operations).
Исходный код — это описание программы (оно делается в классах, как любое
проектирование, один исходный код описывает множество возможных экземпляров
программы), и перед использованием программы её нужно изготовить:
откомпилировать, собрать, разместить в оперативной памяти нужного компьютера
(возможно, перед этим оформив в какой-то контейнер) и передать на неё
управление.
Тем самым программа как система — это процесс, и нас интересует именно тот
процесс, который выполняется на правильном компьютере (или компьютерах —
например, клиентском и в облаке), в тот момент, когда программа работает и
выполняет свою функцию, своё назначение. Понятно, что от исходного кода до вот
так работающей программы обычно долгий путь.
Ошибка, которую делают программисты, считая свой исходный код программой,
ровно того же сорта, которую проектировщики и конструкторы делают, считая
своей системой разрабатываемые ими информационные модели (а раньше —
чертежи) и другую проектную и конструкторскую документацию. Карта не
территория, меню не едят, на чертежах не летают, исходный код не хранит
значений своих переменных в ходе исполнения65.

64
https://en.wikipedia.org/wiki/DevOps
65
Тут есть нюанс, связанный с фон-неймановской архитектурой: программа может быть рассмотрена как
данные на носителе, и как исполняемый объект. То же относится к «программе в мозге»: лежит ли в мозге в
его нейронах только описание, или же нейронная сеть сейчас именно «вычисляет» что-то, то есть там
 62

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

Как найти настоящую целевую систему, которую изготавливают программисты в

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

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

(создаваться, уничтожаться). Это деловая поездка. Да, деловая поездка — это

процесс/работа, но вполне понятно, как её описать и учесть в компьютере. Для
этого просто нужно учесть все входящие в деловую поездку (отношение
участия/части-целого/состава) объекты — людей в роли командированных, билеты
(проездные документы, с разными нюансами отношения к носителям для этих
документов) и т.д. Если речь идёт о программе для станка с ЧПУ, то целевая
система — это описываемая данными этой программы деталь. Программа же
описывает работы станка, а станок нужен для получения детали. Цель — деталь,
деньги от неё, а всё остальное только цепочка, приводящая к этой цели. Так что с
программами как целевыми системами нужно быть осторожными. Это мы будем
обсуждать подробней, когда будем обсуждать целевые системы проекта.
Ещё лет двадцать назад считалось, что мир захватят сложные алгоритмы, которые
будут хитро перерабатывать относительно простые данные. Оказалось, что
современное программное обеспечение сдвигается в сторону работы со сложными
данными, при этом алгоритмы работы с этими данными относительно просты и
единообразно устроены. А поскольку сложность из алгоритмов перемещается в
данные, то системным подходом начинают интересоваться не только инженеры-
программисты, но и инженеры данных. Никогда не нужно забывать, что данные —
это в конечном итоге описания каких-то систем, но в момент их обработки какой-то
программой они сами становятся частью системы этой программы, «вещью». То есть
данные для обработки их программой тоже нужно «изготовить» из первичных
описаний. И когда мы интересуемся, как получить из данных полезный результат,
то как и в случае программ мы должны научиться их изготавливать из исходных
данных — и мы по аналогии с DevOps будем говорить о DataOps66.
Системное мышление тем самым нужно как программистам, так и специалистам по
обработке данных: в силу углубления разделения труда это уже не одно и тоже, а
системное мышление поможет этим специалистам договориться между собой, а
также с менеджерами и другими сотрудниками предприятий, для которых они
работают. Программные системы (в момент работы программ), системы данных (в
момент использования данных) — всё это системы, в мире софта системное
мышление применимо не меньше, чем в мире железных систем, или
организационных систем.
А что же с людьми, которые работают с программами? Очень часто целевой
системой будет какая-нибудь часть организации, которая должна выполнить какое-
то дело — выдать кредит, начислить зарплату, изготовить деталь. И если окажется,
что программа работает правильно, но люди в организации не могут с ней работать,
то не будет засчитана за правильную и работа программы. Что толку в работе
программы по начислению зарплаты, если люди с ней не смогут сработать? Если
программисты хотят получить деньги за свою часть работы, они должны быть
уверены, что кто-то работает и с людьми, а сдаваться заказчику будет совместная
система из людей и программ (а также данных к этой программе, что может быть
отдельной проблемой и может требовать отдельных исполнителей). Системное
мышление заставляет об этом всём думать сразу, а не в момент неподписания актов
приёмки-сдачи по проекту «создания программного обеспечения». Обычно сами по
себе программы никому не нужны, они нужны только как части каких-то других
систем — и нужно убеждаться, что разработка идёт этих других систем в целом

66
https://en.wikipedia.org/wiki/Dataops
 64

прежде всего, а программ только как части этих систем.

3. Роли
Роли и действия
Системное мышление рассматривает системы как имеющие какое-то назначение в
своём окружении, то есть играющие какую-то внешнюю роль. Молоток играет роль
гвоздезабивального устройства. Эту роль может играть камень, может играть
микроскоп. Можно назвать систему, которая играет роль забивателя гвоздей
молотком — по её первичному назначению. Назначение — это поведение системы
в роли, действие. Действие — забивание гвоздей. Роль системы — забивать гвозди.
Система в роли — забивальщик гвоздей. Всё это об одном и том же, разве что
иногда нам нужно указать на действие (куда может входить не только сама система
в роли выполнителя действия, но и сопутствующие предметы — гвозди, доска,
плотник), а иногда на главный в этом действии объект-в-роли, систему. И чаще
всего (увы, но это так) при этом используется «аристотелевская физика», в роли
забивальщика гвоздя будет «активный объект» — молоток (или любой предмет,
назначенный на роль молотка), при игнорировании в этом взаимодействии
действий всех остальных предметов. Помним аристотелевскую физику? Когда палец
давит на стол, но стол не давит на палец? Роли очень часто рассматриваются ровно
так: ролевой объект действует на другой ролевой объект, а обратным действием
пренебрегают.
В какой-то мере это «анимизация» неживого мира, удобный способ думать о
неживых предметах так, как будто они живые — не в терминах ньютоновской
физики, а в терминах аристотелевской (где делятся предметы-участники действия
на «активные» и «пассивные», типа «молоток бьёт по гвоздю»). У этого способа
думать есть свои ограничения, но его нужно как минимум распознавать и понимать,
о чём идёт речь в таких случаях, как понимать подобные описания.
Одним из примеров такого подхода служит инженерный способ разработки
требований «сценарии использования» (use case, но автор Ivar Jacobsen
оговаривал, что в шведском языке, на котором он сначала предложил этот способ
разработки, вместо слова case использовалось слово «сценарий»). Сценарий — это
последовательность действий актёра/актора/actor, то есть активного действующего
предмета. Это может быть как человек (и в предлагаемом для описания сценариев
использования для описания актёра служит фигурка человека), так и вовсе не
человек, и даже неодушевлённый предмет — тот же молоток, который предлагается
активным элементом в последовательности действий, складывающихся в пьесу-
сценарий. Сценарии использования оказались очень удачны для описания
работы/процессов/последовательностей_действий/сценариев/поведения системы и
её частей. Этот способ описания стал повсеместным для инженеров, он приводит к
построению функциональных/ролевых описаний.
Термин «функция», как мы обсуждали в первом разделе, имеет множество самых
разных значений. Очень часто ролевое поведение/действие (поведение для какого-
то назначения) называют функцией. Так, могут говорить, что функция молотка —
забивание гвоздей.
Эта функция/ролевое поведение/действие ему назначена какими-то людьми, это не
сам молоток себе эту функцию назначил. Например, мы можем взять микроскоп и
 65

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

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

Функциональные объекты/роли интересны тем, что они могут исчезать из
физического мира и снова появляться совершенно другими — в тот момент, когда
у них появляется новый исполнитель роли. Колотилка исчезает, когда мы перестаём
использовать камень в этой роли, и вдруг появляется в виде микроскопа, когда мы
начинаем колотить микроскопом. Физичны ли функциональные объекты/роли? Да,
 66

физичны, хотя некоторые философы и настаивают, что роли нужно считать

абстрактными объектами, но инженеры и менеджеры прислушиваются к другим
философам, которые указывают, что большинство людей считает
функциональные/ролевые объекты существующими в тот момент, когда
какие-то физические объекты играют их роль.
Мы можем мыслить о Принце Гамлете, подразумевая что он существует в тот
момент, когда его роль играет один из актёров (например, известный артист
Василий Пупкин). По Принцу Гамлету в этот момент можно постучать, можно ткнуть
в него пальцем, он занимает место в пространстве-времени. А когда Принц Гамлет
идёт обедать? Ответ: никогда, ибо обедать идёт Василий Пупкин, а Принц Гамлет
во время обеда не существует — он прекращает в этот момент своё существование.
Можно вспомнить, что мы с разными именованиями или прочими
неопределённостями по поводу совпадений и различий объектов разбирались в
соответствии с предложением Декарта: нужно уходить от определений (прекращать
спор о терминах, названиях и т.д.) и обсуждать вопрос, какое место в пространстве
занимают обсуждаемые предметы. Роль и играющий её физический объект,
конечно, будут занимать одно и то же место в пространстве. При этом ролевой
объект может исчезнуть в любой момент, когда его роль закончится — когда
физический объект прекращает играть его роль. Физический же объект просто так
не уничтожишь — действует закон сохранения материи.
Например, я могу выделить в своей жизни (ролевой по отношению к моей жизни!)
объект «моя любимая игрушка» — это плюшевый мишка в период 40 лет назад,
игрушечный самолётик в период 30 лет назад и планшетный компьютер сегодня. А
в промежутках, может быть, мне было не до игр, и этот ролевой/функциональный
объект «моя любимая игрушка» в этот период вовсе не существовал. Физические
индивиды, играющие роль функционального объекта «моя любимая игрушка»
несколько раз менялись, а вот функция/действие/поведение «участвовать в моих
играх» оставалась той же. Моя любимая игрушка в тот момент, когда она
существует, вполне занимает место в пространстве — по ней можно постучать, её
можно понюхать, о ней можно говорить как о физически существующем предмете.
Но, конечно, вы будете стучать и нюхать физические объекты, играющие эту роль
в те или иные моменты. Если вы захотите понюхать Принца Гамлета, то вы унюхаете
только запах Васи Пупкина, играющего его роль. Или не унюхаете ничего, если Вася
Пупкин не будет играть эту роль. Но по факту запах Васи Пупкина и будет запахом
Принца Гамлета, как его внешний вид и будет видом Принца Гамлета, как играемая
им роль будет последовательностью действий Принца Гамлета.
Зачем нужны ролевые/функциональные объекты? Чтобы отделить выполнение
каких-то действий от объектов, выполняющих действия. Действий в мире не так
много (можно сравнить число их типов условно с числом глаголов в языке —
несколько десятков тысяч), а вот объектов, пригодных для действий (как и
существительных, которых в языке сотни тысяч) — огромное разнообразие.
Поэтому можно обсуждать деятельность «президента США» и накапливать знания
об этой деятельности — независимо от того, кто выполняет эту роль сейчас. Точно
так же можно по его роли выделить объект «водяной насос» и деятельность
«повышение давления» и дальше использовать или физический насос Муромского
завода в этой роли, или водонапорную башню. Рассуждение тут одно и то же про
«президента США» и про «водяной насос». Все ролевые/функциональные
рассуждения устроены абсолютно одинаково — и про людей, и про животных, и про
 67

системы искусственного интеллекта («нежить»), и про совсем уж неживые системы.

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

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

Много лет в системном подходе считалось, что системы как бы «объективны».
Скажем, самолёт — всем же понятно, что это за система, какое её
назначение/роль/функция! Или радиолокатор — никаких разногласий, зачем он
нужен и какое у него окружение! Или даже лабораторная мышь, которую изучают
биологи — её назначение не нужно обсуждать специально, правда ведь?!
Системный подход подавался как метод, которым в этой «объективно определённой
системе» можно отмоделировать самое важное — которое тоже представлялось
очевидным. Ничего субъективного, «чистая наука», вполне поддающаяся
формализации. И учебники системного подхода в его первом поколении легко было
распознать по обилию в них математики. Если в учебнике системного
мышления/подхода много формул — это верный признак, что это изложение
системного мышления не позже 70-х годов 20 века.
Но в конце семидесятых годов прошлого века системные мыслители обратили
внимание, что системами всегда занимаются люди. Это было связано главным
образом с тем, что в мире перешли от изучения самих по себе растущих
(биологических, «естественных») систем к системной инженерии — и тамошние
радиолокаторы и самолёты не росли сами по себе в лесу или поле, их приходилось
делать.
Именно люди задают системам роли/функции, которые они будут играть/выполнять
в своём окружении. Нет создающих систему людей — нет назначения поведения,
нет роли системы — нет системы, есть какой-то «просто объект», непонятно откуда
взявшийся (ибо его никто не задавал, никто на него не обратил внимания, никому
он не нужен для его деятельности, никто не может уточнить его границы, и любые
фантазийные описания такого объекта нельзя обсуждать). К системам, которые
никого не интересуют, системное мышление не применишь — просто некому будет
его применять! Оказывается, системы не «объективны», они субъективны! Их
определяют люди, которые по отношению к системам сами играют роли/выполняют
функции/осуществляют поведение.
Роль по участию (помощь или вред — от роли проекту системы или от проекта
системы этой роли) в каких-то проектах обеспечения замысливания, создания,
модификации, эксплуатации, уничтожения системы так и назвали «проектной
ролью» (stakeholders, roles, заинтересованные стороны, действующие лица) — люди
в деятельностно/культурно-обусловленных (то есть известных человечеству по
обычно выполняемым ими деятельностям) ролях, исполнение которых как-то
влияет на связанные с системой проекты.
Влияние тут в две стороны (люди в проектных ролях влияют на проект, и проект
влияет на людей в их проектных ролях — отход от аристотелевской физики, «палец
 68

давит на стол, и стол давит на палец»), хотя в первых вариантах системного

подхода 2.0 проектные роли учитывались только те, кто влиял на систему и
связанный с ней проект, причём влиял так сильно, что нельзя было этого не
учитывать (например, заказывал создание системы, платил за это создание — не
учтёшь такую роль, не будет денег на работы!). Позже поправились: те, на кого
влияет система и её проект тоже считаются проектными ролями —это не только те,
кто может наступить вам на ногу, но и кому на ногу наступаете (или можете
наступить) вы! Мышление в отношении людей в системном подходе стало более
«ньютоновским», менее «аристотелевским»: люди взаимодействуют, а не только
действуют!
Обычно проектные роли/стейкхолдеров/заинтересованных сторон в системах и их
проектах интересует целый ряд характеристик — и эти характеристики называют
ролевыми интересами (concern, «озабоченность», реже — interest, иногда даже
driver как «то, что важно»). Интересом могут быть стоимость, производительность,
ремонтопригодность, функции и фичи/возможности системы, сроки, безопасность и
так далее. Интересом может быть что угодно, любая характеристика
системы или проекта, типовая для многих проектов, или уникальная
только для этого проекта.
Обычно с системой связано много проектов, необязательно это один проект (в
одном проекте систему могут замыслить, в другом создать, в третьем изготовить, в
четвёртом эксплуатировать, потом перепродать, в пятом продолжать
эксплуатировать, потом в шестом модернизировать, в седьмом продолжать
эксплуатировать, в восьмом — ликвидировать). Проектная роль может быть в
любом из этих проектов, например, мы уже при замысливании и создании системы
учитываем проектные роли людей, которые будут потом систему эксплуатировать.
В системном мышлении регулярно мы думаем о будущем «как будто оно уже
существует», это нормально. Думать о том, как (главное, кем!) будет
эксплуатироваться система, которой ещё нет, которая едва-едва замыслена — это
нормально, это просто необходимо, с этого вообще нужно начинать думать о
системе! Если система не будет эксплуатироваться, то зачем её вообще делать?! А
если будет эксплуатироваться, то кем, какими проектными ролями? Имени
исполнителя роли не нужно, но саму роль нужно указать!
Разные роли имеют разные ролевые предпочтения/оценки интереса в достижении
предмета интереса. Если общий интерес проектных ролей покупателя и продавца —
цена, то ролевое предпочтение покупателя минимизации цены (если принята
терминология оценки интереса67: цена слишком высокая), предпочтение
продавца — поднять цену (оценка интереса: цена слишком низкая). Для
реализации/воплощения своих предпочтений в интересе проектные роли имеют
какие-то деятельностные намерения — и вот тут люди обычно очень
изобретательны, и могут запустить совсем неочевидную цепочку действий даже при
сугубо положительных предпочтениях (интерес: головная боль, предпочтение:
голова не должна болеть, намерение: отрубить голову — нет головы, не будет
головной боли).
Положительность проектных ролей необязательна. Просто предпочтения
«отрицательных героев» и «антиклиентов» учитываются в проектах с обратным

67
Assessment, элемент языка ArchiMate 3, http://pubs.opengroup.org/architecture/archimate3-
doc/chap06.html#_Toc489946014
 69

знаком — ворам не дают украсть, убийцам не дают убить, террористам не дают

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

68
Тут мы обращаемся к «прагматическому повороту» в философии,
https://plato.stanford.edu/entries/pragmatism/
 70

не проектные роли. Проектные роли — деятели! Собаки лают, а караван идёт:

собаки тут не проектные роли. А вот если купец не оплатит проход каравана, то
караван идти не будет. Купец — проектная роль, он занимает деятельностную
активную позицию по отношению к каравану.
Граница системы — это граница места в физическом мире, которое занимает
система. Она определяет, какие части входят в систему, а какие не входят в систему.
Вот эта граница системы прежде всего и определяется командой людей, играющих
проектные роли создателей системы (инженеры, менеджеры, предприниматели).
Внутренние проектные роли — это проектные роли, которые играет команда
проекта, а внешние роли — все остальные, прежде всего заботящиеся о внешних
по отношению к границе целевой системы системах. Команда проекта определяет,
что (какие части) в целевой системе нужно, а что (какие части) не нужно иметь,
чтобы система могла выполнить свою роль/функцию/назначение в окружении и не
стоила при этом запредельно дорого (больше, чем могут заплатить за её создание
внешние роли). А внешние проектные роли/стейкхолдеры определяют
роли/функции/назначение системы в её окружении (обычно это инженеры,
менеджеры, предприниматели из организации-заказчика, но и многие другие —
регуляторы, представители широкой публики, и даже хакеры, воры, террористы).
Все исполняющие эти внутренние и внешние проектные роли люди (а хоть и каждый
человек будет исполнять несколько ролей, или одну роль будет играть несколько
человек) проявляют находчивость и изобретательность в этом вопросе — исходя
каждый из своих предпочтений в интересах. Система в глазах смотрящего: если
никто не смотрит, т.е. ни в чьей деятельности система не нужна, то и нет системы,
нет её границы, нет назначенного/ролевого поведения/функции. Система
субъективна. Одни люди в одних ролях определяют её одним способом, а в других
ролях те же люди вполне могут определить её другим способом, в других границах,
требовать другого назначения системы. И это нормально, тут нет никаких
противоречий. Это просто начальный этап коллективной деятельности: всем
проектным ролям нужно прежде всего договориться о том, какова же
система, которую мы замышляем, создаём, эксплуатируем,
модифицируем, ликвидируем. Никакие призывы к «объективности» тут не
помогут, придётся договариваться с учётом того, что интересы у проектных ролей
обычно общие, а вот предпочтения в интересах — разные. Одному нужно, чтобы
система ездила побыстрее (интерес: скорость, предпочтение: побыстрее), другому
нужно, чтобы система была полегче (интерес: вес, предпочтение: полегче). Первый
имеет намерение оборудовать систему мощным аккумулятором, который имеет
большой вес — и второй понимает, что ему нужно срочно действовать, чтобы этого
не случилось! Они начинают договариваться, чтобы реализовать их предпочтения.
Успешность системы определяется сегодня не «объективно», а
субъективно — по удовлетворению потребностей (needs) заказчиков,
пользователей и других проектных ролей/стейкхолдеров69. Люди,
играющие самые разные роли по отношению к системе и проекту по её созданию,
должны быть довольны — успех в этом. Нельзя узнать про успех системы, глядючи
только на саму систему. Как система (её границы!) так и её успех — в глазах
смотрящего. Разные люди и даже одни и те же люди (в разных проектных ролях!)

69
http://sebokwiki.org/wiki/Systems_Engineering_Overview — Systems engineering (SE) is an interdisciplinary
approach and means to enable the realization of successful systems. Successful systems must satisfy the needs of
their customers, users and other stakeholders.
 71

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

70
Высказывание Г.П.Щедровицкого.
 72

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

делать в проекте инженер? Что должен делать в проекте менеджер? Если не
представляете, то вам явно нужно иметь деятельностный кругозор — он как раз
даёт об этом представление! Проектные роли явно не занимаются в проектах чем
хотят! Они, конечно, импровизируют — но их импровизация похожа на
импровизацию актёров в театре: чтобы они ни делали, но в конечном итоге
оказывается, что эти действия как-то обусловлены их ролью, не полностью
выдуманы, они не могут быть «любыми». Если вам кажется, что инженер неправ в
своих предпочтениях, то вы будете добиваться замены исполнителя этой роли — и
совсем неудивительно будет обнаружить, что покладистый новый исполнитель
роли, разобравшись в новом для себя проекте, вдруг выскажет те же интересы и те
же в них предпочтения, что и предыдущий исполнитель роли инженера! Роль
оказывается важнее исполнителя!
О деятельностях мы думаем «в классах/типах», деятельностями занимаются классы
людей в их ролях в этой деятельности — люди в ролях инженеров, художников,
воспитателей детских садов, любовников, космонавтов, учителей, спортсменов.
Пока они занимаются этой деятельностью, они играют эти роли, и в них реализуют
свои предпочтения в интересах. Когда эти люди занимаются другими
деятельностями, они играют другие роли, проявляют другие ролевые интересы и
реализуют другие ролевые предпочтения.
Всё это и будут проектные роли/стейкхолдеры, если они имеют интересы и
предпочтения в отношении вашего проекта по созданию/изменению/уничтожению
системы, или к вашей системе и в связи с этими предпочтениями начнут
реализовывать свои намерения изменить мир так, чтобы их предпочтения
реализовались.
Так что проектная роль/стейкхолдер — это не конкретный человек, это типовая
(культурно-обусловленная, которая обычно известна другим людям «из культуры»,
из их деятельностного кругозора), роль, которую играют люди, выполняя типовые
действия с типовыми инструментами, типовыми рабочими продуктами, преследуя
типовые предпочтения в типовых интересах.
Этот поворот от «объективности научного мира» к «субъективности
деятельностного мира» и обращение к стейкхолдерам произошёл в мире примерно
в 1975-1985 годах. В СССР как раз начались гласность и перестройка, из системных
мыслителей на эту тему в те времена говорили представители
системнометодологического движения (последователи Г.П.Щедровицкого 71), в их
языке использовалось очень близкое к проектной роли/стейкхолдеру понятие
«позиция» и они первые начали говорить о том, что привнесение деятельностной
субъективности в системное движение через понятие проектной
роли/стейкхолдера/позиционера означает появление нового, второго поколения
системного подхода. В современной терминологии можно было бы говорить о
системном подходе 2.0.
Вот график частоты упоминания слова «стейкхолдер» в библиотеке англоязычных
книг Гугля72, и это примерно отражает распространение системного подхода в его
второй версии (прежде всего в литературе по проектному управлению, а затем в

71
https://ru.wikipedia.org/wiki/Щедровицкий,_Георгий_Петрович
72
https://books.google.com/ngrams/graph?content=stakeholder&year_start=1950&year_end=2008&corpus=15&
direct_url=t1%3B%2Cstakeholder%3B%2Cc0
 73

системной инженерии):

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

73
http://progstone.narod.ru/reciprocality/r0/index.html
 74

Действующие лица — это вдумчивый Принц Гамлет и безумная Офелия. У них есть
своё назначение в пьесе, это ролевые/функциональные объекты.
Исполнители — это весёлый актёр-стажёр Вася Пупкин в утренних спектаклях и
мрачный народный артист Василий Петрович Черезколеноногузадерищенский в
вечерних спектаклях оба играющие Принца Гамлета, плюс педантичная Елена
Ефимовна во всех спектаклях, и она не болеет и не замещается. Исполнители —
физические объекты, это люди, играющие роли в пьесе-проекте.
Ролевые/функциональные и физические объекты, которые занимают в
пространстве-времени одно и то же место — по Декарту это один и тот же объект.
Так что на момент исполнения роли Принц Гамлет и Вася Пупкин — это один и тот
же объект. Но мы их всё-таки не должны путать: Принц Гамлет существует только
во время спектакля, когда Вася Пупкин играет его роль. А Вася Пупкин существует
независимо от этого, и нас мало волнует Вася Пупкин, когда он чихает или звонит
по телефону подруге — это не Принц Гамлет чихает и звонит по телефону, это Вася
Пупкин в других ролях!
У Принца Гамлета (у роли!) свои интересы — его волнует вопрос «быть, или не
быть!». И у него есть предпочтение больше «быть», чем «не быть». Он действует,
исходя из этого предпочтения. Принц Гамлет действует, а не Вася Пупкин, и не
Василий Петрович Черезколеноногузадерищенский. Действуют не люди, а люди-в-
ролях, действуют проектные роли/стейкхолдеры! А люди? Они действуют, играя
роли, и только играя роли! Если Вася Пупкин заболел, то это не Принц Гамлет
заболел, но это Вася Пупкин стал играть роль пациента в проекте его лечения. И
лечат пациента (Васю Пупкина, играющего роль пациента), а не Принца Гамлета.
«Пациент» — это имя роли в пьесе/типе проекта «лечение»!
В системном мышлении, когда говорим о ролях, то всегда имеем в виду
действующее лицо — Принца Гамлета, роль, функциональный объект. Поведение
 75

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

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

Конечно, в реальной жизни мы непосредственно видим в первую очередь
исполнителей — конкретных актёров-людей, а не «роли». Но обсуждаем по ходу
пьесы мы исключительно роли, если только речь не идёт о качестве исполнения!
Кто говорит фразу «быть или не быть?». Принц Гамлет, или Вася Пупкин? На момент
исполнения роли оба они — один и тот же объект, только называются по-разному
и мы обращаем в зависимости от этого внимание на разные свойства этого объекта.
Когда речь идёт о «действующем лице», то мы обращаем внимание на текст и сюжет
пьесы (деятельности/практики — ситуативный контекст в проекте), а когда речь
идёт об «исполнителе», то на качество исполнения и доступность исполнителя в
момент спектакля.
Мы всегда можем указать Васе Пупкину, что он плохо выучил роль, или играет
чужую роль и всяко по-другому дать понять, что «ты не прав, Вася», если нам
известна пьеса, которую он играет. Если пьеса неизвестна, то мы не можем
понять — прав, или не прав Вася в своих действиях.
Поэтому системное мышление требует кругозора — минимального
понимания, как устроены деятельности/практики/пьесы инженера,
менеджера, предпринимателя и других укрупнённых ролей в разных
сферах деятельности. А.Тюков в 1997 году выделял такие сферы деятельности:
политика, религия, философия, искусство, наука, образование, здравоохранение,
физкультура и спорт, технология, проектирование, коммерция, финансы, право,
армия, материальное производство и "пока не оформившееся просвещение" 74 Нет
кругозора — нет системного мышления, ибо оно трансдисциплинарно, оно призвано
объединять ролевые мышления для этих отдельных сфер деятельности.
Мы рекомендуем иметь кругозорное знание хотя бы о следующих
деятельностях/практиках современного инженерного, менеджерского,
предпринимательского мира:
• системная инженерия (разработка концепции использования, инженерия
требований, инженерия системной архитектуры, управление конфигурацией
и изменениями/жизненным циклом, проверка и приёмка)

74
http://psyhoinfo.ru/programma-sozdaniya-obshchestvennoy-professionalnoy-sfery-prosveshcheniya
 76

• системный менеджмент (операционный менеджмент/цепи

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

половина дела. После понимания нужно ещё и действовать (стать синтетиком, а не

аналитиком), представляя свой ролевой интерес и ролевое предпочтение и
проявляя в деятельности ролевое намерение добиться своих целей реализации
предпочтений. Конечно, у вас может быть множество ролей (особенно в маленьких
проектах, где вечно «театр одного актёра»), но лучше бы маркировать и для себя,
и для окружающих, когда вы переходите из одной роли в другую. Это нужно
тренировать75.
Трудностей тут множество. Например, когда на вас орут, то просто невозможно
сосредоточиться — видишь только человека-исполнителя и его к тебе отношение.
Но это «невозможно сосредоточиться» лишь означает, что вы близки к
мыслительной ошибке: вы перестали мыслить системно, вернулись к мышлению
дикаря, которого ведут эмоции — видите в людях только исполнителей, не
учитываете знаний цивилизации о деятельностях и ролях в них. Вы теряете
деятельностный кругозор, вы не можете вписать ваши ролевые компетенции в тех
или иных деятельностях, вы не можете учесть ваш ролевой интерес и реализовать
ролевое предпочтение в этом интересе из-за того, что вы не замечаете ролевых
интересов и не понимаете ролевых предпочтений людей-как-стейхолдеров, людей-
в-ролях.
Важно, чтобы в проекте все обсуждения проходили в терминах «действующих лиц»,
а не исполнителей. Сравните два диалога:
1. «Исполнительское» обсуждение, в терминах персоналий:
— Иванов опять чертежи испортил! Он присылает их в формате .dwg и ссылается
на Петрова! Сидорова не может работать!
— А что думает об этом «Красшефмонтаж»?
— Его не волнует, лишь бы «Заготбазарбаза» не возражала!
Всё ли вам понятно, если вы случайно попали на совещание? Можно ли задать
какие-то уточняющие вопросы по непониманию — и какие? Если вы хорошо знаете
всех действующих лиц, то можете ли вы предсказать хоть как-то их предполагаемые
реакции в данной ситуации?
2. Ролевое обсуждение («действующих лиц», в терминах
ролей/стейкхолдеров/интересантов):
— Конструктор опять чертежи испортил! Он присылает их в формате .dwg и
ссылается на расчётчика! Архив не может работать!
— А что думает об этом технолог завода-изготовителя?
— Его не волнует, лишь бы поставщик корпусов не возражал!
Стало ли понятней, о чём идёт речь? Какие уточняющие вопросы вы бы задали?
Вот ещё пример, где мы назовём исполнителя по его должности, а не по роли:
-- Старший программист: когда я вчера смотрела на график нашего проекта, то
поняла, что нам может не хватить времени на тестирование, поэтому неплохо бы
озаботиться контрактацией дополнительных серверов для этой работы.
Варианты продолжения беседы (какой выберете?):

75
Доклад по стейкхолдерскому мастерству: https://ailev.livejournal.com/1466773.html
 78

• Инженерный: какие ошибки требуют дополнительных серверов для их

тестирования? Можем ли мы уменьшить объём тестирования? [и оцените
вероятность, что «старший программист» не подумала об этих вопросах,
когда делала своё заявление]
• Менеджерский: у нас предусмотрено это бюджетом, или как всегда? У вас
есть проект контракта? Кто найдёт поставщика? [и оцените вероятность, что
«старший программист» на самом деле не знает ответов на эти вопросы]
Можно ли верить, что «старший программист» желает обсудить инженерные
аспекты дела, она и вправду выступила как программист? Или она выступила как
менеджер?
Вы бы сами какую линию разговора повели: чем бы озаботились, о чём спросили?
Как кто бы вы поступили в этом разговоре (какую бы компетенцию вытащили в
качестве основной?).
Вспомните, когда последний раз в разговоре вы проводили такой ролевой анализ
«кто и о чём говорит — кто и о чём должен ему отвечать»?
Отслеживаете ли вы смену предметов разговора (смену интересов в обсуждении)?
Не означает ли это для вас, что люди поменяли роли, или вытащили для обсуждения
свой другой интерес? Как долго можете удерживать внимание на диалоге — в
любой момент понимая «кто (какая роль) говорит — кто (какая роль) отвечает —
предмет обсуждения/интерес, какие предпочтения в интересе у ролей (не у
исполнителей ролей)»?
Обсуждение в терминах «действующих лиц» (понимание проектных
ролей/стейкхолдеров как ролевых/функциональных «деятелей», а не конкретных
личностей-исполнителей, физических объектов-людей) крайне важно для
коммуникации: такое обсуждение направляет мысль и позволяет понимать, какие
«пьесы» сейчас обсуждаются — какие реплики могли бы следовать, а не только
какие реплики следуют прямо сейчас. Если какой-то Принц Гамлет вдруг начинает
давать реплики Офелии — то можно дальше обсуждать: спасает ли он пьесу ввиду
неявки Офелии, или просто портит дело как некомпетентный актёр-исполнитель и
нужно немедленно его заменить в роли Гамлета, уволить из спектакля и назначить
на роль другого актёра, более грамотного в своей роли или хотя бы более
внимательного.
Когда идёт деятельность, то людей лучше называть по их проектным ролям, а не
по фамилиям или названиям организаций. Самый тяжёлый случай, это когда люди
в проекте знают важность какого-нибудь Василия Петровича (он точно какой-то
стейкхолдер! Он существенно влияет на проект!), но не могут назвать его
деятельностную роль в проекте, не понимают какую именно практику/деятельность
он выполняет, не понимают его ролевых интересов и его ролевых предпочтений,
он поэтому его намерения для них «невычислимы», они не знают, что от него
ожидать, как реагировать на его действия.

Интересы и предпочтения
В конечном итоге нас интересуют даже не сами роли, а их ролевые интересы
(concerns, системные интересы, деятельностные интересы) — это какие-то
характеристики/свойства системы, темы интереса, на которые обращают внимание
роли/которые интересны ролям в связи с их деятельностью/практикой и ситуацию
 79

с которыми они имеют намерение изменить в какую-то сторону для реализации

предпочтений в этих интересах.
Интересом может быть всё что угодно. 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).
Темы интересов определяют вопросы ролей: их интересует прогноз развития
ситуации на предмет реализации их предпочтений. Это не вопросы исполнителей,
это вопросы ролей/стейкхолдеров/действующих лиц! Не вопросы Васи Пупкина,
вопросы Принца Гамлета — интересы и предпочтения ролевые, а намерения могут
использовать средства, далеко выходящие за пределы роли (например,
исполнитель роли может неожиданно позвонить своему другу-начальнику
исполнителя другой роли, и попросить «надавить» на этого исполнителя, чтобы
было реализовано его предпочтение в каком-то интересе, а не предпочтение той
другой роли! Чистая импровизация, никто не сказал, что реализовывать свои
предпочтения люди будут, просто заявляя о них на совещаниях. Нет, люди очень
изобретательны, когда реализуют свои намерения по реализации предпочтений).
Интересы и предпочтения ролевые, то есть действующих лиц, а не исполнителей!
Так что системному мыслителю нужно уметь поддерживать разговор на темы
ролевых интересов, давать для каждой роли ответы по этим темам достаточные,
чтобы роль могла оценить реализуемость своих предпочтений (нужны подробные
модели — ибо много ролей будут интересоваться одним и тем же, только
предпочтения у них будут разные. Например, если интерес в цене уникальной
системы, то нужен какой-то вариант сметы — её будут изучать и продавец, и
покупатель. Смета будет их основным коммуникационным инструментом для
достижения договорённости по их совершенно разным предпочтениям.
Если вы встретили человека, у которого нет ярко выраженного интереса
(интересуется всем подряд, или не интересуется вообще, не имеет ярко
выраженных предпочтений) — значит это не исполнитель роли в проекте, не
стейкхолдер, не заинтересованное лицо, а кто-то просто «любопытненький», «из
статистов», «проходящий мимо зевака», случайно зашедший на сцену во время
 80

спектакля зритель.
Если роль (Принц Гамлет!) беседует о чём-то, что не входит в его деятельностный
интерес, то вы беседуете в этот момент с «актёром» (возможно, играющим какую-
то другую роль в данный момент, вам неизвестную), а не с действующим лицом
вашей «пьесы», вашей деятельности. Для того, чтобы надёжно различать людей в
их различных ролях и определять интересы и намерения этих ролей, нужно иметь
деятельностный кругозор — в общих чертах представлять, как устроена
человеческая деятельность с разделением труда по сферам деятельности
(инженерия, менеджмент, предпринимательство и др.), какие практики есть в
каждой деятельности (в системной инженерии, например — практики инженерии
требований, инженерии системной архитектуры и т.д.), и какие интересы есть и
какие намерения хотят реализовать роли людей в этих практиках.
Слово «интерес» в английском будет interest, это тот самый «коммерческий
интерес», деятельный интерес, предмет заинтересованности. В системном
мышлении просто договорились называть interest немного другим словом:
concern76, что на русском в более точном переводе звучит как «озабоченность»,
деятельный интерес. Интересы — это предметы постоянного внимания ролей в
проекте. На темы своих интересов они постоянно задают вопросы, описывают
систему так, чтобы иметь внятные ответы на эти вопросы и даже предпринимают
действия, чтобы реализовать свои предпочтения по теме интересов. Они
действительно озабочены каким-то предметом, в их мышлении главенствуют эти
деятельностные «озабоченности», concerns — и они действуют исходя из
намерения реализовать свои предпочтения в интересах.
Каждая проектная роль в зависимости от своей функции/роли в деятельности имеет
один или больше интересов — при этом вполне возможно, что разные проектные
роли/стейкхолдеры имеют одни и те же интересы и одни и те же, или разные
предпочтения. Это очень удобно: если даже у одного стейкхолдера два-три-пять
интересов, то общий список этих интересов не будет вдвое или впятеро длинней
списка стейкхолдеров. Если нужно готовить для уторговывания
предпочтений в интересах какие-то материалы (модели), то их число
будет пропорционально числу интересов (а не числу предпочтений, не
числу проектных ролей).
Но при одинаковых интересах предпочтения в предметной области интереса
для разных ролей могут крайне различаться: если встречаются роли «покупатель»
и «продавец», то их интересом наверняка будет «стоимость», а вот
предпочтения/оценки интереса будут разниться: для одного стоимость нужно будет
максимально опустить, а для другого максимально поднять. Конечно, совсем
необязательно появление пары ролей с такими разными предпочтениями для
одного интереса, но такие пары встречаются не так уж и редко (при этом если обе
проектные роли с конфликтующими намерениями по одному интересу играет один
исполнитель, то говорят о конфликте интересов77).
Поэтому правильно говорить об интересе именно как теме, а не склеивать тему
интереса и связанные с этим интересом предпочтения и намерение что-то сделать
для реализации предпочтения. То есть не «интересом продавца является цена

76
Stakeholders have interests in a System; those interests are called Concerns — http://www.iso-
architecture.org/ieee-1471/cm/
77
https://en.wikipedia.org/wiki/Conflict_of_interest
 81

повыше», и «интересом покупателя является цена пониже», а «интересом продавца

и покупателя является цена», и уже потом только говорить о разных предпочтениях
(цена повыше или цена пониже) и намерениях что-то сделать для реализации
предпочтений. Интерес нам нужен, чтобы мы потом смогли сказать, как описывать
этот интерес — интерес оформляется/framed by методом описания
(viewpoint), например, метод описания цены может быть правилами составления
сметы, а может быть правилами указания произвольно определённой цены, но в
долларах или «условных единицах». Этот метод описания нужно будет
использовать, чтобы описанный при его помощи предмет интереса (цена) был
потом обсуждён разными ролями (продавцом и покупателем). Тем самым дискуссия
о методе описания цены (как моделировать цену, как лучше её описывать) будет
отличаться от дискуссии о самой цене, то есть о том, «как снизить цену» и «как
поднять цену», хотя обе эти дискуссии оказываются существенно связанными
(выбор метода описания обычно влияет на переговорную позицию одной из сторон:
разные методы описания интереса удобны для продвигания разных предпочтений).
И когда мы только что разделили одну сложную дискуссию по интересу на две более
простых (по методу описания и по уторговыванию предпочтений), задача стала
немного проще — это и есть цель системного мышления. Разделение ролей,
интересов, предпочтений упрощает достижение договорённостей между
ролями, облегчает коллективное выполнение проектов по созданию
систем.
Поэтому главное, для чего нам нужны роли — это для обнаружения их интересов и
предпочтений, и мы должны отвечать на их вопросы по этим интересам, готовя
какие-то описания системы и проекта, связанного с системой. Мы не можем после
составления списка интересов и подготовки описаний забыть о том, чьи именно эти
интересы: предпочтения разных ролей для найденных общих интересов могут
существенно отличаться, поэтому подготовленные материалы тут лишь материалы
для дискуссий. Системное мышление коллективно — оно подразумевает
непрерывные согласования предпочтений в самых разных интересах
самых разных проектных ролей. Системное мышление предназначено
для структурирования этих обсуждений.
В публичном документе CPS PWG Cyber-Physical Systems (CPS) Framework Release
1.078 приведена более полная, чем в ISO 42010 таблица интересов для
киберфизических систем (то есть систем, в составе которых есть датчики,
эффекторы и управляющий ими компьютер):

78
https://pages.nist.gov/cpspwg/
 82

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

(практики конфликтологии79, изобретательства80 тут могут помочь очень

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

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

79
https://en.wikipedia.org/wiki/Conflict_resolution
80
https://ru.wikipedia.org/wiki/Теория_решения_изобретательских_задач
81
http://praxos.ru/index.php/СМД-методология
 84

будет проектная роль! Чтобы не запутаться, всегда можно проверить:

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

застревание в их позиции происходит у них уже автоматически, как привычка их

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

Лидерство
Чтобы люди устойчиво занимали требуемые от них ролевые позиции в организации,
существует отдельная дисциплина лидерства (leadership): она учит тому, как
содействовать занятию людьми-исполнителями деятельностных позиций в проекте.
Лидерство часто называют катализацией сотрудничества именно потому, что
разделение труда — это разделение прежде всего деятельности по разным ролям,
раздача разных ролей разным исполнителям ролей (не все роли отдаются одному
исполнителю), и если какая-то роль в её исполнении пропущена, то пьеса не идёт,
сотрудничества не получается. Нужно, чтобы были исполнители всех нужных ролей
в проекте. Например, если никто не играет роль Офелии, а собралось четыре
Принца Гамлета в одном коллективе, то никакого сотрудничества нет, его нужно
обеспечивать специально — либо нанимать дополнительных компетентных людей
на роль Офелии, либо переучивать исполнителей Принца Гамлета на исполнение
новой для него роли.
Если люди устойчиво занимают какую-то стейкхолдерскую позицию, они в ней
профессионализируются и следуют ценностям этой позиции, то их жизнь
наполняется смыслом, они после этого способны очень эффективно играть свою
роль в коллективном разделении труда. Поэтому лидер — это тот человек, который
не столько «ведёт за собой», сколько помогает людям занимать и удерживать
стейкхолдерские позиции, он режиссёр-постановщик, назначающий людей-актёров
(исполнителей) на проектные/организационные/деятельностные роли и
помогающий потом им эти роли успешно освоить, удержаться в этих ролях в суете
корпоративной жизни.
Лидерство как практика/деятельность является мостиком, который стягивает
бездушный мир разработки и проектирования организации (знаний, схем,
ролевых/функциональных объектов/стейкхолдерских_позиций) и живой мир
физических объектов, то есть мир людей-исполнителей-ролей.
Неформально говоря, лидер убалтывает какого-то исполнителя играть в проекте
какую-то роль, занять позицию. Скажем, в спектакле не хватает Офелии (роль!), а
из наличных актёров в труппе остался только Пётр Николаевич. И Петру
Николаевичу совсем не улыбается играть Офелию. Лидер может провести с Петром
Николаевичем ряд бесед: рассказать о том, что актёрское мастерство — это
искусство перевоплощения, что нужно приобретать новые компетенции
(непрерывное образование), про сложность перевоплощения мужчины в женщину
и поэтому ровно это будет тестом актёрского мастерства, про древние традиции
театра Кабуки82, где потомственные актёры-мужчины играют роли одновременно
как мужчин, так и женщин. И вот уже Пётр Николаевич вышел как-то вечером из
дома в юбке, чтобы попробовать, признал, что актёрски это неимоверно трудно, и
это «настоящий тест его мастерства», как и говорил лидер, а через месяц он уже с
огромным успехом играет Офелию. Труппа счастлива, Пётр Николаевич счастлив,
зритель доволен. Это и есть лидерство.
Нужно только учесть, что лидер — это тоже роль. Лидер никогда не один
исполнитель роли — лидерством как практикой занимается обычно весь коллектив,
и каждого исполнителя той или иной роли в проекте направляют на устойчивое
занятие его позиции буквально все члены дружного коллектива, каждый в
коллективе играет в том числе и роль лидера. Дружные коллективы этим
82
https://ru.wikipedia.org/wiki/Кабуки
 87

«распределённым лидерством» и отличаются, ибо никакой один исполнитель-

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

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

Условно можно разделить роли/стейкхолдеров на внешние и внутренние по
отношению к проекту создания системы. Внутренние — это команда проекта
(инженеры, менеджеры, маркетологи и т.п.), а внешние — это все остальные,
которые в команду проекта не входят, но на которых влияет или которые влияют
на проект (пользователи, плательщики, подрядчики, инспекторы и т.п.).
Хороший анализ видов внешних ролей в крупных продажах (например,
инженерного оборудования — в отличие от розничной продажи игрушечной
машинки) дан в книге Нила Рэкхема «Стратегия работы с клиентами в больших
продажах»83. В этой книге говорится, что в крупной организации за простым словом
«клиент» могут скрываться самые разные роли — и со всеми ними нужно работать
по-разному. Так что «нашими клиентами являются поликлиники» лучше не
говорить. В реальной жизни внутри этой поликлиники обнаруживается много
разных ролей — и врач, и медсестра, и менеджер, и айтишник (да ещё несколько
разных!), и лаборант, и пациент, и невидимый обычно инвестор-владелец. Когда вы
говорили «нашими клиентами являются поликлиники», то кого из них вы имели в
виду? Для каждого из них нужно уметь отвечать на разные вопросы, подавать
материал на разном уровне детальности, хвалить систему за разное, по-разному
отстраиваться от конкурентов, по-разному вести переговоры на разных стадиях
продажи.
Мы рекомендуем табуировать некоторые слова, которые очень любят использовать
в подобных случаях, и которые скрывают за собой целые букеты ролей с самыми
разными ролевыми интересами и предпочтениями:
• Пользователь — называйте так, как они называют себя в своих
деятельностных ролях. Если речь идёт об игре, то это «игрок». Если
корпоративный софт, то там обычно много самых разных людей, занимающих
самые разные роли — и для этих разных людей придётся учитывать самые
разные интересы, их нельзя объединять словом «пользователь». Ключевой
ориентир тут — роль называется по ключевой практике, которой занимается
исполнитель роли. Если играет — игрок, если врачует — врач, если думает о
финансах — финансист. Но не пользователь!
• Покупатель — обычно там тоже отдельно бенефициар (тот, кто получает
выгоды от купленного), приобретатель (юридическая сторона договора),
плательщик, доверенное лицо (например, курьер, получающий покупку),

83
http://www.koob.ru/rekhem_nick/strategiya_raboti_s_klientami_v_bolshih_prodazhah
 88

эксперт (тот, кто выбирает товар) и т.д. И их всех нужно учитывать в разных
ролях, учитывать их разные ролевые интересы и предпочтения.
• … вы уже поняли идею. Слово «заказчик» или «клиент» также является
подозрительным — часто там есть люди с противоположными
предпочтениями (финансист-заказчик хочет минимальную цену и поэтому
минимальные возможности, инженер-заказчик хочет максимальные
возможности и поэтому максимальную цену — и они там имеют
противоположные предпочтения в цене и возможностях, в случае
объединения их в «заказчика» мало что с этим можно будет сделать, это всё
учитывать в проекте нужно отдельно.
Часто внешние люди-в-роли/стейкхолдеры недоступны (например, у вас 10 тысяч
игроков вашей игры на телефоне, у всех них одна роль «игрок». Но пока игровая
программа ещё не написана и в эту игру никто не играет, то и игроков нет — если
какой-нибудь Вася Пупкин не играет роль Принца Гамлета, то Принца Гамлета в
этот момент нет!). В таких случаях эти внешние роли поручают представлять
членам команды. Поначалу для этого использовался метод персон, где
моделировались не роли, а исполнители ролей — персонажи/персоны (persona)84.
В этом методе предлагалось составить типовой портрет пользователя продукта, и
кто-то из команды должен был играть его или её роль, как в театре. Например,
«мать-одиночка, 32 лет, живущая на окраине небольшого городка, пользующаяся
своим планшетом для ведения домашних финансов». Но в последние годы прошла
волна критики такого моделирования, ибо фокус его был направлен не на
собственно ролевой/стейкхолдерский/функциональный анализ отношения к
деятельности, а на вторичные характеристики исполнителя роли, которые слабо
связаны с сутью дела. Это примерно как мы советовали бы представить Принца
Гамлета, предлагая точнее описать его вес, рост, пищевые привычки, предпочтения
в одежде и надеясь при этом, что это даст нам более точный ответ о его
деятельностных предпочтениях в моменты, когда он задаёт свой стейкхолдерский
вопрос «быть или не быть?». Понятно, что это психологически удобно (и это крайне
важно, чтобы исполнители внешних ролей в команде разрабатывали систему не как
удобную «для себя», а как удобную «для других»), но содержательно это тупик.
Лучше бы абстрагироваться от того, что «мать-одиночка живёт на окраине
небольшого городка» и вместо «пользователя» назвать её «домашним
финансистом» — и это отсечёт в обсуждениях все интересы матери-одиночки, все
интересы жителя небольшого городка, они будут только лишними. Если нужно
учесть какие-то особенности исполнителя, то их учитывают как особенности другой
роли, а не исполнителя. Так, для плохо видящих (интерес: размер текста) нужно
предусмотреть крупный шрифт в интерфейсе (предпочтение). Но при этом мы
понимаем, что роли «домашний финансист» и «плохо видящий» имеют разные
интересы, и эти разные интересы будут отражены в функционале и конструкции
системы по-разному. Может даже быть конфликт интересов (разные
предпочтения по одному интересу у одного исполнителя роли). Домашний
финансист хочет увидеть много на экране, а слабовидящий — крупный шрифт.
Какой в итоге будет размер шрифта — как для слабовидящего, или как для
домашнего финансиста? Кто победит в этом конфликте интересов? Теперь можно
предлагать разные решения. Например, экранную лупу для шрифта (на экране

84
Метод был описан в книге Алан Купера «Психбольница в руках пациентов» в 1999 году,
http://www.koob.ru/cooper_a/psih_v_rukah_pacientov
 89

всего много+лупа), регулируемый размер шрифта (каждый исполнитель роли

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

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

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

85
См., например, практику Jobs To Be Done — https://medium.com/no-flame-no-game/что-такое-jobs-to-be-
done-и-job-stories-4c57c1dc84cf
 90

роли), потом Василий Пупкин увольняется, и на его должность (после увольнения

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

86
https://ru.wikipedia.org/wiki/Джокер
 91

также занимается лидерством (поручает человеку-в-должности стать человеком-в-

нужной-роли, чтобы он занялся деятельностью/практикой этой роли).
За речью начальников нужно следить особо внимательно: их ролевые интересы
обычно не определены, не предъявлены, и они их регулярно меняют в ходе
разговора (помним: «слова-термины важны, и не важны»). Первые пять минут
какой-нибудь «начальник цеха» будет в роли операционного менеджера
(предпочтения: уменьшить сроки работ, уменьшить использование ресурсов), потом
пару минут инженером (например, инженером по требованиям: предпочтение
выявить и согласовать дополнительные требования), потом до конца разговора
оператором станка с ЧПУ (предпочтение низкой сложности обработки деталей,
поэтому намерение выяснить особенности обработки деталей в связи с
изменившимися требованиями и ставшими известными новыми сроками).
Директор театра в пьесах сам не играет, а если и играет, то нельзя понять по
наименованию его должности, какую роль. Директор, как и любой начальник,
может вмешаться исполнение любой роли, в любой момент. Директор театра — не
Принц Гамлет, это просто должность в штатном расписании, и даже не актёрская.
Менеджер-начальник и операционный менеджер/менеджер проекта в проектном
управлении — их не нужно путать. Менеджер-начальник это указание на
ответственность и полномочия (должность), а не на
деятельностную/профессиональную роль с какими-то компетенциями.
Операционный менеджер — это человек, выполняющий практику операционного
управления, увеличивающий скорость прохождения работ в рамках бюджета.
Должности — это не роли, это организационные места. Исполнители ролей
занимают и организационные места (становясь при этом «оргзвеном» — и получая
при этом даваемые местом полномочия по распоряжению трудом и ресурсами и
обязанность выполнения распоряжений их начальников из вышестоящих
оргзвеньев), и вполне могут играть какие-то роли. Более того, если исполнитель
роли ещё и начальник, то он произвольным образом может выбирать свою роль —
пытаясь собой заместить отсутствующего исполнителя роли (и, конечно, играет он
эту роль, как любой нетренированный и непрофессиональный исполнитель роли
часто плохо — занимающий оргместо начальника исполнитель роли инженера
может быть очень плохим инженером. Но он может считать, что решения должен
принимать именно он, ведь он начальник! Плохо путать людей как занимающих
оргместа и тем самым находящихся на должности и играющих роли. Для ролей у
исполнителя роли обсуждается профессионализм и компетенции в ролевой
практике, а для занимающих должность — совершенно другие характеристики.
Слово «менеджер» путает всех: это может быть
• должность «менеджер» «менеджер» (понимаемая как «начальник», хотя
бывает и «менеджер по продажам», представляющий наоборот, нижнюю
ступеньку в иерархии работников),
• роль «менеджер» в значении «менеджера-организатора» (совокупная роль
архитектора предприятия, определяющего ролевую структуру в работах
предприятия и предлагающего организационную структуру
руководства/подотчётности, и лидера, помогающего людям занять
организационные места/должности и приступить к качественному
выполнению закреплённых за этими должностями ролей — стать
организационными звеньями),
 92

• роль «менеджер» в значении «операционного менеджера», которая

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

Звание и компетенция
Аналогично ничего нельзя сказать про то, какой деятельностный интерес у носителя
звания. Слова «профессор», «кандидат наук» или «полковник» ничего не говорят
нам, кроме того, что у человека есть какой-то опыт в непонятно какой деятельности.
Нужно просто запомнить, что «народный артист» ничего не даёт к знанию того,
идёт ли речь об исполнении роли Гамлета или Петрушки в совершенно разных
спектаклях. Это какая-то общая характеристика исполнителя роли, но не самой
роли.
А вот квалификация исполнителя какой-то роли важна. Сегодня квалификация
рассматривается не как набор каких-то отдельных знаний, навыков и умений, а как
набор компетенций, достаточных для игры в какой-то роли. Компетенции
означают, что какие-то дела исполнитель роли, требующей этих компетенций,
может успешно выполнить не только «на экзамене», но и в реальной жизни, в
реальном проекте.
По факту, традиционно использующиеся в российской и советской педагогике
критерии знаний-умений-навыков/ЗУН не включают в себя навыков постановки
задач в нетепличных условиях реальной жизни, а компетенции включает в себя
постановку задач в реальной жизни для их последующего решения — нахождение
в жизни объектов ролевых интересов, умение удерживать роль среди мельтешения
и обилия неважных для игры по роли деталей в жизни.
Грубо говоря, имеющий знания, умения и навыки (ЗУНы) для роли Принца Гамлета
вполне сможет играть Принца Гамлета на репетициях, в тишине и без отвлекающих
зрителей. Но имеющий компетенции Принца Гамлета сможет сыграть Принца
Гамлета где-нибудь в густой толпе посреди суматохи (обычные условия в
проектах!), а когда нужно будет общаться с черепом Йорика, за неимением черепа
приспособит к этому какую-нибудь картофелину, или хотя бы бумажку с
нарисованным черепом — и изготовит этот «череп» себе сам, придумает как это
сделать. Но самое главное — имеющий компетенцию найдёт себе в толпе остальных
участников пьесы и сумеет организовать с ними свои ролевые диалоги. Он умеет
 93

вписать свою деятельность в роли в деятельность всего играющего пьесу

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

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

Нужно запомнить простой принцип: важных ролей/стейкхолдеров в проекте
всегда на одного больше, чем вы выявили. Роли имеющих интерес и
предпочтения по отношению к вашей системе и проекту есть, вы их не
«разрабатываете/изобретаете/выдумываете», вы их «выявляете», «находите»
(discover).
И начинать нужно не с двух-трёх стейкхолдеров, а примерно с 15 (пятнадцати).
Помним при этом, что если пятеро человек в проекте играют одну и ту же
деятельностную роль, то это одна роль/один стейкхолдер. Помните танец
маленьких лебедей из Лебединого озера? Там четыре исполнителя, но роль
«маленький лебедь» по факту одна. Игроков у смартфонной игры может быть сорок
тысяч человек, но роль у них всех одна — «игрок». Так что 15 внешних ролей по
факту могут оказаться исполняемыми довольно большим числом людей. Но верно
и обратное: один исполнитель роли может играть множество ролей, так что пять
человек в проекте могут оказаться на поверку десятком самых разных ролей.
Один из менеджеров проекта нам рассказал, что после того, как он легко выявил
первые пятнадцать внешние роли, он понял, на что незаметно уходило всё его
время: 15 телефонных разговоров в день по 10 минут каждый и 10 минут подготовки
к разговору и обработки результатов разговора сразу дают 5 часов просто на
поддержку адекватного понимания! А если нужно решать какие-то проблемы
проекта с этими ролями, то 10 минут разговора явно не хватает. Поскольку внешних
стейкхолдеров никто в проекте явно не отслеживал, это время уходило «невидимо»,
оно тратилось неосознанно, в планах оно не отражалось, ресурсы менеджера на эту
работу не выделялись и не учитывались. Осознанность по отношению к
ролям/интересантам/стейкхолдерам и планирование работы с ними — они важны!
Согласно ISO 42010 для инженерных проектов необходимо, как минимум,
учитывать следующие роли: пользователей (users), операторов (operators),
покупателей (acquirers) системы, собственников (owners), поставщиков (suppliers),
разработчиков (developers), изготовителей (builders), эксплуатационный персонал
(maintainers) системы. И это только минимальный список для целей этого стандарта!
Мы же крайне не рекомендуем использовать такие обобщённые роли: помним, что
видов ролей «пользователей», как и всех остальных из этого списка, может быть
множество, и лучше называть их более специфичными именами — каждая роль
будет иметь какие-то свои специфичные интересы и свои специфичные
 94

предпочтения в области этих интересов.

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

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

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

87
https://ru.wikipedia.org/wiki/Козьма_Прутков
 95

совпадают.
Если Принц Гамлет вдруг начинает спрашивать про «Молилась ли ты на ночь,
Дездемона?», это уже не Принц Гамлет! Это Василий Пупкин, который
переключился на другую роль (какую? В этот момент важен кругозор! Вы можете
пропустить момент, когда вам ясно говорят, что сейчас кого-то задушат!).
Ещё в этот момент переключения ролей у исполнителя полезно задать вопрос,
почему это он поменял обсуждаемый интерес/тему и стал другой ролью: вы можете
узнать много интересных подробностей. Скорее всего это означает, что всплыл
какой-то новый интерес и предпочтение из-за того что Василий Пупкин что-то
припомнил важное и поэтому переключил роли. Не забывайте задавать вопрос о
причине смены темы, когда люди-исполнители-ролей (должность их неважна!
Должность важна только при отдаче распоряжений!) в ваших проектах будут вдруг
менять эти роли в ходе разговора.
Напомним основные ошибки, которые делают люди, определяя внешние для
проекта и внутренние (командные) роли:
• Указывают исполнителя — конкретного человека (ФИО или название
подразделения/оргзвена)
• Указывают «ответственного» (должность, оргзвено, позиция в штатном
расписании), чаще всего «начальника» (ошибка типа «Директор театра» в
списке действующих лиц «Сна в карнавальную ночь»)
• Указывают звание (учёную степень, воинское звание) вместо роли
• Указывают тип организации, в которой много различных ролей (клиника,
завод)
• Считают, что один человек-исполнитель — это одна роль
• Считают, что пять внешних ролей в проекте — этого более чем достаточно
• Забывают учитывать свои собственные роли, интересы, предпочтения
• Забывают про множество интересов у проектной роли и множество
проектных ролей у интереса
• Не обращают внимания на проявляемый в текущей ситуации интерес,
указывают предполагаемый интерес из каких-то прошлых или ожидаемых
ситуаций.
• Не различают ролевых интересов, предпочтений, намерений по реализации
предпочтений
А теперь вспомните последнее совещание, в котором вы участвовали (малый
вариант упражнения) или текущий проект (большой вариант упражнения). Кто там
участники?
Помним, что в системном мышлении системы (в том числе и люди) учитываются
прежде всего как ролевые/функциональные объекты, а не как физические
объекты/исполнители ролей. Это означает, что вас только что спросили именно про
то, какие роли игрались на совещании (то есть на совещании/в проекте были люди,
которые играли эти роли!).
Заполните табличку.
Но Ро Исполн Должн Органи Квалификация/к Инте Предпо Намер
мер ль итель ость зация омпетенция рес чтение ение
п/п роли исполн исполн исполнителя для
ителя ителя роли
 96

роли роли

Кого нужно было ещё пригласить на совещание, чтобы полноценно обсудить эти
интересы? Для ответа на этот вопрос прежде всего нужно подумать, какие роли
могут иметь другие предпочтения в этих интересах. Затем предположить, кто может
быть исполнителем этих ролей.
Заявляли ли вы на этом совещании свои интересы и предпочтения, раскрывали ли
свои намерения по реализации предпочтений — знали ли участники совещания,
какие роли вы играете в ходе совещания? Знание должности и из какой вы
организации тут совершенно неважно, равно как и какие роли вне совещания вы
ещё можете играть?
Отвечали ли вы в своих выступлениях на интересы и предпочтения остальных
присутствующих ролей, демонстрировали ли вы понимание их намерений? Или вы
отвечали исполнителям-людям?
Вы должны выполнять это упражнение на каждом совещании, в каждом
проекте, доводя его до автоматизма. Это и есть системное мышление, хотя
и только его маленькая часть.

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

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

88
https://ru.wikipedia.org/wiki/Общая_теория_систем
 98

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

Органы

Клетки

Молекулы

Вы видите, что системы обозначены на схеме системной иерархии кружочками, а

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

любого такого разбиения потенциально будет вселенная (все системы являются

частями вселенной как целого), хотя этот самый-самый предельный уровень обычно
не показывается, а на самом нижнем уровне — элементарные частицы или даже
суперструны (они являются частями любой системы). Людей же обычно интересует
очень тонкий слой тех объектов где-то посредине, которые как-то соразмерны с
ними и служат объектами их деятельности, с которыми взаимодействуют они сами.
Явное указание системного уровня важно для управления вниманием: формально,
дотронувшись до цветка у растения (уровень «органы» в системном разбиении
растительных организмов) я дотрагиваюсь до вселенной, и дотрагиваюсь до
элементарных частиц. Или дотрагиваюсь до всего растения и до клеток растения.
Но нет, требуется выделить тот объект внимания, который как-то позволит мне
определить масштаб «дотрагивания» — и это будет «цветок». Когда я машу рукой,
то я машу всеми молекулами руки — но неправильно ведь говорить о молекулах?
Системные уровни принципиальны, они отражают саму суть системного подхода —
для снижения сложности обсуждения ведутся отдельно для отдельных системных
уровней, это существенно упрощает обсуждение сложных систем. Если вы
обсуждаете предприятие, то обсуждайте людей, оборудование, запасы материалов,
здания и сооружения, но обычно при этом не нужно обсуждать планетарную
систему, частью которой является предприятие, или биохимию клеток у людей, как
биохимию части предприятия. Это, конечно, грубо и вроде как «очевидно», но в
рабочих ситуациях явное выделение удобного для обсуждения системного уровня
крайне помогает.
Инженеры описание элементов системного разбиения дают обычно через описание
типов (например, «самолёт»), но в реальности этим типам объектов соответствуют
подводимые под этот тип физические предметы (cамолёт с бортовым номером 128,
самолёт с бортовым номером 2467, и т.д.). В то же время философы (но не мы в
нашем учебнике) часто обсуждают системные уровни с произвольными частями, в
том числе абстрактными89 — и там отношения «часть-целое» определяются очень
по-разному.
Системные уровни преследующие разные интересы и имеющие разные
предпочтения проектные роли для одной и той же системы определяют по-
разному — так, как им это удобно для их деятельности. Никакого «истинного» или
«объективного» разбиения системы на части нет. Поэтому для одной и той же
системы в проекте по созданию системы обычно одновременно рассматривается
несколько вариантов разбиений на части. Эти разные варианты разбиений на части
люди, играющие разные роли в проекте, согласовывают между собой, добиваясь
успешности системы. Даже один человек, играющий три роли, может предложить
три разных разбиения, по-разному выделяя части системы — чтобы ему было
удобней думать в каждой из своих трёх ролей. Это будет подробнее рассмотрено
позже.

Эмерджентность и метасистемный переход

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

89
http://en.wikipedia.org/wiki/Holon_%28philosophy%29
 100

называют эмерджентностью (emergence, системный эффект).

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

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

Разбираясь с этими индивидуальными деталями невозможно понять, как

автомобиль работает. Мы должны рассмотреть как отдельную целую часть/систему
двигатель, чтобы объяснить, откуда появляется движение автомобиля, мы должны
рассмотреть как отдельную целую часть/систему салон автомобиля в сборе, чтобы
объяснить, почему в нём удобно могут находиться несколько пассажиров, мы
должны рассмотреть отдельно собранные все детали тормозной системы, чтобы
показать, каким образом автомобиль может тормозить. Всё это эмерджентные
свойства, бесполезно собирать не детали тормозной системы, а обсуждать
материалы, из которых сделаны детали тормозной системы. То есть
эмерджентность появляется, когда материалы уже собраны в детали, и торможение
происходит из-за взаимодействия деталей. Хотя формально «для математиков»
торможение происходит из-за взаимодействия материалов, и даже молекул
материалов! Системное мышление — это не математическое мышление в этом
плане. Оно содержательно, а не формально.
Корова Маргарита имеет своей частью хвост, корова Маргарита является частью
коровьего стада. Нехорошо позволять говорить, что коровье стадо имеет хвост, хотя
это вроде как корректно. Это корректно, но не системно, и это вроде как интуитивно
понятно всем. Но интуитивно непонятно, можно ли говорить, что карбюратор —
часть автомобиля. Он отдельная часть автомобиля, или он часть топливной
подсистемы, или часть двигателя?! Но интуитивно понятно: неправильно говорить,
что поршень или цилиндр двигателя — это часть автомобиля. Формально это верно,
но неправильно.
Эмерджентность тут хороший критерий: обсуждение автомобиля в целом обычно
требует обсуждения двигателя в целом, но есть ли там внутри двигателя поршень
— это при обсуждении автомобиля в целом неважно. Системные уровни прежде
всего управляют вниманием: на каждой границе системного уровня меняется
 102

интерес, меняются объекты внимания. При метасистемном переходе (переходе от

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

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

в этом не будет, не будет обсуждения собственно танца, это будут

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

Целевая система и коллективное системное мышление

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

(субъективно!) система и будет целевая система (system-of-interest, буквально

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

Система, в состав которой входит целевая система называется надсистема. На

 105

рисунке это система 1. Часы будут надсистемой для шестерёнки, молекула

надсистемой для атома. Целевая система имеет своё назначение/роль в надсистеме,
её функция/действия/поведение позволяют надсистеме проявить в конечном итоге
эмерджентное свойство, т.е. выполнить уже её назначение. Помним, что все
системы определяются прежде всего по их роли, назначению в надсистемах. И
надсистема — тоже система, ей нужно выполнять свою роль в над-надсистеме
(просто на картинке эта над-надсистема не показана, но она всегда есть!).
Если целевая система шестерёнка, то шестерёнка используется в часах (входит в
состав часов), её роль «передатчик движения», назначение/функция/поведение —
передавать движение на стрелки так, чтобы надсистема «часы» могла показывать
время, т.е. могла выполнять своё назначение/функционировать/выполнять свою
функцию.
Все системы в момент эксплуатации целевой системы, которые не входят в целевую
систему, называются системами в окружении (environment, среда, operation
environment, рабочая/эксплуатационная среда, рабочее/операционное
окружение — термин «окружение» предпочтительней, поскольку подчёркивает
центральную роль целевой системы, а термин «среда» не подразумевает какого-то
явного центра).
На рисунке одна из систем в окружении (этих систем множество!) — система 3.
Например, для шестерёнки в часах таким окружением будут стрелки, тоже
входящие в состав часов. А ещё в окружении могут быть какие-то системы, даже не
входящие в состав надсистемы, но без которых трудно обсуждать
работу/функционирование целевой системы. Например, солнце, нагревающее часы
и тем самым влияющее на шестерёнку (при нагреве она может поменять свои
размеры, что может оказать влияние на основное поведение — точно передавать
движение, что далее оказывает влияние на поведение надсистемы — точный показ
времени).
Заправочная станция для целевой системы такси, входящего в состав таксопарка
как надсистемы — это система в окружении. Дорога для бегущего по дороге такси —
это система в окружении. Повторимся: совершенно необязательно, чтобы система
в окружении была именно подсистемой надсистемы, «смежником» для целевой
системы (хотя иногда все другие подсистемы надсистемы для целевой системы
выделяют специально, называя ближним окружением, а за пределами
надсистемы называют дальним окружением. Для автомобильного мотора в
составе автомобиля как надсистемы салон автомобиля и его колёса — ближнее
окружение, это подсистемы автомобиля. А вот дорога и палящее солнце — это
системы из дальнего окружения).
Подсистема — какая-то часть системы. В системном мышлении подсистемы (они
же выделяются по их ролям!) рассматриваются после рассмотрения окружения —
ибо пока мы не понимаем, что должна делать целевая система, какую
функцию/поведение она несёт в окружение, мы не можем ничего сказать про её
состав. На рисунке пример такой подсистемы целевой системы показан под номером
4.
Проблема в том, что целевой системой для разных ролей в проекте/стейкхолдеров
может стать любая, которая будет проявлять интересную для них эмерджентность,
нужный для них системный эффект. И тогда все остальные виды систем будут
определяться по-другому. Скажем, если целевой системой объявить систему 4, то
 106

система 2 будет её надсистемой. И если все договорились, что целевой системой

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

Мы помним, что «слова неважны, и слова важны». Понятия/концепты целевой

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

Чтобы лучше понять идею системных уровней, давайте рассмотрим чуть менее
простой пример социальных танцев (парных танцев типа танго и сальсы), в котором
выделим (от подсистем через целевую систему отдельного танцевального стиля к
надсистемам — чтобы подчеркнуть отсутствие тут каких-то конвенций в
отображении системных разбиений в части «верха» или «низа». Речь идёт только
об отношениях часть-целое):
• Суперструны (физики утверждают, что из них состоит всё, что есть
материального на свете. Даже танцы как промежуточный уровень к
Вселенной, которая тоже состоит из суперструн).
• … огромное число других уровней: физических с элементарными частицами
и атомами, химический с молекулами (в том числе биохимический с большими
молекулами), биологические с органеллами клеток, клетками, тканями.
• Медицинский/анатомический уровень. Если не работают мышцы, связки,
кости, нервы и даже мозг как системы этого уровня — почини их. Этим
занимаются медики, которые занимаются наряду с тканями ещё и органами,
и системами органов.
• Телесный уровень. Умение управлять мышечными усилиями полезными и
паразитными в теле — через всё тело. Это не техника конкретных движений,
это вообще умение двигаться: выдерживать свой вес, выдерживать позу,
выдерживать траектории движений в сложных позах, выдерживать
равномерность движения в разных позах и т.д. Разговор о теле и его частях,
управляемых осознанно больших мышечных объёмах (не об отдельных
мышцах и костях!). Предыдущий уровень «объектов медицины» тут
подсистемы к системе какого-то телесного движения. Важно, что над этим
уровнем можно выстраивать и сольные танцы, и социальные танцы, и даже
какое-то карате или горные лыжи (для них ведь тоже нужно владеть телом!),
и даже просто ходьбу или бег.
• Уровень социальности в танце. Это прежде всего движения ведения-
следования в паре (техника немного различается в каждом танце, но основы
удивительно общи), разные по технике исполнения шаги, волны в теле,
техники эстетично выполняемых поворотов. Это уже обсуждается в
танцевальной терминологии, а строится из объектов предыдущего уровня —
изменяющихся во времени телесных движений, в свою очередь состоящих из
координированных мышечных усилий. Но в мышлении тут уже совсем другие
объекты, обсуждающее этот уровень сообщество другое (уже не
специалисты-телесники, общие для спорта, сольных и социальных танцев, а
мультидансеры и преподаватели разных танцев). Внимание ролей на этом
системном уровне удерживает другие объекты: ведение-следование в паре,
соблюдение линии танца, траектории волн в теле, и т.д.
• Уровень движений отдельного танцевального стиля. Вот тут появляется
обсуждение особенностей именно танго, зука, кизомбы, форро, самбы, хастла
и самых разных других танцев. Обычно именно этот уровень заботит всех
социальных танцоров, преподавателей социальных танцев, он является
главным уровнем при обучении танцам. И тут используется терминология
объектов именно выбранного танца: болео90 из танго рассматриваем именно
тут, не во всех социальных танцах есть этот элемент. Этот уровень владения
техникой танца тоже осваивается сознательно, а потом автоматизируется и

90
https://www.youtube.com/watch?v=uWAX2XOoNiE
 108

оказывается в памяти танцора на уровне условных рефлексов (существует

как физический объект, можно думать об этом примерно так же, как о
программе — это как бы хранящееся в мозгу и мышцах описание танца,
«мозгодокументация» типа «файла с кодом программы», но которое
сработает в момент конкретного танцевания). Но этот уровень танцевального
стиля состоит в том числе и из общих для всех танцев ведения-следования,
поворотов, которые к этому времени обычно уходят из сознания танцоров
«на автомат» и поэтому не распознаются как отдельный системный уровень.
Например, во всех танцах важна «настройка на партнёра», и многие
преподаватели искренне считают, что в других танцах её не делают, это
особенность именно их танцев, равно как движение «от опоры» и важность
«переноса веса» — но это общее во всех танцах, этому можно учить один раз
и обсуждать на уровне отдельного танцевального стиля только особенности,
но не общие вопросы. Если что пойдёт не так, то преподаватель всегда
вернётся на предыдущий уровень, а если и там не так — на предыдущий, и
даже на уровень медицины/анатомии, если ошибки не исправляются на более
высоких уровнях.
• Уровень исполнения/воплощения танца (обратите внимание, что
«исполнение» и «воплощение» тут синонимы для подобного сорта систем.
Можно опять думать об аналогии с компьютерной программой) как длинной
связной в единое сюжетное целое последовательности частей-движений
предыдущего уровня движений отдельного танцевального стиля (или даже
множества стилей одновременно). Это уровень отдельного уникального
танца под конкретную музыку в конкретное время на конкретной вечеринке
в конкретном месте, исполняемый конкретными партнёром и партнёршей.
Только на этом системном уровне подключается язык художественности и
драматургии: «эмоции», «образы», «истории», музыкальные акценты,
«сюжет танца» и прочее. Ибо мозг свободен, работу всех предыдущих
уровней он выполняет «на автомате»: работу отдельных мышц, телесную
работу в целом по управлению нужными и паразитными усилиями в
масштабах тела, внимание на технику выполнения ведения-следования, а
ещё уровнем выше автоматически тело выполняет предписанные каноном
танцевального стиля или даже нескольких стилей сложные фигуры. На этом
уровне считается, что всё уже происходит автоматически, и обсуждается
Танец (часто тут пишут танец с большой буквы, чтобы подчеркнуть не
механический и автоматический, а творческий характер танца. Увы, у
танцоров не слишком развита терминология, позволяющая разводить
понятия разных системных уровней. Но лучше уж писать Танец с большой
буквы, чем не выделять этот системный уровень и его понятия совсем).
• уровень дискотеки/вечеринки, поведения на вечеринке и посещения
вечеринок в целом как уровень субкультуры социальных танцев: много
танцев и связанных с ними мероприятий складываются тут в культурное
времяпрепровождение. Языки обсуждения и люди, занимающиеся этим
уровнем, опять меняются. Появляются диджеи, организаторы вечеринок,
фотографы и видеографы, завсегдатаи вечеринок, бизнес-модели, реклама и
т.д.
• Уровень культуры в целом, ибо танцевальные вечеринки как мероприятия
(физические объекты, имеющие протяжённость в пространстве и времени) —
это только часть систем-физических объектов (перформансов, занятий в
 109

многочисленных студиях, поединков, художественной критики и т.д.),

присутствующих в культуре.
• … огромное число других уровней: вся жизнь на Земле, вся Земля, солнечная
система, Млечный Путь и т.д.
• Вселенная — системы из всех остальных системных уровней лишь части
Вселенной.
Уровень вечеринки и уровень культуры в целом, конечно, сами по себе имеют много
подуровней: ими занимаются разные люди, о них говорят на разных языках.
Пропускать эти уровни танцорам неправильно: без хорошего развития каждого
предыдущего уровня и хорошего понимания каждого последующего невозможна
полноценная культурная жизнь танцора. Жизнь (выходящая, конечно, за рамки
одного танца) происходит сразу на всех уровнях (и уровне ниже медицинского, ибо
там работает биохимия, и на уровне выше культуры, ибо жизнь на планете сложней
только развлекушек, в ней ещё много чего есть). А если жизнь на каком-то из этих
уровней выпадает из осознанного внимания, то можно ожидать разных
неожиданностей на верхних уровнях. Если мышцы болят, то тело не двигается,
ведение-следование не получается, движения танца не выполняются, вечеринка
невозможна, участие в культурной жизни не получается. И такие проблемы могут
появиться на каждом уровне: нужно их отслеживать и решать на том системном
уровне, на котором они появились.
Ровно так же с космическим кораблём (и пример космического корабля легче
понимать, чем пример танца. Для усложнения примера можете рассмотреть систему
полёта космического корабля на Марс, тот же танец, разворачивающийся во
времени полёта). Если корпус корабля изготовлен из неправильного материала, то
нужно опускаться на уровень рассмотрения материала, и решать проблему. Иначе
из-за проблем с материалом нарушится работа всех остальных более высоких
системных уровней космического корабля.
Полезное упражнение тут — это представить авиалайнер как 6млн.
индивидуальных деталей, летящих с одинаковой скоростью 890км/час в одном
направлении на высоте 10км. Это шутка, но это и чистая правда! Если не вводить
тут рассмотрение на разных системных уровнях, оставаться редукционистом, то
остаётся думать про самолёт именно так: 6млн. деталей, которые были собраны
вместе и теперь согласованно летят на десятикилометровой высоте!

Обеспечение и наша система

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

называются системами обеспечения91 (enabling systems). Эти системы

обеспечивают создание и ликвидацию системы, ведут её через разные состояния к
готовности эксплуатации/использования, а потом выводят из
эксплуатации/использования — и затем ликвидируют (это может быть непросто!
Например, оставляют «зелёную площадку» после ликвидации атомной
электростанции), или ремонтируют, или модифицируют и возвращают в
использование. Это системы обеспечения, которые не входят в системное
разбиение с целевой системой, но входят в самые разные иные системные
разбиения обеспечения (обеспечение — это совокупность всех систем обеспечения
жизненного цикла, как и окружение — это совокупность всех систем
операционного/рабочего окружения).
У систем обеспечения есть свои надсистемы и свои подсистемы. Иногда системы
обеспечения называют системами обеспечения жизненного цикла (lifecycle enabling
system), иногда просто системами жизненного цикла, иногда даже предприятиями
(enterprise), ибо проектами обеспечения (проектами по созданию целевых систем)
чаще всего занимаются предприятия, но формально это может быть и просто какой-
то станок, который вытачивает целевую деталь. Станок не участвует в эксплуатации
целевой системы, он не входит в её эксплуатационное/операционное окружение, он
участвует в создании системы — так что этот станок будет системой обеспечения.
И, конечно, станок будет входить в какое-то предприятие, но предприятие будет
для него далёкой над-над-над-надсистемой, через много системных уровней
(например, системные уровни станок-сектор-отдел-служба-предприятие).
В советской (а нынче российской, украинской, казахской и т.д.) традиции есть
значения слова «обеспечение», которые тут могут быть «ложным другом
переводчика» с системного языка:
• Обеспечение как снабжение. Нет, тут слово обеспечение используется как
перевод для enabling — а системы снабжения будут во время эксплуатации
системами в окружении, но и системами обеспечения, если речь идёт о
времени создания или ликвидации системы.
• Обеспечение как вспомогательные, неглавные системы. Нет, неглавные
системы (например, часть-колпачок для системы шариковой ручки по
сравнению с частью-стержнем и частью-корпусом ручки) тут просто являются
подсистемами целевой системы, или находятся в её окружении, т.е. они как-
то участвуют в эксплуатации, а не в замысливании, проектировании,
изготовлении, модификации, ликвидации целевой системы.
Важно, что целевая система определяется для множества ролей, для большого
коллектива. Об этом подробней будет говориться в следующих разделах. А как
называется какая-то система, которая прямо сейчас находится в центре нашего
внимания, но не целевая? Если мы эту нашу систему назовём целевой, то нас
никто не поймёт, будут считать (справедливо), что мы тянем одеяло на себя.
Например, нам («мне и мне», или даже «нас тут пять ролей в команде из троих
человек») поручили разработать винтик для большого и сложного станка. Да,
целевой системой для всей команды является станок, но мы-то в центре
внимания держим этот винтик! Что, считать станок над-над-надсистемой для этого
винтика? Да, конечно. Считать винтик целевой системой? Нет, конечно. Целевая

91
https://en.wiktionary.org/wiki/обеспечение — ударение можно ставить двумя способами, обеспе́чение или
обеспече́ ние.
 111

система уже есть, станок. Вот тут и появляется термин наша система (engineered
system в системной инженерии, managed system в системном менеджменте,
MySystem, OurSystem, система в руках/system in hand), показывающая временный
фокус внимания в системном разбиении целевой системы.

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

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

92
Leidraadse (2008), Guideline Systems Engineering for Public Works and Water Management, 2 nd edition,
http://www.leidraadse.nl/
 112

В транспортной системе мы сначала можем обсуждать мультимодальные 93

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

93
https://ru.wikipedia.org/wiki/Мультимодальная_перевозка
 113

непосредственную составную часть транспортной системы — это с точки зрения

формальной логики будет правильно, но абсолютно бессмысленно. Системный
подход, вводя системные уровни, делает рассуждения осмысленными: все люди
получают возможность договориться, обсуждая проблемы только каждый на
«своём» системном уровне (на уровне, для которого у них есть интересы,
предпочтения, намерение действовать, чтобы изменить ситуацию к лучшему с точки
зрения ролевых предпочтений). Так организованное с разделением на системные
уровни и по разным ролям коллективное мышление — это огромное достижение
цивилизации.
Боинг 747-8 состоит из 6 миллионов независимых видов деталей, которые
производят полмиллиона человек на 5400 фабрик, за один год заказывается 783
миллиона частей самолёта94:

В современных системах число отдельных элементов, которые нужно согласовать

между собой (в проектировании), а часто и создать с нуля (в конструировании)
достигает десятков миллионов в «железных» системах, а если речь идёт об
электронных системах, то и десятков миллиардов: на одном электронном чипе Xilinx
Everest/Versal число отдельных транзисторов — 50 млрд. штук95. Без какого-то
иерархического рассмотрения таких сложных объектов и управления коллективным
и личным вниманием посредством подобной иерархии можно оставить надежду об
их создании. Системное мышление через использование системных разбиений как
средства организации внимания позволяет справиться с такими огромными
проектами. Работа с системными уровнями — самая суть системного
мышления.
Суть системного мышления на одной диаграмме метафорически можно выразить
так:

94
http://787updates.newairplane.com/787-Suppliers/World-Class-Supplier-Quality
95
https://en.wikipedia.org/wiki/Transistor_count
 114

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

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

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

Определение целевой системы как чёрного ящика называют системными

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

системы и её поведение как чёрного ящика, но и указать какие-то детали

внутреннего устройства системы: определить (define) части системы (подсистемы),
указать на процесс взаимодействия подсистем. В этом случае о системе говорят как
о «прозрачном ящике», в нём можно считать известными какие-то подсистемы,
свойства и поведение этих подсистем. Если в какой-нибудь «спецификации» или
«требованиях технического задания» среди требований встречаются описания
прозрачного ящика (описания подсистем, и даже под-подсистем), то их называют
ограничениями (constraints). Эти ограничения нужно понимать как
ограничения конструкторской свободы команды, которая должна
разработать и изготовить систему.
Обычно команда проекта согласовывает с внешним заказчиком системы
функции/поведение, которые должна выполнять система как чёрный ящик,
свойства этого чёрного ящика, т.е. согласовывает требования, а уж как устроена
система внутри, какая у неё конструкция и как она работает, т.е. что там с
подсистемами, команда проекта определяет самостоятельно. Важнейшие из этих
решений по устройству системы, т.е. решения «прозрачного ящика» называют
архитектурой. Но очень часто различные роли в команде заказчика/клиента
пытаются принять такие решения за команду проекта (например, кто-то из команды
клиента считает, что он в роли инженера лучше, чем исполнители инженерных
ролей в команде проекта, или решение принимается из политических или
экономических соображений/предпочтений, неизвестных команде проекта), и тогда
эти архитектурные решения, поступающие вместе с требованиями,
называют ограничениями. Общая рекомендация в таких случаях —
согласовывать требования, но торговаться по поводу ограничений (вполне уместно
предлагать свои варианты — вполне возможно, что клиент просто не знает о
существовании альтернатив и будет вполне согласен с предложениями).
Если рассмотреть надсистему нашей целевой системы как чёрный ящик, то она
будет целевой для команды важнейших внешних ролей проекта. И её описание
будет требованиями для этих внешних ролей. И это описание часто так и называют:
требования стейкхолдеров (stakeholder requirements), а чтобы меньше путать
это описание надсистемы-как-чёрного-ящика с описаниями целевой системы, чаще
называют потребностями стейкхолдеров (stakeholder needs, нужды
стейкхолдеров), или ещё короче — потребностями. Как чёрный ящик описывается
надсистема потребностями (стейкхолдеров), целевая система (системными)
требованиями.
А что будет, когда разработчики целевой системы создадут архитектуру, описав
важнейшие решения по устройству целевой системы как прозрачного ящика? Они
ведь опишут подсистемы! Да, и эти описания будут требованиями к подсистемам.
Если эти подсистемы станут целевыми системами для команды каких-нибудь
контракторов, разрабатывающих и/или изготавливающих эту подсистему, то они
будут называть эти «требования к подсистеме» своими «системными
требованиями». А как они будут называть системные требования для целевой
системы нашей начальной команды, для которой они контракторы? Они их будут
называть потребностями, ибо наша исходная целевая система для них —
надсистема. Системное мышление рекурсивно, оно применяется одинаково на
каждом системном уровне, каждой командой. И каждая команда имеет свои
«системные координаты» вокруг своей целевой системы, поэтому самое важное —
это договориться, что же это за система.
 117

Исполнители ролей, которые замышляют, проектируют, изготавливают,

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

Примеры системной терминологии

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

Целевая система — напорный насос, использованный в насосной станции (т.е.

надсистема — насосная станция). Его роль — напорный насос, чтобы вода доходила
до верхних этажей здания, действие/функция — поднимать давление жидкости.
Одна из его подсистем — ротор с лопатками (это центробежный насос/centrifugal
pump).
Одна из внешних ролей/внешних стейкхолдеров — оператор (owner-operator)
насосной станции. Потребность — бесперебойный напор воды, выходящей из
насосной станции (обратите внимание, что потребность говорит не про насос как
целевую систему, а про насосную станцию как надсистему!). Требования:
обеспечивать напор до 40 метров, расход (проток воды) до 10000 литров/час,
наработка на отказ от 5000 часов.
Некоторые системы в окружении: мотор, трубопровод (они входят в состав насосной
станции, но они внешние по отношению к насосу), электрическая проводка.
Некоторые системы в обеспечении: конструкторское бюро (проектировавшее
насос), завод (изготовитель насоса), проектировщик и строитель насосной станции
(они обеспечивали выбор именно этого насоса, его закупку, монтаж на насосной
станции), гаечный ключ (закручивали гайки, которыми насос крепится к
фундаменту).
Другой пример: электроника с островками софта — наручные смарт-часы.

Чтобы определить надсистему, в состав которой (в момент эксплуатации) входят

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

Собственные вещи человека считаются просто продолжением его биологического

тела. Никто не может взять тело человека или повредить его, но никто не может
взять или повредить его личные рубашку, личные часы — они считаются входящими
в состав человека, буквально (отношение is_part_of). Это и есть «священная
частная собственность». Тело = биологическое тело плюс другие личные вещи и
даже плюс средства производства в собственности личности.
Тем самым мы с некоторой условностью можем считать надсистемой для смарт-
часов самого человека-владельца этих часов: часы будем считать буквально
входящими в состав его тела. Для многих личных предметов и инструментов это
подтверждается и психологическими экспериментами: личности относятся к ним
буквально как к продолжению их тела96, «экзотелу».
Ещё одна интересная система этого класса, включающая людей — это домашнее
хозяйство (household), которое может включать и самих владельцев, и дом, и
домашнюю утварь.
В подобного сорта системах входящие в них люди одновременно и являются
ролями/стейкхолдерами с их интересами и предпочтениями (роли личности), и
представляют из себя «просто тело», с которым мы работаем ровно как и с другими
материалами, т.е. просто учитывая его физические свойства — размеры,
влажность, прочность и т.п.
В примере со смарт-часами надсистема — человек-владелец этих часов, но не как
личность-роль/стейкхолдер, а больше как принадлежащее ей тело со всем на него
надетым: рубашкой, туфлями, часами! Конечно, биологическое тело будет
находиться в окружении этих часов!
Потребности личности владельца как внешней роли/стейкхолдера (владельца тела-
с-часами) — он должен быть информирован о времени, но этот список потребностей
по большому счёту остаётся открытым. Роль часов весьма сложна в
формулировании, ибо речь идёт о гаджете с разнообразным
поведением/многофункциональном.
Требования поэтому будут относиться не столько к самим часам, сколько к самым
разным предполагаемым вариантам их эксплуатации — это могут быть как
собственно часы, так и радио, плеер, измеритель пульса, также от смарт-часов
ожидается, что они не натирают руку (рука как часть тела-надсистемы находится в
окружении смарт-часов!), они должны быть модной на момент продажи расцветки,
работать без подзарядки не менее 20 часов, вес должен быть не более 80 грамм, с
ними должен работать магазин приложений, у них должна быть связь с внешним
компьютером (смартфоном, планшетом, десктопом).
Системы в окружении — рука, одежда (как минимум, рукав рубашки или пиджака),
зарядное устройство. Подсистема — защитное стекло из Gorilla glass.
Системы в обеспечении (жизненного цикла) смарт-часов: конструкторское бюро,
завод в Китае, магазин по их продаже. И вот если взять магазин как одну из систем
в обеспечении и рассмотреть роль его продавца, то про смарт-часы можно узнать
много нового. Потребность продавца (требование к магазину) — это продажи на
какую-то немаленькую сумму, что легко переводится в требование для товаров
удобной упаковки для складской обработки, красочной упаковки и буклетов для

96
Brandon Keim, «Your computer really is a part of you», https://www.wired.com/2010/03/heidegger-tools
 120

выкладывания в торговом зале, а также хорошей рекламы (то есть услуга рекламы
рассматривается магазином как часть продукта — без какого-то уровня рекламы
хороший магазин может просто не взять товар в продажу). И часы как товар
получают тем самым дополнительный набор требований для их использования в
магазине.
Это очень важно — выявлять самые разные внешние роли, выявлять их
потребности, а потом выводить из этих потребностей системные требования. И эти
системные требования опишут систему, помогут с определением её границ: что
войдёт в систему, а что не войдёт. В случае часов понятно, что в состав целевой
системы входят и упаковка, и рекламные буклеты, и даже транслируемая по каким-
то каналам реклама. Можно считать, что магазин приложений находится в
обеспечении, но вот с упаковкой так считать уже не получится.
Этот пример показывает, что для разных ролей удобно по-разному определять
целевую систему. Для магазина эта самая упаковка-с-часами будет целевой: её
нужно замыслить (товаровед!), изготовить (закупка! Логистика!), использовать
(продать!). А сами часы? А они не нужны. Нужна упаковка-с-часами!
Современная инженерия часто имеет дело с киберфизическими системами
(cyber-physical systems), которые имеют в своём составе датчики (sensors),
воздействующие на внешний физический мир исполнительные устройства
(actuators: чаще всего разные моторы, но это могут быть и осветительные приборы,
электрические выключатели) и компьютер (cyber-, кибер-, управляющую часть),
который обеспечивает управление работой всей системы. Примером такой системы
может быть дрон для аэрофотосъемки.

Надсистема — строительство. Одна из внешних ролей в проекте — это заказчик-

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

ремонтирует. Поэтому мы считаем, что эта служба не в окружении, а в

обеспечении).

Разделение труда и системные уровни

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

надсистемах, знать, как сделать целевую систему, знать из чего делать —

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

Системы систем
Иногда систему, которая состоит из других систем называют «системой систем». Это
неправильно, это просто система — не нужно специально подчёркивать тот факт,
что любая система состоит из систем. Тем не менее, термин система систем
(system of systems, SoS) есть, он закреплён за особым случаем выделения систем
по социальным характеристикам их обеспечения, а не по чисто техническим
вложенности друг в друга.
Системой систем называют такую систему, которая (критерии Maier 97):
● Имеет независимое обеспечение её подсистем (нет полномочий предписать
общее развитие-модернизацию)
● Имеет подсистемы, которые могут работать независимо от существования
целевой системы (нет полномочий по указанию, как работать)
● Эмерджентность/системный эффект от объединения в систему (кто-то желает
получить от целевой системы систем функцию/поведение, которое
невозможно получить от работы с отдельными входящими в систему систем
отдельными системами, и требуется совместная работа этих входящих
независимых систем).
● Эволюционное развитие (понимание того, что будет происходить в системе
систем на каждом следующем шаге проекта требует исследований и
дополнительных согласований, ибо нет роли, которая знает, как в каждый
момент устроена система систем — они ведь все меняются независимо)
● Географическое распределение входящих систем.
Эти критерии различаются, конечно, в разных инженерных и менеджерских школах,
но общее остаётся: обычные «системы» подразумевают централизованное
«владение» системой — наличие ролей/стейкхолдеров/заинтересованных сторон,
полномочных принимать решения по всем частям системы, полномочных
распоряжаться всем, что в границах их системы. Это традиционный случай:
автомобиль с двигателем и колёсами, железнодорожный мост и компьютер — это
типичные «просто системы», у них есть свои системные инженеры, которые
полностью определяют их функции, конструкцию, возможности по работе в том или
ином окружении, составляют и выполняют планы по модернизации и выводу из
эксплуатации. У каждой из этих «просто систем» есть один хозяин, один владелец.
А вот в системе систем каждая из входящих в неё систем имеет своего хозяина, и
входящие системы могут работать/эксплуатироваться/функционировать автономно,
без вхождения в систему систем. Тем самым разница между «просто системой» и
«системой систем» определяется не через особую структуру или конструкцию
системы, а через наличие независимых друг от друга систем в обеспечении,
описывающих и воплощающих входящие в систему систем отдельные системы, а

97
http://sebokwiki.org/wiki/Systems_of_Systems_(SoS)
 123

затем имеющие возможность независимо их использовать.

В системе систем важны прежде всего владеющие частями-системами полномочные

люди, именно они делают систему систем особым случаем.
В ISO 15288:2015 выделено четыре типа систем систем, отличающихся степенью
их автономности:
● управляемые (directed), в которых есть назначенный архитектор, который
может выдавать приказы командам проектов составляющих систем и
распоряжается общими ресурсами.
● подтвержденные (acknowledged), в которых признаваемый архитектор
есть, но он может только уговаривать составляющие системы самоизмениться
согласно разработанной им архитектуре.
● сотрудничающие (collaborative), в которых все системы договариваются
друг с другом по каждому чиху, но архитектора, менеджера проекта или
аналогичного выделенного органа управления нет.
● виртуальные (virtual), в которых системы вообще не знают друг о друге
ничего и не влияют друг на друга явно.
Был путём проб и ошибок выведен основной способ работы с системами систем:
совместная постепенная асинхронная эволюция (модернизация) входящих в
систему систем автономных систем — ибо согласованность и синхронность
изменений в этих автономных системах крайне сложно обеспечить. Даты
утверждения проектов модернизации входящих в систему систем отдельных систем
будут различаться, получаемое на модернизацию финансирование будет
выделяться в разные моменты и нельзя будет гарантировать его достаточность,
некому будет вести общий проект реформирования как инженерно, так и
менеджерски, не говоря уже об общем целеполагании (технологическое
предпринимательство). Хозяева автономных систем могут иметь разные мнения по
поводу взаимодействия их систем с другими автономными системами в составе
системы систем, они могут сопротивляться переменам, ибо их вполне может
удовлетворять и автономная работа их систем в их надсистемах, а желание какого-
то даже влиятельного исполнителя стейкхолдерской роли об объединении
автономных систем в общую систему систем они могут не разделять.
Для работы с системами систем тем самым необходима практика лидерства,
понимаемая как катализирование сотрудничества: это «режиссёрская» практика в
театральной метафоре, как уговорить исполнителей ролей исполнять их роли в
выбранной режиссёром к постановке пьесы. В больших системах это лидерство
 124

распределённое (нет одного «режиссёра», все выполняют роль лидера, каждый

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

Люди в системах
Человек в составе систем учитывается сложно, ибо он одновременно может быть и
целевой системой («продуктом»), и «оборудованием» в составе систем
обеспечения, и служить надсистемой, но всегда при этом человек остаётся
стейкхолдером/ролью в проекте: мы можем не учитывать мнений и интересов
животных (хотя и это плохо) и тем более роботов с AI, но мы принципиально не
можем не учитывать мнений людей-в-ролях. А ещё у людей есть отношения
подчинения/руководства и отношения собственности по поводу вещей.
В случае же, если это не один человек, а их несколько, всё становится ещё сложней:
люди могут договариваться друг с другом по самым неожиданным поводам и
предпринимать в этой связи самые неожиданные для команды проекта действия.
Помним, что в области интереса у каждой роли есть не просто предпочтения в
каких-то значениях интересных характеристик, но и намерение изменить
характеристику для реализации предпочтений. Люди дьявольски изобретательны в
реализации своих намерений. И они будут влиять на ход проекта по созданию
системы и на получившуюся систему самыми неожиданными способами.
Пример системы с входящими в её состав людьми — это танец (помним:
разворачивающийся во времени процесс задаётся как перечисление входящих в
него взаимодействующих физических объектов. Танец тоже может быть так задан,
танец вполне можно представить как систему, только её нужно представлять как
существующую в пространстве-времени, а не только в пространстве). В танце люди
выступают и как материал (физические тела, меняющие форму в пространстве-
времени), и как стейкхолдеры (в разных танцах они бывают самые разные, мы уже
обсуждали этот вопрос в предыдущих разделах книги), танец является при этом
процессом, но при этом танец не обладает сложностью предприятия и тем самым
не требует рассмотрения сложных вопросов корпоративного управления,
стратегирования, операционного менеджмента/управления работами. Танцы
бывают и сольные, и социальные (парные), и групповые/ансамблевые. Это
отличный пример, на котором можно тренировать своё системное мышление 98.
Мероприятия так же являются классическим примером систем с людьми.
Менеджмент мероприятий (event management99) даже стал университетской
дисциплиной — сделать (задумать, спроектировать, изготовить,
проэксплуатировать и затем вывести из эксплуатации) концерт или фестиваль
трудно, но ничего необычного в этом уже нет, рассмотреть тысячи людей в составе

98
Танцевальное мышление и его развитие, http://ailev.livejournal.com/1332624.html
99
https://en.wikipedia.org/wiki/Event_management
 125

системы-мероприятия вполне возможно.

Домашнее хозяйство, где есть дом с утварью и его жильцы, уже рассмотренный
случай потребителя одежды и гаджетов — это всё примеры систем с людьми.
Сложнейшими системами с людьми являются системы обеспечения — предприятия,
рабочие группы проекта, расширенные предприятия (extended enterprise),
предприятие с его контракторами, занимающееся какой-то большой целевой
системой (например, самолётом или автомобилем).
Системы с людьми — это системы систем в силу того, что люди обладают
свойством самопринадлежности. Поэтому с системами с людьми в их
составе нельзя работать простыми инженерными методами, в которых
можно сконструировать простую механическую или механическую с
элементами электроники систему, изготовить её части и собрать их в
работоспособное целое. Нет, метафора часовщика с изготовлением деталей
и их сборкой не работает. С людьми (как и любыми другими живыми системами)
больше работают «сельскохозяйственные» метафоры:
• в небольших системах систем садовника (который имеет контроль над тем,
что выращивает),
• больших системах систем лесника (который не имеет контроля над своим
лесом — где какое дерево или кустик вырастет, но тем не менее лесник имеет
достаточно влияния, чтобы предотвратить какие-то серьёзные негативные
события: может предотвратить пожар, подкормить зимой животных, отогнать
браконьеров).
В особо крупных системах (большое сообщество, общество в масштабах
государства, всё человечество) говорят уже не просто о сложности системы, а
сложностности или даже сложносистемном мышлении100, что не позволяет как-то
строить действия с предсказуемым результатом — результаты всегда вероятностны.
В особо крупных системах всё настолько сильно связано друг с другом и настолько
неожиданно реализация намерения одних людей сопротивляется или помогает
реализации намерений других людей, что неожиданности являются нормой, а
отсутствия неожиданностей практически не бывает.
Нужно помнить, что предприятие или даже команду нельзя
проектировать, а потом изготавливать как танк или водонапорную
башню. Системы с людьми должны обсуждаться с использованием
системного мышления, но вот замышлять их, создавать, эксплуатировать,
ликвидировать их методами системной инженерии нельзя.
Трудно представить, что левый ускоритель в ракете будет подговаривать правый
ускоритель лететь не к Марсу (куда они должны лететь), а к Луне — потому что так
надёжней и быстрей, заведомо хватит топлива и менее хлопотно. А вот в системе
из людей такое бывает сплошь и рядом. Осторожней с применением
инженерных практик к системам с людьми. Хотя так же осторожно нужно
относиться и к обратной ситуации — неприменению инженерных практик.

100
См. литературу в П.К.Гречко «Сложносистемное мышление: методологические перспективы.
Парадигмальная эвристика complexity в современном социально-гуманитарном познании» http://web-
local.rudn.ru/web-local/prep/rj/files.php?f=pf_e78b9721c199d6a0e389b198f287d4d5
 126

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

Если ребёнку в руки попадает молоток, то все предметы в доме превращаются в
гвозди — и это означает, что не ребёнок владеет инструментом, а инструмент
владеет ребёнком. Если системный инженер или менеджер, и уж тем более
предприниматель встречается с госстроительством, то он непременно хочет им
заняться (ибо это обычно прибыльно: деньги ведь на проект собирают со многих
под угрозой наказания за неуплату налогов, а отдают ему одному, поэтому почему
бы и не заняться?). Если госстроитель (политик) знакомится с системным подходом,
системной инженерией или менеджментом, то он непременно захочет их
использовать. Системную инженерию в её классическом виде для целей
госстроительства использовать нельзя, она предназначена прежде всего для кибер-
физико-человеческих систем совсем небольших масштабов — в которых чётко
определены проектные роли, занимающимися какой-то «традиционной»
аппаратной или даже программно-аппаратной системой.
В госстроительстве имеют дело главным образом с системами из людей. Обратим
внимание, что создание таких инженерных проектов, как вполне программно-
аппаратные системы слежки за гражданами, системы эффективного убийства
(обычно называемые оружием, и при этом помним, что все в мире министерства
нападения называют себя министерствами обороны), систем принуждения к уплате
налогов и т.д. — это ведь впрямую связанные с госстроительством проекты, и они
не столько про «железо» и «софт», сколько про людей. Создание эффективных
газенвагенов в фашистской Германии — это задача была инженерная, или всё-таки
связанная с людьми?
Краткий тут совет — если уж нужно заняться госстроительством, то используйте
знания по этике, политологии, конфликтологии, праву, экономике, социологии и
системное мышление в его «мягких» вариантах, но не используйте системное
мышление в вариантах системной инженерии, системного менеджмента, системного
предпринимательства. Государство и люди в нём — это не отсеки подводной лодки,
это не детали медицинской аппаратуры, это даже не атомная электростанция
вместе с её персоналом. Помним про эффект бомбардировщика: лётчик вряд ли
кого сможет убить в штыковой атаке, совесть не позволит. А вот сбросить атомную
бомбу на город — запросто, город ведь далеко, смертей не видно. Люди,
занимающиеся работой с государством, должны помнить, что им придётся играть
роли, которые будут уменьшать свободы граждан. Это этический выбор.
У проекта всегда есть вполне определённые проектные роли/стейкхолдеры,
которые платят за этот проект: заказчики проекта (их может быть много разных!).
Кто заказчик в госстроительстве? Политики? Чиновники? «Народ» (например, опрос
общественного мнения или фокус-группа)? «Элита» (и кто её определяет)? Группы
экспертов (вариант «экспертократии» — но как выбрать из этих групп
«правильную», все эксперты ведь говорят разное)? Нужно чётко понимать, что в
случае госстроительства речь идёт о политике, а не о классических проектных ролях
при создании систем. Не нужно себя обманывать, говоря, что «есть заказ,
оплачивается он из бюджета, следовательно заказчиком является тот чиновник,
который будет подписывать мне акт приёмки работ». Госстроительство — это
прежде всего политика, в политике подобные рассуждения неприемлемы. Что для
одного человека в роли политика успех, для другого будет полным провалом, и
наоборот, и таких различий в предпочтениях для каких-то интересов столько,
сколько разных политических групп. Поэтому государственные проекты будут
 127

неуспешными по определению: в них никогда не будут учтены предпочтения в

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

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

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

Будущее и ведущая дисциплина предпринимательства

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

деятельности существуют только «для отвода глаз», упоминания в идеологических документах, а не для
реального дерегулирования.
 129

обычно интересно тем ролям, которые люди играют в своей жизни.

Будущее представляется людям как окружение для множества надсистем, для
которых эти люди в каких-то проектных ролях будут делать их целевые системы.
Какие это надсистемы? Это описывается будущими потребностями. Какие именно
системы будут люди делать в будущем? Это описывается будущими требованиями.
Мы узнаём будущее по описаниям его целевых систем и их надсистем — по
требованиям и потребностям. «Будущеведение» тем самым — инженерия
требований. Это не меняется ни для ближайшего (дни и месяцы), ни для среднего
(год-три), ни для далёкого (от трёх лет — сегодня и на три года ничего загадать
нельзя!) будущего.
Предприниматели зарабатывают на том, что могут предвидеть будущее. Тем самым
ведущая дисциплина предпринимательства — это инженерия требований
(requirements engineering), которая занимается выявлением потребностей
(stakeholder needs/requirements) и требований (system requirements).

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

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

Самые простые системы — это системы с механическими и электрическими

элементами (mechanical and electrical elements), вроде велосипеда, насоса или

102
http://www.incose.org/
103
http://www.incose.org/AboutSE/sevision
 130

холодильника. Более сложные — это в которых можно найти электронику, и

контроллеры с программным обеспечением, управляющие логикой работы каких-то
элементов системы (electronic, isolated islands of software), например, стиральная
машина или современный автомобиль с двигателем внутреннего сгорания. Но вот
уже реактивный самолёт или космический корабль с трудом попадает в эту
категорию: логика их работы уже полностью определяется программным
обеспечением, поэтому такие системы называют программоёмкими (software-
intensive). Это граница применения классической инженерии, все учебники
системной инженерии, все стандарты по факту описывают практики создания
именно таких систем.
Но человечество не останавливается на создании только таких систем, для которых
есть хорошо разработанные методологии. Нет, есть и более сложные системы, и
относительно новый класс таких систем — это сетеёмкие (network-intensive).
Сеть — это обычно какой-то набор узлов и связей между узлами, и поток чего-то
по этим узлам. По сети интернет бегут потоки данных, по водопроводной сети —
вода, по сети датчиков — данные. Сетеёмкие системы сложнее программоёмких,
потому как обычно для сложных сетей в каждом конкретном месте сети неизвестны
все остальные узлы, и неизвестны все связи. Более того, каждый момент времени
ситуация может меняться, поэтому программы управления потоками для такой сети
должны учитывать эти изменения. Это крайне сложно делать: сеть по факту имеет
меняющуюся на ходу структуру, и её нельзя спроектировать и реализовать, для неё
можно только сформулировать общие Принципы, определить структуру узлов и
виды связей — и дальше опять мы оказываемся в мире сложностности с
сельскохозяйственными метафорами садовника и лесника. Сетеёмкие системы
сегодня — фронтир системной инженерии, наряду с системами искусственного
интеллекта, вообще не попавшими в работу 2014 года. Так что укажем, что кроме
сетеёмких систем общепризнанным фронтиром служат беспилотные автомобили —
тоже потому как нельзя «изготовить» и «собрать из деталей» нейронную сеть,
принимающую решения вместо водителя. Такие сети не программируют, а обучают,
и мы опять же оказываемся в «сельскохозяйственном мире» выращивания
искусственного интеллекта беспилотника.
Ещё более сложные системы — это предприятия и другие системы с
организационным надзором, в том числе децентрализованным (enterprise,
organizational governance (decentralized)). Governance рекомендуем переводить как
«поднадзорность», а не «управление»: governance означает, что поднадзорный
субъект не выскальзывает из-под надзора, а продолжает выполнять свои
обязательства исполнять поручения руководителя. Созданием таких
организационных систем занимаются не системные инженеры, а инженеры
предприятий (enterprise engineers, которые, впрочем, с удовольствием пользуются
учебниками и стандартами системного подхода и системной инженерии, равно как
и менеджерскими учебниками, стандартами и публичными документами). В состав
этих систем входят люди, поэтому в силу самопринадлежности людей предприятий
мы сразу говорим о них как о системах систем. Но на этом уровне хотя бы есть
поднадзорность/governance, то есть существуют организационные роли, которые
полномочны выдавать общие распоряжения по использованию ресурсов
оргзвеньев, в том числе и ресурсов средств производства, и трудовых ресурсов
других людей.
Самый сложный вид систем — это системы систем в общем виде. С ними не может
 131

быть гарантии, что они все по степени автономности управляемые, как на

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

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

Понятие сложности интенсивно разрабатывалось не только в рамках системных
исследований (т.е. исследований по развитию системного подхода), но и во
многих других дисциплинах. Окончательного согласия по тому, что такое сложность
нет, и не предвидится: для разных проектов и разных ролей в проектах интересны
разные виды сложности. Seth Lloyd собрал некоторые примеры определений для
мер сложности105. Все эти определения он отнёс к попыткам ответа на три вопроса:
1. Насколько трудно описать систему? Обычно это измеряется в битах,
затрачиваемых на представление описания. Мерами сложности тут будут
информация, энтропия, алгоритмическая сложность или алгоритмическое
содержание информации, максимальная длина описания, информация Фишера
(Fisher), энтропия Рени (Rényi), длина кода (беспрефиксного, Хаффмана, Шэннона-
Фано, корректирующего ошибки, Хамминга), информация Чернова, размерность,
фрактальная размерность, сложность Lempel-Ziv.
2. Насколько трудно создать систему? Сложность как трудность создания
измеряется во времени, энергии, долларах и т.д. Меры сложности тут
вычислительная сложность, временна́я вычислительная сложность,
пространственная вычислительная сложность, основанная на информации
сложность, логическая глубина (depth), термодинамическая глубина, цена,
шифрованность (crypticity).
3. Какая степень организованности? Тут может быть два варианта:
а) «результирующая сложность» (effective complexity), трудность описания
организационной структуры, неважно корпоративной, химической, клеточной.
Приведём их по-английски: Metric Entropy; Fractal Dimension; Excess Entropy;

104
https://en.wikipedia.org/wiki/Business_ecosystem
105
http://web.mit.edu/esd.83/www/notebook/Complexity.PDF
 132

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. Есть
и совсем альтернативные меры сложности (например, основанные на скорости
описания оцениваемых объектов, а не объёме этого описания106).
Ситуация с понятием «сложность» очень характерна для системного подхода:
употребляемые в нём слова кажутся вполне «бытовыми» и имеющими ясные и
интуитивно понятные с детства значения. Но нет, слова эти вдруг оказываются
терминами, за которыми скрываются очень сложные и противоречивые понятия, с
этими понятиями работают самые разные логические или количественные модели,
проводятся количественные измерения самых разных их характеристик.
В рамках настоящей книги мы будем считать сложной систему из
достаточно большого количества элементов, настолько большого, чтобы
в одной голове не получалось оценить все связи и взаимодействия. Если в
системе пятьсот человек, этого вполне достаточно, чтобы в одной голове не
получилось оценить все связи и взаимодействия этих людей. Это сложная система.
В одной голове так же трудно удержать все связи и взаимодействия в системе
смартфона, в системе атомной электростанции, многих других инженерных
системах. Для наших целей обучения системному мышлению такого неформального
понимания сложности вполне достаточно, но вы должны помнить, что кроме этого
неформального понимания, есть и другие, формальные понимания сложности, есть
множество теорий сложности, из которых пришли эти формальные понимания.
Системное мышление не даёт никаких «объективных ответов» на вопросы о
системах. Эти ответы всегда зависят от того, какая роль спрашивает, и какая роль
даёт ответ. В системном мышлении нет никакого алгоритма, приводящего к
правильному ответу, нет последовательности шагов, гарантирующих какой-то
приемлемый результат этого мышления. Системное мышление сложно, его долго
осваивать — этим оно напоминает какую-то «необъективную высшую математику».
Системное мышление даже не трудится давать точные определения своим
понятиям: разные стейкхолдеры норовят приспособить эти понятия для своих самых
разных потребностей. Но понятия системного мышления позволяют
компактно и просто описывать сложный мир! Альтернативные варианты
(например, редукционизм) оказываются много хуже.

5. Целевая система и её надсистема

Сначала найти целевую систему
Первое, что нужно делать в системном мышлении — это не думать о всех системах

106
http://people.idsia.ch/~juergen/speedprior.html
 133

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

изменить, или эксплуатировать, или уничтожить. Сначала нужно найти целевую
систему (system-of-interest). Это очень непросто (речь идёт о
предпринимательской задаче!), а ошибки часты и дорогостоящи.
Большинство предпринимательских проектов неудачны! Систему ведь
нужно создавать сейчас, а для этого предвидеть её успех в будущем. Но
будущее предвидеть гарантированно в общем случае нельзя, можно
только угадать — и это часто не удаётся.
Если нет беглости в системном мышлении, то вы будете определять целевую
систему неправильно не только потому, что плохо предвидите будущее, но и просто
с ошибками непродуманности. Если вы определите целевую систему неправильно,
то вы просто будете заниматься не тем, чем надо, будете зря тратить время: фокус
вашего внимания будет не на важном, а «рядом с важным» или даже «далеко от
важного».
Успешность (в том числе предпринимательская успешность) создаваемой системы
не может быть только «спроектирована» и тем самым гарантирована
(неопределённое будущее всегда внесёт свои коррективы), но системное мышление
поможет избежать многочисленных ошибок — хотя бы тем, что с самого начала
поставит вопрос о вероятностной оценке успешности создаваемой системы, и будет
требовать постоянно отслеживать эту вероятностную оценку в ходе всего проекта
по замысливанию, созданию, эксплуатации и ликвидации системы. Вовремя
замеченные признаки возможной неуспешности дадут команде шанс как-то на них
отреагировать, в том числе и отреагировать путём закрытия проекта — тратить
ресурсы на заведомо неуспешный проект ни в коем случае нельзя, а системное
мышление поможет обнаружить необходимость закрыть проект раньше. Но могут
найтись и способы продолжить проект, увеличив вероятность его успешности —
если будет понятно, над чем нужно будет задуматься в первую очередь, на что
потратить время размышлений о будущей системе.
Предпринимательство тут совсем необязательно в классическом экономическом
смысле слова (то есть системы делают совершенно необязательно из-за желания
заработать деньги). Кто-то может танцевать («делать танец»), но и в этом случае
нужно думать о том, чтобы танец был успешен: успех танца определяется не
успехом в глазах только танцора. В некоторых странах на похоронах не принято
танцевать, а в некоторых странах наборот, принято — с гробом на плечах. Нужно
смотреть на обстоятельства танца, а не только на сам танец как систему. И только
ли танец тут целевая система, или танец тут только подсистема в чём-то большем?
В системном мышлении нужно всегда думать о системе в её системном окружении
и о мнении внешних проектных ролей в обеспечении. Успех определяется
обеспечением, которые должны быть довольны системой в её окружении и её
проектом в обеспечении. Если система никому не нужна (то есть никому не нужно
её поведение в надсистеме, ни для чьей надсистемы не нужна функция этой
системы в достаточной мере, чтобы окупить затраты на создание системы), если
система заведомо неуспешна — её не делают.
Но перед тем, как пытаться оценить успешность системы, нужно её найти.
 134

http://fotokto.ru/photo/view/3189859.html
Целевая система в системном мышлении — это как начало координат в ментальных
«полярных координатах». Все остальные решения по поводу выделения других
систем — надсистемы, систем в окружении, подсистем, систем в обеспечении —
делаются по отношению к целевой системе. И успешность тоже тем самым
определяется по отношению к целевой системе и проекту её создания.
Целевая система определяется субъективно, «система в глазах смотрящего»,
поэтому вопрос определения «системы, которую вы хотите сделать» начинается с
внимания к тому, кто такие «вы»: сколько вас, какие у вас интересы. Системное
мышление — это мышление коллективной/групповой деятельности, оно позволяет
большим командам договариваться в проектах с миллионами индивидуальных
деталей в целевых системах, удерживая внимание разных ролей на их общем
важном, чтобы без потери этого внимания к системному целому позволить
заботиться о деталях подсистем отдельным членам каждой команды.
Для выявления целевой системы нет строгих правил, алгоритма,
последовательности мыслительных шагов, порядка опроса каких-то людей. Так или
иначе в решении по поводу выбора целевой системы будут участвовать самые
разные люди в самых разных ролях, и речь идёт не только о членах команды, но и
о внешних ролях. Если у вас проект, который вы можете сделать в одиночку, то вам
не потребуется развёрнутого системного мышления. Но если проект сложный и
работает группа, то в принятии решений заведомо будет сложный переговорный
процесс и о целевой системе придётся договариваться по ходу дела. Обычно
целевую систему нельзя определить, сидя на своём рабочем месте и
размышляя: требуется не только читать самые разные документы и
хорошо знать свою предметную область, но встречаться и разговаривать
со многими людьми. Не нужно путать «нашу систему» (MySystem, OurSystem,
«мою» личную, или «нашей маленькой команды») и целевую систему: без целевой
системы системного мышления для нашей системы не выстроишь, и поэтому наша
 135

система не будет успешной — мы будем счастливы, наши интересы учтены, но успех

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

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

Целевая система раньше часто мыслилась как поставляемый продукт. Система как
физический объект изготавливается командой проекта, а затем поставляется его
конечному потребителю. И уже у потребителя этот продукт выполняет свою роль:
действия, назначенное ему поведение в ходе эксплуатации.
Потребитель/клиент/собственник системы использует этот продукт двумя
способами:
• в составе своей целевой системы (например, ваши часы-продукт он
устанавливает в свой автомобиль-продукт, а затем продаёт автомобиль
своему клиенту)
• в составе своей системы обеспечения своего клиентского продукта
(например, ваши часы-продукт он устанавливает в свой цех на стену, чтобы
рабочие могли следить за временем в ходе сборки ими клиентского
автомобиля — продаёт же клиенту автомобиль без часов или с какими-то
другими, не вашими часами).
Альтернативный вариант — считать сразу, что целевая система-продукт не у вас,
 136

а у клиента. Работа не из вашего сырья и передача продукта заказчику, а из сырья

заказчика и оставление продукта у заказчика. А ваши тут будут только работы,
изменения в чужой для вас целевой системе. Вы будете тут только системой в
обеспечении, ваша команда будет предоставлять клиенту только внешнее
поведение — сервис (service, услугу) вашей системы107.
Например, парикмахерская оказывает услуги/действия по стрижке головы.
Важные объекты для удержания внимания в этой (и любой другой подобной!)
ситуации предоставления сервиса:
• Надсистема (окружение) — как ролевой/функциональный объект «голова для
свидания» (но не «голова для еды в неё», например, или «голова для занятий
спортом». Определение объекта по назначению/роли/функции/целевому
поведению).
• Потребность (клиента как внешней проектной роли сервиса стрижки) —
«голова должна быть красивой для свидания» (описание вашей надсистемы
= целевая система для клиента парикмахерской, ваша целевая система =
подсистема для клиента, или даже подподсистема, если клиента интересует
внешний вид всего его тела, а не только головы).
• Целевая система: причёска (ролевой/функциональный объект). Получается
из волос клиента путём выполнения работ по стрижке.
• Требование (системное, к целевой системе): волосы должны быть красивы.
• Сервис (оно же внешнее поведение, оно же работы по обеспечению
требования): стрижка волос.
• Система в обеспечении сервиса: парикмахерская. Сервис (стрижка волос) —
это не сама парикмахерская, сервис — это её поведение!
Сервис тут «стрижка», обратите внимание на отглагольное существительное: это
одинаково для конструктивных поведений/сервисов и ролевых поведений/функций.
Только ролевое поведение/функция — это обычно «какое действие/поведение им в
их надсистеме нужно от нас» (и они это знают лучше и формулируют в языках
надсистемы). Сервис — «какое действие/поведение/работу выдаёт наша система
как реализационный/конструктивный объект/модуль».
Сложно? В первый раз — да, сложно. Потом будет проще и проще. Но зачем так
сложно? Затем, что во внимании оказываются моменты ситуации, которые
позволяют обсудить:
• Потребности — для чего всё это нужно. В чём счастье внешних ролей, а не
счастье внутренних ролей. Если причёска будет, но голова окажется после
выполнения причёски не в порядке, то беда. Если причёска будет для спорта,
а не свидания — беда. Всегда обсуждаем/описываем в паре целевую систему
(причёску) и надсистему (голову) в их назначениях (ролях). Описание
надсистемы — потребности, описание целевой системы — требование.

107
В литературе можно найти много разных мнений, что такое «сервис», вот только несколько работ на эту
тему: https://yadi.sk/d/4hIEcpcn3Ny9iN. Основная путаница тут в том, что «службой» называют и процесс
(разворачивающееся во времени действие, наблюдаемое вовне поведение) оказания услуги, и ту систему,
которая вызывает это поведение, т.е. «слугу». И это иногда компонентные «слуги», а иногда модульные.
Изредка «сервисом» называют ещё и интерфейс между «слугой» и изменяемым этим слугой внешним
миром. В нашей книге мы придерживаемся мнения, что сервис — это внешнее поведение системы как
модуля. Это мнение в том числе поддерживается спецификацией архитектурного языка ArchiMate:
http://pubs.opengroup.org/architecture/archimate3-doc/chap08.html
 137

Требования должны как-то прослеживаться/трассироваться к

потребностям.
• Выбранный сервис парикмахерской будет «стрижка». «Сервис
парикмахерской» — это поведение системы в обеспечении, взятой как
конструктив/реализация/воплощение/модуль. Это поведение — работы по
выполнению практики «стрижка» (работа занимает конкретное время,
использует конкретное оборудование и ресурсы. А если говорить «вообще
как это делается», то это — практика). Но могло бы быть «мытьё головы и
укладка», «закрытие головы шляпой», и т.д. Сервис выбирают! Нет
выбора — нет свободы. В этом суть: ролевое поведение/функция/внутреннее
поведение надсистемы и сервис/внешнее поведение продумываются
отдельно в групповой работе: одно ролевое поведение/функцию для
заказчика/клиента/пользователя может исполнить несколько разных
сервисов поставщика/подрядчика/исполнителя. Один
ролевой/функциональный объект или поведение может быть воплощён
несколькими разными реализационными/конструктивными/физическими
объектами с их сервисами/работами.
Голова (надсистема целевой) и волосы на голове (подсистема целевой)
принадлежат клиенту, парикмахерская — система в обеспечении, производит
внешнее поведение (сервис «стрижка»), меняющий голову так, чтобы на ней
появилась причёска (подстриженные волосы, результат взаимодействия с
парикмахерской).
Что является целевой системой? Причёска! А наша парикмахерская? Она наша
система! На её счёт мы выполняем полностью рекурсивно всё системное мышление,
но она находится в другом, нежели причёска системном разбиении. Она может быть
частью парикмахерского холдинга, городского квартала, у неё такие части как
парикмахерское кресло, зеркало и ножницы. Когда речь идёт о сервисе, то мы
обычно проектируем и изготавливаем нашу систему в обеспечении, но выстраиваем
всё мышление всё равно, думая о целевой системе. Если бы нужно было что-то
делать с ракетами, а не с волосами клиента, то мы бы делали ракетное
производство, а не парикмахерскую. Сначала понимаем, что делаем (целевую
систему в её окружении), затем предлагаем вариант обеспечения (помним, что
могут быть варианты! Поставщиков сервисов много, и они конкурируют). Выбор тех
или иных решений по оказанию сервиса/устройству парикмахерской
отслеживается/трассируется и к потребностям надсистемы нашей системы
(например, потребностям владельцев парикмахерской), и к потребностям
владельцев целевой системы (потребностям владельцев волос, которым делают
стрижку).
Описание системы делается и для причёски (целевой системы), и для
парикмахерской (нашей системы). Воплощение системы будет и у парикмахерской
(нашей системы), и у причёски (целевой системы). Внешние проектные роли с их
интересами, предпочтениями в этих интересах и деятельностными намерениями по
реализации этих предпочтений будут и у проекта создания парикмахерской, и у
проекта создания причёски — роли будут разные, интересы и предпочтения будут
разные, забыть никого нельзя, ибо это связано с и с успешностью причёски, и с
успешностью парикмахерской.
Но целевая система будет — причёска, ибо только упустишь из виду, что делать в
конечном итоге нужно причёску (а не «нашу» парикмахерскую), парикмахерская
 138

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

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

Если учесть сервис-ориентацию, то услугой будет «поставка чугуна», и это резко

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

Сервис-ориентация чудесным образом расширяет возможные рынки: разных

типов/видов/категорий/классов действий в мире не так много, несколько тысяч (и
поэтому глаголов в языках всего несколько тысяч), а вот разных видов вещей —
миллионы и миллионы (поэтому существительных миллионы). Мышление о сервисах
экономно: с миллионами и миллионами разных товаров работают одни и те же всё
более и более универсальные сервисы.
Переход от «вещей» к «поведению», изменениям, динамике оказывается очень
продуктивен, поэтому сервис-ориентация стремительно вытесняет ориентацию на
продукт. Операционная система Windows 10 уже рассматривается фирмой Microsoft
не столько как продукт (целевая система, которая передаётся клиенту), но как
сервис по её поддержанию (целевая система у клиента, но Microsoft меняет версии,
добавляя возможности — улучшает целевую систему своим внешним поведением).
Современный магазин тем самым поставляет не продукт, а сервис по продаже
продукта. Программы не нужно поставлять клиенту, ему нужно поставить сервис
(внешнее поведение) этой программы — сама программа может остаться в
датацентре компании, которая эту программу разрабатывает. Так появляются
системы SaaS — software-as-a-service. Заметим, что в данном случае используется
метонимия108: сервисом называется сам service/услуга/поведение, а не
оказывающий эту услугу софт в датацентре. Слова важны и не важны: главное тут
понять, что целевая система — у клиента, а софт находится в составе системы
обеспечения жизненного цикла этой целевой системы. Сервис этого софта делает
какие-то работы с целевой системой (например, меняет описание целевой системы,
отражая это в документации целевой системы, например, меняя содержание своей
базы данных с описанием клиентской целевой системы — а затем это описание
используется для физических изменений воплощения целевой системы, и вся затея
с сервисом именно для этого конечного физического изменения).
Если вам поручили «сделать сервис», то можно совершить крупную ошибку:
считать, что целевой системой является оказывающая сервис система. Нет, целевой
системой является та система, которую мы изменяем сервисом, а сервис в данном
случае — это поведение нашей системы, а наша система в обеспечении!
Целевой системой парикмахера является причёска, сервисом — стрижка (когда
делают ножницами чик-чик, происходит работа, изменения в мире), а
парикмахерская вместе с парикмахером — система в обеспечении жизненного
цикла причёски. Причёска изменяется из «не было» в «стало», с ней работают —
это и есть жизненный цикл причёски. Парикмахерская его обеспечивает.
Шикарный сервис стрижки (работы парикмахерской с волосами клиента) с
результирующей плохой причёской это ведь не то, что нам нужно? Причёска для
спорта вместо причёски для свидания — это ведь тоже не то, что нам нужно?
Никогда не нужно забывать о целевой системе и её надсистеме, когда мы
занимаемся системой в обеспечении, чтобы получить сервис: легко забыть, для чего
существует обеспечивающая система, для чего существует сервис — и в этот
момент целевая система перестаёт быть успешной, вы теряете недовольных
клиентов. А если вы о целевой системе и её внешних стейкхолдерах/проектных
ролях думаете, то думайте явно! И обсуждайте эти мысли с другими людьми.
Системное мышление заставит вас это сделать, не даст допустить ошибку, не даст

108
Термин «метонимия» вам уже встречался, но мы напомним: https://ru.wikipedia.org/wiki/Метонимия
 140

другим людям подумать, что вы допускаете эту ошибку.

Примеры сервисов
Вам совсем необязательно проговаривать типы, как это мы делаем тут в учебном
тексте: «фрукт яблоко», «система самолёт», «система парикмахерская в
обеспечении жизненного цикла причёски», «сервис стрижка парикмахерской как
системы в обеспечении» и т.д. В жизни важно просто обращать внимание на все эти
объекты. Вопрос в том, как вспомнить о том, что вы о них должны подумать? Это
гении могут вспоминать всё нужное вовремя и «по наитию». Системные мыслители
обычно не гении, поэтому они поступают не «по наитию»: они используют понятия
системного подхода как чеклисты — и проверяют, подумали ли они обо всём
нужном, когда речь идёт о сервисе: о системе обеспечения, которая сервис
оказывает, о целевой системе, о надсистеме, о нашей системе (совсем
необязательно это будет оказывающая сервис система обеспечения!), и т.д.
Термины из системного подхода (например, предлагаемые нашей книжкой) полезны
в момент обучения, а потом для обсуждения того, о чём уже подумали, а о чём
хорошо бы подумать, а то и пойти побеседовать со знающими людьми, потому как
многое не нужно выдумывать, а нужно выявлять.
Рассмотрим простейший пример: задача, полностью эквивалентная ситуации с
парикмахерской — но вы будете делать шлифовальную мастерскую. Удивительно,
но редко сталкивающиеся со шлифованием люди мало задумываются над ровно
теми же вопросами, которые им могут прийти в голову, когда они думают над
хорошо знакомой им ситуацией стрижки в парикмахерской. И вот это «задуматься
над важным, когда оно пропущено» — в этом и проявляется сила системного
подхода, сами понятия системного мышления тут являются ключевыми
подсказками.
Шлифовальная мастерская — система в обеспечении чего? Сервиса шлифования! А
целевой системой тут будет шлиф: та самая зашлифованная поверхность
(физический объект! Шлиф занимает место в пространстве, характеризуется своей
шероховатостью, с одной стороны прилегает к телу шлифуемого объекта, с другой
стороны касается какой-то системы в окружении). Обязательно нужно рассмотреть
надсистему: для чего шлифуем? Что будет соприкасаться со шлифом, или шлиф
просто должен блестеть для красоты? Нужно ли закрывать лаком шлиф? Каков
класс обработки поверхности? Важно, что все эти вопросы автоматически придут в
голову опытному шлифовщику. Но мы-то не опытные шлифовщики! Но нам надо,
чтобы эти все вопросы тоже пришли к нам в голову! Системное мышление даёт
ровно это, когда заставляет подумать и о целевой системе (это не так просто
понять, что это шлиф — хотя это полностью эквивалентно «причёске» в случае
парикмахерской!), и о надсистеме (шлиф в соприкосновении со шлифуемой деталью
с одной стороны и пока непонятно чем с другой стороны шлифа), и о потребностях
(зачем шлифуем? Чего хотим от надсистемы) и о требованиях (как именно
шлифуем). Если речь идёт о сервисе, то можно подумать и о функциях («сделать
блестящую поверхность» — для этой работы можно просто покрасить поверхность,
или никелировать её, или даже заклеить блестящей плёнкой; «сделать гладкую
поверхность» — для этой работы тоже можно предложить ряд способов, кроме
шлифования).
Системное мышление заставит подумать и о внешних ролях (клиент, которому
нужен шлиф), и о внутренних (кто будет шлифовать?) и о внешних по отношению
 141

к обеспечению (кому нужна шлифовальная мастерская, но не нужны сами шлифы).

Заставит документировать потребности для шлифа (требования к надсистеме
шлифа — шлифованная поверхность и то, что к ней прилегает), требования к
шлифу (класс обработки поверхности, необходимость какого-то покрытия после
шлифовки, например, лакирования).
Ровно такие же рассуждения нужно делать и в других случаях. Так, вы делаете
систему оформления командировок, и вы подозреваете, что вашим клиентом тут
является бухгалтерия. Системное мышление заставляет пройти по следующим
рассуждениям:
• Поскольку речь идёт о софте (хотя мы пока и не знаем, «система оформления
командировок» включает ли себя в людей, не является ли каким-то
оргзвеном), то этот софт что-то описывает в своих данных. Что описывает?
Командировку, или на формальном языке — «деловую поездку». Итак,
целевая система (ради которой всё затевается, включая оформление через
ваш будущий софт) — деловая поездка. Деловая поездка понимается как
человек (необязательно сотрудник!), который куда-то едет, пункт начала
поездки, пункт конца поездки, транспорт, проездной документ (билет), место
проживания, документ проживания (квитанция) — и всё это на каком-то
отрезке времени.
• Клиент при этом не бухгалтерия, а те, кому нужна деловая поездка —
бухгалтерия оказывается в подчинённой роли обеспечения поездки! Если это
понять, и делать систему, удобную для командированных в первую очередь,
и удобную для бухгалтерии во вторую очередь (а не наоборот), то команда
проекта будет нужна прежде всего фирме, а не главным образом бухгалтерам
фирмы. Это существенно меняет переговорные позиции в проекте! Из врага
всех сотрудников команда становится другом всех сотрудников!
• Какая система тут в обеспечении? Софт (делает программа программистов),
софт-на-серверах (команда DevOps — программисты, выполняющие также и
функции системных операторов), или служба оформления
(софт+сервера+люди, работающие с этим софтом как операторы)? Что будет
сочтено успехом проекта? Какие роли требуются для этих разных проектов,
кто исполняет эти роли? Беда, если вы считаете «нашим проектом» проект
софта, а в момент приёмки проекта в эксплуатацию, или в момент
возникновения трудностей в связи с тем, что нет исполнителей других ролей
спрашивать начнут с текущего разработчика софта! Объяснений, что «мы
считали, что от нас нужен только софт», слушать ведь никто не будет! В
конечном итоге нужны оформленные деловые поездки! В зачёт идут только
они!
Для размышлений о сервисах с участием людей очень полезно обращаться к
танцевальной метафоре. Танцы — это специальное поведение людей,
максимизирующее букет гормонов счастья: дофамина, серотонина, окситоцина,
адреналина и т.д. Разные танцы дают немного разные сочетания этих гормонов.
Собственно, весь маркетинг/продвижение потребительских товаров сегодня
примерно так и устроен: он связывает потребление разных товаров и услуг с
получением именно этого — повышенного удовольствия, нахождения в крови
гормонов счастья, немного разного букета этих гормонов для разных товаров.
Например, магазин предоставляет сервис покупки — он обеспечивает «танец
покупателя» среди полок, облегчая покупателю максимальное наполнение корзины
 142

и максимальное опустошение его кошелька, минимизируя специально

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

Мышление о танце и о покупке оказывается похожим: вот эта экономия мышления

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

109
Социализм этим и отличался: отсутствие инвесторов позволяло почти не обращать внимания на целевые
системы, основное внимание было направлено на обеспечивающие системы, см.
http://odesskiy.com/zhvanetskiy-tom-3/parovoz-dlja-mashinista.html
 143

которое обеспечивает ЖЦ целевой системы. Например, вы консультируете

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

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

работами системы в обеспечении (если организуете авиазавод, то целевая

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

Большая ошибка — это считать себя объективным и нейтральным системным

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

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

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

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

110
https://en.wikipedia.org/wiki/Heuristic
 146

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

практики. Этот участок мозга/обеспечение практики потом будет проявляться как

сервис в той или иной мыслительной работе — и целевая система тут не просто
«участок мозга», но «участок мозга в момент его задействования» (то есть
мыслительного проявления).
Такой мыслительный приём уподобляет проекты по изменению поведения людей
через изменение «мозгового софта» проектам по разработке компьютерного софта
(можно было бы назвать это «нейролингвистическим программированием», но этот
термин уже был занят в середине 70-х годов прошлого века конкретной практикой
такого программирования, описанной Джоном Гриндером и Ричардом Бэндлером, и
тем самым оказался недоступным для общего пользования 111. И да, Джон Гриндер
и Ричард Бэндлер использовали системный подход первого поколения, им в этом
помогал один из видных системных мыслителей этого поколения системного
подхода — Грегори Бейтсон112). Этот приём нередок при моделировании изменений,
проходящих с людьми (образовательные проекты, продвижение каких-то продуктов
и сервисов, психотерапия и т.д.). И помним, что целевая система определяется на
момент её эксплуатации: то есть на тот момент, когда соответствующий участок
мозга будет задействован в выполнении работы с участием тех компетенций,
которым он был научен в ходе обучения/терапии/программирования/кодирования
(да, использовалось и слово «кодирование»!) и т.д.
Целевую систему всегда придётся выявлять, в каждом проекте она будет уникальна,
перечисления «типовых решений» тут нет, можно только давать примеры — в
надежде, что эти примеры не будут восприняты как «делайте именно так».
Системное мышление задаёт лишь набор концептов, которые
обязательно нужно продумать в вашем проекте. И если по ним трудно
принять решение — это означает, что вы что-то плохо понимаете про ваш
проект, и лучше бы вам подумать ещё (а также собрать больше
информации, поговорить с исполнителями разных других ролей в
проекте).
Документация (бумажная или электронная) — не целевая система, даже если речь
идёт о толстой пачке проектной документации для высотного здания или даже если
речь идёт об исходном тексте компьютерной программы, или даже если речь идёт
о каком-то сценарии городского праздника, или даже если речь идёт о какой-то
компетенции в чьей-то голове. Возможно, целевая система — это то, что вы
описываете на этом носителе. Возможно, вы описываете даже не целевую систему,
а систему в окружении целевой системы, или подсистему целевой системы, или
систему в обеспечении. Главное тут — не путать системы и описания (даже если
описания даны нам как документация). Целевая система — это не описание!
Целевая система чаще всего — воплощение того, что описано!
Целевая система — это то, что делает (то есть полномочно меняет, а не «влияет на
то, что кто-то другой поменяет») команда проекта. Если команда делает описание,
по которому потом сделают систему — это непосредственное изменение мира, план
этого изменения. Это не уговоры кого-то, чтобы он изменил свою систему. У
команды есть какие-то полномочия по отношению к целевой системе, по отношению

111
Что происходило с нейролингвистическим программированием и подобными подходами можно
посмотреть по ссылкам в тексте «психопрактики движения по спектру формальности мышления»,
https://ailev.livejournal.com/1461939.html
112
https://ru.wikipedia.org/wiki/Бейтсон,_Грегори
 148

к другим системам (системам окружения, в том числе надсистеме, системам

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

Принцип почтальона
Адреса составлены обычно так, чтобы разные уровни адресации позволяли чётко
найти объект, объект уникален внутри какого-то уровня адресации, его легко
найти — это и есть принцип почтальона (был предложен А.Нечипоренко в ходе
одного из наших семинаров). Скажем, вот адрес пластиковой накладки на ножке
стола по сути перечисляет объекты в системном разбиении, позволяющие перейти
от внимания ко всей Вселенной к вниманию на этой пластиковой накладке:
Вселенная, комплекс сверхскоплений Рыб-Кита113, Ланиакея114, сверхскопление
Девы115, местная группа галактик116, Млечный Путь117, Рукав Ориона118, Солнечная
система, планета Земля, Россия, Ростов-на-Дону, ул. Большая Садовая, дом 105,

113
https://ru.wikipedia.org/wiki/Комплекс_сверхскоплений_Рыб-Кита
114
https://ru.wikipedia.org/wiki/Ланиакея
115
https://ru.wikipedia.org/wiki/Местное_сверхскопление_галактик
116
https://ru.wikipedia.org/wiki/Местная_группа
117
https://ru.wikipedia.org/wiki/Млечный_Путь
118
https://ru.wikipedia.org/wiki/Рукав_Ориона
 149

аудитория 323, первый стол от доски у окна, левая ножка стола, пластиковая
накладка. Адрес «Вселенная, Солнечная система, Дом 105, пластиковая
накладка» — это неправильный адрес целевой системы, неправильное указание на
целевую систему.
В системном разбиении надсистема должна определяться по возможности близко
по уровням отношений «часть-целое» от целевой системы. Тут возможно много
разных типов ошибок:
• пропуск уровней. Обычно заявляется слишком далёкий от целевой системы
системный уровень, например, вместо целевой системы называется её
надсистема, или даже система на несколько системных уровней выше
надсистемы. Типичный пример: я делаю автомобиль! После чего следует
длинный рассказ о морозоустойчивых аккумуляторах. Почему? — Ну, меня
интересуют морозоустойчивые аккумуляторы, они используются в
автомобилях. — Могут ли использоваться, например, для гайковёртов? — Да,
вполне. — А если гайковёрты в Якутии? Да, это много лучше автомобиля, для
моих морозоустойчивых аккумуляторов это отличный рынок! Я занимаюсь
гайковёртами! (после некоторых вопросов становится понятным, что и
аккумулятор тоже не интересует, речь идёт о морозоустойчивом
электролите — он и будет целевой системой! Проект занимается
морозоустойчивым электролитом!).
• Сверхобобщение. Это в некотором роде нарушение адресации, но отношение
не часть-целое, а уровня обобщения/специализации в классификаторе.
Например, не «одноместный учебный самолёт», и даже не просто «самолёт»,
а «летательный аппарат». Что ты создаёшь? Летательный аппарат! А в
реальности это игрушечный самолётик на резиновом моторчике. Ну и назови
его по обычной роли «быть игрушкой»: «игрушечный самолёт». Верно ли
будет «летательный аппарат»? Для математика — верно! Но у нас тут не
математика, у нас системное мышление. Нам все названия и результаты
размышлений нужны для деятельности, а не для «логической истинности».
Для понимания, что можно сделать с создаваемой системой имя «игрушечный
самолёт» много лучше «летательного аппарата».
• Указание не всей системы, или соседней (в окружении или даже в
обеспечении) системы, в надежде, что целевая система будет собеседником
определена самостоятельно, умозаключением. По сути, речь идёт о
метонимии119 — один физический объект (или класс таких объектов)
заменяется другим (или его классом), находящимся в какой-то
связи/отношении с предметом. И вместо названия/указания одной системы
появляется вдруг название этой другой системы. Связь эта может быть как
«часть-целое», так и любой другой. «Я три тарелки съел» — не тарелки, а
находящуюся на тарелке еду. «Ведро расплескалось» — не ведро, а вода в
ведре. В случае метонимии целевой системой могут назвать что угодно,
находящееся в каких-то отношениях с целевой системой: всё, что попадает в
сферу внимания. Проверять метонимию нужно, отслеживая, что речь идёт
именно об отношениях «часть-целое», и уже дальше уточнять, какая целевая
система в итоговом системном разбиении целевая, на каком системном
уровне мы с ней работаем, каким языком мы о ней говорим.

119
И опять напомним, это ведь важное слово: https://ru.wikipedia.org/wiki/Метонимия
 150

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

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

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

который будет восхитительно работать — но самолёты этого авиазавода летать

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

мысли к эксплуатационному времени, а не времени создания системы или

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

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

Так, микроскоп предназначен для того, чтобы рассматривать мелкие предметы:

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

недопустимо. И иногда есть уже устоявшееся название, его и нужно использовать —

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

Надсистема: её тоже нужно найти!

Надсистема (иногда говорят using system, «использующая система») прежде всего
должна проверяться на то, что целевая система является в момент эксплуатации
(operation, работы, функционирования) неотъемлемой физической частью этой
системы, то есть буквально входит в состав (composition) надсистемы. Увы,
большинство ошибок происходят именно по невниманию к этому её признаку.
Системное разбиение (system breakdown structure) — это иерархия по отношению
состава/сборки/часть-целое, а не по каким-то другим отношениям. На ошибку
выделения надсистемы и целевой системы указывают обнаружение между ними
отношений вызова подпрограммы, классификации и специализации,
принадлежности в части имущества, назначения на роль — ведь есть огромное
количество других отношений, кроме предписанного для системного разбиения
отношения состава (composition, is_part_of, включения как физической части).
 154

Например, рассмотрим мужчину и женщину. Один из студентов высказал мысль, что

если женщина целевая система, то мужчина — это надсистема/использующая
система/using system. С этим можно согласиться, но только если мужчина съел
женщину! А как ещё женщина может быть составной частью (is_part_of) мужчины?
В студенческих аудиториях эту загадку решают минут пять, а в более взрослых
аудиториях на это тратят пятнадцать секунд: надсистемой/использующей системой
женщины и мужчины тут является семья (студенты часто говорят «пара»,
подчёркивая возможность более слабой связи), а женщина и мужчина находятся
друг у друга в операционном/эксплуатационном/рабочем окружении. Загадка
решается путём выявления пропущенной, не названной, не выявленной системы в
системном разбиении. Это типичная ситуация: надсистемы обычно плохо
различимы, иногда для них нет устоявшихся названий. Эти «пропущенные» системы
приходится выявлять/определять (то есть описывать их роли, функции, границы) и
как-то называть. Как называть? Точно так же, как любую другую систему, т.е.
преимущественно (если нет какого-то явно устоявшегося исторического названия)
по роли этой надсистемы в её надсистеме, т.е. по роли в над-надсистеме по
отношению к целевой.
Признаком надсистемы в её отделении от целевой системы (а команде проекта
обычно приходится иметь дело с обоими этими системами) является то, что команда
не уполномочена как-то самостоятельно изменять саму эту систему или даже её
определение (требования, архитектуру). Ещё десяток лет назад не предполагалось,
что команда как-то может повлиять на надсистему — она брала её в проект как
данное, и должна была просто стыковать свою целевую систему с имеющимся
системным окружением. Сегодня это не так: команда проекта не уполномочена
изменять системное окружение непосредственно, но она может влиять на то, чтобы
в целях согласования характеристик целевой и надсистемы эта надсистема была
изменена — самостоятельно её владельцами, или командой проекта по
согласованию с владельцами надсистемы. Для этого команда проекта (внутренние
проектные роли) активно работает с внешними проектными
ролями/стейкхолдерами, влияет на них.
При определении надсистемы важно, чтобы это был ближайший системный уровень
(принцип почтальона, адрес должен быть точен — нельзя отсылать в слишком
общий объект), на котором ожидается эмерджентность/системный эффект от
 155

работы целевой системы в её составе. Верный способ найти надсистему — это

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

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

Системное мышление обладает свойством рекурсивности в его применении: оно
похожим образом разворачивается для каждой из систем в обширных системных
разделениях. Как-то специально выделять целевую систему среди многочисленных
системных уровней какого-то системного разбиения нужно главным образом из-за
необходимости помнить, что является коллективной целью, то есть для работы в
каких-то командных проектах. Это новинка системного подхода в его втором
поколении, деятельностное (субъективное, т.е. определяемое намерением какого-
то агента что-то изменить в физическом мире) введение целевой системы/system-
of-interest. Целевая система всегда выделяется из мира кем-то и для чего-
то, а не «объективно».
Тем не менее, понятия системного мышления приложимы ко всем системам, не
только к целевой.
Так, свои надсистемы и подсистемы есть и у целевой системы, и у надсистемы, и у
подсистем, и у любых других систем окружения и даже систем обеспечения.
 156

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

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

• Когда вы общаетесь совместно с клиентом, командой, какую систему ты

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

6. Как описывать системы

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

Три основных описания разбиения системы

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

На рисунке изображены три проектные роли, которых интересуют разные описания

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

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

Минимально в системном подходе нужно увидеть в системе три вида/типа частей:
• Функциональные/ролевые части120 (functional elements, но мы
переводим как «части», ибо элементы не подразумевают дальнейшей
делимости, а мы всегда о ней помним; role elements, components), обсуждение
взаимодействия которых позволяет отвечать на вопрос о том, как работает
система, чтобы она выполняла свою функцию/роль в её надсистеме. Это
обязательно будет обсуждение времени
эксплуатации/работы/операций/использования/службы. На картинке
нарисована принципиальная электрическая схема, на которой приведено
описание функциональных/ролевых частей системы и их соединений
(connectors). Эти функциональные/ролевые элементы выполняют свою
функцию в системе через соединения с другими компонентами, меняя своё
состояние от этого взаимодействия и меняя состояния других компонент.
• Модули/продукты/конструктивные части (modules, products,
сборочные единицы, логистические единицы, конструкты) — этот вид частей
позволяет отвечать на вопрос, из чего собрать и как соединить через
интерфейсы (interface) модули системы, отвечают на вопрос «как собрать
систему», обсуждается время обеспечения. Время эксплуатации, «как
работать» по этим диаграммам обсуждать нельзя!
• Места (locations), или размещения (allocations), которые позволяют отвечать
на вопрос, где можно найти части системы, как она скомпонована в
пространстве (чаще всего это время эксплуатации, а размещения делаются
для модулей! Размещение тем самым важно для совмещения ролевых и
физических объектов: если оба находятся в одном и том же месте в одно и
то же время, то это один и тот же объект!). На картинке изображены отсеки,
в которых ведётся монтаж системы и в которых она затем работает, но
непонятно из чего система собрана и как она работает.
Всё это выделенные в соответствии с разными ролевыми интересами части одной и
той же целой системы, изображённой кубиком с цветными гранями — и каждая роль
получает возможность обсуждать свой интерес по удобно устроенному для
обсуждения этого интереса описанию:
• Интересующийся «как работает» получает
принципиальную/функциональную/потоковую схему с соединениями
компонент/функциональных/ролевых частей,
• интересующийся «из каких продуктов собрать» получает описание
конструкции: модулей и их интерфейсов друг ко другу
• интересующийся «где найти/куда положить» получает описание мест, где
расположена система.
Системные уровни определяются по главному в системном мышлении
разбиению — функциональному! Поэтому функциональное разбиение
часто называют системным разбиением.
В принципе, это не всегда соблюдается. Сама система чаще всего одновременно и
функциональная часть, и конструктивная, и занимает какое-то компоновочное
место. В какой-то мере любое из основных разбиений системно. Но в инженерии

120
В современном русском языке компонента/компонент примерно одинаково по частоте употребления как
в женском роде, так и в мужском, никакой нормы на этот счёт нет.
 161

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

функциональное разбиение, а не конструктивное или пространственное.

Функциональный анализ и модульный синтез

Каждая проектная роль в силу специфики своих интересов видит частное
определение системы как «прозрачного ящика», состоящее из интересующих его
типов элементов, отвечающих на его интерес. Операционный менеджер, например,
интересуется «из чего собрано», но его мало волнует «как работает». А инженер,
думающий над расчётом режима работы/функционирования/операций какой-то
системы думает прежде всего над «как работает» (функциональный анализ), и
решать «из чего собрать» (модульный синтез) он будет потом, когда поймёт,
какие именно там операционные режимы, как система будет работать в момент её
эксплуатации, какие характеристики потребуются от модулей.
Обратите внимание, что тут обязательно присутствуют и
функциональный/системный анализ (системный анализ — помним, что системы
обычно описывают прежде всего по их ролям, функциям), и модульный синтез.
Поэтому у нас учебник системного мышления, в котором анализу и синтезу
уделяется равное внимание. Те, кто занимается только анализом
(функциональным/системным или каким-то другим) — это мечтатели, которые не
имеют шанса изменить мир. Мир-то нужно менять физически. Для этого нужно,
чтобы какие-то физические модули/конструктивные части начали играть роли
функциональных частей системы. Это ровно то же рассуждение, что про
исполнителей человеческих ролей в спектаклях. Если только писать пьесы,
прописывать хорошо роли и их поведение, но не думать про воплощение этих пьес
актёрами (в том числе роботами, в том числе животными!), то можно смело считать,
что это просто художественная литература, а не драматургия. Драматург и
режиссёр обычно представляет, что его пьеса будет жить в реальности. Мышление
должно быть адекватно, то есть не терять связи с физическим миром, не витать
только в облаках. Если и думать, то результаты мышления должны иметь отношение
к изменению мира.
Поэтому системный мыслитель обязательно выделяет не менее трёх
интересов:
• функциональный/ролевой/аналитический,
• модульный/конструктивный/синтетический
• пространственный.
Анализ/декомпозиция всегда только часть мышления! Опасайтесь
проекта, где непонятно кто принимает решения по синтезу! Синтез меняет
мир, анализ не меняет мир! Решения по синтезу меняют мир!
Кто имеет право указать, что в ракете будет три ступени? Что в
предприятии будет три подразделения? Что Вася Пупкин будет играть
роль Принца Гамлета? Это точно не аналитики!
Конечно, «аналитик» при этом — роль, а не должность. Конечно, человек на
должности «аналитик» вполне может выполнять и роль синтетика/конструктора,
принимать решения по модульному синтезу. Но лучше бы назвать такую должность
с принимающим решения по поводу изменения мира человеком иначе: люди не
ожидают от «аналитиков» полномочий по изменению мира. Обычно такие решения
по назначению конструктивных частей системы на ролевые/функциональные части
 162

делает архитектор (важнейшие решения) или просто инженер (все решения), но не

аналитик.

Одна система — множество описаний, множество имён

Тройное (это только основные три! Их много, много больше!), «не единое»
восприятие целостной системы нормально, так и должно быть! Единым в мыслях
у разных стейкхолдеров/проектных ролей, имеющих разные интересы,
может быть только единонемыслие (Салтыков-Щедрин). Реальное же
единство всех этих описаний обеспечивает то самое декартовское
понимание, что конструктивная часть/продукт/изделие/модуль (из чего
собрано) занимает в пространстве то же самое место, что
функциональные части, роли которых он играет, а само это место — это и
есть размещение. Всё это описания одного и того же физического объекта
в пространстве-времени. Никаких отождествлений через отнесение к каким-то
типам! Все отождествления — через ход к физической реальности, к физическому
объекту в конкретном месте пространства-времени!
Три основных способа выделения частей одной и той же системы дают три основных
способа организации внимания, выделения главного и отбрасывания
второстепенного. Далее проектные роли должны договориться о том, что все
три описания не противоречат друг другу, описывают одну и ту же
систему.
У немецких инженеров-электротехников был подсмотрен приём: чтобы сразу было
видно, о каком виде частей системы говорится, их именуют с использованием
специальных префиксов: функциональный/ролевой префикс “=”,
модульный/продуктный префикс “-”, префикс размещения “+”. А имена даются на
каждом уровне системного разделения, так что они получаются иерархичными по
отношению часть-целое, но это отношение строится по одному какому-то типу
объектов в разбиении.
Например, =S12=16 означает, что речь идёт о функциональной части 16, входящей
в состав (отношение composition, part_of) функциональной части S12.
Проектирование, конечно, ведётся в классах: это имя классов частей системы, а не
конкретных частей конкретной физической системы в конкретный момент времени.
Число уровней в таком имени неограничено. Такое функциональное/ролевое имя
часто называют тегом (tag).
Если имя –M87-K5, то речь идёт о продукте/модуле/конструктиве/изделии К5,
который входит в состав модуля М87. Это тоже не конкретный физический объект
с серийным номером, а класс этих объектов, продукт определённой марки.
Стандарт IEC 81346 закрепил такое именование, причём он определяет ещё и как
давать короткие коды вместо «нормальных» длинных имён. Действительно, если в
каком-нибудь Boeing 787 есть 6 миллионов индивидуальных деталей, то это сразу
означает, что у них даже больше имён — и лучше бы держать эти имена короткими,
и каждое имя чтобы было понятно, к какой части самолёта относится. И имён там
больше, чем имён деталей: если «деталь» — это продукт/модуль/изделие, то есть
ещё и функциональные имена, и имена размещений! Стандарт закрепляет три
основных вида разбиения системы на части, но добавляет при этом, что могут быть
и другие виды описаний. Но эти — основные, они обязаны быть!
Мы уже знакомились с ситуацией, когда Принц Гамлет и Василий Пупкин могут быть
 163

одним человеком, но называться по-разному в зависимости от того, что нам от него

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

Альтернативные варианты разбиения системы на части

Суть системного подхода в том, чтобы ни в один момент времени не забывать про
систему в целом — воплощение системы, которое просто по-разному
представляется состоящим из разных частей разными проектными ролями. Беглости
такого одновременного удержания во внимании разных представлений об одном и
том же объекте, беглость работы со множеством описаний одной системы, в том
числе и множеством вариантов деления системы на части нужно некоторое время
учиться, хотя идея понимается с первого предъявления.
Функциональные объекты, конструктивные элементы, размещения — это не
единственный способ увидеть в системе части. Этих способов огромное количество.
А исторически в разных школах мысли части системы выделялись очень по-разному:
● ISO 15926 — две основных: функциональные объекты, физические объекты.
Остальные могут вводиться по потребности.
● IEC 81346 — «по меньшей мере» три (функция, продукт, место)
● Книга Paul Clements at al., Documenting Software Architectures: Views and
Beyond (2nd edition), Addison-Wesley Professional, 2010121 — три стиля
(компоненты, модули, размещения, и разные варианты внутри каждого
стиля).

121
https://www.amazon.com/Documenting-Software-Architectures-Views-Beyond/dp/0321552687/
 164

● Книга Косяков, Свит, Сеймур: «Системная инженерия. Принципы и

практика»122 — функциональный элемент, компонента (в значении «модуль»
из предыдущей книги: ровно обратное использование термина!),
размещение.
● СМД-методология — «по меньшей мере» пять (процессы, элементы и связи,
внешние функции, морфология, материал) 123
● … и так далее, в среднем 3-7 основных ипостасей (впрочем, «ипостаси» тоже
называются везде по-разному) в разных школах системного мышления.
В нашей книге мы примем, что системы имеют минимально три ипостаси/аспекта —
функциональную, конструктивную и размещения. И запомним, что этих
ипостасей/аспектов всегда больше, плюс сами эти ипостаси/аспекты в чистом виде
обычно не встречаются и часто тесно сплетены друг с другом (”гибридны”).
Для разных ролей в проекте система будет представляться в своих разных аспектах-
ипостасях частично, следуя дисциплине того или иного варианта разбиения, но при
этом в системном трансдициплинарном мышлении она будет оставаться
целостной/холистичной/целокупностью всех своих ипостасей/аспектов.

Несовпадение разных системных разбиений

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

Системы отличаются тем, что для них функциональные/ролевые части,

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

122
https://www.ozon.ru/context/detail/id/28160736/
123
http://webcache.googleusercontent.com/search?q=cache:CLJYHzTDPj0J:www.mmk-
documentum.ru/glossary/6
 165

Так, ТРИЗ (теория решения изобретательских задач) повышает идеальность своих

систем тем, что несколько разных функций (помним: функция — это поведение
функциональной/ролевой части системы в ходе работы надсистемы) выполнялись
меньшим числом конструктивных частей — в идеальной системе все функции
выполняются нулевым числом частей конструкции (конструкции вообще нет, а
функции выполняются!), ТРИЗ стремится к этому. Так что нельзя гарантировать, что
системное/функциональное разбиение, а также продуктное/конструктивное
разбиение и пространственное разбиение совпадают.
Нельзя путать компоненты/функциональные части и продукты/модули. Нельзя
путать ролевого Принца Гамлета и конструктивного Василия Пупкина, даже если во
время спектакля это одно и то же. Если вы будете за кулисами говорить Василию
Пупкину «Ваше Высочество», а на сцене говорить Принцу Гамлету «как там твои
жена и дети?», то окружающие на вас будут смотреть странно, а Василий Пупкин
сильно озадачится в обоих случаях.
Мы уже рассматривали заварочный чайник, в котором всего два модуля (корпус и
крышка) и довольно много функциональных частей (емкость, носик, заливочное
отверстие в ёмкости, ручка ёмкости, крышка, ручка крышки, паровыпускное

отверстие).
Кажется, что трудно перепутать в чайнике функциональные и конструктивные
элементы? Увы, легко!
Рассмотрим на примере ножниц, что бывает, если люди путают функциональные
(ролевые времени эксплуатации, работающие с окружением) и конструктивные
(времени создания, над которыми работает обеспечение) части.
Для ножниц инженеры придумывают разные формы ручки и ножевого блока, думая
о ручке и ножевом блоке как о функциональных компонентах. Они обсуждают ручки
и ножевой блок как физически существующие (за ручку держат, считаются её
размеры и гладкость, ножевым блоком режут — считаются его прочность и острота,
угол раскрытия). Если менеджеры будут воспринимать ножницы состоящими из
таких функциональных компонент как из продуктов/изделий/модулей, то они
попытаются заказать работы по изготовлению ручек и ножевого блока раздельно:
ручки фирме, понимающей в эргономике, а режущий блок заводу, который умеет
делать ножи («ножницы» как раз происходят от слова «нож»!). Инженеры от этого
будут в шоке, поскольку они для целей изготовления и сборки начинают думать про
ножницы как состоящие из модулей: двух цельных кусков металла специальной
формы, скреплённых винтиком. Заказать можно только модули, а ручка и ножевой
блок у ножниц только ролевые элементы — их роль никто не играет, если нет
 166

назначенных на эти роли модулей! Модулями в ножницах будут только две

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

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

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

Целевая система едина как компонента и модуль, но вот дальше структура

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

языках моделирования предприятия, функциональные и конструктивные части

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

Создание архитектуры: функциональный анализ и модульный синтез

Самые важные решения по поводу системы называют архитектурными. Важность
определяют как такое решение, которое в случае принятия его альтернативы вело
бы к почти полному перепроектированию системы, полному изменению
конструкции. Так, если поменять винтик в пароходе, то это не потребует каких-то
существенных изменений в конструкции парохода. А вот если принять решение, что
пароход будет не колёсный, а винтовой, то это потребует существенного
перепроектирования. Аналогично требования, которые заставляют принять какие-
то архитектурные (важные! Не все! Только связанные с существенными
изменениями многих других решений в случае их перепринятия!) решения
называются архитектурными требованиями. Что самолёт должен быть зелёного
цвета — это не архитектурное требование. А вот что самолёт должен лететь со
скоростью 3000км/час — это архитектурное требование, ибо это уже сверхзвуковой
самолёт, и это требует существенно другой конструкции самолёта, нежели
конструкция для самолёта, летящего со скоростью 800км/час.
Архитектурные решения часто включают в себя изобретательство и принимаются в
ходе совмещения функционального («как работает») и конструктивного ( «из чего
сделано») разбиения. В литературе для разных разбиений часто используют просто
термин «структура», но нужно помнить, что это именно иерархия по какому-то виду
разбиений: отношения элементов структуры — это обычно иерархия отношений
«часть-целое» (is_part_of, composition, состава), а все другие отношения
(специализации, классификации, предшествования во времени, взаимовлияния и
т.д.) в этой «структуре» разбиений не учитываются. Если разбиение (breakdown),
то структура — это структура частей-целых!
 168

Вот рисунок из стандарта IEC 81346-1, а этот стандарт взял этот рисунок из более
раннего стандарта IEC 1392/09. Это базовая схема архитектурной работы (и она
же — базовая схема изобретательства).
Рассмотрим целевую систему, которую в начальный момент мы рассматриваем как
функциональный объект А (функция/поведение или функциональная/ролевая часть
системы/компонента — это по большому счёту тут неважно и зависит от принятых
соглашений моделирования. Вы или говорите о поведении «забивка гвоздей», или
функциональной/ролевой части «забиватель гвоздей»). Сам стандарт IEC 81346
имеет дело с функциональными частями системы/ролевыми объектами, а не их
поведением/функциями). Реализовать (realize) — это вынести «логический» объект-
функциональную роль в физическую реальность конструктивных модулей
(исполнителей ролей). Грубо говоря, «забивка гвоздей» или «забиватель гвоздей»
назначаются на молоток, микроскоп или камень. Это основа изобретательской
деятельности: для одной и той же функции можно выбрать множество самых разных
предметов, которые дадут нам нужное поведение.
Первое, что происходит — это функциональная декомпозиция: функция или
 169

функциональные части разбиваются на более мелкие (на рисунке это B и другие

четыре) и делается попытка выбрать для них модули, сервисы которых могут
выполнить функции этих компонент.
Помним, что функции системы формулируются на языке проектных ролей
надсистемы, а сервисы — на языке проектных ролей системы. Сервис молотка —
«бить по предмету». Этот сервис отлично подходит для функции «забивать гвозди».
Изобретательство тут — увидеть, что и микроскоп имеет сервис «бить по
предмету», и «камень». И за неимением молотка выбрать, например, камень (ибо
микроскоп может быть большой и неудобный, а камень легко подобрать по размеру
и форме — соображения тут могут быть разные, и отнюдь не только соображения
цены).
На рисунке из стандарта видно, что на первом шаге декомпозиции подобрать
модули с подходящими сервисами удаётся только для двух подфункций из шести (и
показано это как подсистемы: они понятно какую выполняют функцию в надсистеме
с функциональным именем А и из каких модулей они будут сделаны). На следующем
шаге это уже удаётся для всех подфункций, в том числе для подфункций B. Эта
часть функциональной декомпозиции иногда называется функциональным
анализом.
Дальше мы должны из всех модулей, используя их интерфейсы для соединения,
собрать целевую систему-модуль. Для сборки-модуля B на рисунке, реализующего
функцию компоненты B это получается только в два шага — сначала собираются
два промежуточных модуля, и только потом они объединяются. На следующем шаге
модуль B включается в состав модуля А, который реализует изначально задуманную
функцию А. С этого момента функция и сервис совпадают, функциональная часть и
конструктивный элемент/модуль совпадают. Эту часть проектирования системы как
составления целой системы-модуля из её подмодулей называют модульный
синтез. В ТРИЗ это основной ход на изобретательство: как для понятных функций
подобрать иногда довольно неожиданные элементы конструкции, сервисы которых
будут их выполнять. И лучше всего, когда небольшое количество элементов
конструкции будет выполнять большое количество функций (т.е. степень
идеальности системы растёт: идеальная система это та, функции которой
выполняются, а конструкции у неё нет, нет материального воплощения — модулей
в системе ноль, изготавливать ничего не надо).
Проблема в том, что обычно из имеющихся модулей трудно подобрать такие,
которые в конструкции реализуют все необходимые компоненты с их функциями.
Для этого приходится менять способ разбивки на функции (что
эквивалентно предложению другого способа работы устройства, другого
принципа работы), а модули приходится разрабатывать, если их нельзя купить
готовые. Купить — это простейший способ изготовления модулей! И всегда
помним, что модульный синтез — это изобретательская деятельность: желательно
научиться много функций навешивать на один модуль, уменьшая количество
модулей в системе.

Альфы и артефакты/продукты
Стандарт OMG Essence124 предлагает для контроля за изменением состояния
проекта особый вид функциональных объектов — альфа (ALPHA). Альфа — это

124
http://www.omg.org/spec/Essence/
 170

объект внимания, функциональный/ролевой характер которого отвечает интересу

«как проект работает». Если мы хотим как-то связно мыслить о том, как работает
проект, нам нужно мыслить о нём этими альфами.
Этот же стандарт OMG Essence для модулей, физически реализующих альфы,
предлагает имя рабочий продукт/артефакт (work product, artifact, т.е. предмет
искусственного происхождения). Продукт/артефакт/конструктивный объект — это
то, над чем работаем, из чего проект «собран», что можно обнаружить в
окружающем мире.
Альфа отличается от ранее встречавшихся нам функциональных объектов тем, что
она бывает и абстрактным объектом — каким-то описанием системы: требованиями,
архитектурой, неархитектурной частью проекта/design. Понять состояние такой
альфы можно, если такое описание документировано. Как понять, готовы ли
требования? Посмотреть на документы, где записаны эти требования!
Но также альфа бывает функциональными частями воплощений систем,
реализующимися в жизни модулями воплощения системы. Тогда о состоянии альфы
мы судим по состоянию модулей воплощения системы, которые играют роль этих
альф.
Альфы совершенно необязательно свидетельствуют об изменениях в ходе проекта
состояний именно целевой системы. Нет, они могут свидетельствовать и об
изменениях состояний систем окружения, равно как и систем обеспечения.
Основные предложенные стандартом Essence альфы (их список был немного
доработан125, чтобы они были приложимы не только к проектам программной
инженерии, для которых изначально разрабатывался стандарт):
• предпринимательская область интересов (возможности и внешние проектные
роли);
• инженерная область интересов (описание системы и воплощение системы);
• менеджерская область интересов: работы, практики, команда (внутренние
роли).
О состоянии альфы как ролевого/функционального объекта мы можем судить,
наблюдая за играющими их роль артефактами/модулями. О состоянии Принца
Гамлета можно судить, наблюдая за Василием Пупкиным в тот момент, когда он
играет роль (и только в тот момент, и только в той части, в какой Василий Пупкин
играет именно эту роль!).
Альфы и артефакты/рабочие продукты нельзя путать: альфы (роли!) существуют
главным образом в голове (хотя о них мы и думаем как о реальных объектах —
понимая, что эту роль в какой-то момент сыграет физический объект-артефакт), а
рабочие продукты/артефакты существуют в физическом мире. В стандарте они
изображаются разными значками: альфа похожа на греческую α, а рабочий
продукт/артефакт — на лист бумаги с загнутым уголком.

125
Подробно в материале Towards Systems Engineering Essence https://arxiv.org/abs/1502.00121, но есть и
более короткая «официальная публикация» в сборнике Software Engineering in the Systems Context
https://www.amazon.com/Software-Engineering-Systems-Context-Jacobson/dp/1848901763/
 171

Стандарт разрабатывался главным образом для разработчиков информационных

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

Яблоки из жизни, яблоки из задачи

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

Тут нужно привести байку про яблоки из задачи и из жизни, например, в таком
варианте126:
пришла в ... школу учительница, которая начиталась работ о
дидактической функции наглядных пособий и считала, что надо учить на
наглядных пособиях. А проходили они в этот момент задачку на
сложение: «3+5». И она принесла три яблока и ещё пять яблок,
выложила их на стол и говорит: «Дети, вот вы видите здесь — раз–два–
три — три яблока, а здесь вот — раз–два–три–четыре–пять — пять яблок.
Вот я их соединяю, сколько получится всего яблок?» Дети пялятся на
яблоки, слюни у них текут, но задачи не понимают. Второй день
проходит, третий — рекорд: в таком классе обычно за день это
проходили. Она приходит в учительскую, жалуется, что вот–де она
применяет новые методы, наглядно все, а результата нет. И вот на пятый
день с задней парты тянется рука, и ученик говорит: «Мэм, я теперь
понял: эти яблоки, которые вы выложили на стол, не настоящие — это
яблоки из задачи». — «Да, а что?» — «Ну тогда, мэм, совсем другое
дело». И с этого момента, когда класс понял, что это не настоящие
яблоки, а яблоки из задачи, все моментально пошло. Почему? Когда вы
кладёте реальные яблоки — что с ними надо делать? Их надо есть. А
чтобы считать, нужны рисуночки.
Вот ещё про то же самое127:
— Мы займёмся арифметикой... У вас в кармане два яблока...
Буратино хитро подмигнул:
— Врёте, ни одного...
— Я говорю, — терпеливо повторила девочка, — предположим, что у вас
в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас
осталось яблок?
— Два.
— Подумайте хорошенько.
Буратино сморщился, — так здорово подумал.
— Два...
— Почему?
— Я же не отдам Некту яблоко, хоть он дерись!
— У вас нет никаких способностей к математике, — с огорчением сказала
девочка.
Про физические тела из учебника физики (дисциплины/теории/мышления физики,
документированной в учебнике) мы знаем, что при наличии силы тяжести они летят
по параболе. Ускорения и масса — это характеристики физических тел. Если кинуть
камень и не суметь соотнести его с физическим телом, то нельзя сказать, что он
полетит по параболе! Нет таких учебников, в которых описываются полёты именно

126
http://yandex.ru/yandsearch?text=%D1%8F%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8+%2F%2B1+%D0%B8%
D0%B7+%2F%2B1+%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%B8&lr=213
127
https://ru.wikipedia.org/wiki/Золотой_ключик,_или_Приключения_Буратино
 173

камней! Ричард Фейнман в своих заметках по преподаванию физики ровно об этом

сожалел: по всему миру ученики физики не могут сопоставить свои отличные
знания из учебника явлениям окружающего мира128.
Модулей, которыми можно реализовать ролевой объект/альфу, бесчисленное
количество, про каждый из них учебники не напишешь! Поэтому учебники пишут
про ролевые объекты и их роли/про альфы/функциональные элементы: короткий
текст из учебника можно поэтому применить к тысячам и тысячам ситуаций в жизни.
Задача мыслящего человека сопоставить ролевые объекты из учебника и играющие
их в жизни предметы, и только после этого можно будет применить теоретическое
знание из учебника к ситуации в жизни. Нет ничего практичней хорошей теории,
если ты распознаёшь её объекты в жизни, то есть если твоё внимание умеет для
объектов из теории/дисциплины/учебника/научной статьи выхватить какие-то
соответствующие им объекты из окружающего пёстрого фона.
Обычно занимающиеся по нашей книге проходят следующие стадии при изучении
системного мышления:
● Ничего не понимают, ибо неспособны соотнести материал книги с
окружающим их миром. Действительно, в их инженерных, менеджерских,
культурных проектах нет никаких альф. А в книге нет ничего, что есть в их
проектах. Более того, каждый проект уникальный — в них ведь вообще нет
ничего общего, а книга одна и та же для этих самых разных проектов! И эти
проекты в книге не описаны, примеры из них не приведены.
● Всё понимают про приводимые в книге примеры, а также про
проекты однокурсников и коллег по работе, но при этом ничего не
понимают про свои собственные проекты. Конечно, ибо чужие
проекты — это «проекты из чужой задачи» (помним, «яблоки из задачи — их
можно считать»), а свои проекты — это «реальные мои проекты» («яблоки
из жизни», их нужно есть!).
● Всё понимают и про свои проекты, и про проекты коллег. Но ничего
из понимаемого не делают, ибо системное мышление изучается не
для того, чтобы его применять, а «для самообразования и
развития», «для сдачи зачёта» и т.д. Применять знания мешают
начальники, текучка, лень, отсутствие единомышленников, помогать
применять знания некому.
● Применяют материал книги в своих проектах, ибо так работать
оказывается качественней, легче и в конечном итоге быстрее. Очень
часто это происходит только через год-два после знакомства с книгой, после
приобретения некоторой беглости в использовании понятий системного
подхода. В первом разделе нашей книги об этом было подробно сказано.

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

128
http://www.abitura.com/modern_physics/Feynman1.html
 174

можно легко найти в проектах, ткнуть в них пальцем (указать место в пространстве).
К альфам и артефактам применяются разные действия. Как их различить, и как
сопоставить друг с другом — это главная трудность в освоении не только системной
инженерии, но и любой другой дисциплины, описывающей окружающий мир и его
закономерности: как объекты любой теории совмещать с объектами реального
мира. Это как раз то, что физиков и инженеров отличает от
математиков/чистых логиков: физиков волнует, чему в реальном мире
соответствуют их формулы, а математиков/чистых логиков не волнует.
Альфы (alphas) — это функциональные (выполняющие определённую функцию,
играющие определённую роль, идеальные) объекты, по которым мы судим о
продвижении (progress, «как много мы уже сделали?») и здоровье (health, «в
проекте всё идёт хорошо») проекта. Альфы — это абстракция того же сорта, какого
«физическое тело» является абстракцией реальных физических объектов. Да, это
физическое тело имеет массу, а геометрическая точка имеет координаты. Но мы
связываем физические тела и математические точки как идеальные объекты с
реальными объектами, и после надлежащего тренинга «склеиваем» в мышлении
идеальные и реальные объекты. Поэтому у нас и у гири, и у атомной станции есть
масса, и у пёрышка, и у самолёта — мы умеем понять, что это физические тела и
перенести характеристику «масса» этого физического тела на гирю, атомную
станцию, пёрышко и самолёт.
Поэтому об экземплярах альф в проекте принято говорить так, как будто они вполне
реальны и существуют в мире, несмотря на все абстракции — об этих альфах как
мыслительных объектах мы судим по артефактам, играющим роль этих альф. Какие
сейчас требования? Я могу судить о требованиях по имеющейся документации этих
требований (требования-на-носителе информации). Какие у нас внешние
проектные роли представлены в проекте? Я могу посмотреть на реальных людей-
исполнителей, играющих в проекте какую-то роль — и судить о том, представлены
ли они как-то в проекте.
Альфы дают компактное описание мира/теорию/дисциплину, удобную для решения
каких-то практических проблем. Концепты этой теории/дисциплины служат для
известной цели: они привлекают внимание к чему-то важному, выделяют важное
из пёстрого фона многочисленных неважных для того или иного интереса деталей.
Это нужно, чтобы иметь возможность повторно использовать известные нам
способы рассуждений и решения задач для самых разных объектов. Так, мы думаем
о «физическом теле» и «математических точках» единообразно, «как в учебниках
физики и геометрии», а применимо это мышление к самым разным «реальным
объектам вокруг нас», от коробка спичек до галактик. В этой экономии мышления
(учимся думать один раз, затем похоже думаем в самых разных ситуациях) и
заключается смысл разделения альф и артефактов/продуктов. Например, учимся
думать о «требованиях», а применяем потом это мышление к конкретной бумажной
или электронной документации, которую можно найти на производстве «в реале»:
спецификациям требований, требованиям из текстов стандартов, user stories на
карточках, записям в базе данных системы управления требованиями и т.д.
Несмотря на всю «идеальность» и «абстрактность», об альфах говорят как о вполне
существующих в физическом мире, подразумевая при этом их тождественность тем
рабочим продуктам, по которым мы можем судить об их существовании (эти
рабочие продукты «играют роль» альф: о состоянии Принца Гамлета мы судим,
 175

разглядывая выражения лица и вслушиваясь в интонации Васи Пупкина, играющего

роль Принца Гамлета).
Так, можно определить альфу «моя любимая игрушка» — и, хотя в детстве у меня
это был нарисованный на ватмане пульт управления космическим кораблём, а
сегодня это мой ноутбук, я могу говорить про прохождение «моей любимой
игрушкой» состояний «полюблена», «разлюблена», «поломана», «в игре»,
«заброшена» и т.д. — независимо от того, какая именно это игрушка прямо сейчас.
Если в мышлении и разговоре появляется «требование» — то неважно, пункт ли это
протокола совещания с представителями заказчика, или запись в базе данных
системы управления требований, или фрагмент диаграммы какой-то модели
требований, или требования к танцу в концертной части «корпоратива» из
электронного письма его заказчика. В мышлении это будет распознано как альфа
«требование» — и после этого становится понятно, что с ним делать, как о нём
думать (конечно, это будет описание целевой системы на внешней границе!). Это
«требование» будет обсуждаться как реальный (хотя и абстрактный, не имеющий
места в пространстве-времени — это же описание!) объект, существующий в мире,
имеющий своё состояние — и в этот момент неважно, что у этого «требования» есть
ещё и какие-то особенности выражения на конкретном носителе информации,
ровно как при счёте яблок неважно, что их ещё и едят.
Формально (то есть в стандарте OMG Essence129) ALPHA — это аббревиатура,
Abstract-Level Progress Health Attribute, но неформально это просто способ указать
на функциональный элемент/ролевой объект/понятие из какой-то
дисциплины/теории/мышления проекта, связанного с системой. Аббревиатура про
health attribute была для альфы подобрана задним числом, а слово alpha пишут
поэтому маленькими буквами. Альфы — это то, что изменяется в ходе
проекта, меняя свои состояния. Альфы — это то, изменения чего в проекте
мы хотим понимать, отслеживать, обеспечивать, направлять,
контролировать.
Альфы удобны в том числе и потому, что если нам хочется отслеживать состояние
не только физических объектов, но и описаний как
мыслительных/абстрактных/идеальных объектов, то мы вполне можем это делать.
Повторим, что это плохо формализуется, но нас философско-логические нюансы
пока не интересуют.
Рабочий продукт/артефакт представляет/represent собой альфу в реальном мире.
Это «яблоко из жизни», «его едят» — продукт имеет в реальном мире какую-то
пользу для проекта, он материален. Продукты/артефакты — это
документированные спецификации, документированные тесты, документированные
диаграммы и какие-то документированные модели, базы данных и физические
объекты. Продуктом могут быть и какие-то мероприятия (совещания, презентации,
уборка рабочего места), которые можно представлять «вещественно» как
совокупность участвующих в этом мероприятии взаимно изменяющихся объектов.
Мы не рекомендуем злоупотреблять этим. Договориться о том, что представляет
собой мероприятия/процессы/работы можно, перечисляя участвующие в них
«вещи», но при общении с внешними проектными ролями это перечисление
придётся делать каждый раз: люди плохо понимают объекты-процессы.

129
http://www.omg.org/spec/Essence/
 176

Одну альфу может представлять несколько продуктов/артефактов, ибо у альфы в

деятельности могут проявляться много различных свойств, требующих различных
представлений в мире. Скажем, требования могут быть представлены в трёх разных
документах — фрагменте технического задания как приложении к договору, тексте
стандарта и протоколе совещания. О состоянии требований можно будет сказать,
только рассмотрев все эти три документа.
Но и несколько альф могут быть представлены в одном артефакте/продукте. В
документе «Техническое задание» требования обычно есть в одном из разделов, но
в других разделах прописывают работы (полностью же документ обычно
называется «техническое задание на работы» — его главная задача указать
поручаемые контрактору работы!), и очень часто в этом же «техническом задании»
описываются и основные архитектурные решения (часто в разделе, посвящённом
требованиям — это будут ограничения, «ограничения конструкторской свободы»!).
Эта связь продуктов и их альф обычно определяется в рамках какой-то практики
(выбранной технологии работы). Рабочие продукты ситуативны для каждой
конкретной организации и даже конкретного проекта, а вот альфы более
стабильны, они прописаны в культуре: дисциплине/теории.
Экономия мышления заключается в том, что часто в проекте даже не очень большой
сложности одна альфа представляется в до десятка разных артефактах/продуктах
(часто документах, но помним и о просто физических объектах, и даже людях).
Обсуждение и мышление тем самым ведётся только для одного объекта-альфы, и
только при разбирательстве с какими-то конкретными деталями вытаскиваются
отдельные индивидуальные продукты. Например, «воплощение системы готово к
проведению пуско-наладочных работ?» — в то же время доказательство готовности
воплощения системы к пуско-наладочным работам может быть разбросано (кроме
факта наличия самих рабочих продуктов, представляющих воплощение системы “в
металле”) по десяткам разных документов: актов сдачи работ различными
подрядчиками, актов предварительных испытаний, писем контрагентов, записей в
базах данных систем управления активами предприятия, сообщений о наличии
расходных материалов и т.д.
Артефакты могут быть как входными для проекта, так и представлять собой
результаты, или же быть полезными только команде, не являясь ни входными, ни
результирующими для проекта. Мы будем смотреть на них, и понимать, в каком
состоянии находятся представляемые ими альфы — главные объекты нашего
внимания!
Как и альфа меняется, проходя состояния, продукты/артефакты
меняются, проходя уровни детальности. Код компьютерной программы может
быть записан в виде идеи, в виде псевдокода, в виде кода с ошибками, в виде
компилируемого без ошибок кода, в виде хорошо откомментированного кода —
детальность нарастает, но это вовсе не означает, что альфа «код компьютерной
программы» при этом приближается к готовности: вполне возможно, что не нужно
было хорошо комментировать код, а нужно было даже поменять идею этого кода,
документировать совсем другую идею! Подробней это различие состояний альф и
уровня детальности рабочих продуктов разбирается в OMG Essence.
Продукты/артефакты в ходе инженерного, менеджерского или
культурного проекта создаются, модифицируются, уничтожаются. Они
вместе с их уровнями детальности наблюдаемы, в отличие от альф, о
 177

состояниях которых мы можем судить только "по приборам" — по

рабочим продуктам. Но главное — это состояние альф! Вася Пупкин нас
интересует ровно в той мере, в которой он справляется с исполнением роли Принца
Гамлета. Техническое задание нас волнует ровно в той мере, в которой оно с каким-
то уровнем детальности документирует требования и те работы, которые
необходимо выполнить.

Системное описание
Системная документация/документация системы (system description) это
документы, реализующие альфы описания системы (system definition). Если
система есть, то она обычно описана: подразумевается, что уже есть её требования,
есть её архитектура, есть неархитектурная часть проекта/design, их только нужно
выявить (мы их можем просто ещё не знать — система-то в пространстве-времени,
и время тут может быть в некотором будущем, или мы просто не нашли ещё
исполнителя правильной проектной роли, и не догадались ещё задать им
правильный вопрос). Чтобы явить миру описание системы, его нужно записать на
каком-то носителе, чтобы появилась системная документация — записать
требования, архитектуру и т.д. на бумаге, или представить в электронном виде в
базе данных. Есть система — значит кто-то её выделил из окружающего мира,
думает о ней. Думает — значит что-то в ней описывает, или описывает её в целом,
«система в глазах смотрящего». Если не может описать, значит систему из
окружающего мира ещё не выделил. Мы должны чётко различать всегда
существующее описание системы как альфу и не всегда существующую
документацию системы как артефакт.
Иногда переводят описание системы/system definition как «определение системы».
В этом случае нельзя путать термин со «словарным определением», типа «наша
система — это то-то и то-то». Нет, это самая разная информация о воплощении
системы, она включает и требования, и архитектуру, и неархитектурную часть
проекта/design, так что одной фразой «определения из словаря» её не заменишь,
тут совсем другое значение термина.
Стандарт ISO 42010 даёт рекомендации о том, как думать о системном
описании/описании системы. Сам стандарт говорит только об архитектурном
описании, но его положения вполне применимы к любым описаниям. Вот задающая
мышление об описаниях системы диаграмма из этого стандарта, модифицированная
с использованием положений OMG Essence:
 178

В жизни обычно всё начинается с выявления описания, потом документирования

этого описания, а потом переходит к воплощению системы. В философской логике
рекомендуют начинать с воплощения системы, даже если это воплощение будет
существовать только в будущем. Ни на секунду не нужно забывать, что нужно-то
воплощение системы, а описание нужно только в силу того, что без описания очень
трудно воплотить в жизни работающую систему. Поэтому заданного направления
чтения (слева направо, или справа налево, или снизу вверх, или сверху вниз) этой
диаграммы нет: разные проектные роли для разных целей читают эту диаграмму в
разных направлениях. Но самое общее — это, конечно, воплощение системы. Ради
него вся деятельность и затевается, его всегда нужно держать во внимании
(напоминаем, что все подобные диаграммы — это чеклисты для объектов, которые
нужно удерживать во внимании при мышлении о системах).
Диаграмма начинается с уже знакомого нам различения воплощения (realization) и
описания (definition) системы.
Для простоты диаграммы большинство отношений (кроме одного:
удовлетворяет/описывается в одну сторону и характеризует/описывает в другую
 179

сторону) приведены только с одним наименованием связи, но это не значит, что не

существует обратного отношения. Это общее свойство всех подобных схем: даже
отношение «часть-целое» в одном направлении читается «включает_в_себя», в
другом направлении читается «является_частью».
Каждая связь между объектами этой диаграммы может быть прочтена в двух
направлениях, например «описание системы выражается документацией
системы/системной документацией», «системная документация документирует
системное описание». Говорят и «системная документация», и «документация
системы», и «системное описание», и «описание системы».
Обратите внимание, что документация не фиксирует, а документирует
описания! Избегайте слова «фиксирует», потому как люди обычно
думает, что это означает не документирование (как думаете вы,
произнося слово «фиксирует»), а объявление описания уже не
изменяющимся. Фиксация или фиксирование требований для большинства людей
означает не запись требований на бумагу или в базу данных, а объявление текущего
состава требований стабильным и неизменяемым! Но в системном мышлении вы
лучше и лучше описываете систему (или описываете всё более лучшую систему, по
мере понимания этих требований), меняя и меняя тем самым требования —
документированные требования этому не мешают, они просто документированы, но
не фиксированы ни в один момент времени проекта! Вы можете какую-то версию
требований объявить стабильной. Инженеры говорят в этом случае о
базисе/baseline, но это не означает «фиксации»! Просто изменения системных
описаний будут собираться и документироваться в других артефактах, а не в
базисе/baseline — а базис будем меняться по какой-нибудь административной
процедуре.
Вот эта же схема на английском языке:
 180

Описание системы (system definition) состоит из ролевых описаний системы

(view), которые определяются ролевыми интересами (concerns) и задаются
ролевыми методами описаний. Ролевые описания системы — это как раз
требования (формулируются ролью инженера по требованиям), архитектура
(формулируются ролью инженера-архитектора), неархитектурные части дизайна
(формулируются ролью инженера-проектировщика), данные об эксплуатации
(формулируются ролью инженера по эксплуатации): всё что угодно, что определяет
интересные для роли ипостаси/аспекты системы.
Конечно, ролевых описаний может быть множество. Например, роль могут
интересовать финансы. Тогда ролевое описание — финансовое, модели там
будут — бухгалтерский баланс, отчёт о прибылях и убытках, поток денежных
средств. Как сделать эти описания? Эти описания могут быть сделаны по методу
описания РСБУ (Российская система бухгалтерского учёта) или МСФО
(Международная система финансовой отчётности), а мета-модели — это форматы
представления бухгалтерского баланса, отчёта о прибылях и убытках, потока
денежных средств в соответствующих ролевых методах описания (РСБУ или МСФО).
 181

Если финансиста заинтересуют оба метода описания, то он получит два описания —

и по РСБУ, и по МСФО. Как будут документированы эти описания? Или на бумаге,
или в табличках Excel, или в базе данных компьютерной бухгалтерской
программы — в любом случае, содержание описаний можно обсуждать без
обсуждения формата представления на носителях информации.

Подальфы
Подальфы (sub-alpha) определяются по отношению к основной альфе как такие
альфы, при продвижении состояний которых к конечному их состоянию в проекте
мы можем считать, что этим самым как-то продвигается и их основная альфа. Так,
требования являются подальфой описания системы: чем более готовы требования,
тем более готово описание системы (помним, что одни и те же требования, одно и
то же описание системы может быть отображено на разных носителях разными
методами — какая-то степень готовности описаний означает их содержательную
готовность, а не степень документированности!).
Так, системное описание можно представить проходящим состояния:
• Замыслено (ясно, каково будет описание системы)
• Непротиворечиво (описание системы создано и непротиворечиво)
• Используется для изготовления (описание используется для изготовления
воплощения системы)
• Используется для проверки воплощения (описание используется для
проведения тестов и испытаний)
• Используется для эксплуатации (используется проектными ролями для
эксплуатации воплощения системы)
• Используется для вывода из эксплуатации (используется для ликвидации
и/или переработки воплощения системы)
Требования можно представить себе проходящими состояния (эти состояния мы
берём из OMG Essence):
• Замышлены (conceived, проектные роли согласились в необходимости новой
системы для удовлетворения потребностей)
• Ограничены (bounded, назначение новой системы понятно)
• Непротиворечивы (coherent, требования непротиворечиво описывают
существенные характеристики новой системы)
• Приемлемы (acceptable, требования описывают систему, которая приемлема
для проектных ролей)
• Отвечены (addressed, достаточно требований были отвечены воплощением
системы так, чтобы это было принято проектными ролями)
• Удовлетворены (fulfilled, требования полностью отвечают потребностям)
Если требования проходят по этим стадиям, то это как-то ведёт и системное
описание в целом (в системное описание входит ещё и архитектура как важные
проектные решения, и рабочее описание с подробностью, достаточной для
изготовления системы). Поэтому требования — это подальфа системного описания.
Архитектура — это тоже подальфа определения системы: чем более готова
архитектура, тем более определена система.
Отношения альф и подальф определяются деятельностно (а не как
отношения часть-целое! Но мы думаем об этих отношениях похоже, но не
 182

полностью идентично как про отношения часть-целое): если проектные

роли при реализации своих предпочтений двигают подальфы по их состояниям, то
они тем самым двигают альфу этой подальфы. Если проектные роли двигают альфу,
то по факту они это делают, двигая все подальфы этой альфы.
На диаграмме чётко видно, что ролевое описание отвечает на вопросы ролевого
интереса (concern). Помним, что проектная роль может иметь и несколько
интересов. Ролевое описание позволяет описать систему так, чтобы поддержать
разговор с проектной ролью на тему её интереса, ответить на интересующие её
вопросы. Результат? Успешная система: если стейкхолдер соглашается с описанием,
то воплощение системы, удовлетворяющее этому описанию его тоже, скорее всего,
удовлетворит. То есть успешность системы мы часто можем определить ещё тогда,
когда воплощения системы ещё нет, а есть только описание.
При этом показываем проектной роли документы, ибо без носителя информации
нет способа предъявить эти описания! Первым делом все описания нужно
документировать!
Описаний же много: разные роли/stakeholders интересуются крайне разными
ролевыми описаниями/views системы, оформляются ролевые интересы/concerns
самыми разными методами описаний/viewpoints. И, конечно, каждое описание
может быть многократно документировано разными способами (например, с
использованием разных нотаций — числа могут быть записаны арабскими цифрами,
римскими цифрами, в двоичной системе) на разных носителях.
Все эти многочисленные ролевые/тематические/по интересам описания —
подальфы системного (полного/всестороннего/для всех ролей/для всех интересов)
описания.
Разница между описанием и документацией принципиальна, но в жизни очень часто
в речи их путают: архитектуру (часть определения системы) и архитектурную
документацию (рабочие продукты/артефакты/документы, отражающие
информацию об архитектуре на каком-то информационном носителе). Очень часто
слово «документация» опускают и предупреждают читателей, что из контекста
должно быть понятно — об архитектуре (описании системы) говорят или об
архитектурной документации (рабочем продукте/артефакте/документе).
Часто ещё и путаются пары определение/definition (у нас это будет описание) и
описание/description (у нас это будет документация) против пары описание-
документация. Например, архитектура и архитектурное описание, если они
противопоставляются, часто означает архитектура-как-описание и архитектурная
документация! Вы вполне сможете разобраться в любом варианте терминологии,
принятом в той или иной сфере деятельности, если понимаете, что всегда
существует два разных объекта (идеальный и отражённый на носителе
информации) — они просто обозначаются разными словами, принятыми в разных
профессиональных сообществах.
В оригинальном ISO 42010, например, view вообще определено как ролевая
документация, а viewpoint — документация метода описания, но в большинстве мест
самого стандарта они используются как ролевые описания, а не документация!
Более того, полное системное описание встречается в жизни довольно редко, много
чаще встречаются ролевые описания системы. Поэтому view обычно переводится
просто как «описание», без указания на то, что оно ролевое, а не полное
 183

системное — но при этом подразумевается его частичность. Требования — это тоже

описание, и архитектура — описание, и отчётность по РСБУ и МСФО описания, но
они не всё системное описание. Это всё подальфы системного описания, продвинуть
по его состояниям системное описание можно, продвигая работами проекта по их
состояниям ролевые описания.
А какие ещё варианты (ролевых) описаний можно выделить, какие ещё подальфы
могут быть для системного описания?
Прежде всего, можно выделить функциональные/компонентные описания,
конструктивные/модульные описания, описания размещения. Но и кроме этого
может быть огромное количество описаний, интересующих самых разных
стейкхолдеров/самые разные проектные роли: например, финансовое,
синхронизации во времени, структуры владения, информационных потоков и т.д.
Чем сложней система, тем бо́ льшего количества (частных/ролевых/на какую-то
одну тему) описаний можно ожидать. Интересы людей многообразны, и успех
системы определяется как раз учётом многообразия этих интересов. Не учёл
описаний, затрагивающих, например, морозостойкость — не получил успешную
систему. Или не учёл различные описания, которые показывают поведение системы
на разных системных уровнях. Разнообразные интересы и отвечающие на них
разнообразные описания лежат в основе системного мышления.

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

На диаграмме чётко показано, что метод описания (viewpoint) оформляет интерес
(concern), а описание (view) удовлетворяет интерес. Тем не менее, их нещадно
путают, равно как и интерес, предпочтение в этом интересе и намерение что-то
сделать для реализации предпочтения в интересе. Конечно, всё это близкие
понятия, но все они привлекают внимание к разным сущностям проекта!
Если у меня интерес к цвету системы, то моё предпочтение — яркий цвет (оценка
интереса — недовольство тем, что цвет недостаточно яркий). Я выбираю метод
описания цвета (оформляю интерес при помощи метода описания), включающий
характеристики насыщенности цвета — это позволит мне прогнозировать яркость
цвета, испытывать полученную яркость окрашенной системы, формулировать
требования к яркости, и договариваться с другими проектными ролями. Другая
проектная роль — инженер, который должен обеспечить покраску системы. И он
может заботиться о том, чтобы краска была дешёвая (требование ещё одной
проектной роли — менеджера-финансиста), а яркость этой краски его волновать не
будет. Но дешёвая краска яркой не бывает. Но если я документирую нужную мне
цветность, описав при помощи стандартных характеристик colorfulness, chroma,
saturation, плюс будет учитываться внешнее освещение (brightness), то мы как
минимум сможем провести переговоры на тему приемлемых характеристик
цветности, инженер сможет подобрать краску — моё предпочтение яркого цвета
будет реализовано.
Выбор метода описания оказывается нелёгким: описывать цветность и
насыщенность цветов можно по-разному130. Но мы в конечном итоге выбираем
способ, и обсуждаем мои хотелки/предпочтения иметь цвет поярче — моё
намерение тут или заставить краску выбрать подороже, или даже сделать
дополнительную подсветку (что ещё дороже, но я буду искать союзников, которым

130
https://en.wikipedia.org/wiki/Colorfulness
 184

понравится эта опция для реализации каких-то своих предпочтений).

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

7. Системное моделирование
Описания и методы описания, модели и мета-модели
Само (ролевое, view) описание состоит из множества отдельных моделей (models),
которые можно трактовать как отражающие разные важные особенности системы
формальные или неформальные описания, отвечающие на ещё более частные
интересы, чем собранное из этих моделей ролевое описание. Например, полное
системное описание включает в себя финансовое описание системы, но в
финансовом описании можно в свою очередь выделить разные модели, нужные для
ответа на разные вопросы интересующейся финансами проектной роли: баланс,
отчёт о прибылях и убытках (profit and loss, P&L) и денежный поток (cash flow). Если
у вас есть только баланс, то вы не ответите на вопрос о безубыточности работы
предприятия, а если у вас отчёт о прибылях и убытках и даже баланс, то вы не
сможете обсудить кассовый разрыв без наличия документов по денежному потоку.
Одно ролевое описание для одного интереса, три разные модели для трёх
подинтересов (конечно, интересы тоже разбиваются на подинтересы!).
Каждая из моделей должна быть выполнена с использованием одной из мета-
 185

моделей, причем каждая из мета-моделей устанавливает определенные язык,

правила и приёмы моделирования (соглашения), используемые при разработке
модели. Так же как отдельные модели (models), отвечающие на какой-то интерес,
объединяются в тематическое описание (view), так и мета-модели
(metamodels/model kinds), определяющие язык, правила и приёмы моделирования
(соглашения), используемые при ролевых/тематических/частных описаниях,
объединяются в ролевые/тематические/частные методы описания (viewpoints).
Например, для финансового описания нужно прежде всего выбрать один из методов
описания — РСБУ (Российские стандарты бухгалтерского учёта), МСФО
(международные стандарты финансовой отчётности). При составлении баланса
(одна модель финансового описания) и отчёта о прибыли и убытках (другая модель
финансового описания) нужно использовать мета-модели (соглашения по тому, как
делать модели) для этих видов моделей из какого-то одного метода описаний —
либо РСБУ, либо МСФО.
Проще всего считать, что метод описания — это набор условных обозначений для
многослойных карт-моделей, которые описывают территорию. Одно из следствий
рассматриваемой схемы: нельзя делать ролевые методы описания, если в
явном виде не рассматривается ролевой метод описания. Нельзя делать
карты и/или давать рассматривать другим проектным ролям карты, если
изготовителю карты и/или другим проектным ролям неизвестна легенда карты и
методы картографирования. Карты, сделанные по разным методам описания, потом
нельзя сопоставлять друг с другом. Нельзя делать карту, используя слои,
подготовленные согласно разным методам картографирования — нельзя брать
подготовленную геодезистами карту водных ресурсов города и подготовленную
службами метрополитена карту-схему станций метро и просто накладывать их друг
на друга. Нельзя брать баланс по РСБУ, а отчёт о прибылях и убытках делать в
МСФО. Все модели (models) из описания (view) должны быть подготовлены с
использованием мета-моделей из одного метода описания (viewpoint). И да, метод
описаний нужно согласовывать с проектной ролью, ибо в зависимости от интереса,
предпочтений в этом интересе, намерений что-то предпринять разные проектные
роли будут требовать использовать разные методы описаний! Например,
финансисты из бухгалтерии будут требования финансовых описаний по МФСО (и у
них важным будет описание себестоимости), а операционные менеджеры будут
отказываться от таких описаний и настаивать на ведении собственного финансового
учёта, потому что они будут считать «себестоимость» вредной и сбивающей с толку
характеристикой, настаивая на совершенно других методах финансового расчёта,
более пригодных не для целей налогообложения, а для целей операционного
менеджмента. Они могли бы настаивать на использовании методов описания,
принятых в учёте протока/throughput accounting из теории ограничений
Голдратта131.
Метод описания чаще всего бывает библиотечным (library), это означает, что
вместо раскрытия его содержания приводят просто ссылку на литературу по этому
методу. Это всё равно как вместо легенды карты можно было бы просто дать ссылку
на книгу, где рассматриваются условные значки для изображения деталей рельефа,
флоры, фауны, полезных ископаемых, плотности населения и т.д. Но если пришлось
описывать что-то таким способом, который до сих пор не использовался, то вместо

131
https://en.wikipedia.org/wiki/Throughput_accounting
 186

этой ссылки придётся к описанию приложить и документированный метод описания

(метод описания — это тоже альфа, поэтому тоже нуждается в документировании).
Главное — это запомнить: любое описание — это описание системы, любое
описание системы сделано с использованием метода описания (даже если
описывающий этого не осознаёт), доступно людям описание становится только
после его документирования, метод описания — это описание описания (поэтому
уместны вопросы и про метод описания метода описания, и про документирование
метода описания!).
Метод описания оформляет (frame) интерес (concern) проектной роли. Одно из
следствий рассматриваемой схемы: если у стейкхолдера нет
соответствующего интереса, то описание не делается (и, соответственно,
не документируется): описания, к которым ни у кого нет интереса, не
нужны. И наоборот: если у проектной роли обнаруживается интерес, то
описание делается обязательно (документируется! Речь не идёт об устных
ответах на вопросы! На бумаге, или в базе данных, но описание должно быть!).
Описания (views) могут быть двух видов: прожекторные (projective) и синтетические
(synthetic).
Прожекторные описания — это как в театральном прожекторе, в котором лампа
белого цвета, но мы делаем цветной луч, просто отфильтровывая все цвета кроме
того, который нам понравится. По факту это означает, что у нас есть большая база
данных, в которой хранятся все связанные между собой разные модели разных
ролевых описаний — все вместе, в одном каком-то формате документирования. Но
когда нам нужны данные одной модели (model), то просто из этой совместно
хранящейся одной базы данных как системного документа отфильтровывается
только то, что нужно (запрошенные ролевые описания, или даже запрошенные
отдельные модели из этих описаний) и отображается в подходящих форматах
документов.
Синтетические описания — это когда наоборот: исходные описания даны в виде
отдельных документов моделей, причём каждая модель документирована не просто
как часть одной общей для всех моделей базы данных (как в прожекторных
описаниях), а отдельный бумажный или электронный документ. Между этими
автономными моделями из отдельных документов устанавливаются правила
соответствия (correspondence rules, «этот объект этой модели — это вон тот
элемент вон той модели»), и общая модель тем самым получается синтетически
объединением отдельных автономных моделей. Рассуждения про
системные/полные и ролевые/частные описания системы при этом не меняются от
того, как собираются эти описания из документации моделей — сразу в общем
документе (прожекторный подход к описаниям) или после создания отдельных
документов моделей (синтетический подход).

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

Суть системного мышления — это получить системное описание, в котором учтено

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

Почему важно уточнять, что речь идёт именно о структурных моделях? Потому
132

что сейчас есть и коннекционистские (нейронные) компьютерные модели, для

которых эти рассуждения неприменимы.
 188

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

Метод описания и мега-модель

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

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

Понятие конфигурации
Конфигурация (configuration) — это текущее актуальное состояние системы (всех
её частей на всех системных уровнях) и её описаний. Обычно в ходе разных
проектов порождается множество самых разных вариантов частей воплощения
системы, множество самых разных описаний системы и её частей, относящихся к
разным моментам времени, разработанных самыми разными людьми, и нужно
понимать — какие изо всех этих частей системы входят в текущее разбиение
системы, и какие описания являются для них актуальными. Ведь отнюдь не все
изготовленные части будущей системы идут в дело, некоторые остаются
неиспользованными. Отнюдь не все варианты описаний системы идут в
реализацию: некоторые отвергаются в пользу других, подходящих для успешности
системы (более функциональных, более надёжных, более дешёвых, более быстрых
в изготовлении, и т.д.).
В ходе разработки инженерной системы обычно рассматривают самые разные
варианты требований, архитектуры, неархитектурной части проекта/design. И эти
описания ещё и изменяются каждое по нескольку раз. Как определить, какие из
этих описаний должны быть использованы изготовителями системы? А если часть
изготовителей изменили систему так, что она уже не соответствует этим описаниям,
а часть изготовителей работает «как договаривались» — можно ли быть
уверенным, что из изготовленных частей можно будет собрать работающую
систему? Конечно, нет. Ошибки, связанные с тем, что некоторые части системы и
их описания не известны, или даже известны, но не соответствуют друг другу,
весьма распространены.
 190

Конфигурация системы — это сами части системы и их описания. Сама

конфигурация может быть определена (defined) и, соответственно, описана
(described). Документация конфигурации (configuration description, иногда
говорят и «конфигурационное описание») в речи часто сокращают до просто
«конфигурация» — и разницу между конфигурацией (составом самой системы) и
описанием конфигурации нужно определять из контекста так же, как разницу между
архитектурой и архитектурной документацией, когда для обеих используют слово
«архитектура».
Управление конфигурацией (configuration management) — отслеживание, что
конфигурация воплощения системы и описания системы известны и соответствуют
друг другу. Это дисциплина лежит посредине между менеджерскими и
инженерными дисциплинами. Конфигурация составляется из конфигурационных
единиц (configuration item) — самых мелких частей, на которые делится система в
части её логистики. Речь идёт о единицах передачи частей системы и описаний этих
частей от одного исполнителя работ к другому, от одной обработки к другой.
Инженеры часто имеют более детальные описания частей системы, чем это
требуется для организации перемещения рабочих продуктов. Например, каждый из
многих миллиардов транзисторов на чипе уникален, но конфигурационной
единицей в цеху электроники служит сам чип, а не эти транзисторы, ибо отдельно
транзисторы никому не передаются.
Чтобы не потерять эти конфигурационные единицы при учёте, иметь возможность
на них сослаться в разговоре и различных описаниях системы, им даются
индивидуальные обозначения (designations). Стандарт IEC 81346 133 представляет
собой стандарт, в котором предлагается типовой способ такого описания,
учитывающий системный подход — наличие нескольких альтернативных структур
системы (функциональной, модульной/продуктной, размещений, и т.д.).
Описания системы всегда являются описаниями каких-то конфигурационных
единиц и их обозначения обычно создаются путём приписывания к названию
конфигурационной единицы вида описания. Если для каких-то целей вдруг
потребовалось описать три или четыре конфигурационных единицы, то скорее
всего речь идёт об описании какой-то системы из этих единиц и нужно просто
создать из них новую конфигурационную единицу, которой и будет соответствовать
описание.
Версия (version) системы — это её конфигурация по состоянию на какой-то момент
времени. Отслеживание смены версий в результате изменений (changes) нужно
для того, чтобы точно указывать, какая из многочисленных возникающих и
исчезающих по ходу проекта конфигураций системы имеется ввиду.
Базис (baseline, конфигурационный базис) — это проверенная на целостность и
утверждённая административно версия.
Управление изменениями (change management) часто включают в состав
управления конфигурацией (так и пишут: «управление конфигурацией и
изменениями», но обычно это отдельная дисциплина. Её не нужно путать с
управлением организационными изменениями — как нужно менять организацию,

133
IEC 81346-1:2009, Industrial systems, installations and equipment and industrial products — Structuring
principles and reference designations — Part 1: Basic ruleshttps://www.iso.org/standard/50857.html
 191

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

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

Функциональные описания: принципиальные схемы и сценарии

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

В ходе работы/функционирования функциональные части системы

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

Функциональные части физичны, они выбраны так, чтобы удобно было объяснять
работу системы в ходе её эксплуатации/функционирования (run time, operations).
Потоки — это чаще всего логические/ролевые/функциональные объекты, которые
тоже физичны, и через которые функциональные части взаимно влияют друг на
друга. Это могут быть и потоки света, и электрический ток, и энергомассоперенос
(в тепловых машинах), и даже данные (в программных системах).
В любом случае, мы приводим нашу мысль всегда в физический мир, но помним,
что на принципиальных схемах изображается поток, а не физический объект,
играющий роль проводника этого потока: например, электрический ток может течь
по проводнику, по корпусу, по болтовому соединению, но в принципиальной схеме
это разнообразие сред не будет изображено. В электрической схеме совершенно
необязательно иметь ровно такое же количество проводов, которое изображено на
этой схеме. Но между реализующими компоненты модулями ток всё-таки должен
иметь возможность течь, чтобы система работала, «провод» лишь один из
вариантов реализации потока/соединения/связи/взаимодействия. Точно так же
«труба» на гидравлической схеме будет только одним из способов реализации
взаимодействия — играющие роль функциональных частей системы
конструктивные части/модули могут быть соединены друг с другом
непосредственно, фланец во фланец, вообще без трубы, или вместо трубы жидкость
может идти по какому-нибудь жёлобу, вариантов тут не счесть. Главное, что на
схеме изображается то, что компоненты соединены друг с другом и можно
отследить их взаимодействие (чаще всего через передачу какого-то вещества или
энергии, или данных — но данные в конечном итоге будут тоже переданы через
передачу вещества, например, перевозку грузовика с магнитными дисками, или
энергии, например, через оптоволоконную связь, или через электрический ток
между частями компьютера).
Помним, что функциональные описания могут показывать не столько
функциональные части системы, сколько непосредственно поведение этих частей —
и это поведение тоже будет осуществляться над потоками. Тогда обычно говорят о
входе (входной поток), обработке/функции/процессе (преобразование входного
потока в выходной) и выходе (выходной поток). В этом случае говорят не о
принципиальных схемах, а о функциональных диаграммах, процессных описаниях.
 194

Вот пример такой функциональной диаграммы (function model134) в давно

устаревшей, но чрезвычайно распространённой и часто встречающейся нотации
IDEF0. Слева от каждого элемента его входы, а справа — выходы, на стрелках
написано, что именно передаётся от выхода предыдущей функциональной части на
вход следующей.
Ещё один вид функциональных описаний — это сценарии (scenario), иногда говорят
о сценариях использования (use cases, но переводить нужно не варианты
использования, а именно сценарии использования — оригинальный термин
придумал Ivar Jacobson по-шведски, и это был как раз «сценарий», case был признан
им неудачным переводом на английский).

134
https://en.wikipedia.org/wiki/Function_model
 195

Пример такой диаграммы135 иллюстрирует действие активных частей системы,

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

135
https://en.wikipedia.org/wiki/Use_case_diagram
 196

Иногда такие диаграммы дополняют ещё и совсем уже процессными диаграммами,

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

Модульные описания
Когда ролевой/деятельностный интерес относится не ко времени работы системы,
а ко времени построения системы — модульного синтеза, закупки
продуктов/модулей, сборки системы из частей конструкции/модулей/продуктов,
отгрузки получившейся системы-продукта, то необходимо использовать
модульные/конструктивные/продуктные описания. Эти описания отвечают на
вопрос «как сделана система» (ср. с функциональным «как работает система»).
На продуктных/конструктивных/модульных диаграммах показываются модули
(modules), соединяемые через интерфейсы (interfaces, буквально —
«междумордия», «то, что между»). Интерфейс обычно описывается каким-то
стандартом, описывающим как свойства соединения, так и происходящее в ходе
взаимодействия модулей через соединение. Принято говорить о сборке модулей,
обеспечивающей их взаимодействие через интерфейсы как об интеграции, а
описывающие двустороннее взаимодействие стандарты называют протоколами.
Интерфейсы модулей похожи на порты компонент в том плане, что это именно
места присоединения, то есть они не конструктивные элементы, они не занимают
объёма в пространстве, хотя у них и может быть форма. Вилка и штепсель, гнездо
и штеккер, кабель USB и гнездо USB: интерфейс — это то, что между ними. А сам
физический конец кабеля, оформленный в соответствии со стандартом, сам разъём
в компьютере, если речь идёт о USB? Это интерфейсный модуль, главное
назначение которого — обеспечить какой-то интерфейс. И у этого модуля не один
интерфейс обычно, а два интерфейса: один целевой, а другой — присоединяющий
его к какому-то модулю, для которого нужен целевой интерфейс.
Вот пример такого интерфейсного модуля (который в просторечии называют USB-
 197

интерфейс, что неверно — у него есть ещё и сигнальный интерфейс к плате, и

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

А как же соединения, которые нужны для работы — все эти трубы, кабели,
волноводы? Это тоже модули, и у них есть свои интерфейсы: они находятся между
ними и теми модулями, которые они соединяют. Что проходит через эти
интерфейсы, и как оно связано с работой всей системы?! Неизвестно, ибо речь идёт
о конструктивных единицах: функции тут не определить, для этого нужно выходить
за пределы модульного описания в область инженерных решений: важных
(архитектурных) и менее важных (всех проектных, «рабочих»). Большинство этих
решений как раз о том, роли каких именно функциональных частей будут играть те
или иные конструктивные части/модули, какие между ними будут интерфейсы, и
через эти интерфейсы какие будут выполняться сервисы, соответствующие
функциям. Помним: со стороны системы ожидаются от подсистемы как
функциональной части выполнение функций, а со стороны подсистемы как
конструктивной части для системы ожидается выдача сервиса как интерфейс. Часто
речь идёт о выдаче/приёме модулем какого-то физического потока, проходящего
через интерфейс и переработке его. Этот поток будет соответствовать
функциональному потоку из функционального описания (например,
принципиальной схемы), который идёт через функциональную/ролевую часть, на
исполнение роли которой назначен модуль. Так, через USB-интерфейс может
передаваться тот или иной поток данных, физически это будет соответствовать
прохождению тех или иных токов через контакты интерфейса — но на
принципиальной схеме/функциональной диаграмме/dataflow diagram это будет
поток данных между функциональными частями системы.
При интеграции важна не просто сборка, а согласование работы модулей на своих
интерфейсах: монтажник должен убедиться, что соединение через интерфейс
установлено, и тем самым модуль сможет выполнять свой сервис.
Для интерфейсов известны правила, по которым устанавливается соединение через
интерфейс, но неизвестно, что именно и зачем передаётся через этот интерфейс —
это будет известным только из принципиальной схемы.
Например, принтер и компьютер связаны через USB интерфейс, но какая
информация идёт принтеру, это интерфейсу неизвестно. Утюг к электросети
подсоединён через интерфейс между евровилкой и евророзеткой, но этому
интерфейсу неизвестно, какой через неё пойдёт ток и зачем. С другой стороны,
известны предельные значения тока, который может пройти через этот интерфейс,
равно как предельное количество информации, которое может пройти через USB-
 198

интерфейс. Задача модульного синтеза при проектировании системы — это выбрать

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

Обратите внимание, сколько тут упоминается разных стандартов: GPS, HSPDA, DDR,
Bluetooth — перечисление интерфейсов, описываемых стандартами, обычно для
модульных описаний. Ведь вся суть модулей — это замена реализации какой-то
функциональной части системы путём простой замены конструктивной части:
модуля на стандартном интерфейсе.
Вместо одного принтера через интерфейс USB к компьютеру можно подключить
другой экземпляр принтера той же марки, или даже принтер другой марки, или не
принтер, а какое-то другое устройство (скажем, сканер, или даже дополнительный
дисплей) — без стандартизации интерфейса это было бы невозможно.
Все эти рассуждения относятся и к предприятиям/организациям, но для них
функциональные части — это практики работы, а конструктивные части — это
оргзвенья, выполняющие эти практики. Об этом будет рассказано подробней в
последующих главах, когда будем говорить о системах обеспечения жизненного
цикла системы, которые чаще всего социотехнические/организационные.

Платформы и технологические стеки

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

интерфейс. Обсуждение платформы всегда связано с её сервисами, т.е. внешним

поведением, предоставляемом на интерфейсе к вышестоящим в
продуктном/конструктивном/модульном разбиении более крупным
продуктам/модулям. Для программных модулей этот интерфейс обычно называется
API (application program interface), программный интерфейс приложения
(приложение — это более высокий уровень. Платформа буквально входит в состав
приложения в ходе его работы, является его подсистемой, хотя часто платформу
рассматривают как находящуюся в окружении, но тогда в приложении есть
интерфейсные модули, обращающиеся к сервисам платформы вовне приложения и
имеющие второй интерфейс для модулей внутри приложения. Часто такие
интерфейсные модули называются «адаптерами»).
Если речь идёт не о программной системе, то можно говорить просто о прикладном
интерфейсе. Прикладной — это определяемый надсистемой платформы как
согласованного в части выполнения каких-то сервисов набора модулей.
Приложение обычно — это надсистема для платформы-продукта/модуля, части
приложения находятся в окружении продукта-платформы.
Основной вопрос при обсуждении платформ — это так называемая видимость
интерфейсов. Интерфейсы какого-то низкого системного уровня не должны быть
видны снаружи модуля, то есть нельзя соединять модули иначе, чем через
предусмотренные в нём интерфейсы. Грубо говоря, если у вас коробочка с
каким-то разъёмом, то нельзя воткнуть внешнее устройство не в этот разъём, а
куда-нибудь внутрь коробочки, мимо этого разъёма, даже если очень хочется. В
системах всё со всем связано, и по неотслеженному соединению (это ведь будет
тоже интерфейс, только «неучтённый») могут пройти паразитные связи, возникнут
непредвиденные ошибки.
Например, если в ваше подразделение, где вы тщательно планируете работу
сотрудников, получая заказы на эти работы через какой-нибудь трекер
(интерфейсный модуль, предоставляющий интерфейс заказа работ), могут прийти
какие-то люди из других подразделений и попросить сделать работы для них «вне
очереди» — и им не откажут, то последствия для организации будут фатальны:
какие-то неожиданные работы будут выполнены, какие-то вроде как свободные
сотрудники окажутся заняты, какие-то важные (но важность определяется
надсистемой! Внутри модуля-подразделения как заказчика, так и исполнителя
важность может быть неизвестной) работы не будут выполнены из-за задержек,
связанных с этой внезапно появившейся «из ниоткуда» (мимо запланированного
интерфейса) работой.
В электротехнике есть три типа неисправностей: есть контакт там, где он не должен
быть, нет контакта там, где он должен быть, и плохой контакт. Это шутка как раз
про интерфейсы — которые должны быть именно там, где они предусмотрены
конструкцией!
Для обсуждения видимости интерфейсов используется диаграмма
модульных/продуктных/конструктивных уровней. Каждый платформенный уровень
отделён от другого уровня каким-то стандартизированным (то есть описанным и
документированным!) интерфейсом. Реализации/воплощения нижестоящих
уровней тем самым могут быть сменены так, что надсистемы этого не заметят.
Итоговое многоуровневое разбиение называют платформенным стеком или
технологическим стеком (stack, стопка — диаграммы похожи на стопку подносов
 200

в столовой или стопку листов бумаги в пачке). Вот пример различных

технологических стеков для организации связи 136:

На диаграмме видно, что в разных сравниваемых стандартах связи

описываются/определяются пять уровней (по отношению часть-целое)
модулей/конструктивных частей/уровней платформ, которые можно разделить на
реализующие передачу физического сигнала (physical), передачу данных (Data
Link), и т.д. При этом модули передачи данных при работе обращаются к модулям
передачи физического сигнала, используя указанные в диаграмме протоколы. И так
по всем уровням выше: каждый уровень технологического стека (уровень
реализующих этот стек модулей) даёт интерфейс сервиса наверх и использует
сервисы нижележащих модулей.
Неважно, что делают эти уровни платформенного стека (это нужно обсуждать «как
работает», совсем другое обсуждение — не «из чего собрано и как соединено»
времени создания, а функциональное обсуждение времени работы/operations).
Главное в показе этого технологического стека то, что никакой модуль
вышестоящего уровня «не видит» модули более низкого уровня (не имеет к ним
доступа, не может туда «воткнуться»), чем находящийся непосредственно под ним,
и интерфейсы реализующих сервисы этих платформенных уровней
стандартизованы — как стандартизован и сам набор этих уровней.
Есть два способа чтения таких модульных/платформенных/технологического стека
диаграмм: на некоторых диаграммах «платформа» именуется стандартом, а
реализация этого стандарта находится как бы «между уровнями» (ровно этот способ
показан на диаграмме, он самый распространённый), и показ собственно модулей
(именование платформ), тогда API этих модулей либо считаются проименованные
самим модулем (скажем, программный модуль/пакет/библиотека глубокого
обучения TensorFlow имеет API TensorFlow, и поэтому его не нужно отдельно
прописывать — названия модуля достаточно). Но если платформенный уровень
реализует стандарт с другим именем, то он прописывается где-то в границах
реализующего его модуля отдельной строчкой поближе к границе использующего
модуля, или даже выносится и явно прописывается «между платформами», как это
сделано в картинке стека безопасности приложений137 — стандарты указаны сбоку
картинки платформенного стека, а каждая плашка обозначает слой модулей:

136
http://www.slideshare.net/Techtsunami/cn-prt-iot-v1
137
https://f5.com/about-us/blog/articles/why-cves-should-be-given-priority-one-for-resolution-27910
 201

Верхняя скобка для стандарта интерфейса в надсистему от custom code ведёт как
бы в никуда при таком способе показа, поэтому чаще используется способ
предыдущей картинки, где платформа обозначается не по назначениям/именам её
модулей/слоёв, а назначение указывается сбоку.
Часто оба этих способа перемешивают, получая гибридную модульную уровневую
диаграмму. Вот, например, модульная диаграмма компилятора искусственных
нейронных сетей, где верхние строки — наименования программных модулей-
пакетов реализации нейронных сетей (например, пакет MXNet), а нижние —
интерфейсных стандартов для какой-то аппаратуры (например, стандарт
OpenCL)138:

Это неважно, что вы ничего можете не понимать в предметной области,

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

138
https://tvm.ai/2017/10/06/nnvm-compiler-announcement
 202

диаграммы вам предлагает та или иная проектная роль, или какие диаграммы вы
рисуете сами.
Платформенность даёт возможность эффективного разделения труда: реализацией
каждого уровня платформенного стека может заниматься отдельная команда,
хорошо разбирающаяся в работе на их системном уровне (системный подход!), а
поскольку речь идёт о модулях, реализующих/исполняющих роль функциональных
частей, то такие команды могут соревноваться за эффективность реализации
требуемых функций сервисами своих модулей — на каждом системном уровне
своих. Инженеры, использующие какие-то платформы для создания своих целевых
систем, могут не задумываться, как именно и из каких систем были сделаны сами
эти платформы. Если вы пользуетесь каким-то сотовым телефоном, то вам всё
равно, из чего и как сделан этот телефон, если он умеет связаться с базовыми
станциями вашего провайдера сотовой связи.
Инженеры могут использовать прикладной интерфейс платформ, не интересуясь
устройством этих платформ — лишь бы эти платформы осуществляли сервис по
используемому прикладными инженерами интерфейсу! Это существенно упрощает
задачу создания сложных систем. Нужно хорошо разбираться в вариантах модулей
и выдаваемых ими на их интерфейсах сервисах, но необязательно разбираться, как
они устроены внутри, и как именно они внутри себя работают. А если этот
прикладной интерфейс стандартизован, и есть конкуренция поставщиков
модулей/продуктов/изделий/конструктивных частей, то они могут ещё и выбрать
подходящий им по цене и характеристикам вариант реализации. И это происходит
на много уровней вверх и много уровней вниз по технологическому стеку.
Деньги обычно приходят от удачного и массового использования верхнего, самого
прикладного уровня (конечно, для каждого уровня технологического стека
вышестоящий уровень является «прикладным», системное мышление применяется
рекурсивно — то есть одинаково для каждого системного уровня, одинаково для
каждой в нём системы). Посмотрите примеры явного использования рассуждений о
платформе в стратегии фирмы NVIDIA — при описании структуры интеллект-
стека139, технологического стека робо-такси140, стека вычислительной
инфраструктуры 141
и обратите внимание на тип диаграмм, который там
использован.
«Перетряхивание» всего технологического/платформенного стека, перестройка
всех рынков идёт обычно тогда, когда меняется принцип физической реализации
самого нижнего уровня модулей, меняется реализация платформы самого нижнего
уровня.
Например, когда в компьютерах поменялись механические или пневматические
элементы на вакуумные электронные лампы, компьютеры стали масштабируемы и
они начали напоминать уже функционально современные компьютеры, а не
калькуляторы прошлых лет. Замена ламп на дискретную полупроводниковую
технику позволила наладить массовый выпуск компьютеров и это разительно
изменило компьютерную технику. Замена дискретной электроники на большие
полупроводниковые интегральные схемы опять перевернуло весь компьютерный
рынок со всеми надстройками программного обеспечения. Замена CPU на GPU

139
https://ailev.livejournal.com/1380163.html
140
https://ailev.livejournal.com/1384766.html
141
https://ailev.livejournal.com/1416697.html
 203

перевернула рынок искусственного интеллекта. Замена людей-исполнителей на

роботов-исполнителей переворачивает все промышленные предприятия. Эта
особенность делает технологические/платформенные/модульные стеки удобными
для обсуждения стратегии компании — обсуждается, что из модулей будет
компания делать сама, а что закупать вовне, какие стандарты интерфейсов для этих
модулей она будет устанавливать сама, а какие брать уже готовыми142.

Важность функциональных рассмотрений целевой системы

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

142
Болваны для искусственного интеллекта http://ailev.livejournal.com/1356016.html, NVIDIA как поставщик
инфраструктуры для интеллект-стека, https://ailev.livejournal.com/1380163.html, NVIDIA как поставщик
инфраструктуры для роботакси-стека https://ailev.livejournal.com/1384766.html
 204

функция или функциональная часть в надсистеме (что выполняет модуль в составе

надсистемы) — нет.
Например, в архитектуре информационной системы магазина появляется просто
"база данных", а не "цены товарных позиций, правила предоставления скидок,
история покупок". Понятно, что всё это должно где-то храниться, но не факт, что в
нарисованной программистом на первой же его диаграмме "базе данных" (часть,
например, может браться на API какого-то сервиса, а правила представления скидок
могут храниться в настроечном файле или вообще оказаться искусственной
нейронной сетью), и не факт, что даже "база данных" будет одна.
Вот почувствуйте разницу: сервис «повышение давления» и функция
«обеспечение подъёма воды на верхние этажи», сервис «удары» и
функция «забивание гвоздя», сервис «вычисления» и функция «расчёт
калибровочной кривой». Функциональные диаграммы будут содержать
названия функциональных частей или функций, а
модульные/продуктные диаграммы, замаскированные под
функциональные — всё равно будут содержать названия сервисов, и
указывать не потоки, а стандартизованные интерфейсы как
места/каналы оказания сервисов.
Объяснить программисту про необходимость рисовать функциональные диаграммы
в составе архитектуры трудно, ибо он мыслит модулями, которые по его мнению
абсолютно универсальны и поддержат "любую функцию". Любую-любую? Помним,
что вы должны удваивать любой квантор всеобщности — «каждый», «всякий»,
«любой», «все» и т.д. и ставить после этого вопросительный знак, сомневаясь в
этой всеобщности. Нет, конечно. Но разочарование будет не в начале проекта, а
поближе к концу — когда окажется, что универсальных прикладных софтверных
систем не бывает, так же, как и любых универсальных систем других.
Вот пример, иллюстрирующий происходящее у программистов на примере более
понятной работы с «железной» системой — но того же класса, что и программы:
кажущейся суперуниверсальной по форме, но весьма конкретной и уникальной по
содержанию.
У нас стоит задача тонкого химического синтеза
диметилфторидметилхлорпентилбензолтитана для задач фармацевтической
промышленности. Известно, что его трудно синтезировать, и при синтезе
получается много примесей, от которых потом люди умирают. Поэтому мы
предложим аптекам такой чистый продукт, от которого люди не будут
умирать, а маркетинг будет оригинальный: через уборщиц медицинских
учреждений, которые будут подбрасывать наши буклеты врачам, а также
задушевно беседовать с пациентами в очередях ко врачам. Для того, чтобы
получить чистый диметилфторидметилхлорпентилбензолтитан, мы будем
использовать четыре стальных реактора, соединённых трубами диаметром
56мм, последняя труба с тефлоновым покрытием. Второй реактор закажем
внешним контракторам. Чистоту получающегося
диметилфторидметилхлорпентилбензолтитана будем отслеживать при
помощи независимой экспертной службы. Все четыре реактора должны будут
пройти проверку на выдерживание давления в 156 атмосфер.
В этом описании нет никаких идей, какие именно примеси имеют максимально
вредный эффект (а это архитектурное требование, самое важное!), как получить
 205

чистый именно от этих примесей (а не от любых — безвредные ведь не мешают)

диметилфторидметилхлорпентилбензолтитан, какие нужны исходные вещества и
доступны ли они, или их тоже нужно синтезировать в рамках проекта, далее
химические реакции, начиная с доступных веществ — т.е. подробное
разбирательство того, что происходит в реакторах.
Теперь представим инженера, которому маркетологи говорят, что ему нужно будет
решить задачу химического синтеза, но непонятно ещё какую. И они когда-нибудь
потом, но вот не прямо сейчас наймут химика, который всё уточнит. Инженер
соглашается и берётся за дело: ему сразу понятно, что нужны будут реакторы и
трубы. Реакторов непонятно сколько, ибо непонятно, сколько там в синтезе будет
химических реакций. Поэтому лучше бы этих реакторов было побольше. Он
выбирает цифру 4, как "не очень мало, но и ещё не очень дорого", догадывается,
что в этом синтезе может быть хитрая эндотермическая реакция, но сам он для
такой реакции реактор вряд ли спроектирует. Так что этот «хитрый реактор» он
отдаёт проектировать внешним контракторам и честно об этом пишет. Хотя
контракторы и спрашивали, что там с массами и температурой, ответ пока никто не
может дать, поэтому контракт планируется без разговора о требованиях — но
контрактор, разумеется, от заказа не отказывается и говорит, что "сделаю любой
реактор". Слово "любой" никого не отпугивает, ибо нет химика, который бы сказал,
что же будет в этом реакторе происходить. Есть только инженеры по железу,
хорошо разбирающиеся в марках стали и сварке, и маркетологи, беседующие с
врачами и фармацевтами.
В случае железа реактора и труб всё тут очевидно: вероятность выпуска чистого
диметилфторидметилхлорпентилбензолтитана в этой ситуации равна нулю. Но в
случае софта почему-то кажется, что задачу так решать можно. И вот
пишут про "сервера" и "базы данных", но каким образом там будет
происходить обработка какой информации, и с чего бы эта обработка
вдруг оказалась даже не лучше конкурентов, а вообще возможной, этого
вопроса не возникает. Ровно как в предыдущей задаче, где нет химика,
есть только сварщики и спецы по корпусам высокого давления. Они точно
сделают софтверный "универсальный реактор", но вот что там с чистотой
"информационного вещества" или даже просто запуском нужной
"информационной реакции" (слова "обработка информации" или
"расчёт" так и пишутся, без малейших уточнений, какой именно), и
получить исходные данные (или исходную информацию? данные! ибо
информация что-то означает, а данные тут как сырьё — можно
игнорировать их содержание) — это не к ним.
В проекте получения чистого диметилфторидметилхлорпентилбензолтитана химика
пока нет, про химию разговор поддержать некому, равно как сообразить, как же эта
химия влияет на примеси, а примеси на здоровье пациента. За разговорами про
реакторы и трубы к этому моменту уже можно забыть, что задачка про
медицину, потребности тут в здоровье пациента (целевая система тут в
пациенте, а реакторы и трубы — в обеспечении, «сбоку» системного
разбиения!). Делать приходится железную конструкцию «нашей системы». Но
нужно протянуть строгую логическую цепочку от целевой системы к нашей
системе — через химические реакции, которые описывают функциональную
структуру целевой системы, через ведущие к появлению вредных примесей
отклонения от режимов проведения этих реакций. При этом предметная область
 206

функциональных (химических) рассмотрений — по факту клиентская, а итоговые

модульные (труб и реакторов) рассмотрения — предметная область разработчика-
контрактора.
Возвратимся к программированию и типичным ошибкам айтишников. Увы, с первого
раза получить функциональную диаграмму, в которой рассказывается о том, что
содержательно происходит с клиентской информацией в корпоративных
информационных системах, обычно не удаётся. Нужна пара-тройка итераций с
функциональными частями системы и их назначением/поведением (функциям), но
зато после её получения уже вполне осмысленно и существенно корректируется
уже структура модулей.
Как это будет в случае нашего "железного примера"? После разбирательства с
функциональными описаниями будет изменено число реакторов, уберутся лишние
трубы, будут проведены дополнительные исследования по наличию на рынке
дешёвых датчиков чистоты продукта, найдут контрактора, который пишет
управляющий софт для закрытия-открытия задвижек на реакторах, чтобы
управлять ходом синтеза на основе показаний датчиков и т.д.
Сначала нужно разобраться с функционированием: что происходит в тот момент,
когда система работает/функционирует (слово «функционирует» тут не случайно!
Интересуют функции и функциональные части! Это ролевой интерес тех ролей,
которые отвечают за работу системы!), а не когда её собирают из размещаемых
где-то частей-модулей. Потом нужно будет рассмотреть и модули, и размещения.
Но это всё потом.
Рассмотрение функционирования сначала, а конструкции потом — это
важная часть системного мышления: сначала нужно обсудить подробно,
зачем эти конструкции и как они будут работать, а уже потом
рассматривать, из чего они будут собраны.
Например, можно рассмотреть применение этих рассуждений к танцам. Просто
махание ногами и руками (с запасом! Побольше махов, и сами махи пошире!) никого
не устроит. Каждый мах должен быть понятен, зачем — какая там эмоция, что этим
махом хотят сказать, что продемонстрировать. Тогда и мах будет подобран
соответствующий (резкий, плавный, объёмный или короткий, рукой или ногой —
ровно под необходимую функцию, а не "стандартный").
Мыслить только про конструкции нельзя. Отсутствие мышления о
функциональности нужно как-то осознавать и исправлять. А это
отсутствие мышления о функциональности заметно только в случае
наличия системного мышления — оно позволяет заметить то, о чём вы
забыли подумать, управляет вашим вниманием.
А теперь внимательно посмотрите на свой текущий проект: не пропущены ли в нём
функциональные рассмотрения? Если пропущены, то помним: без специалистов
предметной области (subject expert) надсистемы, а потом и целевой системы, и её
подсистем, и вашей системы (если она в обеспечении) вам не разобраться.
Общайтесь, общайтесь, общайтесь. Системные мыслители трансдисциплинарны,
они много общаются с проектными ролями, разбирающимися в самых разных
дисциплинах.
 207

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

оргзвеньев — это конструктивные, а не функциональные части

предприятия/организации. Из обсуждения организационной диаграммы не
скажешь, как работает предприятие, какие функции подразделений в частности и
оргзвеньев в общем (куда кроме подразеделний включены команды, временные
рабочие коллективы, научно-технические советы, кружки по производственным
интересам и т.д.). Именование оргзвеньев это часто отражает, в них самые общие
представления об оказываемом сервисе, вне связи с назначением/функцией этого
сервиса.
Цех №5, палата №6 — простые номера в именах, из которых не следует функций,
являются типичными указателями на конструктивное рассмотрение. Функций,
исполняемых конструктивными элементами предприятия, может быть множество, и
самых неожиданных. С другой стороны, если «подразделение переезжает в другое
здание», то это описание связи ипостасей конструктивной и размещения.
«Подразделение будет выполнять новые практики/виды деятельности» — это
обсуждение связи функциональной и конструктивной ипостасей подразделения.

Необходимость хорошей модульности

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

143
http://www.pnas.org/content/108/22/9008.full
 209

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

144
http://arxiv.org/abs/1207.2743
 210

(design/dependency structure matrix)145.

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

Борьба со сложностью в мышлении

Edsger Dijkstra в 1974 году ввёл 146 понятие разделения интересов (separation of
concerns) как способ упорядочивания человеческих мыслей о каком-то предмете.
Этот принцип гласит, что нужно обсуждать сложные ситуации в разных ролях, по
одному ролевому интересу за раз, удерживая внимание на каком-то одном аспекте,
одной ипостаси этой ситуации. Это не значит, что игнорируются все остальные.
Просто это удерживание во внимании одного аспекта проблемы и одновременно
всей проблемы. По словам Edsger Dijkstra про такое мышление, «It is being one- and
multiple-track minded simultaneously».
И это разделение мышления по интересам проводится на каждом системном уровне
из их множества, поскольку ввиду эмерджентности на каждом уровне система
начинает проявлять какие-то новые свойства и эти свойства нужно обсуждать.
Сложность обсуждения системы тем самым падает по двум направлениям:
• деление полного обсуждения всей системы на обсуждение её отдельных
частей по системным уровням. Каждая часть системы проще, чем система в
целом, поэтому обсуждение проходит более-менее единообразно на каждом
уровне, а каждая часть системы определяется ее требованиями
(requirements), описанием системы как «чёрного ящика». В требованиях
игнорируется внутренняя структура системы и её частей, поэтому
обсуждение начинается всегда с целых систем в составе надсистемы, или
целых подсистем в составе системы.
• деление полного обсуждения каждой системы на обсуждение с помощью
множественных описаний этой системы как прозрачного ящика: принципов
организации взаимодействия и структуры частей системы. Важнейшие из
этих определений — это архитектура (architecture), включающая и
функциональное, и конструктивное, и пространственное описание, равно как
и множество других. Но используются при обсуждении системы и все
остальные описания «прозрачного ящика», сделанные с точностью,
достаточной для изготовления — это неархитектурная часть
проекта/дизайна (non-architectural part of design).

145
http://www.dsmweb.org/
146
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
 211

Тем самым детальное и в подробностях обсуждение огромных сложных систем

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

Системное мышление по своей природе коллективно, оно позволяет разделить

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

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

как надсистемы для часов, а потом и в роли интересующихся временем,

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

8. Требования и архитектура
Требования как часть определения системы
Требования являются подальфой системного описания. Если есть система, есть и
требования к ней: о требованиях не принято говорить, что их разрабатывают (их
не придумывают!), их обычно выявляют (discover) в разговорах с различными
проектными ролями, а также в экспериментах. О требованиях хорошо думать
примерно так же, как о цвете системы в целом (который тоже может входить в
требования, так что это не самый плохой пример), при этом цвет может быть
довольно сложным (рябеньким).
Цвет — это не сама система, и это не часть системной документации
(документированием цвета был бы фрагмент текста с номером цвета из каталога
цветов, или длиной волны для этого цвета, или названием цвета, или пятно краски
нужного цвета, или записанные значения интенсивностей красного-зелёного-
голубого в составе цвета, и т.п.). Мы можем обсуждать цвет системы (уже
существующей, или только которая будет существовать), можем выявлять
пожелания к цвету у разных проектных ролей, формулировать цвет, учитывающий
эти пожелания, а затем документировать выявленный цвет успешной системы (ибо
он будет удовлетворять интересам проектных ролей), и всё это с учётом выбора
адекватного метода описания, подходящего для ответов на цветовые интересы
разных проектных ролей. Вот и самые разные требования как часть описания
системы мы можем выявлять, описывать (после выбора метода описания),
документировать, обсуждать, согласовывать.
Приключения требований на этом не заканчиваются: требования анализируют,
затем их наборы делают непротиворечивыми, при этом обеспечивают к ним доступ
самых разных проектных ролей (это обеспечение доступа и называется
управление требованиями/requirements management — менеджмент не
подразумевает какой-то содержательной работы с требованиями, а только
«логистику»: хранить требования так, чтобы их не терять и принимать их от тех, у
кого они есть и давать тем, кому они нужны. В управлении требованиями никакого
выявления требований или использования требований нет!).
Все практики работы с требованиями вместе называют инженерия требований
(requirements engineering). Обратите внимание, что как выявление требований
входит в инженерию требований, так и управление требованиями. Управлять
 213

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

Два понимания требований

Есть два понимания требований, которые нужно различать по контексту их
употребления (помним, что люди вполне могут разбираться в высказываниях типа
«косил косой с косой косой косой на косе» и понимают при этом, что у каждого
слова может быть много значений):
1. В системном мышлении (и системной инженерии соответственно) требования
(requirements) — это часть описания системы как «чёрного ящика», т.е. описание
того, что делает система в ходе её работы по отношению к её окружению, без
описания внутренней структуры этой системы и происходящих внутри системы
взаимодействий её частей. Прежде всего тут важно внешнее поведение системы,
выполнение ей своего назначения/функции в надсистеме. Поэтому основные
требования называют функциональными требованиями
Нефункциональных требований не бывает, хотя в литературе этот термин
регулярно встречается, но он считается некорректным: все требования описывают
какое-то внешнее поведение системы, ожидания этого поведения со стороны
надсистемы. Но речь не всегда идёт о поведении в надсистеме. Требования
качества в отличие от функциональных, относятся прежде всего к поведению в
системах обеспечения, в том числе обслуживающих уже готовую систему: по-
английски их иногда называют -ilities (reliability, accessability, repairability и т.п.), а
по-русски -ости (надёжность, доступность, ремонтопригодность, т.п.). Но их не
называют «нефункциональными»!
Требования отличают от потребностей (stakeholder needs, stakeholder
requirments) как требований внешних проектных ролей к их целевой системе, то
есть надсистеме обсуждаемого проекта.
Если мы выходим за пределы инженерии, то у требований могут быть другие имена.
Например, для организаций/предприятий речь может идти о стратегии — но суть
тут будет та же самая: описание того, что хотелось бы получить от организации:
какого сорта продукты или сервисы должна выпускать организация, в каких
географических регионах работать.
 214

Требования обязательно указываются для какой-то системы! Не просто X=10, а у

какой системы X=10.
Требование, взятое вместе с именем системы и временем его выполнения (когда
воплощение системы начинает соответствовать требованию), называют
контрольными точками (milestone). Если требование — это «помидор, красный»,
то «помидор, красный, 10 мартобря 2019 года» будет контрольной точкой. Очень
часто на контроле стоят не сами требования, а контрольные точки: «дорога ложка
к обеду».
2. Альтернативное «бытовое» понимание требования уже не имеет отношения к
системному подходу, не связано с границами системы. Это просто любое
утверждение, указывающее на долженствование или дозволение, рекомендацию.
Любое высказывание из описания системы (например, «X=10 для системы S»)
можно понять либо как описание текущей ситуации, или как будущей ситуации, или
ситуации, которая должна быть, или рекомендована быть такой, или которая
дозволена такой быть — и вот если речь идёт о таком
дозволении/рекомендации/долженствовании, то это требование 147: «Я требую,
чтобы X=10 для системы S».
В этом втором «бытовом» понимании требований можно потребовать что угодно —
и оно станет требованием, даже если речь идёт не о чёрном ящике. Например, «в
автомобиле должен быть корпус из углепластика», «в смартфоне должны быть
использованы отечественные микропроцессоры» относятся к «прозрачному
ящику», но слова «должен» и «должны» говорят о том, что в быту это назовут
«требованием»! Но это «требование» не из системного мышления.
Ограничения (constraints) свободы принятия решений инженеров по поводу
«прозрачного ящика» связаны именно с таким пониманием: ограничения как
высказывания по поводу устройства «прозрачного ящика» поступают вместе с
функциональными требованиями и требованиями качества, но их часто тоже
называют требованиями не по их системному пониманию, а по альтернативному,
бытовому. Поэтому «в автомобиле должен быть корпус из углепластика» является
не требованием, а ограничением с точки зрения системного подхода, но «по
бытовому» это будет тоже требование и появится среди других системных
требований. Системное мышление требует отсортировать требования отдельно, а
ограничения отдельно (помним, что при пересечении системной границы обычно
меняется состав проектных ролей, их интересы, язык обсуждения интересов и т.д.).

Требования и системное разбиение

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

147
Ключевые слова для выражения требований в стандартах: "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" в RFC 2119 —
https://www.ietf.org/rfc/rfc2119.txt
 215

Чтобы лучше понять этот пример, нужно «перевести с айтишного» слово business.
Стандарт ISO/IEC 29148:2018 даёт чёткое указание, что слово бизнес (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 user's
environment». Это относится не только к требованиям, но и ко многому другому. Так
бизнес-процесс лучше называть организационным процессом (а то и практикой,
подробней это будет обсуждено в следующих главах) — особенно, если он ничего
общего не имеет с предпринимательством. Всё-таки в русском языке «бизнес» —
это прежде всего предпринимательство, а не «любое дело».
Картинка очень неподробно и схематично показывает системные уровни какой-то
организации, в которой внутри организационного окружения (organization
environment) находится вся работающая организация (business operation), в которой
содержится какая-то часть организации, работающая с системой (system operation),
в которой есть система (system), в которой есть часть системы системы (system
element, неправильно выбранное слово «элемент», указывающее на дальнейшую
неделимость, но нет, там же есть ещё части!), в котором есть программное
обеспечение (software). Каждая система, являющаяся частью своей надсистемы в
этих многих системных уровнях, имеет какие-то описания «чёрного ящика»,
называемые требованиями — и на картинке некоторые из них показаны зелёными
стрелками, указывающими на границы соответствующих вложенных друг в друга
систем. Целевой системой тут является «система» (system), требования к ней так и
называются: системные требования (system requirements). Требования к
надсистеме будут называться требования стейкхолдеров (stakeholder
requirements) или потребности/нужды стейкхолдеров (stakeholder needs). Их
не перепутать: они описывают разные системы на их границах (как «чёрный ящик»,
без подробностей про внутреннее устройство каждой из систем), на картинке это
чётко видно. При перемещении на уровень вверх «потребности» становятся
«требованиями», и появляются новые «потребности» для новой надсистемы. При
перемещении на уровень вниз «требования» становятся «потребностями», и
появляются новые требования для новой «подсистемы». Эти термины
определяются относительно двух смежных системных уровней.
 216

Мы привели эту картинку для того, чтобы показать присутствие в проекте

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

Целеориентированная инженерия требований

Требования не «объективны», а их субъективно задают проектные роли для того,
чтобы достичь каких-то целей, реализовать свои предпочтения. Мы уже упоминали
предложенную в 1986 году Иваром Якобсоном практику выявления требований, при
которой рассматриваются сценарии использования (use cases)148. Сценарий
использования определяет взаимодействие между пытающимися достичь своих
целей активными внешними актёрами (actors) и целевой системой. Актёры в
вариантах использования (в других практиках термин актёр/актор/actor может
означать совсем другое!) — это функциональные объекты, которые необязательно
люди: они могут быть людьми, компанией или просто оргзвеном, компьютерной
программой или даже компьютером. Требования при анализе взаимодействия
внешних актёров и системы легко выявлялись, и подход получил широкое
признание в инженерии требований. Вот типичная диаграмма вариантов
использования149 (мы уже приводили аналогичную диаграмму, рассказывая о
функциональных объектах, упоминали «аристотелевскую физику» этих диаграмм,
но этот пример подчёркивает, что не все акторы/актёры на этих диаграммах —
люди):

В 1995 году появился подход к моделированию требований, называемый i*150, и он

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

148
https://en.wikipedia.org/wiki/Use_case
149
http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html
150
http://www.cs.toronto.edu/km/istar/
 217

описания взаимодействий самих актёров, а весь подход получил название

целеориентированной инженерии требований (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.151151, в котором
для моделирования требований предлагался целеориентированный язык
требований подхода i* (Goal-oriented Requirements Language) и карты вариантов
использования (Use Case Maps).
В простейшем случае вариант целеориентированной системной инженерии
предполагает написание коротких пользовательских историй (user story), в
которых актёр сведён до обычной внешней проектной роли. Пример формата таких
историй152 включает как формулировку требования, так и формулировку
потребности, так и указание того, чья это потребность. Таким образом, каждое
требование трассируется к потребности и указывается, чья (какой проектной роли)

151
https://www.itu.int/rec/T-REC-Z.151/en
152
Mike Cohn, 2008, Advantages of the “As a user, I want” user story template, blog post,
http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-userstory-template
 218

это потребность: «Я как _стейкхолдер/проектная роль_ хочу, чтобы _целевая-система_

_формулировка требования _, для того чтобы _потребности-для-надсистемы_».

Проверка и приёмка
Проверка и приёмка (verification and validation, V&V, верификация и валидация)
служат для того, чтобы убедиться в работоспособности системы. По сути, это просто
тщательное тестирование системы, проведение испытаний, обоснование
успешности системы. Успешность — это соответствие ожиданиям заинтересованных
проектных ролей. Проектных ролей/стейкхолдеров у нас два набора:
• внешние, которых волнует прежде всего работоспособность надсистемы.
Работает ли надсистема с включением в её состав целевой системы как
задумано, удовлетворяет ли требованиям стейкхолдеров/потребностям?
Работают ли часы, в которых внутри работает сделанная нами шестерёнка?
Отстают ли, или спешат? Обращаем внимание, что «отстают или спешат
часы» замеряют на часах, это эмерджентные свойства, у шестерёнки таких
свойств нет.
• и внутренние, которых волнует работоспособность целевой системы —
работает ли целевая система как задумано, удовлетворяет ли системным
требованиям? Мы спроектировали шестерёнку: то ли мы получили, что
описывали? Тот ли у неё диаметр, вес, число зубьев? Про часы тут речь не
идёт.
Почему же используется два слова? Потому что по факту проверяется
работоспособность двух систем, проводятся два набора испытаний: проверочные
(соответствие целевой системы требованиям) и приёмочные (соответствие
надсистемы/использующей системы потребностям).

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

учтено в требованиях, но не поддержано конструкцией системы — и требования

будут удовлетворены, а потребности — нет. Инженеры/команда будут считать, что
они выполнили требования (испытания их системы успешны!), и требовать оплаты
за работу. А внешние проектные роли/стейкхолдеры будут считать, что денег за
работу давать не нужно, ибо для них целевая система оказывается бесполезна —
надсистема-то не работает, или работает не так, как задумано! И внешние
проектные роли всегда найдут способ доказать, что они правы (помним, что люди
удивительно изобретательны, когда они играют свои роли!). Поэтому не только
проверяется целевая система, но и принимается/валидируется работа надсистемы
с учётом работы в её составе целевой системы.
Испытания/тестирование разного сорта могут составлять до 85% от общей
стоимости проекта. Именно потому, что недостаточно проверки/верификации, но
ещё нужна и приёмка/валидация, в испытаниях требуется участие не только
целевой системы, но и значительной части её системного окружения. Поскольку
системное окружение может быть недоступно, или очень дорого, то это требует
часто создания испытательных стендов, более дорогих, чем сама целевая система.
В результате какая-нибудь задвижка для атомной станции или космического
корабля оказывается полностью идентичной задвижке для городского водопровода,
но будет стоить впятеро дороже, потому что её много тщательней испытывали на
специальных стендах.
Проверка и приёмка понимаются только при наличии системного
мышления — это же разговор про системные уровни!

Понятие архитектуры
Архитектура, как и любое другое описание/определение/definition системы, всегда
есть, начиная с того момента, когда вы выделили своим вниманием систему из
окружающего мира. Не всегда есть архитектурная документация. Альфа
архитектуры, как основной объект внимания в проекте создания системы, дана нам
в виде архитектурной документации, и поэтому в речи и текстах часто путаются
понятия «архитектуры», «архитектурного описания», «архитектурной
документации». Обычно понятно из контекста, о чём идёт речь.
Так, «цвет» шкафа тоже есть, но есть и описание цвета — слово «чёрный», код
цвета по одной из цветовых моделей 153 или даже попытка
воспроизвести/документировать этот цвет (на каком-то носителе, вот прямо
как тут). Но если есть шкаф, то и цвет у него есть. И архитектура у шкафа есть. Но
может не быть документирования цвета (нигде не будет написано, какой у шкафа
цвет), и так же может не быть архитектурной документации.
О цветовой или архитектурной документации мы говорим, об их описании или о
самих цвете или архитектуре — это понимаем из контекста, или проговариваем
явно. Если мы говорим «вот тут цвет нужно сделать почернее», то это про цвет, а
если «цвет в кодировке RGB», то про описание цвета, если «запись базы данных с
описанием цвета в кодировке RGB», то про цветовую документацию. С архитектурой
всё то же самое. Место в пространстве смыслов, какое-то понятийное выражение
этого места (описание) и запись на носителе этого описания (документация) — как

153
https://colorscheme.ru/
 220

они все связаны, подробней изложено в книге «Визуальное мышление»154.

ISO 42010 даёт следующее определение архитектуры: «Архитектура (системы) —
основные понятия или свойства системы в её среде, заключающиеся в её элементах,
их отношениях и принципах её проектирования и развития»155. Обратите внимание,
что в этом определении нет никакого упоминания структуры системы — то есть
разбиения системы на части каким-то способом. Ибо для такой системы как
интернет нельзя указать на структуру системы: в интернете никто не знает, что
входит в структуру интернета (является частью интернета) в каждый конкретный
момент, какие есть связи между частями интернета, ведь непрерывно появляются
и исчезают новые узлы интернета, и между ними непрерывно появляются и
исчезают новые каналы связи. Но даже если из определения архитектуры
исключили структуру, определение от этого не стало понятней.
Вот другое определение архитектуры, от части авторов того же ISO 42010, но
данное ими в книге про документирование системных архитектур156: «Архитектура
системы — это набор структур, необходимых для рассуждений о системе, каковые
структуры состоят из элементов, отношений и свойств этих элементов и
отношений»157. Там наоборот, дан акцент на структуры.
Но самых разных определений много больше, и в интернете есть место, где собрано
более 150 таких определений158. Самые разные проектные роли определяют
архитектуру по-разному, с акцентом на те или иные её свойства, те или иные классы
целевых систем.
Мы будем придерживаться неформального простого и понятного определения
архитектуры, которое дал Ralf Johnson: «Архитектура — это обо всём важном.
Что бы это ни было.»159.
Эти слова обычно указывают на важные решения, которые могут быть для
«железных» систем инженерные, для предприятия организационные,
менеджерские или предпринимательские, в случае танцев —
постановочные/хореографические решения, и т.д. Важные решения определяются
как такие, что при принятии альтернативных им решений придётся перепринять
большинство других решений, то есть перепроектировать, и затем переделать всю
систему. Так, если при проектировании самолёта принято решение сделать его с
реактивным двигателем, а не обычным поршневым, то это означает переделку
практически всей конструкции: от устройства топливной системы до формы
крыльев и фюзеляжа. Если в здании принято решение печатать его на бетонном
3D-принтере, а не выкладывать его из бетонных блоков или даже из кирпича, то
смело можно переделывать всю проектную документацию или переделывать весь
дом, если он уже построен.
Если принято решение сделать какой-то винтик не с левой резьбой, а с правой, то

154
https://ridero.ru/books/vizualnoe_myshlenie/
155
Architecture (of a system) — fundamental concepts or properties of a system in its environment embodied in
its elements, relationships, and in the principles of its design and evolution.
156
Paul Clements at al., Documenting Software Architectures: Views and Beyond
157
The architecture of a system is the set of structures needed to reason about the system, which comprise
software elements, relations among them, and properties of both.
158
http://www.sei.cmu.edu/architecture/start/glossary/community.cfm
159
Ralf Johnson: «Architecture is about the important stuff. Whatever that is»,
https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf.
 221

вряд ли это приведёт к переделке всего изделия. Будет переделан лишь этот винтик
и резьба в связанной с ним гайке. Такое решение не архитектурное. Весь
проект/design тем самым делится на две части: архитектура и неархитектурная
часть проекта/design (non-architectural part of design).
Архитектурная документация в простейшем виде представляет собой список
принятых важных инженерных решений. При этом то, что одному архитектору
кажется важным, другому архитектору может казаться неважным — это не
«объективный» список, он существенно зависит от опыта и знаний того, кто этот
список составляет. Важно при этом, что такой список находится не в голове
архитектора (в голове человека, исполняющего проектную роль «архитектор»), а
выписывается отдельно, документируется. Неважно, будет ли это
документирование в форме электронного текста или таблицы, или в виде
бумажного документа, или просто в виде записей фломастером на флип-чарте —
подойдёт любая форма, в которой эти важные решения перечислены, и их можно
обсудить с командой проекта и внешними экспертами.
Более сложные формы архитектурной документации включают в себя
функциональные и модульные диаграммы, трассировку функциональных частей
системы и/или их функций к модулям, размещения и компоновки. То есть
архитектурное описание — это совсем необязательно список принятых решений:
решения вполне могут быть документированы и в других формах. Главное, чтобы
они не оказались устными — тогда трудно добиться, чтобы мышление по поводу
важного в системе было коллективным.
Интересно, что в советской устной архитектурной традиции, когда
архитектурной документации практически не было, всё важное
обозначалось словами «заделы», «опыт», «наработки». Архитектуры
были, но их нельзя было предъявить, обсудить, передать, развить иным
способом, кроме как задействовав ту команду, которая имела тот самый
«опыт» и «заделы» в голове.
Обычно важнейшими архитектурными решениями оказываются решения
модульного синтеза: какие модули-продукты выбираются для выполнения каких
потребных для работы системы функций. Тем самым в архитектуру попадают
решения по верхнеуровневому разбиению на функции и верхнеуровневому
разбиению на модули в их взаимосвязи. Иногда функциональные описания
называют логической архитектурой, а модульные описания и описания
компоновки — физической архитектурой. Есть и возражение к такой
терминологии: архитектура это про всё важное, а если выбирать только
логические и только физические части важного, то это только части архитектуры,
а не отдельные архитектуры. Тем не менее, термины эти можно встретить довольно
часто, равно как часто можно встретить и другой нерекомендованный термин
«нефункциональные требования».
Все эти решения оказываются не только субъективными в части отнесения к
архитектурным (и поэтому нельзя провести чёткую границу между «важным» и
«неважным»), но относительными в части принятия их разными
проектными ролями: что архитектурное для одного, неархитектурное для
другого. Если один конструктор делает самолёт (целевая система), а другой делает
к нему двигатель (подсистема), то для первого выбор типа топливного насоса —
неархитектурное решение, а для второго — важное архитектурное решение.
 222

На рисунке субъективность отнесения к архитектурным решениям показана

насыщенностью цвета, при этом стрелки примерно соответствуют небольшому
числу взаимосвязанных решений, определяющих все остальные решения.
Проектных ролей-архитекторов показано две: один архитектор занимается
архитектурой всей целевой системы, другой архитектурой подсистемы (надсистема
не показана, но она есть!). Где остановиться в принятии архитектурных решений?
Спускаясь по отношениям часть-целое в системном разбиении нужно остановиться
там, где архитектор считает, что там уже нет его важных решений, то есть работа
уже поделена между разработчиками модулей-подсистем, и дальше будут их
важные решения.
Самые важные требования, которые однозначно ведут к архитектурным решениям
(то есть к важным решениям, от которых зависят все остальные решения) часто
называют архитектурными требованиями. Например, для самолёта скорость
является архитектурным требованием. Если самолёт должен обеспечивать скорость
0км/час, то его архитектура должна быть архитектурой вертикального взлёта и
посадки. Если скорость должна быть 2000км/час, то это может быть обеспечено
только для реактивного самолёта.
Итак, архитектура (с точностью до разницы между описанием и документацией)
может пониматься как любой из следующих вариантов:
• самые важные части функционального и конструктивного определений
системы в их взаимосвязи;
• функциональные части + модули/продукты + размещения (только важные,
верхнеуровневые);
• принципиальная схема + заказная спецификация + компоновка (только
важные, верхнеуровневые);
• логическая архитектура + физическая архитектура (при учёте возражения о
недопустимости именования «частичных архитектур» архитектурами), или
оно же как;
• список важнейших принятых конструкторских/проектных/организационных
(в зависимости от типа системы выберите подходящий термин) решений.

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

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

Этот паразитический плоский червь проводит свою жизнь в разных состояниях

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

Жизненный цикл системы 1.0 — работы, меняющие состояния целевой

системы
Поначалу жизненный цикл (life cycle) просто обозначал отрезок времени, во
время которого происходили проводимые обеспечивающими системами работы с
целевой системой, при этом по аналогии с биологическим циклом последовательно
проходящие работы относили к разным стадиям (stages), иногда называемым
фазами (phase) жизненного цикла — отрезками времени, в которых система
была в каком-то состоянии.
Жизненным циклом чайника называли отрезок времени, в течении которых с ним
проводились работы (чайник ведь сам себя не сделает, это не биология — системы
обеспечения должны были провести с ним все работы): решить сделать чайник (а
160
Это знание входит сегодня в формат ЕГЭ: http://distant-lessons.ru/ploskie-chervi.html
 224

не кофейник), запроектировать чайник (выбрать внешний вид и материалы),

сделать (согласно проекту закупить материалы и изготовить), затем использовать
для заварки чая, затем разбить и выкинуть. Вот всё это время прохождения работ
с чайником как целевой системой и называли жизненным циклом, а сами работы в
их самом верхнеуровневом разбиении (принятие решения о чайнике,
проектирование чайника, изготовление чайника, эксплуатация чайника,
ликвидация чайника) называли стадиями/фазами.
Назовём это понимание «жизненным циклом v1.0», оно разрабатывалось где-то в
70-х годах прошлого века, и не только в системной инженерии, но и в менеджменте.
В системном подходе тогда признавали непосредственно выходящим из него не
только системную инженерию, но и operations research/исследование операций161 —
исследование работ/operations с целью принятия лучших решений по ускорению их
прохождения, «управлению потоками работы». Исследование операций скоро
перестало быть «аналитикой», только исследованиями, и в его
синтетической/управленческой ипостаси стало operations management
(операционное управление, акцент не только на понимании и отчётах, но и на
действиях на основе этих исследований — собственно управлении, изменении
ситуации).
Дальше это направление управления работами на базе каких-то представлений
тогдашнего системного подхода развилось в классическое проектное
управление/project management, как его понимают сегодня в менеджменте.
Например, одна из самых популярных книжек по проектному управлению,
вышедшая первым изданием ещё в июне 1979 года, это Harold Kerzner "Project
Management: A Systems Approach to Planning, Scheduling, and Controlling". То есть
управление проектами с самого начала было применением системного подхода к
планированию, построению графика работ и контролю выполнения работ. Это
похоже на то, как понималась и системная инженерия: применение системного
подхода к инженерной работе.
Конечно, использование системного подхода в менеджменте не ограничивается
сегодня только операционным управлением. Инженерия предприятий тоже
относится к менеджменту (но не операционному, а организационному), и она
похожа на традиционную инженерную работу (хотя и с особенностями, в том числе
терминологическими: инженерия требований в ней — это стратегирование,
инженерия системной архитектуры — это инженерия предприятия, управление
конфигурацией — это операционный учёт, основная практика в изготовлении —
лидерство, ибо предприятие невозможно «собрать из частей» так, как это делается
с традиционными инженерными системами типа часов или ракет, и т.д.).
Понятие жизненного цикла 1.0 как времени производства работ с системой активно
разрабатывалось и в инженерии, и в проектном управлении для принятия решений
о планировании и составлении графика работ.
Работы — это конкретные процессы, в которых участвуют ресурсы для этих
работ. Анастасия забивает гвозди молотком в доски. Забивание гвоздей – это и есть
работа, которую она выполняет (работы чаще всего называются не по их цели, а по
их текущему содержанию – не «скрепление досок», что может предполагать и
клеевое соединение, и гвоздевое, а именно «забивание гвоздей», хотя тут есть

161
https://en.wikipedia.org/wiki/Operations_research
 225

множество и других вариантов. Но в целом работы – это сервис, т.е. поведение,

оказываемое вовне системы в обеспечении). Анастасия в роли плотника как
оргзвено, гвозди, молоток и доски – ресурсы, без доступности которых выполнение
работы/сервиса оргзвена Анастасии невозможно.
Для планирования работ обычно составляется план, в котором прописываются
ответственные за выполнение работ (собственники ресурсов — если не
собственники, то выполнение работ будет проблематичным), и время, за которое
эти работы должны быть сделаны (проектное управление имеет дело с
нормированными работами — т.е. работами, для которых накоплено достаточно
статистики, чтобы понимать их время выполнения при наличных ресурсах.
Например, это строительные работы и нормы выкладки кирпича, заливки бетона и
т.д.). То есть работы — это экземпляры выполнения сервисов оргзвеньев.
За забивку гвоздей у нас ответственна Анастасия в должности «плотник», и обычно
она забивает 180 гвоздей за час. Обсуждаемая работа начинается в полдень 3
мартобря 2029 года, и планируемая её продолжительность — десять минут. За это
время Анастасия как оргзвено «плотник» должна забить 20 гвоздей в четыре места
на досках.
Работы легко наблюдать: это просто взаимодействующие между собой ресурсы
(включаемые в работу по отношению участия/participation, это такая специализация
отношения composition/состава/is_part_of/часть-целое), но взятые не только как
объёмы в пространстве, но и протяжённые во времени. Так, работа «забивка
гвоздя» состоит из молотка, гвоздя, доски и забивающего их работника. Их нужно
собрать вместе, чтобы работа произошла.
Обсуждение работ обычно затрагивает логистический интерес, то есть интерес ко
времени прохождения потока ресурсов, интересует тут не столько содержание
работы в ходе работы, а как собрать для этой работы ресурсы, то есть время
организации ресурсов на работы, и время самой работы без погружения в её
содержание. Жизненный цикл 1.0 как последовательность крупных работ-стадий
тем самым отражает модульное/конструктивное/продуктное представление о
системах обеспечения. Чтобы собрать какую-то нужную нам (целевую, мыслимую в
её момент эксплуатации) конструкцию из досок, нам нужны в обеспечении (т.е. в
момент изготовления целевой конструкции) модули Анастасия-с-ответственностью
(то есть оргзвено) и молоток. А ещё нужно предусмотреть 20 гвоздей, четыре доски
и 20 минут времени, иначе работы не случится. Нам нужно всё это откуда-то взять,
а результат работы (скреплённые доски) куда-то отдать – задача не инженерная, а
менеджерская (операционного менеджера). Интересует только логистика, «как
собрать работу из её частей-вещей/ресурсов». Не интересует «как работает
работа», как вообще нужно забивать гвозди, и почему нужно скреплять доски
гвоздями, а не склеивать их, или вообще приматывать их друг ко другу верёвками,
и не интересует, как сделать гвоздевое соединение прочным. А раз так, то по
работам бесполезно обсуждать, как же именно эти работы в их
взаимодействии будут двигать систему по её состояниям в жизненном
цикле. Обсуждение работ не связано с функциональностью/ролями этих
работ, оно связано с планированием ресурсов и контролем выполнения
плана.
Обратите внимание, что по факту жизненный цикл ничего не говорит о целевой
системе и её состояниях! Он говорит про то, что делают системы обеспечения:
 226

работают-то они! Это только в биологическом жизненном цикле любое яйцо или
гусеница обеспечивают сами себя! Помним, что «обеспечение» в системном
мышлении означает не системы, которые делают снабжение/заправку/подкормку в
ходе эксплуатации (это обычно делает окружение, системы времени эксплуатации),
а системы, которые во время создания и ликвидации системы двигают её по
жизненному циклу. Вот взгляд на эти системы как на «традиционные вещи»,
функциональные объекты, связанные отношениями
организации/полномочий/обязанностей по распоряжению ресурсов — это системы
обеспечения, чаще всего организации/оргзвенья (хотя в общем случае системой в
обеспечении может быть и отдельный станок, оргзвеном никак не являющийся). Но
экземпляры реализации/разворачивания во времени сервисов/полезного
поведения оргзвеньев — это и есть работы!
Итак, Анастасия забивает гвоздь. Жизненный цикл гвоздя в представлении 1.0
состоит не из состояний гвоздя, а происходящих с ним работ, которые, конечно,
можно описывать и как конечные состояния гвоздя, но всё-таки это работы систем
обеспечения, сам гвоздь при этом ничего не делает, он пассивен. В не жизненном
и не цикле принят аналог «аристотелевской физики», где палец давит на стол, а
стол не давит на палец. Работают системы обеспечения, а гвоздь в ответ не
работает, он пассивный объект для систем обеспечения, он просто меняет
состояния по мере выполнения с ним работ:
• Обнаружение потребности в гвоздевом соединении (гвоздь запланирован —
но так пишут реже, ведь это указание на работу, а не на гвоздь! Состояние
«гвоздь запланирован» тут указывает на результат выполнения сервиса по
закупке гвоздя! Так писать правильней, потому как легче проконтролировать
результат работы, но так при документировании жизненного цикла пишут
редко. Но именно такие эквиваленты принято писать в наименованиях работ
в методологии управления проектами PRINCE2162, это хорошая практика!)
• Закупка гвоздя (или гвоздь закуплен — помним, что в жизненном цикле 1.0
волнуют работы, а не состояния гвоздя! Состояния гвоздя волнует тогда,
когда обсуждаем целевую систему и прохождение ей различных состояний в
ходе жизненного цикла — то есть прохождение различных состояний в ходе
работ с целевой системой. Состояние «гвоздь закуплен» тут указывает на
результат выполнения сервиса по закупке гвоздя!)
• Выдача гвоздя монтаж (или гвоздь доступен в месте забивки — указание на
работу по выдаче в монтаж. Дальше мы просто не будем писать эти
разъяснения, идея тут понятна)
• Нацеливание гвоздя (гвоздь нацелен)
• Вколачивание гвоздя (гвоздь вбит)
• Проверка крепости соединения (гвоздь держит крепко)
• Эксплуатация соединения (объект поменялся! Теперь это соединение!
Куколка стала бабочкой! Другой объект!)
• Вытаскивание гвоздя (гвоздь вытащен)
• Ликвидация гвоздя (гвоздь выкинут — жизненный цикл всегда идёт до
исчезновения объекта работ).

162
https://www.prince2.com – в этой методологии управления проектами сертифицировано более 1млн.
человек.
 227

Выполнение работ оргзвеньями

Обеспечение жизненного цикла (принудительное изменение снаружи целевой
системы её состояний в ходе её замысливания, создания, эксплуатации,
ликвидации, т.е. «жизни») делается оргзвеньями — людьми и оборудованием. Чаще
всего оргзвенья сами не инициируют работы. В коллективной деятельности одни
оргзвенья имеют полномочия просить сделать работу у других оргзвеньев, у
которых есть обязанности такие просьбы выполнять. Если вы попросите в пиццерии
пиццу, то вам выполнят работы по её приготовлению – и это само по себе факт
замечательный. Попробуйте попросить в пиццерии приготовить вам летние
босоножки, и посмотрите, что получится. Это и есть действительность
организации: кто кого (оргзвенья) о чём (работы) имеет право попросить так, что
просьбы вызывают их выполнение, а не вопросы и сопротивление.
Речь тут продолжает идти не о том, как и почему выполняются работы с
содержательной точки зрения (то есть функциях/ролях систем обеспечения как
функциональных частях), а о логистике работ: как сделать так, чтобы кто-то эту
работу выполнил (сервисах систем обеспечения как конструктивных
частях/модулях). Системное мышление позволяет рассуждать про системы
обеспечения и системы окружения для целевой системы с использованием одних и
тех же понятий. Понятия для всех видов систем одни и те же, в этой компактности
сила системного мышления.
Каждая работа проходит следующий цикл взаимодействия оргзвеньев (это
подробно обсуждается в подходе к архитектурному описанию предприятий
DEMO163):
• Работа затребована оргзвеном-инициатором, часто в виде её появления в
каком-то плане (с заданной последовательностью выполнения работ, а если
план-график, то и указанными сроками выполнения) или бэклоге (backlog,
набору работ к выполнению — но без указания строгой последовательности
их выполнения, в том числе сроков): координационный акт, речь идёт об
информационном мире поручений-согласований-обещаний оргзвеньев, но не
о реальной физической работе по изменению мира или даже работе по
изменению описаний системы.
• Работа принята оргзвеном-исполнителем к исполнению, это тоже
координационный акт.
• Работа выполняется оргзвеном-исполнителем. Это производственный акт
(production act), реальное выполнение работ. Именно это учитывается в
жизненном цикле целевой системы, над которой выполняется работа. В
жизненном цикле обсуждаются только производственные акты, а не
координационные акты!
• Работа предъявлена к приёмке оргзвеном-исполнителем, это
координационный акт.
• Работа принята оргзвеном-инициатором работы, координационный акт.
Деление на координационные и производственные акты важно, чтобы делать
правильные оценки времени: от момента затребования работы до момента
принятия работы на координационные акты может уходить до 40%
времени, и только 60% времени на проведение самой работы. Поэтому

163
http://ailev.livejournal.com/644440.html
 228

жизненный цикл гвоздя может занимать в разы больше времени, чем время
выполнения самих работ как производственных актов.
Как планировать работы — по полному времени координации+производства работ,
или только по актуальному времени потребления ресурсов? Разные школы
управления работами отвечают на этот вопрос по-разному. Управление
работами как раз занимается планированием работ как единиц поведения
модулей/продуктов/оргзвеньев/конструктивных единиц — без обсуждения того, как
правильно выполнять работы так, чтобы они меняли целевую систему в нужном
направлении. В интересах управления работой нет функциональности
происходящих с системой действий жизненного цикла, то есть в управлении
работой не рассматриваются функции систем в обеспечении, системы в
обеспечении не рассматриваются как оргроли/функциональные части, но только
как конструктивные части-ресурсы, которые не важно что делают, но важен факт
их наличия или отсутствия. Забегая вперёд: оргроли выполняют практики
(функциональное/ролевое/инженерное рассмотрение), а оргзвенья
выполняют работы/сервисы
(конструктивное/организационное/менеджерское рассмотрение).
С момента начала использования понятия «жизненный цикл» в
инженерных/менеджерских проектах в этот «жизненный цикл» первой версии стали
включать и время работ, которые происходили в начальный (до изготовления
частей будущей системы) период времени, т.е. время работ по описанию будущей
целевой системы и документированию этих описаний, то есть работы не с самим
воплощением системы, не работы по изготовлению-сборке. С этого момента
жизненный цикл вообще перестал при этом ассоциироваться с изменением
состояний воплощения системы (на чём был сосредоточен жизненный цикл
биологических живых систем), а значение термина перешло полностью на работы
систем обеспечения. Жизненный цикл перестал быть жизненным, перестал быть
циклом и перестал быть жизненным циклом самой системы — он просто через
именование целевой системы стал указывать на работы как сервисы систем
обеспечения. Жизненный цикл гвоздя – это работы завода, выпускающего гвозди,
сети торгующих гвоздями дистрибуторов, плотника.
Вскоре повсеместно жизненным циклом стали называть уже не сам
отрезок времени жизни целевой системы, а работы/сервисы систем в
обеспечении. Эти сервисы упоминались на всём времени существования системы:
от появления первых описаний до ликвидации использованного и уже не нужного
никому воплощения. Обеспечение оказалось обеспечением жизненного цикла как
работ, необходимых для изменений состояний целевой системы в ходе её «жизни
как изменений внешними силами».
Сама целевая система при этом просто была маркером, который позволял отметить
все относящиеся к системе (как к воплощению системы, так и к определению
системы) работы, кто бы их ни производил в самых разных предприятиях, которые
занимались системой на всём протяжении жизненного цикла.
Когда говорили «жизненный цикл АЭС», то имели ввиду разбитые на
стадии/крупные работы все работы с АЭС, которые выполняли своими сервисами
многочисленные предприятия/оргзвенья от момента замысла АЭС до момента
вывода её из эксплуатации с получением после этого зелёной площадки. Когда
говорили «жизненный цикл танца», то имели ввиду работы по замыслу танца, его
 229

постановке, последующих перформансах — кто бы этими сервисами ни занимался

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

Изображение жизненного цикла как работ (ЖЦ 1.0)

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

Нижняя строчка там представляет собой один из вариантов

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

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

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

Жизненный цикл проекта

Но поскольку уже было понятно, что речь идёт о работах, а естественной
максимальной (соразмерной стадиям ЖЦ) единицей работ в проектном управлении
стал «проект» (project, а не design), то появился ещё один термин: жизненный
цикл проекта (project life cycle) — он означал те работы жизненного цикла
системы, которые попадали в конкретный проект. Проекты эти обычно совпадали с
работами, проводимыми для каких-то полных стадий жизненного цикла, одной или
нескольких. Это было естественным делением жизненного цикла, потому что
разные проекты часто выполнялись разными организациями — и нужно было как-
то выделять части жизненного цикла, за которые несла ответственность
проводящая проект организация/оргзвено.
По факту системное мышление и проектное управление вот так и были связаны:
жизненным циклом называли происходящие по поводу целевой системы работы,
которые являлись предметом проектного управления в разнообразных проектах по
поводу целевой системы. В этот момент в самом системном мышлении не очень
было принято думать о системах обеспечения (в биологии этого не было, а в
технических проектах инженеры редко думали об обеспечении), поэтому проектное
управление довольно много сделало для того, чтобы в системном мышлении
появились мысли не только об окружении, но и об обеспечении. По большому счёту
и проектные роли/стейкхолдеры пришли в системное мышление в существенной
мере по линии проектного управления: они же часто входят в состав различных
систем обеспечения как их функциональные части! Если я делаю шестерёнку для
часов, то проектная роль архитектора часов, который и придумал часы с
шестерёнкой, сформулировал в ней потребность, задал к ней требования и будет
принимать от меня результат — воплощение шестерёнки, она и есть внешняя
проектная роль для моего проекта шестерёнки! А для него, скорее всего, будет
стадия жизненного цикла часов «создание деталей часов», где будет и моя работа
по созданию шестерёнки. Мышление об обеспечении происходит существенно с
использованием понятий проектных ролей, жизненного цикла (системы, если не
указано иного), жизненного цикла проекта. Хотя и не только этих понятий (ведь
кроме жизненного цикла 1.0 будет и жизненный цикл 2.0).
 232

Часто жизненный цикл системы в представлениях 1.0 (т.е. в представлениях

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

Поскольку проект имеет конкретные даты начала и конца, конкретные ресурсы, то

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

работами/сервисами состояние целевой системы от момента её замысливания до

момента её вывода из эксплуатации). И эти системы обеспечения/жизненного цикла
не являются системами из окружения, которое мы обычно рассматриваем только на
стадии эксплуатации целевой системы (когда не столько над целевой системой
работают, а сама целевая система работает). Эти организационные системы из
совсем других системных разбиений, из разбиений обеспечения. Целевая система в
её ближнем (подсистемы надсистемы) и дальнем окружении это одно разбиение
(иерархия по отношениями часть-целое), а вот системы обеспечения — из других
разбиений, они части совсем других систем, и это обычно системы систем, что
делает их во много раз трудней в рассмотрении. Между целевой системой и
системами обеспечения/обеспечения жизненного цикла целевой
системы/обеспечения проведения работ с целевой системой отношение не часть-
целое, а обеспечения! Садовник обеспечивает цветок (обеспечивает
сервисы/работы, которые обеспечат замысел вырастить цветок в конкретном месте,
посадку семечка, полив семечка, а потом и растения. удаление сорняков из
окружения растения, удобрение почвы для благоприятного окружения цветка, а
после цветения обеспечит вывод из эксплуатации отцвётшего цветка — выкинет
его. Цветок ничего не делает сам, всё делает его обеспечение в лице оргзвена-
садовника!).
Жизненный цикл в начальном (1.0) понимании — это по-крупному
нарезанные все возможные работы систем обеспечения с целевой
системой. При этом жизненный цикл можно понимать как надсистему для
всех систем обеспечения — каждая из систем обеспечения входит в
жизненный цикл как систему систем обеспечения/систему всех систем
обеспечения.

Проблемы с жизненным циклом 1.0

Но не успело новое понятие жизненного цикла как поделённых на стадии работ
обеспечения прижиться, как начались проблемы.
Первая проблема понимания жизненного цикла как последовательности крупных
работ проекта: в реальных проектах по созданию систем массово начала
вырождаться стадийность. Сначала в agile164 (гибких) подходах к разработке софта
появились не тематические по видам работ «стадии», а безымянные «итерации»
какой-то фиксированной длины — и на этих итерациях было очень трудно
отследить, какая же там преимущественная тематика работ. Затем в строительных
проектах появилась параллельная инженерия (concurrent engineering), в
которой намеренно в параллель/одновременно выполнялись работы, ранее
считавшиеся строго разнесёнными по разным последовательным «тематическим»
стадиям жизненного цикла: одновременно и велось проектирование, и
изготовление системы, а какие-то неполные версии системы ещё и начинали
эксплуатировать (например, крыло недостроенного здания).
Быстро улетучилась идея, что работы на стадиях жизненного цикла ведутся с каким-
то определённым состоянием целевой системы. Система разными своими частями
находилась в разных состояниях, и все виды работ велись одновременно над
разными частями системы: если корабль красили, то не как раньше — сначала
зачищали поверхность, потом грунтовали, потом красили, но сначала зачищали

164
https://ru.wikipedia.org/wiki/Гибкая_методология_разработки
 234

кусочек, потом его грунтовали, но начинали зачищать следующий кусочек, потом

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

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

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

165
https://www.isene.se/pppp/
 235

выполнить работы, и нужно было менять сам набор работ, а не оптимизировать

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

Практики
Модульное/продуктное/конструктивное представление работ жизненного цикла
«как в управлении проектами» для инженеров оказывалось недостаточным, как это
обычно и бывает в системном подходе. Для проектирования, «изготовления»,
«наладки» работ (то есть проектирования, изготовления, наладки систем в
обеспечении, выполняющих соответствующие сервисы/работы) нужно было
выходить на функциональное/ролевое представление, обсуждать виды работ с
точки зрения их ролевого назначения. Работы тем самым играют роли каких-то
других функциональных/ролевых объектов, удобных для обсуждения «как работает
обеспечение, чтобы целевая система меняла своё состояние и становилась
успешной». Что делает Вася Пупкин, не понимая его текущей роли — всегда
непонятно (он играет роль Отелло? Принца Гамлета? Офелии?). Что делает та или
иная работа, не понимая её текущей роли — всегда непонятно. Нужно отдельно
обсуждать роли/назначения работ!
Рассмотрение поведения систем обеспечения как функций в жизненном цикле
произошло не сразу: ресурсы в обеспечении ведь были конструктивными
объектами, и как системы с их ведущим пониманием как именно функциональных
объектов не воспринимались! Систем обеспечения не было как систем, не было
системного рассмотрения!
Переход к диаграммам типа принципиальных/функциональных схем произошло не
сразу, поначалу появилось множество гибридных диаграмм, пытавшихся отразить
сразу и конструктивную/логистическую и функциональную/назначения ипостаси
жизненного цикла как поведения систем обеспечения. И это не случайно:
ключевые/архитектурные решения по устройству жизненного цикла — это решения
о том, какими работами будут выполнены те или иные практики/виды
работы/деятельности. Это принятие архитектурных решений будет называться
управлением жизненным циклом.
Одной из самых известных гибридных диаграмм жизненного цикла является
горбатая диаграмма (hump diagram) из методологии rational unified process
(RUP)166:

166
https://en.wikipedia.org/wiki/Rational_Unified_Process
 236

В этой диаграмме 1996 года уже видно, что кроме безымянных «итераций» как
групп работ, по-старинке разбитых на «стадии» во времени, появилась новая
сущность, практика (practice, деятельность, род/вид работы, труд), именованная
по её теоретической инженерной или менеджерской дисциплине (discipline,
теория). «Практика» и есть появление функционального/ролевого аспекта в
поведении систем обеспечения. Работы выполняют роль тех или иных практик, из
которых и состоит жизненный цикл.
Работы разных практик (в RUP это практики организационного
моделирования/business modeling — помним про перевод business как
«организационный», инженерии требований, анализа и проектирования,
разработки, испытаний, разворачивания, управления конфигурацией и
изменениями, управления проектом, работы с окружением) как-то распределены по
времени жизненного цикла в его начальном (1.0) представлении как
«последовательности работ». Эти работы делятся на стадии, а потом на более и
более мелкие работы в классическом разбиении работ (work breakdown structure,
WBS) из проектного управления, в то же время практики (показанные на диаграмме
как дисциплины) отражают разделение труда (division of labor). Разделение работ
обсуждает, как много работы разбить по ресурсам (например, если нужно
выполнить однородную работу вдвое быстрее, то нужно поставить вдвое больше
людей, или использовать станок с большей производительностью), а вот
разделение труда обсуждает как ранее однородную практику разбить на
подпрактики, требующие разных квалификаций. Врач раньше занимался всеми
дисциплинами, а потом прошло глубокое разделение врачебного труда, и врач-
гинеколог начинает существенно отличаться по своей квалификации от врача-
дантиста. Работы — это про количество работы и её скорость, а
труд/деятельность/практика — это про разнообразие видов/родов/сортов работы и
их уместность/правильность/роль в проекте.
На горбатой диаграмме в строчке каждой практики показано, что интенсивность
этих работ разная в разные моменты жизненного цикла: компетентные трудовые
(функциональные!) ресурсы то больше, то меньше задействованы для выполнения
работ жизненного цикла в разные его моменты. Тем самым на графике зависимости
интенсивности работ от времени появляются «горбы», отсюда и название «горбатая
диаграмма». Напомним, что работы — это взаимодействующие
продукты/люди/оборудование/ресурсы, участвующие в выполнении
 237

сервиса/поведения оргзвена из жизненного цикла.

В 21 веке описания жизненного цикла перестали обсуждаться как исключительно
описания поделенных на стадии работ и стали обсуждаться как архитектурное
описание поведения систем обеспечения: на основные (не все! Это архитектура!)
практики (функциональные/ролевые части обеспечения, определявшие, что нужно
делать, чем заниматься, чтобы обеспечение выполнило своё назначение по
прохождению целевой системой своих состояний в ходе её замысливания-создания-
эксплуатации-ликвидации), назначаются производимые компетентными ресурсами
работы, разворачиваемые во времени (модульные/конструктивные объекты,
указывающие на единицы использования ресурсов и места во времени, когда эти
ресурсы задействованы). Архитектура для обеспечения — это
функциональная/деятельностная/ролевая декомпозиция практик жизненного цикла
+ конструктивный/продуктный/модульный синтез работ жизненного цикла. Нужны
и практики, и работы. Жизненный цикл — это системы обеспечения,
рассматриваемые в их единстве поведения как практик (функций в
жизненном цикле как обеспечении в целом) и поведения как работ
(сервисов, поставляемых отдельными системами в обеспечении).
Осталось разобраться, как называются системы обеспечения в их функциональной
ипостаси. Они так и называются «организационные роли», ибо нет у них своих
называний! Парикмахерская выполняет сервис/внешнее поведение как оргзвено
(например, предприятие, или подразделение), а практику выполнения причёсок как
…парикмахерская! Оргроль парикмахерской — «парикмахерская», «делатель
причёсок»! Увы, оргроли в бытовом языке не имеют своих специальных слов для
названия. А проектные роли? Это они и есть. В проектной роли может быть не
только человек (самое маленькое оргзвено), но и любое другое оргзвено. Главное
тут не впадать в свехобобщение, оргроль «клиника» или ещё более обобщённое
«лечебное заведение» не даёт возможности что-то содержательно обсуждать:
лечебное заведение выполняет слишком много практик/деятельностей для целевых
систем с самых разных системных уровней, и лучше бы такие «сверхроли» дробить
до ролей с более-менее понятными компетенциями, которые мог бы выполнять
отдельный человек как оргзвено. Проектные роли не «клиника», а «врач» и «техник
медицинской аппаратуры», а ещё лучше не «врач», а «гинеколог» и «дантист».
Принцип почтальона: адрес предмета обсуждения лучше бы давать точно, без «на
деревню дедушке Константину Макарычу». А оргзвено? Для каждой более мелкой
роли будет более мелкое оргзвено. Для клиники — предприятие; для врача — не
слишком понятно, что (и это должно напрягать: модульный синтез будет трудным);
для гинеколога — человек, обладающий компетенциями/знающий
дисциплину/практикующий гинекологию и занимающий позицию в штатном
расписании и распоряжающийся в силу этого необходимыми для его работы
инструментами/оборудованием: оргзвено размером с одного человека.
А ещё помним про слово оргвозможности/capability для указание ресурсной
обеспеченности какой-то практики (то, что на выполнение практики-поведения
назначено какое-то компетентное оргзвено, и ему выданы все полномочия по
распоряжению своими ресурсами для выполнения этой практики. Компетентное —
это которое знает, как выполнять практику, включая компетенции отдельных людей
и компетенции по объединению труда/деятельности этих людей, а ресурсы
включают необходимое оборудование и материалы).
 238

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

Недостаточность и ограниченность описания жизненного цикла/поведения систем
обеспечения через метод описания (viewpoint) последовательностей крупных работ
как стадий жизненного цикла с каждым годом становилась очевидней. Во всё
большем и большем числе проектов (начиная с айтишных проектов) признавали,
что никакого предварительного планирования отдельных работ достичь нельзя,
разработка велась, как судебные дела, «непрерывно открывающимися
обстоятельствами». Наборы различных архитектурных решений по поводу
планирования работ для выполнения различных практик жизненного цикла
получили название модели цикла (life cycle model167, вид жизненного цикла).
Эти наборы решений по связи практик и работ грубо можно отнести к двум разным
полюсам: в одном укрупнённые практики и работы-стадии совпадают и для их
выражения хватает «колбаски» с интерфейсами между работами (обсуждается
«видимость работ», как обычно в модульных диаграммах — нельзя из работ одной
стадии затребовать ресурсы соседней стадии), а в другом не совпадают и для их
выражения нужны какие-то сложные структуры с акцентом на связь практик, т.е.
даже внешне похожие на принципиальные схемы с их «логическим временем» и
«потоками», а не модульные диаграммы с их «видимостью интерфейсов».
Первый вид жизненного цикла (квинтэссенция подхода 1.0, «проектное управление
с непересекающимися стадиями») получил название «водопад» (cascade, каскад).
Как и в водопаде, работы какой-то практики выполняются, созданные рабочие
продукты/артефакты как output передаются как input-ресурсы для следующих
работ, и больше к этим практикам никакого возврата нет, выполняются работы
последующих практик. Водопад/каскад течёт всегда сверху вниз. Для более
убедительной иллюстрации этого «невозвратного» хода работ традиционную
«колбаску» начали рисовать как ступеньки настоящего водопада 168:

Между стадиями осуществлялась тщательная проверка и приёмка (verification and

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

167 слово «модель» тут используется в смысле обозначения группы похожих жизненных циклов,
«модельного ряда», а не в смысле «упрощённого объекта, сохраняющего лишь важнейшие свойства
моделируемого объекта», поэтому при переводе мы иногда будем использовать и термин «вид жизненного
цикла».
168
http://www.managersystem.ru/geds-459-1.html
 239

Но данная модель жизненного цикла оказалась для проектов с существенной доли

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

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

обсуждать многократное возвращение работ по каким-то практикам.
Была предпринята радикальная попытка заменить модель жизненного цикла с
приматом метода описания работ-стадий на прямо противоположную,
функциональную, с приматом метода описания практик. Работы в этой модели
учитывались как развёртка применения тех или иных практик работы во времени,
а сама линия времени как символ выделения ресурсов для показанных практик была
нарисована по спирали. Этот вид жизненного цикла был предложен Barry Boehm в
1978 году, успешно реализован им 1981 и опубликован 1988 году — задолго до
появления «горбатой диаграммы» в RUP (напомним, она появилась в 1996 году).
Этот жизненный цикл получил название спирального169:

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

169
http://www.sei.cmu.edu/reports/00sr008.pdf
 241

(эксплуатация и вывод из эксплуатации опускался). Эти все недостатки не

помешали спиральной модели считаться основой неутопических вариантов
жизненного цикла.
«Горбатая диаграмма» 1996 года как раз представляет собой гибридный вариант
спиральной модели (выделены отдельно практики, введены «итерации» как
повторения практик) и водопадной модели (введена линейная ось времени,
последовательные стадии жизненного цикла, хотя и признаётся, что на каждой
стадии жизненного цикла будут работы всех практик, определяемых их
дисциплинами).
Современный вариант спиральной модели жизненного цикла носит название
«модель пошагового спирального выделения ресурсов» (Incremental Commitment
Spiral Model, разрабатывалась Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong,
Richard Turner в 2006-2014 годах как продолжение работ по развитию идей
спирального вида жизненного цикла) и используется в военных инженерных
проектах США170.
Вот современный вариант, в котором укрупнённые практики обобщённого
жизненного цикла раскладываются по линии времени (и обратите внимание, что
тут тоже по факту «жизненный цикл проекта» (не полный жизненный цикл
системы!), так как не входит замысел, эксплуатация и вывод из эксплуатации):

Тем самым произошёл переход от

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

170
https://www.amazon.com/dp/0321808223/
 242

Жизненный цикл сегодня отвечает на вопросы инженера предприятия

(enterprise engineer, инженер, который организует предприятие как систему
обеспечения, а не создаёт целевую систему): и вопрос «как будем практиковать,
чтобы целевая система была успешной», и вопрос «из какой структуры
ответственности/орзвеньев будем делать предприятие, чтобы оно было успешным».
Модель жизненного цикла документирует архитектурные решения о назначении
оргзвеньев с их сервисами/работами на оргроли с их функциями/практиками.
Поэтому время в диаграммах жизненного цикла прежде всего «логическое»
(функциональное), и только во вторую очередь «физическое» (конструктивное, для
выстраивания последовательности работ) — и то, «физическое» время сегодня
отображается не на всех диаграммах. Часто диаграммы жизненного цикла только
функциональные, а конструктивные диаграммы не называют диаграммами
жизненного цикла, а называют диаграммами проектного управления (например,
диаграммы Гантта171).

Эксплуатация как выделенная стадия жизненного цикла

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

171
https://ru.wikipedia.org/wiki/Диаграмма_Гантта
 243

Сам человек тут показан как система, которую делают (а не которая сама растёт-
развивается). В отличие от биологических жизненных циклов тут показан не
жизненный, и не цикл — ибо не рассматривается цикл именно биологической жизни
человека.
Человека рожают (показана семья в обеспечении практик рождения), учат
(школа/учительница как система в обеспечении обучения), и в этот момент, когда
он ещё не вырос, и недоучен, он не является полностью дееспособным. Затем он
эксплуатирует (сам себя! У него самопринадлежность — системы в обеспечении не
показаны, а вместо них мы находим множество систем в его операционном
окружении). В это же время нарастающее время уходит на практики ремонтов
(врачи в обеспечении) и «модернизации» (учёба, физподготовка), но чаще всего на
диаграммах жизненного цикла это не отражается. А затем доктора его главным
образом лечат (эксплуатация закончена, человек больше не работает — выведен
из эксплуатации), а потом микробы прекращают существование тела (практика
ликвидации. Альтернативная реализация практики ликвидации в данном случае —
кремирование, там без микробов).
Где же тут жизненный цикл человека? Жизненный цикл тут — это выполняемые
практики всех систем обеспечения, воплощённые в работах по поводу
«замысливания», «проектирования», «производства» и «вывода из эксплуатации»
человека, плюс практики работы операционного окружения с целевой системой,
воплощённые в соответствующих работах в ходе её эксплуатации (практики
контрактации, лидерства, оплаты труда и т.д.).
Пример с человеком очень провокационен, ибо человек самопринадлежен, слово
«эксплуатация» (в любых вариантах: использование) крайне эмоционально
окрашено, по отношению к человеку плохо говорить о его «проектировании» и
 244

«производстве» в любом смысле этих слов. Но этот пример крайне полезен, чтобы
понять принцип: одно и то же системное мышление с обязательным учётом границ
его применимости можно использовать для снижения сложности разбирательства с
самыми разными системами в самом разном окружении и самыми разными
системами в обеспечении.
Есть два разных понимания эксплуатации в части представления ремонтов
(обслуживания, maintainance — конструкция и функциональность остаются
прежними) и модернизации (modernization, частичное изменение
функциональности и конструкции):
• Эксплуатация как стадия включает в себя все эти работы. Главные проектные
роли — операторы и различные виды пользователей. Ремонтники и
инженеры по модернизации отдельно не учитываются.
• Техобслуживание и ремонты, равно как и модернизация считаются
отдельными стадиями жизненного цикла, при этом модернизация разделяет
несколько разных (первую, вторую и т.д.) стадий эксплуатации, а
техобслуживание и ремонты считается стадией, которая протекает в одно и
то же время («перекрытие стадий жизненного цикла) с эксплуатацией,
понимаемой как «рабочее функционирование» (operations). То есть
техобслуживание и ремонты не считаются «короткими стадиями», а
считаются длинной стадией, которая длится всё то же самое время, которое
длится сама стадия эксплуатации — и это неважно, что сами работы по
обслуживанию и ремонтам составляют не слишком большое время от этой
стадии. Важно, что разделяются работы разных людей, эти работы (времени,
когда система работает, и времени, когда система не работает) в
обсуждениях не смешиваются друг с другом.
Это лишний раз подчёркивает условность отнесения работ к разным стадиям и
необходимость упора на обсуждение практик.

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

172
http://forum.rmnt.ru/threads/koloda-dlja-kolki-drov-nou-xau.102202/
 245

системы как работы проекта обеспечения показываются стрелкой-скобочкой на

линии времени жизненного цикла очередной системы в цепочке обеспечения:

На таких диаграммах удобно рассказывать истории типа «мы организуем стартап,

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

Три времени жизненного цикла

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

1. Время эксплуатации, оно в момент разработки обычно находится в будущем, и

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

3. Методологическое время, в котором мы прямо вот сейчас думаем о всех этих

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

Понятие практики
Как и для любых других определений системы, ключевым для определения систем
в обеспечении является их функциональное/ролевое определение, отвечающее на
вопрос «как работает?». Функциями систем обеспечения как поведения являются
практики (practices). Системы обеспечения — это системы человеческой
практики/деятельности.
Сегодня часто кроме слова «практика» говорят и «процесс» (process) — за
последние пять лет слово «процесс» перестало всегда означать развёртку в
физическом времени/конструкцию работ и приобрело оттенок указания на
функциональный аспект работ, развёртку в логическом времени. Словом «процесс»
пользуются отнюдь не только в операционном управлении, например в процессном
управлении.
Очень часто про практику говорят «деятельность» (activity или action), когда речь
идёт о выполнении работ какой-то практики предметными ролями, исполнители
которых обладают какими-то предметными (domain) компетенциями в сфере
человеческой деятельности (инженерия, менеджмент, предпринимательство,
здравоохранение, правоохрана и т.д). По этой терминологической традиции
инженерные практики называют «инженерной деятельностью», практику
 247

управления конфигурацией называют «деятельностью по управлению

конфигурацией». Неправильно говорить, что это «профессии», потому как часто
речь идёт о возможности/умении/компетенции что-то сделать в условиях
реальных проектов, а не именно «работе по профессии». Например, практики
подготовки презентаций — презентации готовят очень многие люди, компетенции
по подготовке презентаций есть у всех них, но отнюдь не все они готовы считать
себя «профессиональными презентаторами». Вообще, мы избегаем говорить о
«профессии» как пожизненном занятии в какой-то сфере человеческой
деятельности, оно сегодня отмирает173, человек просто овладевает множеством
разных компетенций. Компетенции дают возможность практиковать какую-то
деятельность, то есть при наличии ресурсов выполнять работы этих практик.
Практика как альфа (внимание на поведение) имеет две важных подальфы:
дисциплины/теории и поддерживающей эту дисциплину
технологии/инструментов/рабочих продуктов/артефактов/средств производства.
Помним при этом, что практика (поведение) не состоит из дисциплины и
технологии, там другая связь: продвижение дисциплины по состояниям её
освоения/компетенции в этой дисциплине продвигает практику как
соответствующее поведение. Продвижение технологии по линии её готовности к
использованию продвигает возможность практиковать что-то с использованием
этой технологии, тоже продвигает практику. Это отношение не часть-целое для
поведения, а отношение альфы-подальф.
Дисциплина имеется ввиду — «научная дисциплина», или «учебная дисциплина»,
то есть некоторая теория (фундаментальная или прикладная, это неважно), которая
определяет основные объекты внимания/альфы/функциональные объекты,
необходимые для деятельностного мышления о предметной области (domain).
Дисциплине обучается актёр-исполнитель-роли, который потом будет играть
проектную роль, требующую владения этой дисциплиной/будет компетентен в
практике.
Технология — это поддерживающие дисциплину инструменты/средства
производства.
Формула для запоминания: «в практике дисциплина загружается в голову
исполнителя, а технология разворачивается на месте исполнения».
Практика прежде всего ролевое поведение системы обеспечения, это функция
системы обеспечения как функционального объекта. Мышление о функциональных
объектах трудно и контринтуитивно. Дополнительно нужно запомнить, что очень
часто практикой называют не только ролевое поведение системы обеспечения, но
и саму систему обеспечения как функциональный объект, оказывающий это
поведение — это уже знакомая нам метонимия. Это довольно легко различать по
именам: чаще всего практика именуется отглагольным существительным (как и
любая другая функция) — «забивание», «протирка», «разработка», но бывает и
инженерия, предпринимательство, здравоохранение (как практики очень высокого
уровня). Если же речь идёт о ролевом объекте, то это будет имя какого-то агента с
его компетенцией в дисциплине и умении обращаться с технологией:
«забивальщик», «протирщик», «разработчик», и дальше «инженер»,
«предприниматель», «здравоохранитель» (но так не говорят! Но такой принцип
словообразования типичен) или «медицинский работник» (необязательно врач! Это
173
http://erazvitie.org/article/zakat_professij
 248

может быть и санинспектор).

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

Управление жизненным циклом, архитектура предприятия и операционный

менеджмент
Управление жизненным циклом (life cycle management) это практика
убеждения в том, что будут в правильном порядке выполнены все необходимые
работы со всеми элементами конфигурации. Её предметом является
конфигурационный/операционный учёт самих объектов
работы/продуктов/артефактов (и описаний/данных, и воплощения системы —
взятых как логистические единицы, это «управление/менеджмент», а не
«инженерия», функциональность не рассматривается, только
конструктивная/продуктная ипостась и описаний, и воплощения системы), а также
учёт всех необходимых работ, получающихся из практик в соответствии с принятой
моделью жизненного цикла.
Управление жизненным циклом не касается того, какие именно оргзвенья в
конечном итоге будут выполнять работы, реализующие практики — это назначение
оргзвеньев на роли основной вопрос другой дисциплины, архитектуры
 249

предприятия (enterprise architecture). Архитектура предприятия занимается

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

Дисциплина практики
Главное в практике — именно эта «невидимая» часть: дисциплина/теория.
Мышление «по дисциплине» (дисциплину ума, дисциплину использования понятий
теории при мышлении) нельзя просто проверить, использование
дисциплинированного (а не дикого, «самодеятельного», «народного») мышления в
деятельности трудно обсуждать, описание дисциплины/учебник непонятно как
делать. «Видимой» дисциплина может стать только путём её моделирования, путём
 250

описания. По факту мало у кого наличествуют компетенции в работе с

дисциплинами практик, как объетками. Это методологические компетенции:
компетенции в практике методологии, как практике по созданию (в том числе и
описанию) самых разных практик. Методология отвечает на вопрос «как
делать/практиковать». Учебники, регламенты, стандарты по разным методам
работы пишут методологи совместно с предметными экспертами (SME, subject
matter expert) в соответствующей предметной области.
Дисциплина чаще всего появляется как результат исследований. Это могут быть
либо фундаментальные исследования, когда предлагаются гипотезы-предложения
по новым альфам, существование которых раньше не обсуждалось. Дальше эти
гипотезы проверяются (ставятся эксперименты по адекватности этих альф реальной
жизни — точны ли модели, в которых о ситуации размышляется в терминах
предложенных альф и отбрасываются разные другие возможные
концептуализации) и в случае их подтверждения появляется новая дисциплина,
обычно с новым названием.
Но дисциплина может быть прикладной, она появляется тогда в результате
прикладных исследований, больше не научного (выдвижение гипотез, а потом
экспериментальная их проверка), а инженерного характера. Учебников с их
предложениями альф для каждой предметной области много, научных статей
много, описаний практического опыта достаточно (не нужно самому делать
эксперименты, они уже проведены, хотя проводившие их люди могли и не называть
это «экспериментом», они «просто работали» с использованием понятий какой-то
дисциплины). Так что достаточно отобрать какой-то набор альф из уже известной
литературы, гармонизировать их между собой, изложить в виде учебного курса или
справочника (для удобства обучения этой дисциплине: дисциплина ведь «оживает»
только после «загрузки» в чью-то голову, или хотя бы оживления её в виде
компьютерной программы, использующей её понятия и выполняющей фрагменты
её предметного мышления).
В частности, дисциплина системного мышления в варианте настоящего учебника
была создана именно таким методом, она не была придумана с нуля в результате
фундаментальных научных исследований. Для создания этой дисциплины в её
конкретном варианте по инженерной и менеджерской литературе (стандартам и
публичным документам, подразумевающим публичное обсуждение соответствия
предлагаемых ими методов описания мира реальному положению дел во множестве
проектов) был выявлен минимальный набор понятий системного мышления.
Этот набор понятий изложен в виде учебника дисциплины системного мышления и
в ходе управления жизненным циклом получившегося курса прошли несколько
итерационных витков спирали коррекции содержания для совершенствования
результата — жизненный цикл разработки курса был, конечно, вариантом
спирального.
Как такую работу по созданию дисциплины делать — это и есть практика
методологии (и понятие практики/деятельности её самое главное понятие, оно
определяется именно в ней). Можно сказать, что практика методологии это
трансдисциплинарная практика, равно как и практика самого системного
мышления. Но методология трансдисциплинарна и по отношению к самому
системному мышлению как дисциплины.
Есть ли какой инструментарий (технология) для поддержки системного мышления
 251

как дисциплины, то есть существует ли технология для практики системного

мышления? Да, конечно: это всевозможные моделеры, позволяющие делать модели
самых разных систем. Тем самым системное мышление вполне возможно считать
практикой: содержание её загружается в голову, а на местности необходимо
развернуть инструментарий моделирования систем, поддерживающий ролевые
описания (view), методы описаний (veiwpoints), управление конфигурацией
мегамодели174.
Но именно дисциплина определяет, какой технологией она может быть поддержана,
а не наоборот. Функциональную нагрузку в практике несёт именно дисциплинарная
часть, и именно по дисциплине называют всю практику на конкретном предприятии.
Дисциплина в практике меняется относительно редко, чаще всего речь идёт о цикле
изменений в 20 лет, а то и больше. Например, системный подход относительно
стабилен, знания его текущей версии помогут пару десятков лет. А вот технологии
меняются много чаще. Моделеры для того же системного подхода меняют свои
поколения каждые 4-5 лет (средняя скорость смены поколений в информационных
технологиях), но они при этом по факту поддерживают одну и ту же много
медленней меняющуюся дисциплину.
Тем не менее, быть успокоенным владением какой-то дисциплиной нельзя. Так,
состояние state-of-the-art (SoTA, «лучшее известное на сегодняшний момент»)
дисциплины описывается в учебниках через пять после его появления в результате
исследований, ещё пять лет проходит до начала изучения дисциплины в вузах
(дисциплина попадает в учебные планы не сразу!), и всего через десять лет после
окончания вуза можно обнаружить, что владеешь каким-то уже совсем антикварным
пониманием дисциплины — двадцатилетней «свежести». Например, большинство
сегодняшних инженеров, менеджеров, предпринимателей и даже спортсменов и
танцоров если и знают хоть как-то системный подход, то устарелую его первую
версию, в которой ещё нет стейкхолдеров, а жизненный цикл означает только
работы. Lean manufacturing (бережливое производство) впервые был упомянут в
статье 1988 года175, прошло более тридцати лет с момента появления этой
практики! Нужно регулярно отслеживать не только относительно частые
смены технологии в практике, но и относительно редкие изменения в
дисциплине!

Технология поддержки практики

Технология хорошо видима (это ж «станочки», при этом современные станочки —
это главным образом софт, заметить технологию просто), но «ружьё в руках
дикаря — кусок железа». Технология без понимания поддерживаемой ей
дисциплины мертва, тот самый «кусок железа» из пословицы. Традиционный
капитал (средства производства) мёртв, если он не поддержан человеческим
174
Можно считать, что с точки зрения системного подхода инструментарий моделирования в каком-то
проекте — системный фреймворк (system framework). Это позволяет предложить какую-то типовую
архитектуру программных средств системного моделирования, например
https://ailev.livejournal.com/1277009.html. Можно даже говорить о прикладной дисциплине «системная
информатика», которая даёт теорию для создания инструментария системного подхода:
http://ailev.livejournal.com/1272169.html, http://ailev.livejournal.com/1274210.html,
http://ailev.livejournal.com/1273208.html, http://ailev.livejournal.com/1275143.html.
175
Термин «lean» был впервые предложен John Krafcik в его статье 1988 года, "Triumph of the Lean
Production System". Эта статья была основана на материале его магистерской дипломной работы в
Слоановской школе управления MIT.
 252

капиталом — образованными в части дисциплины и натренированными на владение

конкретным вариантом инструментария данного предприятия сотрудниками.
Если есть какой-то станок, приспособление, или программное обеспечение, то они
обязательно поддерживают какую-то дисциплину/теорию. Не знаешь этой
дисциплины — неминуемо будешь микроскопом гвозди заколачивать, чисто в силу
неведения.
Так, программы проектного управления могут поддерживать самые разные
дисциплины проектного управления, которые определяют самые разные наборы
подальф альфы «работы». Например, управление проектами может быть
классическим с альфой «критический путь» (critical path), но теория ограничений
критикует использование альфы «критический путь» и предлагает другую альфу:
«критическая цепь» (critical chain)176 и управление по заполнению буферов
проекта177. Если вы не понимаете связи между инструментами и разными
вариантами дисциплин проектного управления с их специфическими альфами и
подальфами, и купите просто какую-нибудь «популярную программу управления
проектами», то вас может ожидать сюрприз.
В программе классического управления проектами на рисунке нет никаких буферов
проекта, поэтому она не поддерживает мышления согласно дисциплине управления
проектами теории ограничений:

А вот эта программа поддерживает, «светофоры» управления буферами хорошо

видны на её скриншотах:

176
https://ru.wikipedia.org/wiki/Метод_критической_цепи
177
http://tocpeople.com/terminy/bufer-proekta/
 253

Если не владеть каким-то менеджерским кругозором в части дисциплин проектного

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

Совершенствование и развитие
Тем самым совершенствование (improvement) предприятия/системы в
обеспечении/ жизненного цикла сводится к смене технологий на более
современные, наладке бездефектной работы технологий, обеспечению хорошей
логистики рабочих продуктов между технологическими операциями. Практика при
совершенствовании меняется только в части технологий, но не дисциплины
практики. При совершенствовании люди переучиваются (training) на работу с новой
технологией, им не нужно менять образование — мышление остаётся тем же.
Развитие (development) предприятия/оргзвена происходит тогда, когда меняется
практика в части дисциплины и тем самым неминуемо происходит также и смена
технологии для поддержки этой дисциплины. При развитии люди
образовываются (education, «как в вузе») для освоения новой дисциплины
мышления и обучаются/тренируются (training, часто на рабочем месте) в работе с
новой технологией, новым инструментарием.
Текущий тренд в том, что периоды совершенствования становятся всё короче и
короче, и всё чаще и чаще приходится осуществлять шаги развития:
предприятие/оргзвено начинает использовать незнакомые членам команды
 254

практики работы, ибо ожесточается конкуренция не только технологий, но и

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

Практики жизненного цикла

Множество примеров документирования практик, встречающихся на протяжении
жизненного цикла системы (их часто так и называют — практики жизненного
цикла, life cycle practices, или life cycle processes), можно встретить в различных
инженерных стандартах (известен способ проверки соответствия стандарту) и
публичных документах (всё то же, что у стандарта, но не предполагается проверки
соответствия). Наиболее типичны тут своды знаний (body of knowledge178, корпус
знаний), описывающие различные варианты подпрактик какой-то более-менее
крупной практики/деятельности.
Все эти стандарты и публичные документы используют для практик разные
названия — практика (practice), способности (abilities), процессы (следуя традиции
«функционального описания процессов», заложенной серией стандартов ISO 9000,
в которых путались модульный/конструктивный «процесс как последовательность
шагов/операций/работ во времени» и компонентный/функциональный «процесс как
описание принципов, каким способом нужно достичь результатов»), методы
(наборы практик, достаточных для решения какой-то содержательной задачи «под
ключ»), и даже методологии (ISO 24744 предложил считать метод/method и
методологию/methodology синонимами), иногда «область знаний» (knowledge area),
с которой связывают какую-то «деятельность» (activity). Иногда и вообще не
используют каких-то терминов — просто говорят, «что нужно делать», приводя
название практик, но не используя сам термин (говорят «проектное управление»,

178
https://en.wikipedia.org/wiki/Body_of_knowledge
 255

но не «практика проектного управления», так же, как часто говорят «самолёт», но

не «система самолёт» — слово «практика» как указатель типа встречается отнюдь
не всегда.
Вот примеры документирования некоторых методов/практик:
• свод знаний по организационному анализу (business analysis body of
knowledge, BABoK)179. Тут в главе 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)180. То, что называется «практики» в нашей книге, в PMBoK называют
«процесс». Например, группа процессов планирования определяет и
уточняет цели и планирует действия, необходимые для достижения целей и
содержания, ради которых был предпринят проект. В группу процессов
планирования входят следующие процессы: Разработка плана управления
проектом, Планирование содержания, Определение содержания, Создание
иерархической структуры работ (ИСР), Определение состава операций,
Определение взаимосвязей операций, Оценка ресурсов, и т.д. (всего 47
процессов в актуальной 6 версии PMI PMBoK).
• свод знаний по системной инженерии (systems engineering body of knowledge,
SEBoK)181. Сами практики тут не выведены явно, а рассыпаны по всему тексту.
Это, скорее, «краткое оглавление для большой литературы по предмету
системной инженерии», поделенное на «области знаний».
• … множество других BoK, это сегодня стандартная форма выражения знаний
по практикам какой-то инженерной или менеджерской дисциплины.
Можно спорить, описывают ли подобные документы практики (и дисциплину, и
технологии — «гвозди должны быть забиты быстро и ровно, для этого используйте
молотки»), или только дисциплины/теорию, оставляя какое-то описание возможных
технологий за своими пределами («гвозди должны быть забиты быстро и ровно»).
Авторы подобных документов обычно уделяют не столь большое внимание таким
вопросам, не различают дисциплины и технологии. Но нужно помнить, что
дисциплина меняется медленно, а технологии — быстро. Поэтому дисциплину
нужно учить, а вот к новым технологиям эти своды знаний правильно адаптировать:
в части новых технологий эти своды знаний могут быть уже довольно устревшими.
Но и новые технологии могут отражать изменения дисциплины, которые ещё не
успели отразиться в сводах знаний!

179
http://www.iiba.org/babok-guide.aspx, оглавление на русском https://iiba.ru/babok/chapters-of-babok-
version-3/
180
https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
181
http://sebokwiki.org/
 256

Не уделяют авторы сводов знаний внимания и вопросам выбора варианта

функционально одинаковых практик, оставляя этот выбор за человеком-актёром,
готовящимся к выполнению какой-то проектной роли. Например, есть набор
практик проектного управления PMI PMBoK, но есть и альтернативый вариант, APM
BoK182 — и нужно выбирать, каким набором практик пользоваться для изучения
дисциплины, они ведь разные (это химия или физика в двух учебниках окажется
одной и той же, а проектное управление может оказаться очень разным!).
Абсолютно не исключено, что разные группы компетентных в той или иной практике
людей будут рекомендовать использование своего любимого варианта практики,
несовместимого с другими, и без дополнительных исследований при выборе будет
не обойтись.
Методы работы/практики/деятельности глубоко иерархичны. Не только метод
состоит из практик (и гарантируется, что набор этих практик достаточен для
достижения цели метода), но и сами практики состоят из подпрактик на много
уровней. Например, можно говорить о системной инженерии как методе или
практике работы. Но в системной инженерии можно выделить её основные практики
инженерии требований, инженерии системной архитектуры, управления
конфигурацией и изменениями, проведения испытаний/проверки и приёмки.
Но и дальше может быть деление: например, в инженерии требований можно
выделить практики выявления потребностей и требований, анализа требований,
специфицирования (документирования) требований, управления требованиями.
И даже на этом уровне могут быть самые разные варианты. Например, при развитии
ТРИЗ за последние двадцать лет тамошние практики инженерии системной
архитектуры были дополнены практиками инженерии требований. Так что для
выявления требований можно или использовать методы/практики ТРИЗ183 (включая
технологию: моделеры специфических для этого диаграмм ТРИЗ), или
альтернативных других практик, например сценариев использования (use cases,
включая технологию: моделеры специфических диаграмм use cases).

Пример: практики жизненного цикла системной инженерии

Стандарт практик жизненного цикла системной инженерии ISO/IEC/IEEE
15288:2015184 Systems and software engineering — System life cycle processes
устанавливает наиболее общие описания практик жизненного цикла систем,
созданных людьми. Он определяет необходимый для системной инженерии набор
практик, связанную с ними дисциплину/теорию (в том числе предлагается
терминология для её выражения). Эти практики могут быть применены на любом
уровне разбиения системы — предполагается рекурсивное использование
стандарта. Эти практики определены для всего жизненного цикла. В выполнение
этих практик вовлекаются все стейкхолдеры, с главной целью — удовлетворить
клиента.
Стандарт делит все практики на 4 группы, часть из них «технические» и относятся
к преобразованиям целевой системы, часть «управленческие» и относятся к
оргзвеньям/проекту/project/системам в обеспечении, часть к обеспечению
обеспечения (практики порождения проекта создания системы), и часть относится
182
https://www.apm.org.uk/body-of-knowledge/about-bok/
183
https://ru.wikipedia.org/wiki/Теория_решения_изобретательских_задач
184
https://www.iso.org/standard/63711.html
 257

к заключению и выполнению соглашений по закупкам и поставкам. Вот они:

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

остальные всевозможные BoK, описывает отнюдь не минимум или оптимум

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

Методологии
Популярные методологии разработки (development process), т.е. разные
варианты agile185, «гибкая методология разработки», обеспечения качества (six
sigma186), преодоления барьера между разработкой и эксплуатацией (DevOps187 и
DataOps188), и даже социализации в танце (социальные танцы189 — танго, кизомба,
сальса, самба) оказываются все наборами практик жизненного цикла, разве что не
всех стадий.
Методологии часто содержат в себе три части:
• Общее описание дисциплины для многих составляющих методологию
практик. Эта дисциплина вводит альфы, а отдельные практики потом могут
работать с подальфами этих альф. Например, agile-практики вводят альфу
backlog190 как «список хотелок». Практики ТРИЗ-методологии используют
понятие «идеального конечного результата»191, социальные танцы работают
с понятием «коннекшн» 192
• практики как инструкции «что и как нужно делать» в каждом конкретном
случае: «если встретил X, то делай Y». Их обычно много разных, они могут
вводить свои подальфы.
• указания на то, как сочетать практики с работами в ходе жизненного цикла,
то есть упоминание желаемых практик операционного
менеджмента/управления работами. Тем самым методология содержит
прямые указания на подходящую для её практик модель жизненного цикла.
Иногда даже слова «методология разработки» используют именно как
указание на этот аспект (подменяя словами «методология разработки» слова
«модель жизненного цикла»).

185
https://en.wikipedia.org/wiki/Agile_software_development
186
https://en.wikipedia.org/wiki/Six_Sigma
187
https://en.wikipedia.org/wiki/DevOps
188
https://en.wikipedia.org/wiki/DataOps
189
https://en.wikipedia.org/wiki/Social_dance
190
https://www.agilealliance.org/glossary/backlog/
191
http://www.triz.natm.ru/trizz/triz2_01.htm
192
https://ailev.livejournal.com/1315064.html
 259

Сегодняшний тренд — это разборка крупных методологий на отдельные

практики. Если ещё лет десять назад считалось, что нужно обязательно
использовать в работе все описанные какой-то методологией практики, и без любой
из описанных результат будет плохим, то сегодня такого уже нет и такой подход
жёстко критикуется. Для методологий разработки Ивар Якобсон (один из соавторов
стандарта описания моделей жизненного цикла OMG Essence) призывает
«освободить практики от методологий», ибо они являются отличными единицами
накопления опыта — его доклад на SECR’17 так и называется: «Kill All Methods —
Free the Practices»193.
Интересно, что это относится даже к танцевальным методологиям, повсеместно
происходит переход к fusion dance194 как сплаву практик разных танцевальных
стилей, определяемых разными методологиями отдельных танцев, например смеси
практик танго, кизомбы, форро, сальсы (см. как пример проект Буфф,
основывающийся на системном мышлении в социальных танцах195). Помним, что
практика в танце поддерживается не только дисциплиной/теорией/каноном какого-
то танца, но и инструментарием в виде тела и звучащей музыки, поэтому
объединение практик танца из разных видов/стилей требует дополнительного
развития тела, а часто и подстройки музыка — если хотите смешать практики из
методологии хип-хопа и методологии кизомбы, то придётся доразвить тело и
подобрать подходящие треки. В инженерии, менеджменте, предпринимательстве
при сочетании практик, взятых из разных методологий, тоже приходится не только
обучать людей необходимым фрагментам дисциплин этих методологий, но и
дорабатывать инструментарий, чтобы он поддерживал разные дисциплины
одновременно.
Сами методологии необязательно ограничиваются практиками, взятыми из какой-
то одной сферы человеческой деятельности. Так, agile-методологии появились как
некоторый сплав (fusion) инженерных и менеджерских практик, хотя за последний
десяток лет там практически не осталось инженерных практик, но только
менеджерские196, а методологии проектного управления всё больше и больше
обращают внимание на инженерные аспекты разработки (в последние годы в них
даже появляются отдельные практики инженерии требований, хотя и совершенно
недостаточные для полноценной инженерной работы).
Системное мышление позволяет похожим образом думать о практиках
таких разных сфер человеческой деятельности с их такими разыми
дисциплинами и технологиями, как менеджмент, инженерия,
предпринимательство, культура. А учитывая то, что развитие это замена
одних практик на другие (обычно с заменой дисциплины, а не только
технологии — речь не идёт о совершенствовании), то системное
мышление позволяет обсуждать организационное развитие в рамках
управления жизненным циклом: обсуждать использование различных
практик и способ их связи с выполняемыми работами.

193
http://2017.secr.ru/lang/en/program/invited-speakers/ivar-jacobson
194
https://en.wikipedia.org/wiki/Fusion_dance, пример fusion кизомбы с разными другими стилями см. в
https://ailev.livejournal.com/1373388.html
195
https://vk.com/buffdance
196
https://ailev.livejournal.com/1183548.html
 260

10. Вид жизненного цикла

V-диаграмма
Самым упрощённым, популярным и распространённым представлением жизненного
цикла в его современном виде акцента на функциональное поведение систем
обеспечения как первичное рассмотрение является V-диаграмма (V-diagram, Vee
diagram), популяризованная в 1991 году Kevin Forsberg197:

Название этой диаграммы происходит от формы латинской буквы V, а форма

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

197
Forsberg, K., Mooz, H., 1991, "The Relationship of System Engineering to the Project Cycle", Chattanooga,
Tennessee: Proceedings of the National Council for Systems Engineering (NCOSE) Conference, pp. 57–65.,
http://ife2010.wikispaces.com/file/view/SE+%26Project+Cycle,+Forsberg%26Mooz,+1995.pdf
 261

двух разных значениях (и никогда в значении «словарное определение» из

неправильного перевода system definition!), и его значение определяется из
контекста:
• Информация о системе, выраженная в требованиях, архитектуре и
неархитектурной части проекта/design (акцент на то, что это описание как
содержание системной документации)
• Обобщённая/укрупнённая стадия жизненного цикла, то есть работы по
описыванию системы/созданию описания системы в первом смысле этого
слова.
Дальше линия времени делает перегиб, и логически начинается вторая стадия
воплощения системы (system realization, реализация как «вынос в реальность»).
Словосочетание «воплощение системы» тем самым тоже используется в двух
значениях:
• Сама система как физическое тело в пространстве-времени
• Обобщённая/укрупнённая стадия жизненного цикла, то есть работы
различных практик по воплощению системы/созданию воплощения системы
в первом смысле этого слова.
Сам излом V нужен для того, чтобы показать суть проверки/верификации и
приёмки/валидации: изготовление деталей (неделимых далее в проекте модулей)
системы делается и проверяется (verification) в соответствии с проектом/design,
стрелки проверки показывают именно этот факт. Ради показа этих стрелок
проверки соответствия определения и воплощения и сделана сама V-диаграмма:
она показывает способ работы, в котором воплощение/создание/realization системы
происходит не путём проб и ошибок, сразу работы «из головы» с материалом для
изготовления, а сначала путём размышлений и моделирования-
документирования — описания системы/system definition. И созданная
(изготовленная в виде деталей, а затем собранная из этих деталей) система
проверяется на соответствие её предварительно разработанному описанию — эти
проверки изображаются стрелочками на диаграмме.
Последнее, что происходит в ходе воплощения — это приёмка в эксплуатацию,
которая проходит в форме проведения испытаний на соответствие определённым в
самом начале потребностям (то есть проверяется, что происходит не с целевой
системой, а с надсистемой, когда в её составе работает целевая система).
На этом первые V-диаграммы обычно и заканчивались, но потом иногда начали
изображать и стадию эксплуатации (работу/функционирования системы, system
operation) как длинный горизонтальный отрезок. На нашем рисунке это «иногда»
показано квадратными скобочками вокруг [работы системы]/system operation.
Внешний вид диаграммы больше стал напоминать квадратный корень, но название
«V-диаграмма» осталось.
Стадию вывода из эксплуатации на V-диаграммах изображать так и не начали. Это
отражает постепенное восприятие системного мышления инженерами: сначала
идея жизненного цикла проекта разработки системы (то, чем занимаются
системные инженеры в своём проекте), потом охват мышлением стадии
эксплуатации, и только в самое последнее время (уже в 21 веке, начиная со
стандарта ISO 15288, первая версия которого вышла в 2002 году) умолчанием
является обязательное рассмотрение полного жизненного цикла — в том числе и
 262

(инвестиционный) замысел, и вывод из эксплуатации/уничтожение после

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

Моделеориентированность в жизненном цикле

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

198
https://incose-ru.livejournal.com/12765.html
199
https://www.bristol.ac.uk/media-library/sites/eng-systems-centre/migrated/documents/pdavies-blockley-
lecture.pdf
 263

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

Требования x1 (единица отсчета)

Проектирование x5

Строительство x12

Проверки X40

Эксплуатация X250
Учитывая то, что ведущая практика описания системы — это моделирование, то
речь идёт о максимизации моделирования разного рода по сравнению с инженерной
работой с воплощением системы в физическом виде и неизбежными при этом
«пробами и ошибками». Думай, думай, моделируй много раз, и только потом один
раз сделай.
«Моделирование в широком смысле — это эффективное по затратам
использование чего-то одного вместо чего-то другого для мыслительных целей. Это
позволяет нам использовать вместо реальности что-то такое, что проще,
безопаснее или дешевле чем реальность для заданной цели; модель является
абстракцией реальности в том смысле, что она не может представить все аспекты
реальности. Это позволяет нам иметь дело с миром упрощённым способом, обходя
сложность, опасность и необратимость реальности»200.
Мы не тратим силы на обсуждение и обработку ненужных деталей моделируемого
объекта. Модели — это «правильные упрощения». Обсуждаем только то, что
отмоделировано, то, что важно, что нужно.
Формальную (на основе математики) модель можно относительно легко проверить
на формальную правильность — вручную или даже компьютером. Это называется
проверкой моделей (model checking). Так, в радиосхеме можно формально
удостовериться, что все её компоненты соединены и нет неприсоединённых
компонент, все соединения не имеют разрывов (то есть не идут откуда-то в никуда).
Формальную модель можно подвергнуть оптимизации (в том числе компьютерной)
по самым разным критериям, в том числе многим ранжированным критериям. С
формальной моделью может работать поиск/search — искать вычислительными
методами оптимальное решение в пространстве решений (при этом модель может
быть даже деформализована при поиске оптимума, речь тут идёт о так называемых

200
Modeling, in the broadest sense, is the cost -effective use of something in place of something else for some
cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for
some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense
that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding
the complexity, danger and irreversibility of reality. "The Nature of Modeling.", Jeff Rothenberg, in Artificial
Intelligence, Simulation, and Modeling, L.E. William, K.A. Loparo, N.R. Nelson, eds. New York, John Wiley and Sons,
Inc., 1989, pp. 75 -92,
http://poweredge.stanford.edu/BioinformaticsArchive/PrimarySite/NIHpanelModeling/RothenbergNatureModelin
g.pdf
 264

дифференцируемых архитектурах201).
Где физический объект (систему) изготовить долго и дорого, можно ограничиться
быстро составляемой информационной моделью, и всё-таки получить ответ на
вопрос.
Формальную модель можно не делать руками, а породить (generate)
компьютером — это решение проблемы сложности. Так, 21 миллиард транзисторов
в современном микрочипе202 невозможно нарисовать руками на кремниевой
пластине, и даже невозможно руками нарисовать принципиальную схему такого
микрочипа. Но можно породить и принципиальную схему, и литографическую маску
из моделей более высокого уровня на языке описания микросхем.
С использованием компьютерного моделирования резко поднялась точность и
безошибочность основанного на проверяемых моделях проектирования и
одновременно резко поднялась точность изготовления деталей. Компьютерное
управление конфигурацией и изменениями позволили в разы снизить количество
конфигурационных коллизий.
В результате происшедших изменений в распределении работ в жизненном цикле
(больше работ по описанию системы, меньше работ по воплощению системы — и
как описание делается с большей точностью и проверяется больше, так и
изготавливается система с большей точностью и тоже испытывается/тестируется
больше) первый же самолёт новой модели летает, что раньше было невозможно.
Сегодня потеряла актуальность традиционная шутка про необходимость для каждой
детали «подгонки по месту напильником». Все изготовленные (чаще всего не
вручную) по тщательно продуманному и отмоделированному проекту детали просто
собираются в целую систему, и она работает как определено. Это соответствует
одному из слоганов системной инженерии: «с первого раза правильно», т.е. первое
же воплощение системы должно быть работоспособно. Не всегда ещё так
получается, не у всех команд и не во всех областях деятельности, но всё чаще, чаще
и чаще. Так, из сорока полётов на Марс до настоящего времени только половина
закончилась успешно. Но команда инженеров Индии сумела отправить на орбиту
Марса ракету с первого раза.
Практика интеграции (сборки из плохо подогнанных друг ко другу частей и
связанного с этим решения системных проблем) была раньше одной из основных
практик системной инженерии. Сейчас из набора основных практик системной
инженерии практика интеграции исчезла, а сборка стала рутинной нетворческой
операцией.
Иногда V-диаграмму c опорой на моделирование изображают так:

201
https://ailev.livejournal.com/1464563.html
202
https://en.wikipedia.org/wiki/Volta_(microarchitecture)
 265

В этой диаграмме увеличение количества работ по определению системы за счёт

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

203
V-диаграмма моделеориентированной системной инженерии, http://ailev.livejournal.com/820662.html
 266

Есть два типа работы с моделями. Когда пара моделей связаны «через голову
человека», то есть когда человек смотрит на одну модель и разрабатывает или
проверяет другую модель, то это будет моделеориентированной (model-based)
работой. Так, моделеориентированная системная инженерия (model-based
systems engineering, MBSE) ориентируется на использование архитектурных языков
и языков представления требований в определении системы. Но когда создаётся
цепочка моделей, каждая из которых берёт данные логически предшествующих ей
прямо в машиннообрабатываемой форме, без интерпретации этих данных
человеком, это будет моделеуправляемой (model-driven)204 работой.
Современные модели в определении системы делят на неисполняемые
компьютером, но исполняемые головой проектных ролей «модели для понимания»
(тексты на языках моделирования, схемы, диаграммы, предназначенные для
изучения их человеком) и исполняемые компьютером модели имитационного
моделирования (simulation), которые предназначены для воспроизведения каких-
то разворачивающихся во времени характеристик моделируемой системы. Про
более-менее полный набор компьютерных инженерных моделей имитационного
моделирования говорят как про виртуальную (virtual) систему. Часто об этом
говорят так: «перед тем, как построить атомную станцию, её нужно сначала
построить в компьютере» и называют результирующий набор моделей
«виртуальная атомная станция».
Виртуальная система часто включает в себя и модель изготовления (результат
компьютерного моделирования правой части V-диаграммы), например,

204
Definitions to Close on — Model, MBD, MBE, MBIT, MBSE, MBT, MDA, MDD, MDE, https://www.ppi-
int.com/newsletter/SyEN-046.php
 267

моделирование сооружения атомной станции в 4D для целей точного планирования

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

V-модели как модель декомпозиции системы

Ещё один вариант V-диаграммы показывает декомпозицию системы по системным
уровням, определяемым отношениями часть-целое (уровням разбиения системы)206:

205
https://bizzdesign.com/blog/the-digital-twin-organization-can-enterprise-architecture-help/
206
The Vee Activity Diagram (Prosnik 2010) Released by the Defense Acquisition University (DAU)/U.S. Department
of Defense (DoD), http://sebokwiki.org/wiki/System_Life_Cycle_Process_Models:_Vee.
 268

На рисунке показано, что на каждом системном уровне готовятся в левой части V

(описании системы, system definition) спецификация и планы
испытаний/тестирования итоговых продуктов следующего уровня системного
разбиения, а потом идёт изготовление деталей (элементов, которые не собирают),
и на каждом уровне в правой части V (воплощение системы как стадия/работы,
system realization) происходит сборка из частей предыдущего уровня и испытания
этих готовых систем.
Тут нужно указать, что в системной инженерии «изготовление» совершенно
необязательно означает именно изготовление чего-то из сырья. Это может означать
и просто покупку готового модуля, если он удовлетворяет требованиям. Более того,
это предпочтительный способ! Самый простой способ изготовить — это
купить! Но при этом нужно понимать, что для покупки всё равно нужно
подготовить требования, описать покупаемую систему. Нет требований —
непонятно, что покупать.
Общий принцип «соответствие воплощения описанию» тут показывается стрелкой
на каждом системном уровне — собранные и испытанные части
системы/подсистемы каждого уровня удовлетворяют своим определениям. Как и
многие другие диаграммы системного мышления, V-диаграмма подразумевает
рекурсивное применение, она применима на каждом системном уровне.
Обратите внимание, что на этой диаграмме система называется product/продукт —
то есть у автора в голове именно продуктный/модульный, а не функциональный
аспект ведущий.

Гибридные модели жизненного цикла

Примером гибридной между колбаской-«водопадом» из последовательности
крупных работ-стадий и более современной функциональной схемы с
выполняемыми в ходе всего времени жизни системы практиками является модель
жизненного цикла капитального строительства будущего, разработанная
 269

консорциумом FIATECH207:

В середине этой диаграммы мы видим развёрнутые во времени стадии-работы

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

207
http://www.fiatech.org/tech-roadmap
 270

будут учитывать работы с новыми материалами, методами, оборудованием? На

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

Уход от «водопадов» с гейтами

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

новую модель самолёта208.

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

Управление работами и управление жизненным циклом

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

208
Altfeld, Hans-Henrich. Commercial aircraft projects: managing the development of highly complex products,
2010
 272

описывающей целевую систему, равно как и описывающей её жизненный цикл —

что делать в ходе её создания).
Обратим внимание, что управление жизненным циклом не включает ответы на
вопрос «кто это всё делает» и «когда делает»! Логическое «когда» включает
(«красить только после зачистки», инженерное замечание), а вот операционное
«когда» и конкретные ресурсы («красит Вася в 12:00») — вот этого нет, это предмет
управления работ.
Управление работами (operation management, управление операциями)
заключается в управлении выделением ресурсов для прохождения всех
контрольных точек в срок и в соответствии с бюджетом. Управление жизненным
циклом рассматривается как преимущественно инженерная дисциплина (нужно
хорошо знать практики инженерной работы), управление работами как чисто
менеджерская дисциплина (нужно хорошо знать практики операционного
менеджмента).
Управление работами абстрагируется от инженерной сути операций, знания о
способах выполнения работ. В управлении работами достигается максимально
быстрое и дешёвое выполнение работ, и для достижения этого используются не
инженерные методы (например, изменить способ изготовления), а менеджерские
способы (если производительность станка для обработки кучки однородных
деталей мала, поставить два станка — при этом неважно, что это за обработка).

Виды практик управления работами

В управлении жизненным циклом в том числе принимается решение о том, какие
практики управления работами выбрать, ибо существует большое разнообразие
этих практик — и главный вопрос тут в том, можно ли заранее запланировать
работы: как заранее провести «логическое планирование» в рамках управления
жизненным циклом (какие вообще практики применять, какими практиками лечить
пациента, когда непонятно, ещё, чем он болеет? Какими практиками изготавливать
систему, когда ещё непонятно, из чего она будет сделана?), так и «операционное
планирование» — кому и когда выполнять практику, производя необходимую
работу, чтобы общая продолжительность и стоимость работ были минимальны.
Классическое управление проектами (project management, проектное
управление) подразумевает одномоментное планирование перед началом проекта
для всех контрольных точек/milestones как сроков их достижения, так и ресурсов
для их достижения. По факту это означает составление плана-графика выполнения
всех работ с назначением ресурсов на эти работы ещё до начала выполнения работ.
Это часто называют предварительным (up-front) планированием работ, а весь
проект просто считают уникальной работой, имеющей чётко определённые время
начала и конца, а также выделенные для неё ресурсы. В современных версиях
методологий проектного управления, конечно, предусматривают регулярную
актуализацию планов по ходу выполнения проекта, но именно актуализацию уже
имеющихся планов работ, они не предполагают непрерывного планирования на
маленькие шаги вперёд работы в ситуации неопределённости с содержанием,
бюджетом, сроками проекта.
Кроме известности состава, трудоёмкости и последовательности работ перед
началом проекта для управления проектами нужно знать ещё и нормы выработки
для ресурсов: оценки производительности ресурсов, полученные из опыта прошлых
 273

работ. В строительстве, например, хорошо известны нормы выработки: сколько

кирпичей в час в среднем кладёт каменщик, сколько арматуры в час вяжет
арматурщик.
Но отнюдь не все работы с системой удаётся запланировать до начала выполнения
этих работ, когда мало что известно про описание системы (нет ещё требований,
нет архитектуры, нет «рабочки»), мало что известно про воплощение системы, и
даже мало что известно про то, кто будет систему делать — системы обеспечения
(в проектном управлении это «ресурсы»). Предварительное планирование легко
делать для проектов изготовления и сборки, когда определение системы готово.
Это, например, крупное машиностроение «под заказ», строительство. Но вот
детально планировать работы по описанию/проектированию системы обычно не
удаётся — часто даже непонятно, какие при проектировании могут потребоваться
ресурсы, сколько и каких частей системы придётся разрабатывать. И тогда
используют другие методы управления работами, не требующие обязательного up-
front планирования и обязательного знания норм выработки для выполняющих
работы ресурсов.
Если непонятно, какие могут быть контрольные точки больших кусков работы, то
речь идёт об управлении программами (program management). По мере
понимания этих контрольных точек программой запускаются проекты ведения
работ по их достижению, используя предварительное планирование достижения
каждой из них. Но нет плана запуска отдельных проектов программы, ибо
деятельность программы как раз и состоит в определении этих проектов и
планировании их, а дальше работы проектов управляются стандартными методами
проектного управления. Управление программами отличается от остальных
методов управления работами тем, что более мелкие работы управляются в них
другой практикой: в программах обычно нет «подпрограмм», но есть «проекты». В
проектах же обычно подпроекты, в процессах процессного управления
подпроцессы, в кейсах управления кейсами подкейсы и т.д.
Если контрольные точки и ресурсы для их выполнения известны, но неизвестно, в
какой момент происходит запуск большого числа однотипных работ, речь идёт о
процессном управлении (process management). Процессом тут называют не
уникальную работу, а типовую последовательность шагов, обычно определяемую
не столько планом (и уж тем более не графиком), а регламентом.

Гибкие методологии управления жизненным циклом и управление кейсами для

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

системы были очень непохожи, и нельзя было даже сделать предположений, какие
работы нужно включать в план их разработки — в отличие от зданий, где заранее
было известно, что нужно будет делать фундамент и возводить стены, а потом
делать монтаж оборудования и внутреннюю отделку, в отличие от самолётов, где
сразу понятно, что в составе самолёта будет фюзеляж, крылья, салон, в
программных системах нельзя сразу было сказать их состав, и поэтому работы по
разработке нельзя было привязать к этому составу up-front, перед выполнением
этих работ.
Общее для всех этих гибких методологий/методов и соответствующих им видам
жизненного цикла в том, что они используют в части управления работами
управление кейсами (case management)209. Кейс — ситуация, обстоятельства или
начинание, которые требуют набора действий для получения приемлемого
результата или достижения цели. Кейс фокусируется на предмете, над которым
производятся действия (например, человек, судебное дело, страховой случай), и
ведется постепенно появляющимися обстоятельствами дела.
Управление кейсами по факту обобщает управление проектами и процессами. В
кейсе сначала мы имеем вопрос контрольной точки (формулировку кейса), после
этого формулируется работа для прохождения этой контрольной точки (ибо
формулирования задания на работу — отдельная операция, но контрольная точка
может быть учтена задолго до этого), потом отдельно назначение ресурса на
работы и тем самым разбирательство с планированием и графиком. Тут могут быть
использованы удобные для управления кейсами методы планирования, например,
канбан (Kanban for development 210 для управления кейсами прежде всего, для
планирования производственных процессов используется обычно Kanban for
manufacturing211). И даже тут жизнь контрольной точки в управлении кейсами не
заканчивается, потому как в рамках управления изменениями конфигурации нужно
сообщить участникам проекта, что кейс закрыт: состояние системы изменилось, и
всем остальным нужно ориентироваться на новую ситуацию.
Технологии, используемые для гибких методов в управлении жизненным циклом и
управления кейсами в управлении работами — это технологии трекинга
контрольных точек (issue tracking, часто их называют «системы управления
задачами», «системы отслеживания ошибок», «системы отслеживания
поручений»). Название отражает тот факт, что контрольные точки появляются не в
плановом порядке, они изначально представляют собой вопрос/проблему (issue),
требующую своего решения. Трекеры (issue trackers, софт для трекинга
контрольных точек212) учитывают эти контрольные точки по мере их появления.
Вопросы (если они признаны важными), превращается потом в задачу/task как
единицу назначаемой на конкретный ресурс (попутно определяется практика,
которая поможет решить вопрос, и ресурс, который владеет соответствующей
оргвозможностью/capability выполнять работы для этой практики), а после
выполнения задачи она превращается ещё в уведомление/notice о завершении.

209
http://ailev.livejournal.com/946134.html
210
https://en.wikipedia.org/wiki/Kanban_(development)
211
https://en.wikipedia.org/wiki/Kanban
212
Кроме трекеров контрольных точек общего вида, были распространены трекеры ошибок в программном
обеспечении bug trackers, трекеры инцидентов/заявок пользователей в ходе администрирования IT-
инфраструктуры. Постепенно опыт работы с этими специализированными трекерами был обобщён, и
сегодня трекеры более-менее универсальны.
 275

Состояние мира изменилось после решения исходной проблемы/вопроса/issue, и

нужно уведомить все заинтересованные в этом проектные роли.
Конечно, если появляется возможность что-то спланировать, в управлении кейсами
это делается. Часто тут план — это просто опыт прохождения какого-то кейса,
шаблон. Вот этот план и будет называться шаблоном (template). Если шаблоны
готовят не специально обученные программисты таких шаблонов, а сами участники
команды проекта, то такое управление кейсами называют адаптивным (adaptive),
а шаблоны — шаблонами сообщества (community template).
Мы различаем управление жизненным циклом и виды/модели жизненного цикла
(например, водопад, спиральный жизненный цикл, параллельную инженерию,
гибкие методы — способы назначения работ на типовые практики разработки
прежде всего, т.е. когда в проекте выполняются инженерия требований, инженерия
системной архитектуры прежде всего) и соответствующие им методы управления
работами (например, управление программами и проектами, процессное
управление, управление кейсами) и в рамках управления работами методы
планирования работ (например, метод критического пути или критической цепи для
планирования в управлении проектами, канбан в управлении кейсами).
Вот схематическое изображение жизненного цикла одной из самых
распространённых методологий гибкой (agile) работы, SCRUM213:

В этой диаграмме бросается в глаза её нелинейная/неводопадная форма, в которой

выделяются наличие циклов ежедневной работы и месячных «спринтов».
Нелинейность, отсутствие предписанной чёткой стадийности выполнения
практик — верный признак «принципиальной схемы». Суть диаграммы в том, чтобы
показать, откуда берутся выполняемые работы. Если бы речь шла о чистом
управлении работами, на диаграмме не было бы слов «выбор требований»,
«демонстрация заказчикам», а просто обсуждались бы какие-то работы в их отвязке
от содержания (и названия были бы типа «работа 1», «работа 2», и т.д.):
менеджерские практики не работают с содержанием работ, они работают только с
213
https://en.wikipedia.org/wiki/Scrum_(software_development)
 276

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

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

Тренды в практиках управления работами

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

214
https://ailev.livejournal.com/1388412.html
 277

поддерживающих их технологий), железной дисциплиной выделения ресурсов этим

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

За пределами жизненного цикла

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

215
https://en.wikipedia.org/wiki/Dynamic_systems_development_method
216
https://github.com/agilelion/Open-Kanban
 278

потенциальной целевой системы и формирование проекта по её созданию.

В последней версии ISO 15288:2015 даже появилась новая практика «6.4.1. Business
or mission analysis process». Суть этой практики — понять, какую целевую систему
берётся делать команда, и определить, стоит ли её вообще делать, соответствует
ли это стратегии компании, чья команда будет выполнять проект.
«Начало жизненного цикла» тут необязательно означает «начало работ», именно
стадию жизненного цикла как укрупнённую группу работы. Можно говорить и о
«логическом начале», практиках. В частности, можно указать на практику
моделеориентированного концептуального проектирования (model-based
conceptual design)217:

Практика концептуального проектирования/MBCD/замысла новой системы, то есть

формирования нового проекта, оказывается практикой предпринимательской
(интересы/perspective высших руководителей/executives), пересекающейся с
практикой определения соответствия стратегии/организационной (интересы
business management), потому как речь идёт о создании нового проекта (выделение
организационных ресурсов на работы по проекту) и только отчасти интересна для
архитектора/architect. При этом концептуальное проектирование пересекается с
практиками моделеориентированной системной инженерии (model-based systems
engineering), но уже не пересекается с практиками использования САПР (система
автоматизации проектирования, CAD tools) для подготовки неархитектурной части
проекта/design.
Окончание жизненного цикла системы тоже не всегда легко определяется. Система
может ремонтироваться и модернизироваться так, что в её индивиде не останется
уже ничего от предыдущей. Берём швабру, через некоторое время ломается ручка,
меняем ручку, потом меняем перекладину — это та же швабра? Да, это та же
швабра-система (функциональный объект тот же!), только поменялись какие-то
модули, конструктивные части. Швабра определяется по её функциональному
описанию, если заменить наполнение конкретными модулями или даже поменять

217
Steven J.Saunders, INCOSE INSIGHT volume 17 issue 4
 279

размещение, ничего страшного с системой не произойдёт — она останется

существовать.
Microsoft объявила, что Windows 10 будет её последней операционной системой, но
непрерывно производит в ней изменения. Срок службы атомных электростанций
сначала делали 60 лет, но сейчас продляют его до 80 лет. Жизненный цикл системы
оказывается не содержащим чёткое заранее определённое число проектов перед
выводом из эксплуатации/уничтожением после использования, и может не иметь
чёткого срока окончания.
В атомной промышленности даже случилась терминологическая коллизия:
управлением жизненным циклом (lifecycle management) там называют не практики
управления жизненным циклом из системного подхода, а практики продления срока
эксплуатации атомных станций 218! К счастью, по мере распространения знаний
системного мышления среди работников атомной промышленности, значение
термина меняется на общепринятое.
С вот этой «неоканчивающейся разработкой» связан ещё один вариант показа
жизненного цикла — как развёртки во времени выпуска версий какой-то системы,
roadmap/дорожная карта. Этот термин пришёл из проектного управления219, но всё
чаще используется для показа ориентировочных сроков выпуска версий системы.
Вот пример жизненного цикла с упором на практики не столько инженерии или
менеджмента, сколько на практики предпринимательства 220 — с совмещением с
дорожной картой (показаны три продукта разной степени готовности):

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

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

218
Например, https://www.iaea.org/newscenter/statements/nuclear-power-life-cycle-management-managing-
nuclear-knowledge-and-nuclear-security — тут «управление жизненным циклом» чётко связывается не со
способом назначения практик на работы, а с удлинением срока службы энергоблоков АЭС.
219
В проектном управлении это диаграмма основных контрольных точек проекта,
https://www.productplan.com/roadmap-basics/
220
https://hackernoon.com/crafting-your-perfect-product-roadmap-7b42b1033c4e
 280

занимается организация: в архитектурном языке обычно есть отдельные элементы

для обозначения практик и работ, требуемых для них технологий и человеческих
компетенций. В отличие от инженеров, у которых ведущим является жизненный
цикл системы (полный! Все стадии!) у архитекторов предприятия, а особенно
менеджеров ведущим является жизненный цикл проекта, ограниченный
временными рамками и практиками проекта, в котором участвует их предприятие.
Не ждите от описаний жизненного цикла органиграмм (схем распределения
ответственности и полномочий: кто кому подчиняется, «оргструктура»).
Органиграмма — это модульная диаграмма оргзвеньев организации, статическая
структура. Жизненный цикл же — это поведение систем обеспечения, поэтому он
представляется развёртками во времени: диаграммой работ-стадий как модулей в
физическом времени, функциональной диаграммой связи практик в логическом
времени, архитектурными диаграммами с показом принципов назначения работ на
практики. При обсуждении жизненного цикла (практики управления жизненным
циклом) вопрос «кто это выполняет» обычно остаётся за рамками обсуждения,
назначение ресурсов поднимается только при обсуждении управления
работами/операционного управления.
Физическое время при разговоре о жизненном цикле тоже лучше смотреть на
диаграммах управления работами (планы-графики в системах проектного
управления, штампы времени в выдачах трекеров) соответствующих проектов, а не
на диаграммах жизненного цикла.
А если посмотреть на постепенный переход на платформенный способ организации
продуктных линий (product lines, иногда product families, когда из стандартных
модулей собираются разные конфигурации системы для разных потребностей, и это
происходит на нескольких платформенных уровнях), жизненные циклы разных
платформ как частей системы могут быть переплетены причудливым образом.
Нужно всегда помнить, что системы определяются субъективно, в зависимости от
деятельностного/стейкхолдерского интереса, и тем самым определение жизненного
цикла системы тоже субъективно.
Различные классификации жизненных циклов (в том числе по видам/моделям
жизненных циклов) тоже не жёсткие, нужно учитывать вероятностную логику
отнесения к классам. Более того, вид/модель жизненного цикла может потихоньку
меняться по мере его прохождения: заменяться отдельные инженерные практики,
практики менеджмента, в том числе даже практики управления работами, практики
предпринимательства. Поэтому нужно всегда помнить, кто (какая проектная роль)
говорит о жизненном цикле, для чего был затеян разговор, какие практики
управления жизненным циклом и управления работами доступны для
использования в проекте, какое место жизненного цикла проекта в жизненном
цикле системы, какие вероятности того, что жизненный цикл системы будет
проходить не так, как ожидается командой проекта.
Обязательно определите жизненный цикл не только вашей системы, но и
надсистемы. У систем в обеспечении тоже есть свои жизненные циклы, их ведь тоже
создают — часто те же люди, которые составляют их части в ходе работы над
целевой системой, но играющие при этом организационные проектные роли
(лидера, архитектора организации и т.д.).
Вот это одновременное удержание внимания на жизненном цикле всей системы в
первую очередь (поведение окружения какой-то системы обеспечения, в которой
 281

вы находитесь) и жизненном цикле проекта (поведение самой системы

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

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

Диаграмма системной схемы проекта
Стандарт OMG Essence221 предложил набор семи основных (essence,
существенный, основной) альф проекта программной инженерии. Мы немного
доработали этот набор альф для более общего случая системной инженерии 222, где
информационные/программные системы только один из многочисленных видов
разрабатываемых систем. Эти альфы объединены в системную схему проекта:

221
http://www.omg.org/spec/Essence/
222
Towards a Systems Engineering Essence, http://arxiv.org/abs/1502.00121, опубликовано в краткой форме
также в Software Engineering in the Systems Context, https://www.amazon.com/Software-Engineering-Systems-
Context-Jacobson/dp/1848901763
 282

Оригинальный набор альф был получен путём экспериментального ответа на

вопрос: какие объекты внимания команды присутствуют в каждом проекте
разработки? Было рассмотрено более 250 программистских проектов, и в системную
схему попали только те из них, которые встречались буквально в каждом проекте.
Основных альф проекта оказалось семь: возможности, внешние проектные роли,
описание системы, воплощение системы, работы, метод и команда. Эти альфы все
тесно связаны отношениями, на диаграмме показаны отнюдь не все отношения —
это просто напоминание о том, что связей много, и причины и следствия в проекте
(как и в любой системе) могут быть существенно разнесены во времени и
пространстве. Да и самих альф в проекте много больше: это только альфы самого
высокого уровня, основные/essence, а у них есть многочисленные подальфы, о
которых подробней будет рассказано позже.

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

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

классической практике проектного управления/project management как его

определяют в ассоциациях проектного управления Project Management Institute
(PMI)223, PRINCE2224 или аналогичных. Проектом тем самым будет назван и кейс
починки протекающего унитаза в офисе, и программистский трёхмесячник по
методу SCRUM225 в котором вообще не строилось диаграммы Гантта (зато с выдачей
через месяц после начала минимального жизнеспособного продукта/MVP, ещё
через пару недель второй версии этого MVP и затем ещё через неделю крутым
виражом/pivot с полной перепиской продукта), и даже какая-нибудь певица у
какого-нибудь продюсера (при этом сама певица-исполнитель в "проекте" может
быть легко заменена одна на другую без переименования проекта). И даже
программы из классического проектного управления (то есть множество
классических проектов, которые порождаются по мере осознания в них
необходимости) тоже сегодня часто называют «проектом».
Иногда даже вместо «проектного управления» говорят просто об «управлении
работами» и «управлении задачами», чтобы не путать с проектным управлением в
его классическом виде. Но это будет «управление работами в проектах» и
«управление задачами в проектах», при этом слово «проект» будет означать просто
некоторую работу оргзвена по достижению какой-то цели.
Ещё в русском языке есть разница между проект/design и проект/project, это тоже
нужно учитывать. Обычно продукт — это целевая система в её окружении, а
проект/project — система в обеспечении. Если это проект/design, то
продукт — воплощение системы, а проект/design её описание (system
definition).
Тем самым, говоря о системной схеме проекта, мы имеем ввиду прежде всего схему
объектов внимания (альфы), которые нужно учитывать в проекте как деятельности
какого-то оргзвена независимо от выбранного метода управления работами.

Предпринимательская, инженерная, менеджерская области интересов

Три области интересов (area of concerns) группируют семь основных альф
проекта по трём темам интересов. Помним, что ролевой интерес — это тема
озабоченности роли, а не «чего роли хочется достичь». «Чего хочется» это будет
не сам интерес, а предпочтения разных проектных ролей — в одном интересе роли
могут двигать его характеристики в разные стороны. Если укрупнить все темы-
интересы, то получатся три важнейших темы, соответствующие трём сферам
человеческой деятельности: предпринимательской, инженерной и менеджерской:
• Предпринимательская область интересов относится к надсистеме. В ней
показано, что внешние проектные роли дают возможность выполнить
проект. Предпринимательская область интересов разворачивается вокруг
надсистемы (ближнего окружения) прежде всего, в ней речь идёт прежде
всего о потребностях проектных ролей, надсистема — это подальфа
возможности. Приёмка — это про удовлетворение потребностей, деньги
проекту платят за это. В команде проекта альфами возможности и внешних
ролей проекта с их многочисленными подальфами в связи со всеми
остальными альфами и подальфами проекта занимаются предприниматели

223
https://www.pmi.org/
224
https://www.prince2.com/
225
https://ru.wikipedia.org/wiki/SCRUM
 284

(стратеги, специалисты по продвижению и т.д.). Из инженеров — прежде

всего инженер по требованиям, ему нужны потребности, чтобы
сформулировать требования. Если не отслеживать в ходе всего проекта
альфы предпринимательской зоны интересов, то результаты проекта могут
оказаться никому не нужными — возможность выполнения проекта может
исчезнуть в любой момент времени проекта, внешние проектные роли в
любой момент могут перестать поддерживать команду проекта и
материально, и административно.
• Инженерная область интересов относится к альфам описания и
воплощения целевой системы. Это то, чем в команде проекта будут
заниматься самые разные инженеры, создающие сначала описание системы
(требования, архитектуру, неархитектурную часть проекта/design)чтобы
уменьшить число проб и ошибок за счёт моделирования — дешёвой по
времени и усилиям проверки моделей, а не дорогой и долгой проверки
воплощения системы в физическом мире), а затем изготавливающие
удовлетворяющее этому определению системы воплощение. Внешние
проектные роли используют воплощение целевой системы в
надсистеме/окружении, удовлетворяя тем самым свои потребности. Ведущие
практики работы этими альфами — инженерные, занимаются этими альфами
главным образом инженеры в рамках инженерной сферы деятельности.
• Менеджерская область интересов относится к организации команды
(оргзвена, выполняющего проект), работам и методу работ (метод — это
набор практик, достаточный для выполнения целей проекта). В проекте
нужно управлять работами, управлять жизненным циклом (определять
метод: практики и способы назначения работ на практики), разворачивать и
использовать технологии метода, поддерживать сотрудничество
компетентной команды. Альфой работы занимаются операционные
менеджеры, используя практики управления работами/операционного
управления. CTO/CIO (chief technology/information officer, в современном мире
«станочный парк» стал во многом «парком» корпоративных информационных
систем, и «главный инженер» и «главный айтишник» это одно и то же по их
задачам) занимаются альфой метода, то есть совокупностью практик
жизненного цикла. Организатор, организационный менеджер, управляющий
талантами (найм компетентных сотрудников), лидер — все эти (и многие
другие) роли занимаются командой на предмет её появления, организации и
налаживания сотрудничества. Это всё практики сферы деятельности
инженерного и организационного менеджмента.
Какая альфа главная на системной схеме проекта? С одной стороны, все альфы —
отслеживать изменения в проекте нужно всех альф, ни одной не забывать! Но с
другой стороны — альфа воплощения системы, привязывающая все рассуждения по
схеме к физической реальности, задаёт адекватность. Воплощение системы —
главная альфа, именно привязка всех остальных альф к ней помогает избегать
оторванных от физической реальности рассуждений, которые могут оказаться
фантазиями.
Главность воплощения системы видна в том числе и по числу связей на диаграмме.
У воплощения системы на диаграмме оставлено максимальное число связей: оно
даёт возможности, его используют внешние проектные роли (им для включения в
состав надсистемы нужно воплощение системы, это только членам команды бывает
 285

нужно определение системы, но только для того, чтобы с меньшим количеством

проб и ошибок получить воплощение системы), его в конечном итоге и
создаёт/производит команда. Воплощение системы — это и есть целевая система в
её физическом виде.

V-диаграмма и системная схема проекта

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

Эта схема также в явном виде цитирует V-диаграмму, показывая те альфы, с

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

брать «откуда хочется», «разрабатывать», «придумывать». При их

выявлении/discovering фокус внимания инженеров задается потребностями
внешних проектных ролей. Описываемая требованиями целевая система должна
решать какую-то проблему надсистемы, то есть проблему внешних проектных
ролей, занимающихся надсистемой.
То же относится к системной архитектуре: она разрабатывается не любая, но её
разработка сфокусирована на поддержке требований: архитектура указывает на то,
каким образом из частей системы получатся требуемые эмерджентные свойства
целевой системы.
И рабочее описание (non-architectural part of design, неархитектурная часть
проекта/design, «рабочка») берётся не любое, её появление фокусируется
архитектурой. Часто в инженерной документации (документы, отражающие
состояния всех альф описания системы) требуют явно указать, какая архитектура
вызвала те или иные инженерные решения в рабочих описаниях, какие требования
вызвали те или иные архитектурные решения, какие потребности заставили
сформулировать те или иные требования. Явное описание (то есть
документирование, приведение к явному/видимому виду на носителе информации)
этих связей фокусировки называют трассировкой (trace). Трассировка помогает
избежать типовых ошибок фокусирования, когда в проекте появляются лишние
требования, или наоборот, недостаточно требований — какая-то потребность не
ведёт ни к каким требованиям.
Члены команды выполняют практики метода своей работы (практики обеспечения
жизненного цикла целевой системы), работая с альфами и подальфами проекта,
продвигая их по состояниям к завершению проекта. Скажем, требования
продвигаются по состояниям замышлены, ограничены, непротиворечивы,
приемлемы, отвечены, удовлетворены.
В приведённом варианте V-диаграммы возможность, описание/definition системы,
внешние проектные роли/stakeholders и воплощение/realization системы — это
просто основные альфы из системной схемы проекта (причём не все, ибо
используем прожекторный подход, когда рисуется на диаграмме не всё, что
известно, а только важное для данной диаграммы), а все другие альфы к ним
пририсованы как подальфы.
Стрелочки на диаграмме выбраны с ромбиками на конце, обычно они означают
отношение «часть-целое», но тут ими обозначено отношение подальфы (если
подальфа продвигается в своём состоянии, то это означает, что и её альфа как-то
продвигается в своём состоянии).
Форма V-диаграммы позволяет легко обсуждать в системной схеме проекта разницу
между проверками (verification, проверка соответствия описания и воплощения
системы) и приёмкой (validation, испытание надсистемы на то, что она
удовлетворяет потребностям, работая с включённой в её состав целевой системой,
тем самым реализуя возможность проекта). На системной схеме проекта эта
разница наглядна.

Альфы — общий объект отслеживания команды

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

оргзвеньев) операционный менеджер управляет работами (занимается альфой

работа), системный инженер занимается требованиями и архитектурой (занимается
подальфами описания системы). Но это поверхностное впечатление. Системная
схема проекта подразумевает, что все члены команды занимаются всеми альфами
проекта, а не каждый только своей. И члены команды договариваются о своих
действиях по поводу этих альф. Например, можно взять подальфу требований,
проходящую в ходе проекта какие-то свои состояния (берём их по OMG Essence):
• Замышлены (conceived, проектные роли согласились в необходимости новой
системы для удовлетворения потребностей)
• Ограничены (bounded, назначение новой системы понятно)
• Непротиворечивы (coherent, требования непротиворечиво описывают
существенные характеристики новой системы)
• Приемлемы (acceptable, требования описывают систему, которая приемлема
для проектных ролей)
• Отвечены (addressed, достаточно требований были отвечены воплощением
системы так, чтобы это было принято проектными ролями)
• Удовлетворены (fulfilled, требования полностью отвечают потребностям)
Можно выразить взаимодействие проектных ролей по поводу требований такой
схемой:

Системного инженера интересует прежде всего целевая система, но он также может

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

роль системного инженера, не разбитую на подроли, которые играют разные

исполнители) интерес к описанию системы, т.е. содержанию требований.
Предпринимателя интересуют внешние проектные роли и возможность (он должен
найти достаточное число платёжеспособных людей с потребностями, которые
можно удовлетворить — «рынок». Тогда он сможет привести инвесторов, которые
дадут начальный капитал). И поэтому его интересует трассировка требований на
потребности внешних проектных ролей, он контролирует сфокусированность
инженерной команды.
Операционного менеджера/руководителя проекта интересует система в
обеспечении, его оргзвено. Для инженерии требований ему нужно выделить время
и ресурсы исполнителей.
CTO и CIO — это близкие позиции: «станочный парк» сегодня часто соответствует
«парку корпоративных информационных систем». CTO и CIO интересуют практики
инженерии требований, в том числе поддержка какой-то выбранной дисциплины
инженерии требований каким-то моделером требований, системой управления
требованиями.
Получается, что все основные роли в команде работают с альфой требований: кто-
то меняет состояние этой альфы, кто-то выделяет на это изменение ресурсы и
планирует время, кто-то обеспечивает практики изменения состояния
технологиями, кто-то озабочен доступностью внешних проектных ролей для
ведения с ними переговоров по выявлению потребностей. И всё это для того, чтобы
изменения альфы требований, стали возможными, и тем самым продвинулось и
описание системы в целом (то есть ещё архитектура и «рабочка»).
Примерно то же самое происходит и со всеми остальными альфами и подальфами:
состояния всех из них изменяются командой не порознь, а в тесной взаимосвязи.
Команда совместно обсуждает текущее состояние альф и подальф
проекта и на основе этого обсуждения планирует шаги (работы) по
достижению следующих состояний.

Альфа возможности
Из V-диаграммы с подальфами хорошо видно, что потребности/требования
стейкхолдеров/проектных ролей это подальфы возможности, а не подальфы
описания системы.
Альфа возможности (opportunity) нужна для отслеживания в ходе проекта по
созданию/изменению целевой системы самой возможности его выполнения.
Целевая система будет разрабатываться, изготавливаться, эксплуатироваться
только в том случае, когда
• Она будет кому-то нужна, и за неё смогут заплатить — есть потребность,
неудовлетворимая без целевой системы.
• Её кто-то сможет сделать за разумную плату — есть команда, которая готова
сделать целевую систему.
Это ведёт к следующим возможным подальфам возможностей:
• Потребности внешних проектных ролей (нет потребностей — нет
возможности сделать проект, никто не заплатит).
• Оценка выгодности проекта в команде (финансовые расчёты, которые
 289

зависят в том числе и от уже имеющейся загрузки ресурсов — учитывается

маржинальная прибыль226). За проект внешние проектные роли должны
заплатить команде/внутренним ролям достаточно, чтобы он был команде
выгоден.
• Инновации, как освоенные новые технологии (часто в составе новых
практик). Они косвенно также связаны с оценкой выгодности: работы по
старым практикам обычно будут дороже, если только клиент не
заинтересован по каким-то причинам переплачивать лишнее именно за
использование старых практик. Часто оказывается, что для выгодной работы
по проекту нужно освоить если не какую-то новую практику (т.е. новую
дисциплину и поддержать её новой технологией), то хотя бы какую-то новую
технологию, иначе издержки по проекту будут выше, чем издержки
конкурентов, которые уже эту практику или технологию освоили — и заказ
на систему уйдёт к конкурентам.
Альфа возможности важная альфа (нет возможности проекта — команда не должна
его делать, даже если очень хочется), но инженеры и операционные менеджеры
часто о ней забывают после заключения контракта, она интересует
предпринимателей, но те тоже склонны больше заниматься внешними проектными
ролями и их потребностями, чем балансировать эти потребности с
оргвозможностями/capabilities команды эти потребности удовлетворить.
Информация о том, сколько стейкхолдеры готовы отдать за целевую систему или
предоставление сервиса, обычно доступна на самом старте проекта (хотя и не
всегда: если речь идёт о выпуске продукта на массовый рынок, то с
ценообразованием можно крупно промахнуться — информация о цене покупки
может оказаться неверной). Но вот информация о том, сколько реально будет
стоить система, включая её разработку, изготовление, наладку, испытания — вот
эта информация будет меняться в ходе всего проекта. Поэтому команде нужно
постоянно следить не только за подальфой потребностей, но и за подальфами
оценок выгодности.
Состояние альфы возможности может характеризоваться самыми разными
документами: «бизнес-планом», «концепцией», «обоснованием
инвестиций/инвестиционным меморандумом», «бюджетом проекта», «рыночным
исследованием», «проектным предложением» и т.п.
Возможность выполнить проект — это предпринимательская возможность, она
слабоформализуема и прежде всего связана со способностью предугадать будущее.
Альфа возможности в ходе проекта проходит следующие состояния/контрольные
точки (даётся в варианте OMG Essence, в формулировках в том числе
подчёркивается связь состояния этой альфы с состояниями других альф)227:
• Выявлена (identified): найдена идея; найдена как минимум одна проектная
роль, желающая сделать инвестицию в понимание возможности; определены
другие проектные роли.

226
https://ru.wikipedia.org/wiki/Маржинальная_прибыль
227
Формулировки условий прохождения контрольных точек даны по мотивам упрощённой версии
стандарта Essence, представленной в карточках состояния альф фирмы Ivar Jacobson International,
https://www.ivarjacobson.com/publications/tools/alpha-state-cards-pdf-version, кроме альф определения и
воплощения системы.
 290

• Нужно решение (solution needed): выявлено инженерное и/или культурное

решение; установлены потребности; определены проблемы и их причины,
подтверждено, что внешним проектным ролям это решение нужно; было
предложено как минимум одно архитектурное решение.
• Польза установлена (value established): польза возможности была определена
количественно; влияние решения на внешние проектные роли понятно;
польза системы внешними проектными ролями понимается; критерии
успешности ясны; результаты ясны и выражены количественно.
• Жизнеспособна (viable): инженерное решение обрисовано в общих чертах;
решение возможно с учётом ограничений; риски приемлемы и управляемы;
решение выгодно; причины для разработки решения понимаются; ясно, что
реализация возможности жизнеспособна.
• Реализована (addressed): возможность реализована; решение достойно
воплощения; внешние проектные роли удовлетворены;
• Извлекается выгода (benefit accrued): решение приносит выгоду; возврат на
инвестиции приемлем.

Альфа внешних проектных ролей

В системной схеме проекта альфа внешних проектных ролей/стейкхолдеров
относится к тем проектным ролям, для которых надсистема проекта является их
целевой. Команда (внутренние проектные роли) представлена отдельной альфой.
Внешние проектные роли дают возможность выполнения проекта, они его
оплачивают. Ими определяется и успешность целевой системы, ибо целевая
система — это та, в которой учтены их ролевые предпочтения в интересах.
Проектные роли могут играться ролевыми группами (например, 30 тыс.
пользователей программного приложения с 30 тыс. продаж, или 1 тыс. зрителей
спортивного поединка), каждая из групп может быть представлена каким-то
«образцом проектной роли», или даже членом команды (например, отвечающим за
продвижение/маркетинг), ответственным за представление интересов и
отстаивание перед командой и другими внешними проектными ролями
предпочтений в интересах этих проектных стейкхолдеров.
Хорошей практикой является сразу разделение альфы «внешние проектные роли»
на отдельные подальфы индивидуальных проектных ролей и раздельный учёт
состояния каждой из этих подальф.
Вот состояния/контрольные точки для внешних проектных ролей:
• Признаны (recognized): групповые проектные роли выявлены; ключевые
группы проектных ролей/стейкхолдеров представлены; ответственности
представителей/исполнителей проектных ролей определены.
• Представлены (represented): исполнители проектных ролей согласились с
ответственностью; представители проектных ролей получили полномочия;
подход к сотрудничеству согласован; практики работы поддерживаются и
уважаются.
• Вовлечены (involved):представители/исполнители проектных ролей
помогают команде; реагирование представителей на запросы своевременно
и они предлагают решения; изменения сообщаются вовремя.
 291

• В согласии (in agreement): минимальные ожидания/предпочтения

согласованы; представители/исполнители проектных ролей довольны своим
вовлечением; вклад проектных ролей приносит пользу; вклад команды
приносит пользу; приоритеты ясны и перспективы команды и внешних
проектных ролей сбалансированы.
• Удовлетворены для разворачивания (satisfied for deployment): имеется
отклик/feedback от проектных ролей; система готова для разворачивания в
месте её эксплуатации.
• Удовлетворены в использовании (satisfied in use): отклик/feedback по
использованию/эксплуатации системы доступен; система отвечает
ожиданиям/предпочтениям.
Проектные роли совпадают с актёрами (конкретными людьми, которые исполняют
эти роли) в тот момент, когда они играются. Люди-актёры могут играть в проекте
несколько ролей. Ведущая практика, которая катализирует сотрудничество актёров
такое, что они начинают хорошо играть свои проектные роли — лидерство. Команда
должна обеспечить лидерство не только для налаживания сотрудничества внутри
себя, но и с необходимыми представителями/исполнителями внешних проектных
ролей, чтобы играющие эти роли внешние по отношению к команде люди были
вовлечены в проект и оказывали содействие в продвижении альф проекта по их
состояниям.

Альфа описания системы

Описание системы наряду с воплощением системы относится к инженерной области
интересов. Как самостоятельная альфа описания системы осмыслена только в
самых общих разговорах по проекту, для реального отслеживания дел с описанием
системы нужно сразу разбивать ее на подальфы. Для разных типов систем
подальфы описания системы называются по-разному. Например, что для
информационных и «железных» системы «требования», для предприятия может
называться «стратегией», а для спортивного события «правилами».
В оригинальном OMG Essence в числе основных альф нет описания системы в целом,
но зато есть альфа «требования» как часть описания. Доработанный для системной
инженерии вариант включает в себя все подальфы описания системы — и
требования, и архитектуру, и неархитектурную часть проекта/design («рабочку»).
Обратите внимание, что потребности относятся не к описанию системы, а к
возможностям, ибо описывают надсистему. Требования и потребности нужно
различать, проверку относят к требованиям, но приёмку ведут по удовлетворению
потребностей.
Вот очень обобщённый пример набора состояний альфы описания для «железной»
системы, для других видов систем рекомендуется адаптировать эти состояния:
• Замыслено (concieved): внешние проектные роли и команда согласны, что
система будет сделана; методы описания системы согласованы; способ
согласования описаний с внешними проектными ролями согласован;
механизмы управления конфигурацией документации согласованы.
• Непротиворечиво (coherent): описания системы документированы, и
документация доступна команде и стейкхолдерам; происхождение описаний
ясно; описания проверяются; противоречивые описания выявлены и ими
 292

занимаются; команда понимает описания и соглашается их воплотить;

соответствующая описаниям система принимается внешними проектными
ролями как заслуживающая воплощения.
• Используется для изготовления (in use for manufacturing): изготавливающая
систему часть команды считает, что описаний хватает для начала
изготовления; технологии изготовления описаны и документированы;
возникающие при изготовлении системы проблемы приводят к доработке и
актуализации описаний системы.
• Используется для проверки и приёмки воплощения (in use for V&V): есть все
описания, нужные для проверки и приёмки; испытания, критерии их
успешности и способ проведения определены; внешние проектные роли
согласны с объёмом испытаний.
• Используется для эксплуатации (in use for operations): описание системы
используется для сбора информации о состоянии эксплуатируемого
воплощения системы (цифровой двойник, digital twin); описание системы
наряду с информацией цифрового двойника используется для принятия
решений о техобслуживании, ремонтах, модернизации.
• Используется для вывода из эксплуатации (in use for retirement):
используется для определения момента вывода из эксплуатации или
принятии решения о продлении эксплуатации; демонстрирует отсутствие
вредных эффектов (например, загрязнения окружающей среды) при выводе
из эксплуатации; используется для планирования и проведения работ по
уничтожению и/или переработке воплощения системы.
Приведённые выше состояния альфы описания системы являются настолько
общими, что для реального проекта должны быть конкретизированы для
актуального вида жизненного цикла. Например, предлагаемый набор состояний для
описания системы совершенно сознательно не формулируются как водопадная
«логическая» последовательность «готовы потребности», «готовы требования»,
«готова архитектура» и т.д. Более того, возможны подальфы описания системы,
выделенные по частям или версиям системы (например, «описания первого
прототипа», «описание минимально жизнеспособного продукта»), а не по типу
описаний («требования», «архитектура», «неархитектурная часть проекта/design с
подробностью, достаточной для изготовления»).

Альфа воплощения системы

Альфа воплощения системы ещё более разнообразна: состояния воплощения
системы будут абсолютно разные для атомной электростанции, мобильного
приложения, танца, стартапа. Вот пример очень общего списка состояний
(определяемых событиями достижения их контрольных точек) для «железной»
системы, но его нужно тщательно перерабатывать для каждого отдельного вида
систем:
• В виде сырья (as a raw material): материалы для воплощения системы
наличествуют и позволяют создать части системы с нужными
характеристиками; оборудование для переработки материалов в детали
наличествует; график производства и логистики частей системы согласован;
возможны работы по изготовлению частей системы.
 293

• В виде частей (as a parts): части воплощения системы созданы и/или

закуплены и проверены; график интеграции/сборки/монтажа/строительства
из частей согласован; возможны работы по
интеграции/сборке/монтажу/строительству.
• Демонстрируемо (demonstrable): воплощение системы может быть
опробовано в отдельных функциях и ключевые характеристики могут быть
измерены; ключевые характеристики могут быть продемонстрированы
внешним проектным ролям; критические интерфейсы системы были
продемонстрированы; система готова к проверке; необходимые внешние
проектные роли согласны, что систему нужно проверять.
• Готово (ready): функциональность протестирована; уровни дефектов для
внешних проектных ролей приемлемы; установочная и другая
пользовательская и операторская документация доступна;
представители/исполнители внешних проектных ролей удовлетворены
системой; состав передаваемой системы известен;
представители/исполнители внешних проектных ролей готовы
эксплуатировать систему; эксплуатационная поддержка наличествует.
• Эксплуатируется (operational): доступна внешним проектным ролям для
эксплуатации в рабочем окружении; есть как минимум один пример
работающей системы; поддерживается на согласованном уровне сервиса.
• Выведено из эксплуатации (retired): Воплощение системы было заменено или
прекращено в использовании; система больше не поддерживается; нет
«официальных» внешних проектных ролей, которые до сих пор используют
систему; доработки/доделки системы больше не будут производиться; все
материальные компоненты системы либо повторно используются, либо
надлежащим образом уничтожены.

Альфа работы
В каждом проекте есть работы, которые необходимо выполнить для того, чтобы в
конечном итоге целевая система была создана и успешна. Этой альфой занимается
главным образом практика управления работами. Вот пример
состояний/контрольных точек альфы работ (даётся по OMG Essence):
• Инициирована (initiated): требуемый результат работ ясен; ограничения
ясны; известна проектная роль, которая платит за работы; инициатор
выявлен; принимающие работу проектные роли известны; источник денег
ясен; приоритеты ясны.
• Подготовлена (prepared): обязательства приняты; цена и потребные усилия
оценены; доступность ресурсов понимается; правила и процедуры контроля
ясны; критерии приёмки определены и согласованы; работы разбиты на
части в достаточной для начала работ мере; задачи (tasks) определены,
приоритеты для них расставляются; наличествует правдоподобный план;
финансирование работ наличествует; как минимум, один человек из команды
готов начать работу; моменты интеграции результатов работы определены.
• Начата (started): работа по разработке начата; прогресс работы
отслеживается; работа разбита на единицы действий с ясными
определениями того, что нужно сделать; члены команды принимают и
 294

выполняют задания.
• Под контролем (under control): количество завершённых задач растёт;
незапланированная работа под контролем; риски под контролем; оценки
пересматриваются, чтобы отражать реальную производительность команды;
прогресс измеряется; переделки под контролем; обещания выполнения работ
выполняются.
• Закончена (concluded): остались только административные задачи; результат
работ был достигнут; внешние проектные роли приняли результирующую
систему.
• Закрыта (closed): метрики были сделаны доступными для других проектов;
всё было заархивировано; бюджет был сверен и закрыт; команда была
освобождена; нет незавершённых недоделанных задач.

Альфа команды
Альфа команда представляет собой тех сотрудников, которые охотно и качественно
выполняют внутренние проектные роли. Ведущие дисциплины тут — управление
персоналом (human resources management), управление талантами (talent
management, занимающиеся обеспечением организации сотрудниками-актёрами и
их подготовкой к выполнению внутренних проектных ролей в командах проектов,
практика лидерства (leadership), занимающаяся обеспечением сотрудничества в
команде, т.е. качественного отыгрывания проектных ролей и продуктивного
взаимодействия с другими членами команды (ср. «режиссура» в театральной
метафоре) и дополнительная к ней практика «ролевого мастерства» («актёрское
мастерство» в театральной метафоре: актёра учат быстро входить в роль,
качественно её отыгрывать и выходить из роли).
Естественные подальфы — «командная роль» (внутренняя проектная роль,
определяет необходимые компетенции члена команды в выполнении необходимых
практик), «сотрудник» (носитель командных ролей), «оргзвено» (исполнитель
командной роли, вместе с вверенным ему оборудованием, обладающий какими-то
правами и обязанностями по распоряжению частью труда и капитала предприятия).
Для команды важно существование команды как целого, это не просто набор
занимающих какие-то места в штатном расписании актёров, которые выполняют
время от времени работы согласно своим компетенциям. Вот
состояния/контрольные точки, по которым отслеживают успешность изменений
альфы команды в ходе проекта по созданию системы:
• Намечена (seeded): миссия/рабочее задание команды определено;
ограничения известны и явны; механизмы роста команды наличествуют;
состав команды определён; обязанности команды обрисованы в общих
чертах; уровень принятых командой обязательств ясен; требуемые
компетенции определены; размер команды определён; правила надзора за
деятельностью определены; вид/форма лидерства выбрана.
• Сформирована (formed): Было набрано достаточное число членов команды;
роли в команде понимаются её членами; все понимают, как работать; члены
команды узнают друг друга при встрече; члены команды понимают
индивидуальные обязанности и как они увязаны с их компетенциями; члены
команды принимают работу; внешние смежники (организации, команды и
отдельные люди) определены; механизмы общения в команде определены;
 295

каждый член команды принял обязательство работать так, как это принято в
команде.
• Сотрудничает (collaborating): команда работает как одно сплочённое
оргзвено; общение в команде открытое и честное; команда сфокусирована
на достижение миссии/задания команды; члены команды знают друг друга.
• Производит (performing): команда постоянно выполняет обязательства;
команда непрерывно адаптируется к изменяющемуся контексту; команда
определяет и решает проблемы без внешней помощи; минимум возвращений
к сделанному и переделок; работа впустую (waste) и причины для работы
впустую постоянно устраняются.
• Распущена (adjourned): обязанности были выполнены; члены команды
доступны для участия в других командах; миссия завершена.

Альфа метод
В оригинальном стандарте OMG Essence речь идёт об альфе way of working (способ
проведения работ), а мы передаём это как метод/методология — набор
практик, необходимый для выполнения работ проекта «под ключ». В
практиках дисциплина грузится в головы исполнителей работ, её нужно искать в
компетенциях команды, в человеческом капитале. И сама практика называется по
имени своей дисциплины (проще всего думать о практике как о поведении,
описанном в каком-то учебнике «как делать то-то», например, «как вести
переговоры» или «как управлять проектом» для практики переговоров и практики
управления проектами).
Ещё различают начальное состояние «практики где-то там» (то, что обычно делают
люди) и конечное состояние «доступной для использования в работах практики тут
у нас». Для этого случая есть термин оргвозможности/capability, как поставленная
практика и полномочия по её применению. Поставленная практика — это
имеющиеся в команде/оргзвене обученные дисциплине люди и развёрнутые
инструменты, на которых эти люди умеют работать). Полномочия и обязанности всё
это использовать в проекте — это «организационная/политическая воля», без этого
ресурсы могут наличествовать, но не будут задействованы, ибо «мы пока так не
работаем». Для работы по-новому обычно должно быть отдельное распоряжение.
Говорить сразу о всех практиках (как и о стейкхолдерах) не получится — поэтому
лучше всего будет отслеживать в проекте связанные с технологиями подальфы
отдельных практик/способов работы, а то и дробить их дальше на подальфы
компетенций (существенно связанных с альфой «команда» — компетенции тут у
членов команды), инструментов и отдельных артефактов/рабочих продуктов
(помним, что артефакты/рабочие продукты отнюдь не всегда «документы»,
воплощения систем у нас не сводятся к описаниями! Они в физическом мире!).
Вот состояния/контрольные точки основной альфы «метод»:
• Дисциплины установлены (principles established): команда активно
поддерживает дисциплину/теорию/принципы; внешние проектные роли
согласны с принципами; потребные для их поддержки инструменты
согласованы; рекомендации по выбранному подходу доступны; рабочий
контекст понимается; ограничения практик и выбранных в их составе
инструментов известны.
 296

• Основа положена (foundation established): ключевые практики метода и их

инструменты выбраны; практики, необходимые для того, чтобы начать
работу, согласованы; практики, по которым не будет обсуждений и их
инструменты выявлены; разрыв между доступными и необходимыми
оргвозможностями/capability определён; способ работы, в котором все
практики удобно использовать, определён.
• Используется (in use):
практики и их инструменты используются;
использование практик и их инструментов регулярно проверяется; практики
и их инструменты адаптированы к контексту; практики и их инструменты
поддерживаются командой; механизмы получения откликов/feedback на
практики и их инструменты работают; практики и их инструменты
поддерживают общение команды и сотрудничество.
• Наличествует (in place): практики и их инструменты используются всей
командой; оргвозможности доступны всей команде; проверяются и
адаптируются всей командой.
• Работает хорошо (working well): делается предсказуемый прогресс; практики
применяются естественным образом; инструменты естественным образом
поддерживают принятую дисциплину работы; идёт постоянное
совершенствование/подстройки.
• Вышел из употребления (retired):
больше не используется; уроки
использования практик метода опубликованы для использования в будущем.

За чем следить в проекте

Основное использование системной схемы проекта — в качестве чеклиста
(checklist, список контрольных вопросов), заставляющего подумать о том, о чём
можно забыть подумать.
Когда самолёты стали слишком большими для управления одним человеком, они
часто взрывались на взлёте из-за банальных ошибок: то с ручного тормоза не
снимут, то забудут проверить работу всех многочисленных двигателей перед
взлётом. Помогло введение чеклиста: чеклист заставлял подумать и проверить то,
что в спокойной обстановке все знают, что нужно делать, но в суматохе взлёта
иногда забывают действительно сделать, и это ведёт к фатальным
неприятностям228.
Системная схема проекта представляет собой ровно такой чеклист: на верхнем
уровне это альфы, которые необходимо удерживать во внимании всё время
проекта. Если члены команды не задумывались о состоянии какой-то из альф, то
возникают большие риски, что там что-то может пойти не так — просто потому, что
не хватило внимания. Проект создания системы обычно не менее сложен и
хлопотен, чем взлёт самолёта, поэтому можно ожидать отсутствия самых понятных
и простых работ — например, можно в суете проекта забыть наладить
коммуникацию с внешними ролями проекта/стейкхолдерами, или даже забыть
провести испытания по проверке и приёмке (особенно часто забывают испытания
по приёмке!) системы.
Контрольные точки/milestones каждой альфы (формулируются как вопросы
228
https://www.litres.ru/atul-gavande/chek-list-kak-izbezhat-glupyh-oshibok-veduschih-k-fatalnym-
posledstviyam/
 297

чеклиста, положительный ответ на которые означает достижение этой контрольной

точки) требуют выбора практик для их достижения, а затем выполнения работ по
их достижению.
Например, контрольная точка для альфы команда — «сотрудничает»
формулируется как пункт чеклиста «команда работает как одно сплочённое
оргзвено; общение в команде открытое и честное; команда сфокусирована на
достижение миссии/задания команды; члены команды знают друг друга».
Достижение этой контрольной точки требует выбора практики лидерства
(дисциплину из какого учебника лидерства будете применять для достижения этой
контрольной точки? Инструменты какого поставщика — в 21 веке ведь даже
лидерство поддерживается инструментально!). Затем нужно будет провести работы
(понять, кто и когда будет проводить эти работы — запланировать работы, а потом
выделить время и другие ресурсы, и провести эти работы — выполнение работы)
для выбранной практики.
Если команда не обсуждает достижение всех этих контрольных точек и не
выполняет работы по их достижению, то у проекта могут быть большие (в том числе
фатальные для проекта) неприятности.
Формулировки контрольных точек в OMG Essence (и, соответственно, в нашем
учебнике) намеренно «мутные», неопределённые и расплывчатые. Авторы
стандарта говорят, что это поощряет команду провести обсуждение этих
контрольных точек, чтобы адаптировать формулировки к индивидуальным
особенностям проекта, и получить явное соглашение команды о том, что все члены
команды одинаково понимают эти контрольные точки. Адаптация
(редактирование для учёта обстоятельств проекта) списка состояний
альф, равно как контрольных вопросов, определяющих их состояние,
обязательна! Без адаптации к конкретной предметной области проекта и
уровню опыта конкретной команды чеклисты альф использовать нельзя!
Тексты из учебника тут — только ориентир, предмет для начала обсуждений с
командой! Команда должна договориться, за чем следить в проекте и кто должен
уделять особое внимание каким альфам.
Всего семи основных альф как объектов внимания в проекте не будет хватать — тем
более в больших проектах. Поэтому команде необходимо уделять внимание не
только альфам, но и подальфам. Часто команда будет брать эти подальфы из
дисциплин/теорий/принципов принятых ими практик. Например, в практике
управления проектами методом критической цепи вводят альфу «буфер проекта»
(project buffer) и отслеживают затем её состояние — сначала этот буфер проекта
создаётся, потом потихоньку расходуется в ходе проекта. Стандарт OMG Essence
предлагает, чтобы все эти подальфы обязательно были подальфами либо основных
альф, либо друг друга (подальфы представляют собой направленный граф, в том
числе подальфа может быть подальфой сразу нескольких основных альф или других
подальф). Так, альфа «буфер проекта» может быть подальфой «работы». И ответ
на вопрос «в каком состоянии работы проекта?» может включать в себя отдельный
рассказ про состояние «буфера проекта».
В разговоре про альфы необязательно каждый раз произносить слово «альфа». Как
не говорят «система самолёт», «система чайник» (но добавляют слово «система»,
когда хотят подчеркнуть рассмотрение как системы), так в проекте не говорят
«альфа работа» и «альфа команда», но говорят «работа» и «команда» (а слово
 298

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

Состояния альфы и артефакты/рабочие продукты

Состояния альф можно узнать не сами по себе, «умозрительно», а посмотрев на
состояние связанных с ними артефактов/рабочих продуктов. С альфами происходит
мышление, с рабочими продуктами/артефактами (в том числе с документацией, но
и с воплощением системы непосредственно, и с инструментами поддержки
дисциплин) происходит работа. Конечно, для описания (view, набор моделей)
состояния альфы в рабочем продукте должен быть использован какой-то метод
описания (viewpoint, мета-модель и принципы создания модели, методические
указания по моделированию предметной области ролевого интереса/concern).
Поэтому в реальной обстановке обсуждение ведётся не только альф, но и рабочих
продуктов/артефактов (и в том числе документов).
Вот пример контрольных точек состояния «признаны» альфы «внешние проектные
роли», дополненное необходимыми видами описаний и их методов — это позволяет
перейти от чисто «устной» работы к документированию (письменному или
электронному — это всё равно). Моделирование по сравнению с чисто устной
работой «с голоса» имеет достоинства (возможность коллективной и независимой
проверки моделей, возможность помнить о деталях через долгое время после
обсуждений, моделирование только важного и т.п.) и недостатки (лишняя работа,
требующая времени — в простых случаях и при малом числе участников проекта
иногда ведь хватает и устных обсуждений с неформальными заметками), каждая
команда выбирает свой уровень документирования происходящего в проекте, это
тоже вопрос договорённостей в команде:
«Внешние проектные роли признаны»
Контрольные точки Пример рабочих продуктов Пример практик/методов
(views) описания (viewpoints)
Все различные группы «Длинный список» (long Таблица в Excel/Word с
внешних проектных ролей, list) внешних проектных ролями и описаниями
которые на данный ролей ролей (или описания
момент, или в будущем ролей даны где-то в
будут затронуты отдельном документе, и
разработкой и собран только список).
функционированием
инженерной системы,
определены.
Есть соглашение по Завизированный командой Отметка в «длинном
группам исполнителей «короткий список» списке» для ролей о
внешних проектных ролей, (shortlist) ролей, которые представлении и ссылка на
которые будут будут представлены явно наличие соглашения
представлены. Как какими-то исполнителями (завизированный
минимум, должны этих ролей (в CRM- протокол, подписанное
приниматься в расчёт системе, таблице внешних распоряжение и т.д.)
представители внешних проектных ролей, и т.д.)
ролей, которые
финансируют, используют,
поддерживают и
 299

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

Как работают с системной схемой проекта

Самое простое использование системной схемы проекта — это структурирование
отчёта о ходе проекта (progress-report). Нужно просто дать краткую
содержательную характеристику каждой альфе, не пропуская ни одной.
Пропущенная в характеристике альфа часто означает не то, что её состояние
плачевно и докладчик почему-то его хочет скрыть. Обычно «миром правит не
тайная ложа, а явная лажа», и причина пропуска в отчёте рассказа о состоянии
какой-то альфы означает, что просто про эту альфу давно не думали, её состояние
(включая её подальфы) давно не оценивалось, о необходимости осознанного и
структурированного внимания к ней просто забыли за какими-то другими делами. И
это означает, что самое время подумать, что с такой пропущенной альфой и её
подальфами происходит. Как с любыми чеклистами, в 9 случаях из десяти всё
оказывается в порядке, а в 1 случае это предотвращает неминуемую катастрофу.
Альфы системной схемы проекта полезны не только для того, чтобы делать отчёт о
ходе проекта, но и для того, чтобы давать полезный отклик по таким отчётам. Если
в отчёте не сказано ни слова про команду, то обязательно нужно задать вопросы —
в каком состоянии команда. Может выясниться много интересного (ключевые члены
команды надумали уходить, сотрудничества уже три дня как нет по разным
причинам, и т.д.). Эти вопросы по пропущенным в мышлении о проекте альфам не
будет случайными вопросами, альфы ведь эти выбраны не случайно, а отражают
опыт многочисленных разработок, обобщённый авторами стандарта OMG Essence.
Ещё один вариант использования системной схемы проекта — это понять, какие
 300

компетенции в команде проекта есть, а какие отсутствуют. Распечатайте системную

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

Подальфы
Подальфы и их состояния порождаются командой по потребности, когда команда
понимает, что уровня контроля не хватает, и нужно внимание к частям ситуации,
определяемой альфой. Подальфа — это просто альфа, только она не «верхнего
уровня», не основная (essence), не из системной схемы проекта. Более того, у
каждой альфы (в том числе у подальф) могут быть свои подальфы, а одна подальфа
может быть подальфой нескольких альф и подальф. Примеры этих подальф можно
брать в самом стандарте OMG Essence, можно брать в разнообразной литературе
(прежде всего тут нужно указать на разработки Ivar Jacobson International по
разработке альф для самых разных практик, особенно для гибких методологий 229).
Вот пример альфы «подрядчик» как подальфы «внешняя проектная роль» и
«команда». Это альфа была подготовлена для крупной компании, занимающейся
сооружением сложных инженерных объектов, отсюда и специфика её состояний.
Для других проектов и других компаний это были бы совсем другие состояния:
• Признан — обоснование аутсорсинга есть; требования и ограничения для
подсистемы есть; требования к гарантийному обслуживанию и ремонтным
работам есть; требования к технологиям работы есть; сроки поставки
определены; критерии приёмки результата есть; оценка возможной цены
есть.
• Выбран — технико-коммерческие предложения получены; переговоры с
кандидатами проведены; технико-коммерческие предложения оценены;
подрядчик нами выбран.
• Привлечён — валютные, сроков поставки, качества и прочие риски оценены;
договор с учтёнными рисками подписан; аванс перечислен; необходимая
документация для начала работ передана; уведомление о начале работ
получено; процедура коммуникации команды с исполнителями установлена.
• Работы идут — надзор за работами установлен; запросы обоих сторон
учитываются; запросы обоих сторон своевременно решаются; график работ
соблюдается; технология работ соответствует ожидаемой; коммуникация

229
https://practicelibrary.ivarjacobson.com/
 301

команды с исполнителем не прерывается.

• Работы приняты — уведомление об окончании работ получено; испытания
проведены; претензий к качеству работ нет (претензии сформулированы и
устранены); акты проведения успешных испытаний подписан; результаты
работ доставлены на место; документация передана; монтажные работы
произведены; пуско-наладочные работы проведены.
• Работы закрыты — акт приёмки-сдачи подписан; деньги перечислены;
никаких дел к подрядчику нет; гарантийные и сервисные работы
производятся; документация архивирована.
Регулярная проверка сделанного и не сделанного по такому чеклисту существенно
снижает риски. О рисках хорошо не думать до того момента, пока они не
реализуются. Но поскольку люди не компьютеры, один раз из десятка просто в силу
отвлечения внимания или надежды, что какую-то важную работу сделает кто-то
другой в команде, важная работа просто не делается. И обращение к чеклисту
может спасти ситуацию.
Как пользоваться постоянно раздувающимся списком подальф с их контрольными
вопросами для прохождения контрольных точек может помочь практика работы с
чеклистами, описанная в книге Атула Гаванде «Чеклист. Как избежать глупых
ошибок, ведущих к фатальным последствиям».230
По всем проблемам, обнаруженным в ходе рассмотрения состояния альф такого
отчёта, планируются решающие эти проблемы работы и им выделяются ресурсы в
соответствии с принятой практикой управления работами (например, для
документирования заданий на эти работы используется трекер, а для запуска в
работу практика канбан). Затем эти работы будут двигать состояния всех альф в их
взаимосвязи в направлении к успешному завершению проекта, а новые проблемы
будут своевременно выявляться опять же с применением системной схемы проекта.

Диаграмма основного жизненного цикла

Горбатая диаграмма, использовавшаяся в RUP, получила своё развитие: в более
современных версиях (например, из enterprise unified process, EUP, 2013)
приводится другой набор практик и другой (полный, а не только стадии разработки
и перехода к эксплуатации) набор стадий231:

Интересно, что и тут есть трудности — попытка изобразить те работы, какие

230
https://www.ozon.ru/context/detail/id/26845885/
231
http://enterpriseunifiedprocess.com/
 302

происходят до момента запуска проекта как последовательности стадий работ, но

в жизненный цикл системы попадает, хотя не попадает в формальный проект.
Стандарт OMG Essence предложил ещё один метод описания жизненного цикла,
удобный для отслеживания смены состояний основных альф. Это представление
похоже на «горбатую диаграмму», использовавшуюся в EUP, только вместо практик
там указаны задающие тематику работ основные/essential альфы (а практики
подразумеваются те, которые будут работать с этими альфами и их артефактами):

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

Разные модели жизненных циклов проекта (указание на то, когда начинаются

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

Как и любые диаграммы видов жизненного цикла, диаграммы OMG Essence —

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

Модели зрелости и модели готовности технологий

Иногда последовательность смены состояний альфы «метод» выделяют как
отдельную модель зрелости (maturity model). Модель зрелости иногда путают с
жизненным циклом практик, но чаще всего практика как дисциплина/теория в
головах и развёрнутая в предприятии технология уже есть, и речь идёт только о
том, чтобы эта внешняя по отношению к организации практика превратилась в
оргвозможность (capability) данной организации, то есть могла быть реально, а не
потенциально задействована в работах. Модель зрелости тем самым не жизненный
цикл того, как осваивают практику в части обучения дисциплине и разворачивания
технологии, а жизненный цикл применения практики.
Например, для ISO 15288 (стандарта практик жизненного цикла системной
инженерии) штатно предполагается использование модели зрелостей из ISO 1504
(стандарт проверки соответствия используемых в жизни практик описанным
международными стандартами «эталонов»). Соответствие предполагает некоторые
уровни, и вот эти уровни соответствия жизни стандарту и есть «модель зрелости»
(maturity model) в применении практик из стандарта практик жизненного цикла.
Модели зрелости часто изображаются в виде «ступенек», по которым нужно «идти
вверх»:
 305

Модели готовности технологий (technology readiness) затрагивают как раз

предыдущие по отношению стадиям модели зрелости группе стадий жизненного
цикла технологии: они посвящены эволюции/появлению технологий (при этом
дисциплины обычно стабильны, но готовность технологий для дисциплин в
практиках меняется).
Например, Technology Readiness Level, разработанная 35 лет назад для аэрокосмоса,
а затем распространившаяся в машиностроении и нефтегазовой промышленности,
где ступеньки-уровни для технологии ближе к классическому жизненному циклу в
варианте 1.0, только речь идёт именно об инструментарии, «технологии» 232:
• TRL 1. Сформулирована фундаментальная концепция технологии и
обоснование её полезности.
• TRL 2. Определены целевые области применения технологии и её
критические элементы.
• TRL 3. Получен макетный образец и продемонстрированы его ключевые
характеристики.
• TRL 4. Получен лабораторный образец, подготовлен лабораторный стенд,
проведены испытания базовых функций связи с другими элементами
системы.
• TRL 5. Изготовлен и испытан экспериментальный образец в реальном
масштабе по полупромышленной технологии, проведена эмуляция основных
внешних условий.
• TRL 6. Изготовлен полнофункциональный образец на пилотной
производственной линии, подтверждены рабочие характеристики в условиях,
приближенных к реальности.
• TRL 7. Прототип системы продемонстрирован в составе системы в реальных
условиях эксплуатации.
• TRL 8. Окончательное подтверждение работоспособности образца.
Разработка. функционирующей реальной системы завершена.
• TRL 9. Изделие удовлетворяет всем требованиям: инженерным,
производственным, эксплуатационным, по качеству и надёжности. Возможна
модификация по снижению себестоимости, развитию и эволюции системы.
Функционирующая реальная система подтверждена в ходе реальной

232
http://www.atominfo.ru/newsp/w0965.htm
 306

эксплуатации через успешное выполнение испытательных заданий.

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

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

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

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

корпоративные изменения/развитие и системное лидерство)

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

Итоговое эссе
Увы, решения задач по материалу учебника для освоения системного мышления не
хватает. Они нужны главным образом для того, чтобы хоть как-то запомнить
терминологию. Чтобы научиться применять системное мышление, мы рекомендуем
написать эссе по какому-то своему рабочему (не учебному! не выдуманному
"кейсу"!) проекту. Эссе (essay) предполагает сочинение в свободной форме на
 309

заданную тему, а его минимальное содержание задаётся описанием и

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

времени подготовки эссе. Удивительно, но даже после тщательной самопроверки в

представленном разбиении можно найти все описанные в учебнике ошибки —
начиная с того, что в разбиении есть абстрактные объекты (не имеющие места в
пространстве времени, т.е. описания), не выдерживается отношение часть-целое
(вместо отношения composition вдруг обнаруживаются отношения classification,
specialization, representation и множество других), нарушается принцип
почтальона — пропускается много системных уровней и делается суперобобщение,
разбиение делается не на момент стадии эксплуатации и т.п.
Попытайтесь всё-таки представить функциональное/системное разбиение, а не
модульное/продуктное (или пространственное, но пространственное разбиение в
эссе почему-то попадает редко — это большой бонус, если оно там будет).
Назовите вашу целевую систему по её основной, самой трудной в реализации и
наиболее полезной внешним проектным ролям функции (беда, если все эти три
функции не совпадают — «за восемью зайцами погонишься, ни одного не
поймаешь»). Если вы делаете сервис, то вам придётся ещё и описать создаваемую
для этого сервиса систему в обеспечении. Для случая парикмахерской вам придётся
описать и причёску как целевую систему, и её окружение, и сервис стрижки
(поведение парикмахерской по изменению целевой системы), и парикмахерскую,
которую вы делаете для создания причёски. Просто описать парикмахерскую будет
недостаточно. И вы удивитесь, сколько самых неожиданных проектов (в том числе,
возможно, и ваш тоже) почти точно повторяют этот пример «причёска и
парикмахерская».
2. Основная часть эссе: краткое описание проекта создания целевой системы,
структурированное по всем основным альфам проекта (возможность выполнения
проекта, внешние проектные роли, определение и воплощение системы, работы,
метод, команда), включая их важнейшие подальфы (потребности, требования,
архитектура и прочие, которые могут быть интересны для проекта, включая, но не
ограничиваясь подальфами, перечисленными в учебнике). Дайте характеристику
этим альфам и подальфам, оцените их текущее состояние, основные проблемы в
продвижении их по состояниям, рекомендуйте работы как задействование практик
то есть вместо «проблема X — решить проблему X» формулируйте «проблема X —
использовать практику Y для решения проблемы X», нужен ведь способ решения
проблемы, а не просто признание факта, что «проблему нужно решать, не знаю
как». Эссе — это хороший повод подумать над вопросами, которые поднимаются в
связи с проектом, а затем просто документируйте результаты размышлений в эссе.
Обратите внимание, что при описании нужно кратко характеризовать состояние
каждой альфы. Так, команда интересует не только на предмет закрываемых ей
проектных ролей (требуемых компетенций, разных для каждого проекта), но
интересен вопрос — сотрудничает ли она? Продуктивна ли она? Помним про
лидерство: как у вас с ним? Работы характеризуются прежде всего тем, как вы ими
управляете: просто текущий список запланированных работ тут бесполезен, он же
будет меняться каждый день по мере выявления всё новых и новых проблем. Есть
ли у вас какие-то ожидания по срокам окончания работ, по требуемым для этого
ресурсам? Какие работы лежат на критическом пути, критической цепи? В каком
состоянии буферы проекта? Какие работы нужно стартовать прямо сейчас? Какие
работы нужно стартовать, но к их старту ещё ничего не готово, и нужно
обеспечивать эту готовность?
 311

Метод обязательно разбейте на отдельные практики, укажите их дисциплины и

технологии. Не знаете дисциплины, но используете инструменты? А что тогда
поддерживают ваши технологии — работу по наитию?!
В ходе описания альфы «метод» не забудьте привести краткую характеристику
модели жизненного цикла целевой системы (а если вы делаете сервис, то и
жизненный цикл предоставляющей сервис системы в обеспечении жизненного
цикла целевой системы: ЖЦ парикмахерской, обеспечивающей сервис стрижки в
ЖЦ причёски). Покажите ЖЦ проекта (помните, чем отличается жизненный цикл
системы от жизненного цикла проекта?), опишите практику управления жизненным
циклом (как вы назначаете работы на практики? Как управляете конфигурацией и
изменениями в проекте?). Дайте краткую характеристику используемых практик
предпринимательства, инженерии, менеджмента, других практик проекта. И опять:
проблемы, рекомендации по их устранению (рекомендация — это применить какую-
то практику, а не просто совет устранить проблему!). Особое внимание должно быть
уделено вопросу насколько планы управления работами и финансовые планы
отражают архитектуру системы и особенности её жизненного цикла, а также
насколько принятая модель жизненного цикла помогает удовлетворить внешние
проектные роли (и если окажется, что принят «водопад», то нужно честно дать себе
ответ на вопрос — что реально будет в проекте, ибо «водопад» будет только на
бумаге, в отчётных документах! Водопад обычно — утопия, не врите сами себе, что
«работаете по водопаду»!).
4. Рефлексия: случилась ли метанойя (помните материал первого раздела?) и по
каким именно темам, что осталось непонятным в материале курса?
5. Планирование: какие у вас планы по продолжению образования в системном
мышлении других дисциплинах методологического группы (онтологика,
вычислительное мышление, научное мышление), как вы намерены получить
кругозор в системном предпринимательстве, инжерении, менеджменте, других
деятельностных дисциплинах? Как планируете системно развить свою личность,
получить когнитивные навыки управления собственным вниманием, борьбы с
прокрастинацией, умения играть свои проектные роли и взаимодействовать с
другими людьми в их проектных ролях?
В эссе не пересказывается и не цитируется материал учебника, не
приводятся диаграммы из учебника. В зачёт идёт только приложение
материала к реалиям проекта: это легко проверяется — есть ли в вашем
тексте термины предметной области проекта, или только общие термины,
верные для всех проектов? Нет ли фраз типа «сделать как можно более
дешёвую систему» или «сделать систему, максимально удобную для
использования», которые «правда, но совершенно бессмысленная
правда», ибо приложима к любому проекту? Просмотрите ваше эссе и
конкретизируйте все общие высказывания, чтобы они были уникальными
для вашего проекта.
Тщательный выбор целевой системы — это примерно половина работы (опыт
показывает, что в случае менторства это занимает от часа до трёх часов обсуждения
с ментором при хорошем знании проекта). Нужно, чтобы эссе делалось по одному
какому-то проекту, ибо даже "типовой проект" часто оказывается в жизни набором
очень разных проектов. Начальники часто берут целевые системы трёх десятков
разных порученных им проектов, думают про них как один проект и получают три
 312

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

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

Что дальше
Поздравляем, на этом учебник системного мышления закончен. Что делать дальше?
• Перечитайте учебник, в первой же главе довольно много рассказано о том,
как обучаться мышлению: решать задачи, тренировать беглость, применять
это мышление к чужим проектам (это проще! Вы будете видеть в них «задачи
из учебника», ибо не будете знать многих деталей и не будете эмоционально
в них вовлечены), к своим проектам (это сложней! В этих проблемах будет
много отвлекающих от важного деталей — удерживать мысль на
предлагаемых шаблонах системного мышления будет труднее). Возможно,
вам нужно будет дополнительно пройти курсы методологических дисциплин
перед прочтением учебника (например, разберитесь подробней, чем
отличаются абстрактные объекты от физических, и как устроено мышление с
использованием схем — как пользоваться полным спектром мышления от
интуитивного через вероятностное до формального).
• Не просто перечитайте учебник, но и пройдитесь по ссылкам на литературу.
В упомянутых в учебнике стандартах, публичных документах, книгах, статьях,
энциклопедических справках для вас найдётся много интересного и
полезного.
• Решайте задачи по системному мышлению (в Школе системного
 313

менеджмента233 есть курсы, где практикуется решение этих задач). При

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

233
http://system-school.ru/
234
http://techinvestlab.ru/systems_engineering_thinking/