Альфы

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

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

Подробней об альфах и о том, как моделировать продвижение проекта при помощи альф, будет говориться в руководстве по методологии.

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

Но самые общие альфы как самые общие предметы самых общих методов работы — это объекты мета-мета-модели, они даются нам в знаниях/теориях/объяснениях/алгоритмах фундаментальных методов мышления, принципиально оторванных от предметных областей конкретных проектов. Именно поэтому дисциплины интеллект-стека фундаментальных методов мышления (физики, математики, онтологии, логики, рациональности и т.д.) называют трансдисциплинами: они «транс-», по ту сторону от предметных прикладных дисциплин, они дают нам абстрактные типы мета-мета-модели, а не более конкретные прикладные типы мета-модели.

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

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

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

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

Работайте с типами: описания идут на многих уровнях, но это описания! А физический мир**—** это физический мир**, и там уровни не абстракции (по отношению классификации), а системные уровни (по отношению** композиции)****! Отличайте отношение композиции («часть-целое») для физических объектов и «классификации» (класс-экземпляр) для описаний!

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

Альфы (alphas) — это объекты, по которым мы судим о продвижении/progress («как много мы уже сделали?») и здоровье/health («всё ли в проекте идёт хорошо?») проекта, отслеживая изменение состояний каких-то предметов метода.

Альфы — это абстракция того же сорта, какого «физическое тело» является абстракцией реальных физических объектов. Это физическое тело имеет массу, а геометрическая точка имеет координаты. Но мы отождествляем физические тела и геометрические точки как идеальные/абстрактные объекты с реальными/физическими объектами. Мы «склеиваем» в мышлении идеальные и реальные объекты, реальные объекты наследуют характеристики идеальных объектов — о реальных объектах мы начинаем думать так, как описано в учебниках про абстрактные объекты. Поэтому у нас и у гири, и у атомной станции есть масса, и у пёрышка, и у самолёта тоже есть масса — мы умеем (после довольно долгой тренировки по отождествлению физических объектов из жизни и абстрактных объектов из учебника**!**) понять, что это физические тела и перенести характеристику «масса» этого физического тела на гирю, атомную станцию, пёрышко и самолёт. Если вы узнали, что в проекте основной альфой будут работы системы (вот прямо таки реальное задействование системы, которая что-то там меняет в своём окружении, производит работу/функционирование), то мы можем отслеживать что там происходит с работой: «работы системы ещё не было», «работа на тестовых данных прошла», «работа идёт на реальных данных», «работа прервана», «работа закончена» (и там ещё в графе состояний цикл по «работа идёт на реальных данных» и «работа прервана»). Зачем нужна альфа работы? Чтобы отслеживать — система просто создана, или создана и выполняет уже свою функцию. Работает или не работает система — это важно, за этим надо следить. Вот вы как инженер-менеджер освоили системное мышление (мы близки к концу руководства!), у вас есть уже какое-то мастерство. Работает ли ваше мастерство? А ещё вы член десятка самых разных команд — работают ли они, или просто созданы, а работа стоит как вкопанная?

Об экземплярах альф в проекте принято говорить так, как будто они вполне реальны и существуют в мире, несмотря на все абстракции — об этих альфах как мыслительных объектах мы судим по артефактам/рабочим продуктам.

Какая концепция использования автоматизированной зубочистки в нашем конкретном проекте, идущем прямо сейчас, 28 мартобря 2028 года? Я могу судить о том, что нужно внешним проектным ролям и как вписана зубочистка в её окружение (то есть судить о концепции использования, это же описание, абстрактный объект, да ещё и меняющий своё состояние в ходе проекта) по имеющейся документации концепции использования. Это могут быть несколько разных документов с частями этой модели (частями концепции использования одной из моделей автоматизированной зубочистки), но они также могут содержать и многое другое, что мне сейчас не нужно. Концепция использования — одна из альф, документация с концепцией использования — набор артефактов/рабочих продуктов. Какие у нас внешние проектные роли только представлены агентами в проекте на сегодня, а какие внешние роли представлены агентами, которые уже сотрудничают с командой? Я могу посмотреть на реальных людей-исполнителей (или даже не людей, а роботов), играющих сегодня в проекте какую-то роль — и судить о том, представлены ли они как-то в проекте, и сотрудничают ли уже (например, настроены, если это роботы), или команде для этого нужно ещё поработать (или даже ещё обсудить, считает ли команда AI-робота членом команды, или считает его просто чьим-то инструментом).

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

Вся эта работа с абстракциями нужна, чтобы иметь возможность повторно использовать известные нам способы рассуждений и решения задач для самых разных объектов. Так, мы думаем о «физическом теле» и «геометрических точках» единообразно, «как в учебниках физики и геометрии», а применимо это мышление к самым разным «реальным объектам вокруг нас», от коробка спичек до галактик.

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

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

• требованиям (если это старая инженерия!), с рабочим продуктом «спецификация требований» (в современной разработке такого нет, говорят о разных гипотезах по нужным характеристикам системы и её поведению, при этом стараются их ещё и не собирать в одном рабочем продукте, это ведь быстро становится «бутылочным горлышком» в разработке, поэтому функциональные описания системы стараются сегодня не складывать в одном рабочем продукте)
• сценариям использования, а рабочими продуктами тут будут какие-то файлы с этими сценариями, изложенным на специальных для них языках (если они будут использованы) для каких-то моделеров,
• описаниям из текстов стандартов, а сами файлы с текстами стандартов тут будут рабочими продуктами
• user stories, рабочие продукты — карточки с user stories,
• пожелания (даже не потребности, а просто «хотелки») внешних проектных ролей, а рабочими продуктами могут быть, например, записи этих «хотелок» в базе данных или файлы анкет с этими «хотелками»,
• … и т.д. Артефактов, которые могут документировать концепцию использования и разные описания в её составе — тысячи их, а вот разобраться с тем, что это такое и зачем концепция использования нужна, при изучении системной инженерии нужно всего один раз.

Помним, что системное мышление указывает на концепцию использования как необходимый объект внимания в проекте, методология учит, что изменение состояний концепции использования нужно будет отслеживать по альфам, а сама она будет изложена в самых разных рабочих продуктах/артефактах, но вот методам работы по разработке концепции использования (дисциплине/знаниям/теории, дающим набор альф по выявлению внешних проектных ролей, их потребностей, выявлению важных событий в использовании, выявлению сценариев happy path и сценариев при обнаружении затруднений в использовании, а также использованию моделеров для документирования концепции использования, и т.д.) учит системная инженерия.

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

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

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

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

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

В стандарте OMG Essence^[1] для ALPHA придумали аббревиатуру, Abstract-Level Progress Health Attribute, но эта аббревиатура про health attribute была для альфы подобрана задним числом (просто потому, что альфы нужны были для отслеживания их изменения в ходе проекта — если не изменяются, то проект «нездоров»), а слово alpha часто пишут поэтому маленькими буквами, чтобы не акцентировать липовую «аббревиатурность».

Повторим: в стандарте OMG Essence есть две части: язык/language, который вводит понятия альфы, рабочего продукта, работы (и мы их используем), и ядро/kernel как предлагаемый стандартом начальный набор основных**/ядерных/**kernel альф (в kernel также предлагаются и какой-то набор стадий/этапов проекта, мы их тут не рассматриваем), чаще всего встречавших в софтовых проектах некоторое время назад. Предложенные стандартом в kernel альфы — проектные роли, возможность создания системы, требования, воплощение системы, команда, способ работы, работы. Стандарт активно разрабатывался где-то до 2015 года (последние косметические изменения там сделаны были в 2024 году, версия 2.0), поэтому одна из основных альф предложенного примера kernel в стандарте — требования. Но инженерия требований как один из частных методов общеинженерной работы оказалась не такой удачной идеей, когда перешли к непрерывной гибкой/agile разработке, поэтому требования перестали разрабатывать. Так что мы используем language из этого стандарта, но предлагаем другой набор основных альф (kernel), что прямо предусмотрено в стандарте (подробней об этом будет в руководстве по методологии). В нашем наборе альф для kernel — воплощение системы, описание системы, метод работы системы и работы системы в области интересов каждой из систем.

Альфы**—** это объекты**,** меняющиеся в ходе проекта. Альфы как предметы методов работы меняют свои состояния в ходе работ по методам**.** Альфы**—** это те важные объекты, изменения которых****в проекте мы хотим знать, понимать, отслеживать, проводить**, направлять, контролировать** и для этого надёжно удерживать эти объекты во внимании команды**.**Наверняка вы это уже запомнили. Это означает, что если:

• Самолёт::система, то мы воображаем его сразу в операционном окружении в момент, когда он летит, как физический объект, прежде всего функциональный физический объект, но воплощённый конструктивными физическими объектами, которые все занимают какие-то места и сколько-то стоят. Это первое поколение системного мышления. Первое поколение главным образом использует отношение композиции, системные уровни тут**, разговор про подсистемы****.**
• Самолёт::«альфа воплощения системы», то мы воображаем его сразу предметом метода разработки, проходящим какие-то состояния, например, «самолёт только-только задуман», «самолёт спроектирован», «изготовлен» и «самолёт в его операционном окружении в момент, когда он летит». Это предмет метода работы создателей в графе создателей, второе поколение системного мышления. Второе поколение системного мышления главным образом использует отношение создания, системы как предметы методов работы создателей тут. Разговор про альфы и изменение состояний альф создателями системы тут.
• Самолёт::«версия системы», то мы воображаем ряд феномов (воплощений системы, аналог фенома^[2] в биологии — «фактическое описание взрослого организма»), соответствующих разным мемомам^[3] (описаниям в проекте/design системы, аналог генома^[4] в биологии — гены, описывающие взрослый организм как проект/design). Третье поколение системного мышления обсуждает эволюцию систем, в том числе дарвиновскую для живых систем (на основе геномов, которые хранятся в каждой клетке организма) и техно-эволюцию, поэтому основным отношением кроме отношения создания является отношение развития**(между версиями системы, трассируемое, конечно, к версиям описания****—** как развитие видов организмов как феномов в ходе эволюции трассируется к развитию их геномов). Разговор про непрерывность разработки и версионирование**—** тут.

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

Рабочий продукт/артефакт/исполнитель роли представляет/represent (или в OMG Essence говорят не термин из семантики «представление/representations» знаком понятия, а о свидетельствовании/evidence объектом модели состояния другого объекта) собой альфу в реальном мире. Это «яблоко из жизни», «его едят» — продукт в реальном мире определяется в физических границах, он материален. Продукты/артефакты — это документированные спецификации, документированные тесты, документированные диаграммы и какие-то документированные модели, базы данных, а также и физические объекты (люди-исполнители проектных ролей, оборудование, материалы, здания и сооружения). Рабочим продуктом могут быть и какие-то мероприятия (совещания, презентации, уборка рабочего места), которые можно представлять «вещественно» как совокупность участвующих в этом мероприятии взаимно изменяющихся объектов. Мероприятие как артефакт тоже может увеличивать детальность в своей подготовке — оно может быть готово «в основных чертах», «спланировано», «организаторы сами организованы», «люди приглашены», «площадки подготовлены», «проходит», «завершено», «уборка площадок закончена». Но нельзя объявлять системой процессы/методы. Помним: если мероприятие или перформанс с чётким временем начала и конца, в него можно ткнуть пальцем (в материальное место, где оно проходит) — моделировать можно, а вот если это что-то долгое-непрерывное типа «течение воды», или «человеческая жизнь», или «работа предприятия», то моделировать процесс как продукт/артефакт нельзя.

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

Скажем, концепция использования может быть представлена в трёх разных документах — фрагменте начального технического задания как приложения к договору (часто под названием «предмет работы»/scope of work), тексте учебника по прикладной области, где используется система подобного сорта (или стандарте, где описываются подобные системы), а ещё в протоколе совещания, где обсуждались потребности внешних проектных ролей. О состоянии концепции использования (насколько продвинулись в её разработке, в чём там основные проблемы, что нужно с ней делать дальше) можно будет сказать, только рассмотрев все эти три документа — то есть состояние «концепции использования»::альфа (состояние концепции использования как предмета метода разработки концепции использования в ходе работ по этому методу) свидетельствуется в данном случае тремя документами. А какие документы свидетельствуют состояние концепции использования в вашем проекте?

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

Эта связь продуктов и их альф обычно определяется в рамках какого-то метода работы. Рабочие продукты и инструментарий метода ситуативны для каждой конкретной организации и даже конкретного проекта, а вот альфы более стабильны. Скажем, в методе проектного управления теория проектного управления (в науке — operations research^[5]) одна и та же, а вот инструментарий (софт проектного управления, моделер для проектов) в разных проектах может быть очень разным. Метод/способ/практика работы определяется по его теории/дисциплине/объяснениям с их предметами, но в целом метод описывается не только теорией и дисциплиной работы с предметами прикладной предметной области, но и включает в себя описания работ с инструментарием. Инструментарий обычно уникален для проекта, он состоит из разной аппаратуры, оборудования, программно-аппаратных комплексов, которые часто надо ещё и разработать в рамках самого проекта, поэтому работы по одному и тому же методу могут сильно отличаться — рытьё котлована лопатами и экскаватором имеет один и тот же метод «рыть», предмет метода «котлован», альфа котлована будет отражать его состояния (начиная с «потребность в котловане осознана», дальше через «проект/design котлована готов», «инструментарий рытья выбран», «рытьё начато», «котлован вырыт»), но вот как это в мире будет выглядеть — отличаться для лопат и экскаватора будет сильно. А ещё котлованы роют взрывом.

Экономия мышления заключается в том, что часто в проекте даже не очень большой сложности состояние одной альфы отражается/представляется в десятках разных артефактов/продуктов (часто документах или базах данных, но помним и о просто физических объектах, и даже людях). Мышление/рассуждения тем самым ведутся только для одного объекта-альфы, но при разбирательстве с какими-то конкретными характеристиками ситуации (concerns) вытаскиваются отдельные индивидуальные продукты, в которых отражены именно эти характеристики (дано соответствующее описание/view, следующее методу описания/viewpoint, отражающему нужную важную характеристику/concern). Например, «насос готов к проведению пуско-наладочных работ?» — в то же время свидетельства готовности насоса::воплощение системы к пуско-наладочным работам может быть разбросано (кроме факта наличия самих рабочих продуктов, представляющих насос «в металле») по десяткам разных документов: актов сдачи работ различными подрядчиками, актов предварительных испытаний, писем контрагентов, записей в базах данных систем управления активами предприятия, сообщений о наличии расходных материалов и т.д.

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

Мы будем смотреть на какие-то артефакты, чтобы понимать, в каком состоянии находятся представляемые ими альфы — главные объекты нашего внимания в проекте. Как альфа меняется, проходя по мере выполнения с ней работ метода разработки свои состояния, продукт****ы/артефакты меняются в ходе проекта**, проходя уровни детальности****.** Код компьютерной программы может быть записан в виде идеи, в виде псевдокода, в виде кода с ошибками, в виде компилируемого без ошибок кода, в виде хорошо откомментированного кода — детальность нарастает, но это вовсе не означает, что альфа «код компьютерной программы» при этом приближается к готовности: вполне возможно, что не нужно было хорошо комментировать код, а нужно было даже поменять идею этого кода, документировать совсем другую идею! Подробней это различие состояний альф и уровня детальности рабочих продуктов разбирается в OMG Essence, мы не будем это разбирать в нашем руководстве. Работа с состояниями рабочих продуктов рассматривается в инженерии, мы же в системном мышлении и тем более методологии будем сосредоточены на альфах: на важнейших объектах внимания в проектах, изменение состояний которых говорит о ходе проекта.

Продукты/артефакты в ходе инженерного (предмет метода инженерии**—** киберфизическая система)****, менеджерского (предмет метода инженерии**—** организация), учебного (предмет метода инженерии**—** мастерство), культурного (предмет метода инженерии**—** сообщество) создаются, модифицируются, уничтожаются. Они вместе с их уровнями детальности наблюдаемы, в отличие от альф, о состояниях которых мы можем судить только «по приборам» — по рабочим продуктам. Но главное**—** это состояние альф!

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

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

Альфу системного описания можно представить проходящей состояния (помним, что эти состояния нужно адаптировать для разных проектов: для какого-нибудь музыкального, или учебного, или медицинского проекта системное мышление вполне применимо, но вот многие термины для состояний альфы системного описания в этих проектах лучше бы заменить на термины мета-модели из музыки, обучения, медицины, равно как уточнить сами состояния):

• Замышлено (ясно, каково будет описание системы)
• Непротиворечиво (описание системы создано и непротиворечиво)
• Используется для изготовления (описание используется для изготовления воплощения системы)
• Используется для инженерных обоснований воплощения (описание используется для проведения тестов и испытаний)
• Используется для эксплуатации (используется проектными ролями для эксплуатации воплощения системы)
• Используется для вывода из эксплуатации (используется для ликвидации и/или переработки воплощения системы)

Концепция использования — это подальфа описания системы (system definition): чем более готова концепция использования, тем более готово описание системы. Помним, что одна и та же концепция использования, одно и то же описание системы могут быть отображены на разных носителях разными методами, с использованием даже разных нотаций — какая-то степень готовности описаний означает их содержательную готовность, а не степень документированности! Степень документированности — это степень роста детальности в изготовлении рабочего продукта, а степень готовности концепции использования — это про альфу, предмет метода, про готовность содержания (насколько продвинулись в выявлении сценариев использования), независимо от оформления в рабочем продукте/документации.

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

• Замышлена (conceived, внутренние проектные роли согласились в необходимости новой системы для удовлетворения потребностей внешних проектных ролей)
• Ограничена (bounded, основная функция/назначение/сервис новой системы понятна)
• Непротиворечива (coherent, концепция использования непротиворечиво описывает основные сценарии использования, в том числе существенные характеристики новой системы)
• Приемлема (acceptable, концепция использования описывает такую систему, которая приемлема как для внутренних, так и для внешних проектных ролей)
• Отвечена (addressed, воплощение системы удовлетворяет концепции использования настолько, что система принимается внешними проектными ролями в эксплуатацию)
• Удовлетворена (fulfilled, воплощение системы полностью отвечает концепции использования, внешние проектные роли считают систему успешной)

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

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

Архитектура — это тоже подальфа описания системы: чем более готова архитектура, тем более описана система. «Рабочка» (детальные модели/чертежи, а в случае софта это исходный код, готовый для компилирования) тут тоже подальфа описания системы.

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

---

1. http://www.omg.org/spec/Essence/ ↩︎

2. https://ru.wikipedia.org/wiki/Феном ↩︎

3. https://en.wiktionary.org/wiki/memome ↩︎

4. https://ru.wikipedia.org/wiki/Геном ↩︎

5. https://en.wikipedia.org/wiki/Operations_research ↩︎