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