Программа, как система — это вещь, физический объект, она занимает место в пространстве-времени, она материальна. По работающей программе (программному процессу в компьютере) можно «постучать», можно ткнуть в неё пальцем! Работающая программа — физическая часть компьютера, которая проводит вычисления этой программы в ходе её работы.
У программы как физического объекта в момент работы есть разные состояния (которые представляют собой физические состояния оперативной памяти и регистров процессора), а компьютер занят физическими процессами/изменениями/взаимодействиями своих составных частей в ходе вычисления. Эти процессы в компьютере занимают какое-то место в физическом мире: пространство, в котором расположены взаимодействующие части компьютера, и время, во время которого программа (то есть части компьютера в её составе) проводит вычисления:
Ещё раз подчеркнём: программу следует считать воплощением системы только в тот момент, когда она реально запущена на исполнение и работает, делает то, ради чего она была написана. Это довольно контринтуитивно, но исходный код программы — это не программа, но только описание программы; исходный код программы в системе управления версиями или просто в файле на носителе — это только документация программы. Программа — это то, что отражает состояние программы в момент её исполнения.
Поэтому программисты, которые считают, что их инженерная работа закончена в момент написания исходного кода — эти программисты глубоко неправы, и это типичная ошибка. Из признания этой ошибки появилось целое движение DevOps[1] — программисты признали, что они должны выполнять роль не только разработчиков кода программы (Development), но и сопровождением работы программы на рабочих серверах (Operations).
Исходный код — это описание программы (оно делается в классах, как любое проектирование, один исходный код описывает множество возможных экземпляров программы), и перед использованием программы её нужно изготовить: откомпилировать, собрать, разместить в оперативной памяти нужного компьютера (возможно, перед этим оформив в какой-то контейнер) и передать на неё управление.
Тем самым программа как система — это процесс, и нас интересует именно тот процесс, который выполняется на правильном компьютере (или компьютерах — например, клиентском и в облаке), в тот момент, когда программа работает и выполняет свою функцию, своё назначение. Понятно, что от исходного кода до вот так работающей программы обычно долгий путь.
Ошибка, которую делают программисты, считая свой исходный код программой, ровно того же сорта, которую проектировщики и конструкторы делают, считая своей системой разрабатываемые ими информационные модели (а раньше — чертежи) и другую проектную и конструкторскую документацию. Карта не территория, меню не едят, на чертежах не летают, исходный код не хранит значений своих переменных в ходе исполнения[2].
Ещё одна ошибка — это считать программу целевой системой, а не просто описанием целевой системы. Программа как книга: нас чаще всего волнует не книга, и даже не содержание книги (сам книжный текст), а описанное текстом книги. Волнуют описанные в книге миры, не волнует сама красота слога (ну, разве что «особых ценителей», если речь идёт о беллетристике, письме ради письма). С программами то же самое: волнует описанный программой фрагмент окружающего мира, не волнует сама программа (волнует не больше, чем книга и её текст). Если у вас программа заказа химчистки, то вас волнует одежда, которая из грязной станет чистой, деньги, которые с вас спишут, варианты транспортировки вещей на чистку и назад. Программа волнует программиста, но это его личное дело: всех остальных волнует, как эта программа справится с собственно ситуацией химчистки, да и программиста тоже должно это волновать. Если программа будет шикарна как софт, но химчистка с ней будет невозможна — то это провал проекта! Информационные технологии — они всего лишь про описания, ищите за ними физический мир, изменения в котором имеют значение!
Ещё одна ошибка — это включение в систему только софта, но не всей службы, которая выполняет какую-то осмысленную работу. В корпоративной разработке софта клиенты ожидают по итогам этой разработки не столько корректную работу компьютера, сколько корректную работу той части организации, которую должен этот компьютер поддержать: люди в организации должны вместе с программой сработать по какому-то организационному алгоритму. Софт без людей не работает, нужно предъявлять работу софта с людьми. Такой совместный поток работы людей и компьютеров называется обычно workflow, хотя часто называют и оргпроцесс, и рабочий процесс. Программа-в-разработке — это чаще всего только часть целевого оргпроцесса. И помним, что про процессы (в том числе оргпроцессы, рабочие процессы) люди думают трудно. Поэтому программа тут будет частью подразделения/службы/провайдера, которая будет выполнять нужные изменения в физическом мире. Сама по себе программа будет личным делом программиста или небольшой команды программистов, удерживать её в эпицентре внимания как полноценное воплощение системы — опрометчиво.
Дело ещё осложняется тем, что программы как информационные объекты (носители информации, включая все свои базы данных) могут выстраиваться в длинные цепочки, в которых на базе одних описаний программы или программы-с-людьми меняют другие описания, дальше третьи — и только в конце такой длинной цепочки наступает желаемое изменение мира. Вы можете долго описывать себя, где взять ваши деньги, ваши намерения, записывать промежуточные результаты принятия решений всевозможными другими программами и людьми в компьютер и/или телефон, но только в конце длинной цепочки заказа авиабилетов вас физически пропустят на самолёт: сотни самых разных программ, часть из которых вам известна, а часть даже неизвестна, срабатывают, чтобы получить этот результат в физическом мире. Если этого результата не случится, все эти программы и люди сработали зря. Поэтому не ленитесь раскручивать все эти «описания описаний», все длинные цепочки программ и программ-с-людьми — пока не дойдёте до изменений в физическом мире, ради которых всё делается. И убедитесь, что в физическом мире будет всё в порядке. Да, это трудно, но системное мышление заставляет развернуть ваше внимание в эту сторону. Это важно, выход софта в физический мир — это имеет значение, если надёжных и ожидаемых изменений в физическом мире не будет, то проект разработки софта можно и не делать вообще, всё одно ведь в физическом мире ничего не изменится!
Для того, чтобы клиент смог получить результат оргпроцесса, эту программу нужно настроить, дать ей какие-то данные, научить с ней работать сотрудников и проверить не столько работу самой программы, сколько работу всей оргструктуры/оргзвена/службы/провайдера в целом, включая приданную этой оргструктуре программу. Никого не волнует работа программы начисления зарплаты, волнует само начисление зарплаты (можно представить его как деление какой-то кучки физического золота на предназначенные для раздачи сотрудникам части) — и если начисления зарплаты не произойдёт, то программистам трудно будет объяснить, что с их программой всё в порядке, а неправы все остальные сотрудники, неправильно заполняющие поля этой программы и нажимающие не те кнопки. В проектах по разработке программ очень часто есть части по работе с людьми (обучение работе с программой: нужно «изготовить» те части людей, которые смогут делать что-то полезное с программой) и данными, с которыми будет работать программа. Не пропускайте эти части! Они физичны, их тоже нужно «проектировать», а затем «изготавливать»: людей учить (и разрабатывать способы, которыми это будет происходить, и способы проверки научения), дополнительный софт настраивать (и проверять, всё ли настроилось).
Как найти настоящую целевую систему, которую изготавливают программисты в конечном итоге? Ибо даже работающая программа оказывается часто работающей с описаниями и документированием описаний какой-то другой системы, нежели реальной системой, изменяющей физический мир!
Тут просто: нужно смотреть не на саму программу, а на данные этой программы (часто они лежат в какой-нибудь базе данных). Эти данные описывают какую-то систему — чаще всего она и будет целевой системой в проекте! Именно это и будет воплощением системы, которым будут озабочены все окружающие разработку люди! Это срабатывает не в 100% случаев, но может быть хорошим стартом поиска целевой системы, когда вокруг много программистов.
Если речь идёт о программе учёта командировок, то целевая система — то, что описывается её данными, и будет в результате работы программы изменяться (создаваться, уничтожаться). Это деловая поездка. Да, деловая поездка — это процесс/работа, но вполне понятно, как её описать и учесть в компьютере. Для этого просто нужно учесть все входящие в деловую поездку (отношение участия/части-целого/состава) объекты — людей в роли командированных, билеты (проездные документы, с разными нюансами отношения к носителям для этих документов) и т.д. Если речь идёт о программе для станка с ЧПУ, то целевая система — это описываемая данными этой программы деталь. Программа же описывает работы станка, а станок нужен для получения детали. Цель — деталь, деньги от неё, а всё остальное только цепочка, приводящая к этой цели. Так что с программами как целевыми системами нужно быть осторожными. Это мы будем обсуждать подробней, когда будем обсуждать целевые системы проекта.
Ещё в мире софта (а весь мир потихоньку становится миром софта) могут быть такие странные воплощения системы, как сессии — учебные сессии, или игровые сессии. Например, игровая сессия состоит из игрока в состоянии игры, игрового сервера, который помнит состояние мира игры, работающей на телефоне игровой программы, которая управляется игроком с одной стороны и сервером игры (через интернет) с другой стороны. Все эти объекты, взаимно меняющие состояния — это и есть игровая сессия. Бизнес-люди будут счастливы с таким определением целевой системы, ибо они продают эти игровые сессии, увеличивают их суммарное время! Обратите внимание, что ни одна из упомянутых тут других систем не будет достаточна для полноценного описания происходящего: ни сам игрок в состоянии игры, ни серверный софт, ни софт в телефоне, ни софт платёжной системы (оплата-то идёт обычно как раз за игровые сессии, с небольшими вариациями!).
Часто происходит путаница, когда софт представляет собой «маркетплейс». Мало того, что софт этого «маркетплейса» считают целевой системой, так ещё и игнорируют данные для этого софта, всех обслуживающих этот маркетплейс людей, клиентов этого маркетплейса, всех возможных посредников и провайдеров, которые работают с этим маркетплейсом, чтобы получить в итоге такое воплощение системы, за которое кто-то будет согласен заплатить. Никто не заплатит за «маркетплейс», это просто одна из частей, которая позволит зарабатывать: маркетплейс изготавливает то, что нужно людям. Например, маркетплейс может изготавливать «доставку»: это какой-то товар (вещь!), находящийся в пространстве прямо на пороге того места, куда эта самая доставка предназначена. Вот эта «доставка» и есть целевая система, за это платят, это воплощено в физическом мире, это изготавливается, а всё остальное — это просто цепочки описаний, другие системы, ведущие к этой целевой. «Доставка» будет наносить клиентам непоправимую пользу, а всё остальное будет наносить непоправимую пользу лишь продавцам-разработчикам, путём обмена на деньги.
Можно ли считать, что тут перечислены все типовые случаи целевых систем, связанных с софтом? Нет! Мир крайне разнообразен, целевых систем неисчислимое количество разных типов, каждый день появляются новые бизнес-модели, с этими бизнес-моделями появляются новые типы целевых систем. Физический мир меняется всё более и более изощрённо, а системное мышление позволяет не запутаться в этом море описаний и таки обратить внимание на главное: что меняется в физическом мире, что является воплощением системы, что является целью всего большого (а не только вашей маленькой части) проекта, за что люди будут согласны заплатить.
Все эти рассуждения легко переносятся из мира алгоритмов в мир данных. Ещё лет сорок назад не было даже персональных компьютеров (первый появился в 1980 году), а лет двадцать назад ещё считалось, что мир захватят сложные алгоритмы, которые будут хитро перерабатывать относительно простые данные в базах данных. Сегодня оказалось, что современное программное обеспечение сдвигается в сторону работы простыми алгоритмами над сложными данными. Поскольку сложность из алгоритмов перемещается в данные, то системным подходом начинают интересоваться не только инженеры-программисты, но и инженеры данных. Никогда не нужно забывать, что данные — это в конечном итоге описания каких-то систем, но в момент их обработки какой-то программой они сами становятся частью системы этой программы, они меняют своё состояние, они могут пропасть, они ведут себя как «вещь». То есть данные для обработки их программой тоже нужно «изготовить» из первичных описаний. И когда мы интересуемся, как получить из данных полезный результат, то как и в случае программ мы должны научиться их изготавливать из исходных данных — и мы по аналогии с DevOps будем говорить о DataOps[3].
Системное мышление тем самым нужно как программистам, так и специалистам по обработке данных: в силу углубления разделения труда это уже не одно и тоже, хотя и существенно связано. Системное мышление поможет инженерам-программистам, инженерам по данным, инженерам-администраторам датацентров, менеджеров всех этих многочисленных ролей договориться между собой, а также с другими сотрудниками предприятий и клиентами, для которых они работают. Программные системы (в момент работы программ), системы данных (в момент использования данных) — всё это системы, в мире софта системное мышление применимо не меньше, чем в мире железных систем, или организационных систем. Просто нужно не выпячивать именно программистскую часть, всё время помнить про подчинённую роль софта и примат физического мира — и всё в проекте тогда будет в порядке.
А что же с людьми, которые работают с программами? Очень часто воплощением системы, которое интересует людей в проекте будет какая-нибудь часть организации, которая должна выполнить какое-то дело — выдать кредит, начислить зарплату, изготовить деталь. И если окажется, что программа работает правильно, но люди в организации не могут с ней работать, то не будет засчитана за правильную и работа программы. Что толку в работе программы по начислению зарплаты, если люди с ней не смогут сработать? Если программисты хотят получить деньги за свою часть работы, они должны быть уверены, что кто-то работает и с людьми, а сдаваться заказчику будет совместная система из людей и программ (а также данных к этой программе, что может быть отдельной проблемой и может требовать отдельных исполнителей). Сдаваться будет начисленная зарплата, изготовленная качественная деталь — и дальше по цепочке работа подразделения, ведущая к этим важным целевым результатам, а внутри этой работы подразделения будет сдаваться софт.
Примерно такие же рассуждения, что и рассуждения про компьютерные программы можно проводить для обучения людей. Книги, видео — это только описания того, что хотелось бы получить после обучения. Целью обучения является работа части мозга человека, которая в момент попадания в целевое окружение включается по аналогии с компьютерной программой и производит те вычисления/мышление, на которые было направлено обучение. Мозг — это вычислитель, а прочтённые книги, просмотренные видео лишь задают описание того, что потребуется от мозга в плане протекания в нём физического процесса (со сменой состояний!) мышления в соответствии с результатами обучения.
Единственное что, так это не нужно говорить о нейронах и их обучениях, это явно не тот уровень деталей, который обсуждается при обучении. Но представление результата обучения как обученного для работы в целевых условиях участка мозга заставляет продумать и то, как выглядит это обучение в физическом мире (участок мозга должен в момент обучения быть где-то расположен!) и как выглядит в физическом мире работа результата обучения как системы: должно быть соответствующее физическое окружение. Скажем, в этот момент человек может находиться в машиностроительном цеху, среди жуткого грохота окружающих машин. Включится ли обученный участок мозга без дополнительного напоминания? Выдаст ли безошибочно и без пропусков то мышление, которому его учили в этом окружении? Сколько времени это займёт? Что происходит до этого момента, что будет происходить после этого момента? Переход к физической системе (участку мозга, который готов действовать/мыслить) оказывается продуктивным и для ситуации обучения. В обучении много описаний, но не они оказываются главными. Главным тут оказывается результирующий физический объект с предписанными ему свойствами.
Что является целевой системой проекта строительства моста? Мост, конечно! Но для строительства моста нужно создать организацию, которая проведёт его проектирование, затем создать организацию, которая развернёт стройку моста, потом провести работу этой организации-стройки (несколько тысяч человек в чистом поле!), и только потом получить удовольствие от моста. Это всё длинные цепочки обеспечения. И уж если они такие длинные в случае простых физических систем типа моста, то в случае софта они могут быть и существенно длиннее. Представьте, например, любой из программистских проектов, которых много в рамках строительства моста. Зачем они существуют? Зачем этот весь софт? Чтобы в конечном итоге появился мост! Вот системное мышление требует отследить всю цепочку от используемого в проекте строительства софта до самого моста. И если окажется, что мосту от этого софта ни холодно, ни жарко, то это будет означать, что софт можно этот и не писать, проектом этого софта не заморачиваться.
Системное мышление проверит, не занимаетесь ли вы никому не нужной работой. Системное мышление заставляет об этом всём думать сразу, а не в момент неподписания актов приёмки-сдачи по проекту «создания программного обеспечения». Обычно сами по себе программы никому не нужны, они нужны только как части каких-то других систем — и нужно убеждаться, что разработка идёт этих других систем в целом прежде всего, а программ только как части этих систем или как части систем, которые делают эти целевые системы — разбираться нужно со всеми цепочками, ведущими к реальности, к физическому миру. Не путайте фотографию и изображаемый на фотографии предмет, книгу и живой мир, который описан в книге, софт и реальный мир, описываемый и меняемый софтом.
- [1] https://en.wikipedia.org/wiki/DevOps, есть похожий вариант этого движения, SRE
- [2] Тут есть нюанс, связанный с фон-неймановской архитектурой: программа может быть рассмотрена как данные на носителе, и как исполняемый объект. То же относится к «программе в мозге»: лежит ли в мозге в его нейронах только описание, или же нейронная сеть сейчас именно «вычисляет» что-то, то есть там работает программа-как-процесс в физическом мире – это тот самый вопрос про «материальность мысли». Это нюансы, мы их тут не рассматриваем. Совет тут – рассмотреть вероятность, с какой речь идёт о «просто документированном описании программы/мысли» или «исполняющейся программе/думающейся мысли», а вероятность эту брать исходя не из «истинности», а из целей какого-то действия. И обсуждать нужно наиболее вероятную ситуацию, полезную для осуществления вами задуманного. Но это нюанс, он непринципиален в большинстве ситуаций. Мы помним, что у нас тут в системном мышлении не математика со 100% формальными утверждениями, плохо приложимыми к жизни, а вероятностные рассуждения, «как в жизни».
- [3] https://en.wikipedia.org/wiki/Dataops
Источник: учебник А.Левенчука «Системное мышление 2020»