Области интересов надсистемы, целевой системы, создателя ​

Области важных характеристик/предметов интереса (area of concerns) предложены в стандарте языка/language OMG Essence для группировки объектов внимания в проекте по укрупнённым характеристикам связи с какими-то системами. Они настолько укрупнены, что их было предложено называть не интересами, а областями интересов. В основных/kernel объектах это были области интереса к объектам внимания, связанным с заказчиком/customer, программной системой/software system и работами проекта/endeavor. Мы оставляем язык стандарта, сохраняем понятие «области интересов», но отказываемся от предложенного узкого понимания областей, меняем основу/kernel.

Важная характеристика/предмет интереса --- это тема озабоченности/concern роли, оформляемая каким-то методом описания/viewpoint, это не «чего роли хочется достичь». «Чего хочется» --- это будет не сама характеристика, а предпочтения проектной роли для этой характеристики, сам интерес в предмете интереса ---роли могут двигать целевые характеристики в разные стороны, для этого они используют удобные для этого методы описания. И роли договариваются между собой по поводу реализации своих предпочтений в этих важных характеристиках.

Если укрупнить все такие характеристики/предметы интереса вокруг каких-то важных систем в проекте (альф), то получатся три важнейших, соответствующих трём видам систем (но вы смело можете адаптировать основные области интересов к вашему проекту, добавить дополнительные области интереса). В подразделе «Цепочки создания» раздела «2. Не жизненный не цикл, в том числе развитие» мы уже приводили пример такого представления: альфы предприятия, разложенные по основным областям интереса надсистемы, целевой системы и различных создателей в цепочках создания. Мы также сделали замечание о том, что все связи между альфами так или иначе ведут к целевой системе. Повторим диаграмму с цепочками создания^[1]:

Если это система-создатель, то для каждой альфы даны её подальфы типовых ролей (прикладных инженерных или менеджерских --- объясняются подробно в курсах «Системная инженерия» и «Системный менеджмент»). Если это группа агентов/оргзвеньев, которые играют какие-то роли (например, клиентура или просто «внешние проектные роли»), то показываем подальфы для отслеживания состояний отдельных агентов. Например, на вопрос о том, в каком состоянии клиентура, вы могли бы отвечать «Клиенты 3, 5, 8 в процессе перезаключения договора, клиент 64 вчера отказался от наших услуг и мы проводим дополнительную с ним работу, от клиентов 39, 40 и 35 ожидаем оплаты, остальные обслуживаются». При этом у вас есть и альфа «клиентура», ибо если её нет, то что вы развиваете? Развиваете вы как раз клиентуру, наращиваете число клиентов в целом, увеличиваете лояльность, считаете показатели юнит-экономики^[2].

А теперь покажем группу из трёх альф в каждом звене графа создания на диаграмме, добавим немного дополнительных подробностей, просто чтобы оценить топологию графа создания, когда начинаем его разворачивать для отслеживания не только самих систем, но и их описаний и их работ^[3]:

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

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

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

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

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

Планирование этих работ/operations/services целевой системы не всегда делает сама целевая система (это может делать оператор из системы создателя), поэтому планирование на отношении связи между воплощением системы и её работами на диаграмме взяли в скобки. По большому счёту, в момент времени работы/эксплуатации целевой системы она может при достаточной степени агентности/автономности/сознательности планировать (заранее или «на лету»/on the fly) свои работы сама. Это умеют делать и самые простые системы, типа предохранителя в электрической цепи, который «срабатывает» ровно тогда, когда нужно, «планирует на лету свою работу». Тем не менее, какой-то станок включается иногда сам, но иногда его включают извне, а потом уж он сам только работает. В каждом конкретном проекте это всё нужно обсуждать и адаптировать системную схему проекта к конкретной ситуации, всё-таки безмасштабность и дезантропморфизация мышления в методологии ещё не сильно развита, думать о системах как обладающих разной степенью разумности (включая системы с развитым AI) люди ещё не научились, и на каждом сочетании масштабов и с учётом огромного разнообразия систем могут быть какие-то особенности. Важно, чтобы вы не боялись менять и состав основных альф, и их подальфы, и число звеньев в цепочках создания, и раскладывать разные операции по цепочкам создания.

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

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

Инженерия производственной платформы (современный подход к DevOps/SRE как к platform engineering), в том числе создание административных служб предприятия, на этих диаграммах не показана. Но это тот самый случай: инженер платформы разработки создаёт «большой станок» (в случае ракеты это завод ракет, в случае софта это inner development platform, в случае системы-предприятия это административные службы, подробней см. курсы системной инженерии и менеджмента) и обеспечивает его работу, и уже на нём изготавливается целевая система. Вам нужно предусмотреть это, когда будете адаптировать основные альфы для вашего проекта. Этим занимаются чаще всего исполнители ролей CTO/CIO (chief technology/information officer, в современном мире «станочный парк» стал во многом «парком» корпоративных информационных систем, и «главный инженер», и «главный айтишник» --- это одно и то же по их задачам), и этих инженеров производственной платформы не надо путать с инженерами целевой системы: одни проектируют и эксплуатируют завод, а другие проектируют и эксплуатируют целевую систему, изготавливаемую и проверяемую на этом заводе. В приведённой диаграмме наличие по факту двух инженерных команд не показано. Впрочем, команд разработчиков тоже может быть много для разных частей системы, а архитектор::роль быть реализован одной командой (не одним человеком! Командой с их моделерами!)::оргзвеном на все команды, исполняющие роли разработчиков. Будьте внимательны в моделировании прикладной инженерии, там не всё так просто, как в примере из текущего подраздела. В вашем проекте внимание наверняка нужно будет уделить большому числу альф --- и сразу рекомендация: записывайте! Моделируйте, делайте списки и таблички, размышляйте над ними, тратьте на это время: оно окупится, вы потом не будете тратить часы и часы на разных совещаниях, чтобы разобраться со всеми недоразумениями. Эти недоразумения не получат шанса возникнуть!

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