Системное мышление

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

Формально (то есть в стандарте OMG Essence124) ALPHA – это аббревиатура, Abstract-Level Progress Health Attribute, но неформально это просто способ указать на функциональный элемент/компоненту проекта. Аббревиатура про health attribute была для альфы подобрана задним числом, а слово alpha пишут поэтому маленькими буквами.

Альфы – это то, что изменяется в ходе проекта, меняя свои состояния. Альфы – это то, изменения чего в проекте мы хотим понимать, отслеживать, обеспечивать, направлять, контролировать.

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

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

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

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

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

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

Как и альфа меняется, проходя состояния, рабочий продукт меняется, проходя уровни детальности. Рабочие продукты в ходе инженерного, менеджерского или культурного проекта создаются, модифицируются, уничтожаются. Они вместе с их уровнями детальности наблюдаемы, в отличие от альф, о состояниях которых мы можем судить только «по приборам» – по рабочим продуктам.

Описание системы

(Полное) описание системы (system description) это рабочие продукты, реализующие альфы (полного) определения системы (system definition). Если система есть, то она обычно (полностью) определена: подразумевается, что есть её требования, есть её архитектура, есть неархитектурная часть проекта/design, их только нужно выявить и как-то записать – на бумаге или в электронном виде в базе данных тут неважно. Важно чётко различать всегда существующее определение системы-альфу (есть система – значит кто-то её выделил из окружающего мира, думает о ней. Думает – значит определяет, «система в глазах смотрящего») и не всегда существующее описание системы-рабочий продукт.

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