Альфа описания системы

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

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

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

Состояние альфы описания системы свидетельствуется проектной документацией (которая может быть в базах данных инженерного и менеджерского софта, о бумаге давно забыли), описание ставится под управление конфигурацией: описано обычно несколько вариантов системы, в реализацию идёт или один из них, или даже несколько (скажем, в продуктовых семействах или при A|B тестировании).

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

Речь может идти не только о создании всего описания для впервые создаваемого MVP системы, но и об описании инкремента/модернизации или какой-то отдельной фичи системы. Вы можете использовать подобный чеклист и не для полного описания, а для какого-то частного, лучше бы сразу работать с подальфами, но альфа описания системы нужна, чтобы был пункт чеклиста, где вы задумаетесь, какие там вообще описания есть, какие нужны подальфы для отслеживания состояния отдельных частных описаний/views.

Описание системы (или её инкремента, фичи, опции) может иметь состояния:

• Замыслено (conceived): внешние проектные роли и команда согласны, что система будет сделана; методы описания системы согласованы; способ согласования частных описаний с внешними проектными ролями согласован; механизмы управления конфигурацией документации согласованы.
• Непротиворечиво (coherent): частные описания системы документированы; документация доступна команде и внешним проектным ролям; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда понимает описания и соглашается их воплотить; соответствующая описаниям система ожидается как успешная (в ней учтены интересы внешних проектных ролей).
• Используется для изготовления (inuseformanufacturing*)**😗 изготавливающая систему часть команды считает, что описаний системы хватает для начала изготовления/производства; методы/технологии изготовления по этим описаниям системы сами описаны и документированы; возникающие при изготовлении системы проблемы приводят к доработке и актуализации описаний системы.
• Используется для инженерных обоснований воплощения (inuseforassurance*)😗 есть все описания, нужные для инженерного обоснования успешности системы (assurance case); испытания/тесты, критерии их успешности и способ проведения определены; внешние проектные роли согласны с объёмом испытаний/тестов.
• Используется для эксплуатации (inuseforoperations*)**😗 описание системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); описание системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации/развитии системы.
• Используется для вывода из эксплуатации (inuseforretirement*)**:*используется для определения момента вывода из эксплуатации или принятия решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.

Повторим: приведённые выше состояния альфы описания целевой системы являются настолько общими, что для реального проекта должны быть обязательно конкретизированы — и в части терминологии и самих состояний, принятых для описания системы, но также и в части подальф.

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

Оргмодель (или её инкремент для оргизменения) может иметь состояния:

• Замыслен**а (conceived): служба оргразвития согласна, что организация проекта будет создана; методы моделирования организации проекта согласованы; способ согласования оргмодели с внешними проектными ролями службы оргразвития согласован; механизмы управления конфигурацией оргмодели согласованы.
• Непротиворечив**а (coherent): оргмодель документирована, документация доступна службе оргразвития и команде проекта; происхождение оргмодели ясно; оргмодель проверяется; противоречия в оргмодели выявлены и ими занимаются; служба оргразвития понимает оргмодель и соглашается её воплотить; соответствующая оргмодели организация проекта принимается службой оргразвития как заслуживающая воплощения.
• Используется для лидерства (inuseforleadership*)**😗 служба оргразвития считает, что оргмодели хватает для начала создания организации проекта; методы оргразвития по этой оргмодели сами отмоделированы и документированы; возникающие при организации команды проекта проблемы приводят к доработке и актуализации оргмодели.
• Используется для работы (inuseforoperations*)**😗 оргмодель используется для сбора операционной информации о состоянии проекта (цифровой двойник, digital twin); оргмодель наряду с операционной информацией цифрового двойника используется для принятия решений о совершенствовании (непрерывных улучшениях) и развитии.
• Используется для роспуска команды проекта (inuseforadjourn*)**😗оргмодель используется для определения момента роспуска команды проекта или принятии решения о продолжении работы; демонстрирует отсутствие вредных эффектов (например, выполнение каких-то сервисов, до сих пор нужных для внешних по отношению к команде проекта оргзвеньев предприятия) при роспуске команды проекта; используется для планирования и проведения работ по роспуску или перепрофилированию.

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

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

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

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

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

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

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

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