Целевая система в проектах разработки софта ​

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

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

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

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

И тут надо не промахнуться, ибо «командировкой»/«деловой поездкой» называют разные процессы::поведения или мероприятия::система (и вам надо определиться ещё --- вы это считаете процессами, или системами?):

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

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

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

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

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

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

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

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

Все эти рассуждения легко переносятся из мира алгоритмов в мир данных. Ещё лет сорок назад не было даже персональных компьютеров (первый появился в 1980 году), а лет двадцать назад ещё считалось, что мир захватят сложные алгоритмы, которые будут хитро перерабатывать относительно простые данные в базах данных. Сегодня оказалось, что современное программное обеспечение сдвигается в сторону работы простыми алгоритмами над сложными данными. Даже в алгоритмах AI сработал этот принцип: самые простые нейросетевые алгоритмы над сложными данными весов нейросетей добиваются огромных успехов, разве что нужно очень много вычислительной мощности, которая позволяет выполнить эти простые алгоритмы (горький урок Sutton'а^[1]).

Поскольку сложность из алгоритмов перемещается в данные, то системным подходом начинают интересоваться не только инженеры-программисты, но и инженеры данных. Никогда не нужно забывать, что данные --- это в конечном итоге описания каких-то систем. Даже в больших языковых моделях их данные --- это описание/представление/presentation нашего материального мира как системы, только в сжатом виде модели мира --- результат процесса познания/learning. Но в момент их обработки какой-то программой они сами становятся частью системы этой программы, они меняют своё состояние, они могут пропасть, они ведут себя как «вещь». То есть данные для обработки их программой тоже нужно «изготовить» из первичных описаний. И когда мы интересуемся, как получить из данных полезный результат, то как и в случае программ, мы должны научиться их изготавливать из исходных данных --- и мы по аналогии с DevOps будем говорить о DataOps^[2].

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

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