Текст книги "Системное мышление 2019"

Автор книги: Анатолий Левенчук

сообщить о нарушении

Текущая страница: 7 (всего у книги 9 страниц)

Работы и действия

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

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

А отношение участия (participation) в изменениях/действиях/процессах/процедурах/activities – это просто специализация отношения состава (composition, part_of).

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

.

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

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

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

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

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

Системы (в том числе процессы, в том числе и работы) какого-то предприятия, и в том числе оргпроцессы6262
  Мы вслед за ISO 29148 рекомендуем говорить не «бизнес-процессы» (business process), а «организационные процессы» (organizational processes), оргпроцессы.


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

Мы часто будем приводить в качестве примера системы танец – танцы имеют процессную природу, они не такие тривиальные для мышления, как насосы или автомобили. Но танцы всё ещё много проще предприятия, поэтому думать о танцах проще, чем о предприятии. И совсем недаром одна из классических (год выпуска – 1999) книг Peter Senge по системному мышлению для предприятий называется «Танец перемен»6363
  https://www.ozon.ru/context/detail/id/1378492/


[Закрыть].

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

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

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

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

Поэтому программисты, которые считают, что их инженерная работа закончена в момент написания исходного кода – эти программисты глубоко неправы, и это типичная ошибка. Из признания этой ошибки появилось целое движение DevOps6464
  https://en.wikipedia.org/wiki/DevOps


[Закрыть] – программисты признали, что они должны выполнять роль не только разработчиков кода программы (Development), но и сопровождением работы программы на рабочих серверах (Operations).

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

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

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


[Закрыть].

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

Как найти настоящую целевую систему, которую изготавливают программисты в конечном итоге? Ибо даже работающая программа оказывается часто работающей с описаниями и документированием описаний какой-то другой системы, нежели реальной системой, изменяющей физический мир!

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

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

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


[Закрыть].

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

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

3. Роли

Роли и действия

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

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

Одним из примеров такого подхода служит инженерный способ разработки требований «сценарии использования» (use case, но автор Ivar Jacobsen оговаривал, что в шведском языке, на котором он сначала предложил этот способ разработки, вместо слова case использовалось слово «сценарий»). Сценарий – это последовательность действий актёра/актора/actor, то есть активного действующего предмета. Это может быть как человек (и в предлагаемом для описания сценариев использования для описания актёра служит фигурка человека), так и вовсе не человек, и даже неодушевлённый предмет – тот же молоток, который предлагается активным элементом в последовательности действий, складывающихся в пьесу-сценарий. Сценарии использования оказались очень удачны для описания работы/процессов/последовательностей_действий/сценариев/поведения системы и её частей. Этот способ описания стал повсеместным для инженеров, он приводит к построению функциональных/ролевых описаний.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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