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

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

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

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

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

64

https://en.wikipedia.org/wiki/DevOps

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

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

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

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

65

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

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

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

Если

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

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

66

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

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

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

3. Роли

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

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