Подальфы
Подальфы и их состояния порождаются командой по потребности, когда команда понимает, что внимания к ситуации на уровне альф не хватает, и нужно внимание к дополнительным объектам, от которых зависит продвижение альф по их состояниям. Подальфатак и определяется — это альфа, связанная с другой альфой отношением «если состояние подальфы продвигается, то и состояние её надальфы продвигается». Более того, у каждой альфы (в том числе у подальф, у которых тот же тип «альфа») могут быть свои подальфы, а одна подальфа может быть подальфой нескольких альф и подальф. Примеры этих подальф можно брать в самом стандарте OMG Essence, можно брать в разнообразной литературе. Прежде всего тут нужно указать на разработки Ivar Jacobson International, они предложили наборы альф с их состояниями и контрольные вопросы этих состояний для самых разных практик, особенно для гибких методологий[1].
Основных альф различных областей интереса из модели графа создателей как объектов внимания в проекте не будет хватать, слишком маленькое разрешение, нужно видеть в проекте больше деталей. Поэтому увеличиваем разрешающую способность нашего внимания, для чего команда берёт эти подальфы из дисциплин/теорий/принципов принятого ей инженерного процесса. Дальше с подальфами всех уровней работа идёт ровно такая же, как с любыми другими альфами: если их брали из литературы, то они обязательно адаптируются к предметной области проекта, для них формулируются состояния (которые тоже организованы в какой-то граф состояний), контрольные вопросы для составляющих этих состояний — и этих вопросов для составляющих состояний может быть ещё несколько уровней. Это всё организуется в шаблоны чек-листов, затем в операционном софте реализуются сами чеклисты для каждой ситуации (скажем, для каждого подрядчика делается отдельный чеклист, например, в формате строки таблицы). Дальше для перевода состояний подальф в нужном направлении в графе состояний этой подальфы, как и в случае любой альфы, предлагаются методы работы, работы планируются в виде кейсов, а затем ведутся работы этих кейсов.
Например, в практике управления проектами методом критической цепи вводят для альфы «работа» подальфу «буфер проекта» (project buffer) и отслеживают затем её состояние — сначала этот буфер проекта создаётся, потом потихоньку расходуется в ходе проекта. Ответ на вопрос «в каком состоянии работы проекта?» (вопрос про альфу «работа») может включать в себя отдельный рассказ про состояние «буфера проекта» (подальфу альфы «работа»). Вот именно поэтому подальфа определяется не через отношение часть-целое, онтологически «буфер проекта» уж точно не часть «работы». Онтологически буфер проекта — это описание работы, хотя можно трактовать и так, что это описание «потенциальной работы». В любом случае, трудно представить «буфер» истинной частью «работ». А вот как подальфа — да, это удобно.
Подальфа — тоже альфа! Так же, как подсистема — тоже система, подкейс — тоже кейс. Разве что отношение не «часть-целое», а определённое более хитрым образом. Всегда проверяйте, какого типа отношение имеется в виду, когда применяют приставку «под-»!
Вот пример подальфы «подрядчик» для альфы «команда» (навскидку: обратили внимание на «под-»? Какого там типа отношение с «рядчиком»[2]? А в субподрядчик какое отношение «суб-» с подрядчиком? Особого смысла эти рассуждения не имеют, это просто проверка — обратили ли вы внимание на предыдущий абзац).
Подальфа «подрядчик» альфы «команда» была отмоделирована автором руководства для крупной строительной компании, занимающейся сооружением сложных инженерных объектов, отсюда и специфика её состояний, это адаптированная для этой предметной области альфа (обратите особое внимание, что работы тут считаются выполняемыми однократно, «по-старинке», в строительстве по-другому пока просто «не понимают»):
- Признан*—* обоснование аутсорсинга есть; концепция использования для подсистемы есть; ожидания к гарантийному обслуживанию и ремонтным работам есть; понимание по технологиям работы есть; сроки поставки определены; критерии приёмки результата есть; оценка возможной цены есть.
- Выбран*—* технико-коммерческие предложения получены; переговоры с кандидатами проведены; технико-коммерческие предложения оценены; подрядчик нами выбран.
- Привлечён*—* валютные, сроков поставки, качества и прочие риски оценены; договор с учтёнными рисками подписан; аванс перечислен; необходимая документация для начала работ передана; уведомление о начале работ получено; процедура коммуникации команды с исполнителями установлена.
- Работы идут*—* надзор за работами установлен; запросы обеих сторон учитываются; запросы обеих сторон своевременно решаются; график работ соблюдается; технология работ соответствует ожидаемой; коммуникация команды с исполнителем не прерывается.
- Работы приняты*—* уведомление об окончании работ получено; испытания проведены; претензий к качеству работ нет (претензии сформулированы и устранены); акты проведения успешных испытаний подписаны; результаты работ доставлены на место; документация передана; монтажные работы произведены; пуско-наладочные работы проведены.
- Работы закрыты*—* акт приёмки-сдачи подписан; деньги перечислены; никаких дел к подрядчику нет; гарантийные и сервисные работы производятся; документация архивирована.
Поскольку это описание подальфы — мета-модель предметной области, а не мета-мета-модель из нашего руководства «для всех видов проектов», для других проектов (например, подрядчиков в проектах создания какого-то корпоративного софта) состояния «подрядчика» были бы совсем другие.
Регулярная проверка сделанного и не сделанного по такому чеклисту существенно снижает риски.Поскольку люди не компьютеры, один раз из десятка важная работа просто не делается, «по совокупности причин»: просто в силу отвлечения внимания или надежды, что какую-то важную работу сделает кто-то другой в команде. И обращение к чеклисту состояний альфы**, подальфы (прохождение по списку контрольных вопросов)**может спасти ситуацию.
По всем проблемам, обнаруженным в ходе рассмотрения состояния альф как чеклиста, планируются решающие эти проблемы работы. Этим работам выделяются ресурсы в соответствии с принятой практикой управления работами (например, для документирования заданий на эти работы используется трекер, а для запуска в работу практика TameFlow). Затем эти работы будут двигать состояния всех альф в их взаимосвязи в направлении к успешному завершению проекта, а новые проблемы будут своевременно выявляться опять же с применением отмоделированного в виде набора чеклистов графа состояний.
Например, если для альфы «подрядчик» работы приняты (предпоследнее состояние этой альфы, мы даже не пишем тут кавычки, чтобы подчеркнуть, что это понятие с типом «состояние альфы»), то работы закрыты (последнее состояние альфы) будут только после подписания акта приёмки-сдачи (первый вопрос чеклиста). Так что порождаем задание подписать акт, записываем его в трекер как task/задачу (работу, которая может быть назначена конкретному исполнителю и имеет конкретный проверяемый результат), назначаем кого-то выполнить эту задачу. Эта работа не будет забыта, это и есть управление коллективным вниманием в проекте**. В этом и смысл использования** чеклистов с проверкой и отслеживани****ем состояний альф и подальф**.**
А откуда берутся альфы верхнего уровня? Из системного мышления и методологии**: что скрывается за этими альфами****,** подробно на сотнях страницобсуждалось в наших руководствах**.** Системное мышление и методология (как и остальные фундаментальные методы мышления интеллект-стека) занимаются управлением вниманием в сложных проектах, меняющих физический мир.
А теперь подумайте, как бы вы отмоделировали работу с альфой «подрядчик» из текущего раздела, в ситуации, когда непрерывно открываются новые обстоятельства, а работу принципиально нельзя выполнить как однократное выполнение требований. Как бы вы перестроили организацию работ с подрядчиками в таких условиях? Какие чеклисты бы для этого создали?
Множество подальф появляется, когда вы начинаете заниматься моделированием воплощения системы: каждая отдельная модель и каждое их согласованное (без конфигурационных коллизий) объединение может быть выражено подальфой с каким-то своим набором состояний.
Цифровые двойники (digital twins) — информационные/цифровые модели систем (физические двойники, то есть воплощения системы), существующие на всём протяжении их жизненного цикла, особенно включая эксплуатацию. В наших примерах моделирования графа состояний мы вместо альфы «описание системы» для целевой системы прямо говорили «цифровой двойник».
В реализации это может быть сеть цифровых двойников/digital twins network, реализующую цифровые двойники для подсистем как физических двойников.
Это всё можно считать альфами, проходящими свои состояния. Но если пройдём на уровень ниже, уровень подальф, то получим как целый ряд моделей по самым разным методам описания/viewpoints времени эксплуатации (это особо подчёркивается по сравнению с машиностроительными или строительными PLM-моделями, часто не доходящими до эксплуатации), так и целый ряд моделей, использующихся во время создания: все эти 3D-модели, кинематические, электрические, тепловые и прочие инженерные модели.
Цифровая нить(digital thread) — это инструменты и метод федерирования-унификации-интеграции данных, обычно на основе так называемых семантических моделей данных (semantic data models), которых довольно много в инженерии, связывающая между собой все эти отдельные модели, а также цифровые двойники окружения и физического двойника. «Железный» инженер (машиностроитель или строитель) старой закалки скажет «интеграция данных жизненного цикла» и помянет множество PLM (а если это не машиностроение, а корпоративный софт, то может помянуть и «корпоративную шину данных»), менеджер новой закалки скажет «цифровая нить» и помянет PLM, ERP, EAM и даже CRM (и ещё довольно много «трёхбуквенных сокращений»[3]). И, поскольку «цифровой — это новый информационный», то заметят, что для какого-нибудь здания или моста кроме BIM (building information model) цифровая нить добавит к цифровому двойнику данные дронов, сенсоры интернета вещей и какой-нибудь «искусственный интеллект» обнаружения аномалий для ремонта по состоянию. Инженеры старой закалки продолжают говорить «управление информацией» или «управление данными», их язык «цифровой нити» не увлекает, хотя менеджерам эта метафора очень нравится.
Так, если нужно сшить между собой мультифизическую модель (модели нескольких физик — механическую модель, электрическую модель, тепловую модель, акустическую модель и т.д.), то инженеры будут говорить управление данными имитационного моделирования/SMD/simulation data management, а менеджеры старой закалки предпочтут говорить управление информацией (имитационного/мультифизичного) моделирования/simulation information management (но говорят так довольно редко, менеджеры до этих тонкостей уже не доходят, они больше про «нить»).
Цифровая инженерия/digital engineering — это создание цифрового двойника путём сплетения цифровой нитью различных его моделей, экземпляра его физического двойника и цифровых двойников окружения. Цифровой инженерией занимается цифровой инженер/digital engineer, причём знания цифрового инженера::роль должны быть настолько широки (вся просто инженерия и всё просто айти), что его оргроль часто выполняется обычно командами/оргзвеньями из нескольких человек, и часто коллективами из многих оргзвеньями. Ещё один синоним для цифровой инженерии: моделеориентированная инженерия**/MBE **(model-based** **engineering)**.**
Современные инженерные проекты растут в сложности, число одновременно удерживаемых объектов внимания в них растёт, простые формализации становятся сложнее. Это означает, что число подальф растёт, и для удержания всех их во внимании нужно использовать экзокортекс: самые разные компьютерные модели, включая цифровых двойников, связанных в сети и привязанных к датчикам и актуаторам/эффекторам физических двойников цифровыми нитями.
Цифровые двойники и цифровые нити оказались очень удобным способом говорить о системном моделировании[4]. Из инженерии этот подход перешёл в самые разные другие предметные области (в медицине речь идёт о цифровом двойнике пациента, в педагогике о цифровом двойнике ученика/студента, и так далее). Эта идея и терминология настолько прижились, что говорят о цифровых двойниках безмасштабно: для всех видов систем (вещество, киберфизические системы, существо, личность, организация, сообщество, общество, человечество).
Основная мысль подраздела в том, что надо отслеживать состояния не только воплощения системы, но и описаний системы**—** надо отслеживать ход моделирований, которых в современных инженерных проектах множество самых разных видов. Для этого используйте подальфы описания системы, и работайте с этими подальфами письменно**—** ведите изменение их состояний в каком-то универсальном моделере, а работы по изменению этих подальф (достижение какими-то моделями цифрового двойника тех или иных состояний) ведите в issuetracker. Вы наверняка и так это делаете, но главная мысль тут — обо всех этих подальфах думать можно (и даже нужно) абсолютно одинаково, действовать по их поводу можно абсолютно одинаково, моделирование их на уровне мета-мета-модели можно вести одинаково. Уже на уровне мета-модели там все слова-термины и набор типов будет разный, но вас не должно это смущать. Какой бы ни был набор типов, какие бы ни были слова — вы сможете узнать знакомый вам набор альф и даже какие-то подальфы.