Альфы ​

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

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

Это как раз то, что физиков и инженеров отличает от математиков/чистых логиков: физиков волнует, чему в реальном мире соответствуют их формулы, а математиков/чистых логиков не волнует.Физики озабочены тем, чтобы аннотировать типами математики типы физических объектов.

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

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

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

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

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

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

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

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

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

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

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

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

Формально (то есть в стандарте OMG Essence^[1]) ALPHA --- это аббревиатура, Abstract-Level Progress Health Attribute, но неформально --- это просто способ указать на функциональный элемент/ролевой объект/понятие из какой-то дисциплины/теории/мышления проекта, связанного с системой. Аббревиатура про health attribute была для альфы подобрана задним числом (просто потому, что альфы нужны были для отслеживания их изменения в ходе проекта --- если не изменяются, то проект «нездоров»), а слово alpha часто пишут поэтому маленькими буквами, чтобы не акцентировать липовую «аббревиатурность». При этом в стандарте OMG Essence есть две части: язык/language, который вводит понятие альфы (и мы его используем), и ядро/kernel как предлагаемый стандартом начальный набор основных альф, чаще всего встречавших в проектах некоторое время назад (проектные роли, возможность создания системы, требования, воплощение системы, команда, способ работы, работы). Стандарт активно разрабатывался где-то до 2015 года, поэтому одна из основных альф там --- требования. Но инженерия требований как подкультура/подметод общеинженерной работы оказался не такой удачной идеей, когда перешли к непрерывной гибкой/agile разработке, поэтому требования перестали разрабатывать. Так что мы используем language из этого стандарта, но предлагаем другой набор основных альф (подробней об этом будет в курсе «Методология» и далее в курсах «Системная инженерия» и «Системный менеджмент»).

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

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

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

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

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

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

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

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

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

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