Системная схема проекта

Стандарт OMG Essence предложил набор семи основных (essence, существенный, основной) альф проекта программной инженерии. Мы немного доработали этот набор альф для более общего случая системной инженерии, где информационные системы только один из многочисленных видов разрабатываемых систем. Эти альфы объединены в системную схему проекта (Рис. 8).

Оригинальный набор альф был получен путём экспериментального ответа на вопрос: какие объекты внимания команды присутствуют в каждом проекте разработки? Было рассмотрено более 250 проектов, и в системную схему попали только те из них, которые встречались буквально в каждом проекте.

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

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

Три области интересов (area of concerns) группируют эти семь альф по трём темам (помним, что «интерес» это интересующая разных стейкхолдеров тема, а не «чего хочется». «Чего хочется» это будет не сам интерес, а оценка/assesment интереса разными стейкхолдерами):

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

• Область интересов инженерного решения (solution) относится к определению и воплощению целевой системы. Это то, чем в команде проекта будут заниматься самые разные инженеры, создающие сначала определение системы (чтобы уменьшить число проб и ошибок), а затем работающие над удовлетворяющим этому определению системы воплощением системы. Стейкхолдеры используют воплощение целевой системы в использующей системе, удовлетворяя тем самым свои потребности. Ведущие практики – инженерные.

• Область интересов предпринятия (endeavor) относится к работам, технологии и команде – обеспечивающей системе. В проекте нужно управлять работами, управлять жизненным циклом (определять практики и способы назначения работ на практики), разворачивать и использовать технологии, поддерживать сотрудничество компетентной команды. Этим в команде занимаются операционные менеджеры (практики управления работами), CTO/CIO (chief technology/information officer, их прерогатива в отличие от системных инженеров и инженеров по специальностям работоспособность методологии разработки и производства, т.е. оргвозможности поставленных практик, особенно входящих в их состав технологий – практики технологического менеджмента), организаторы, управляющие талантами (практика поставки в команду компетентных в необходимых для практики дисциплинах сотрудников-актёров), лидеры (практики лидерства, обеспечения сотрудничества как качественного выполнения своих стейкхолдерских ролей членами команды).

Какая альфа главная на системной схеме проекта? С одной стороны, все альфы. Но с другой стороны – альфа воплощения системы, привязывающая все рассуждения по схеме к физической реальности (воплощение системы – 4D индивид). Это видно в том числе и по числу связей на диаграмме, воплощение системы имеет максимальное число связей: оно обеспечивает возможности, его используют стейкхолдеры (внешним стейкхолдерам нужно воплощение системы, это только инженерам нужно определение системы, чтобы с меньшим количеством проб и ошибок получить удовлетворяющее стейкхолдеров воплощение системы – и воплощение системы удовлетворяет этому определению системы), его в конечном итоге производит команда.

 

V-диаграмма и системная схема проекта

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

Вот, например, схема, полученная добавлением подальф определения и воплощения системы (Рис. 9).

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

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

На диаграмме хорошо видно, что возможности проекта определяются в том числе тем, как потребности стейкхолдеров фокусируют требования.

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

То же относится к системной архитектуре: она разрабатывается не любая, но её разработка сфокусирована на поддержке требований. И рабочая документация (non-architectural part of design, неархитектурная часть проекта/design, «рабочка») берётся не любая, её появление фокусируется архитектурой. Часто в инженерной документации требуют явно указать, какая архитектура вызвала те или иные инженерные решения в рабочей документации, какие требования вызвали те или иные архитектурные решения, какие потребности заставили сформулировать те или иные требования. Явное документирование этих связей называют трассировкой (trace). Трассировка помогает избежать типовых ошибок фокусирования, когда в проекте появляются лишние требования, или наоборот, недостаточно требований – какая-то потребность не ведёт ни к каким требованиям).

Члены команды выполняют практики жизненного цикла, работая с альфами проекта, продвигая их по состояниям к завершению проекта.

В приведённой диаграмме возможности, определение системы, стейкхолдеры и определение системы – это просто фрагмент основной схемы проекта, а все другие альфы к ним пририсованы.

Форма V-диаграммы позволяет легко обсуждать в системной схеме проекта разницу между проверками (verification, соответствия определения системы и воплощения системы) и приёмкой (validation, обеспечение воплощением системы возможностей, т.е. удовлетворительная работа использующей системы со включённой в неё целевой системой). На системной схеме проекта эта разница наглядна.

 

Альфы – общий объект отслеживания команды

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

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

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

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

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

 

Альфа возможности

Из V-диаграммы с подальфами хорошо видно, что потребности/требования стейкхолдеров это подальфы возможности, а не подальфы определения системы.

Альфа возможности (opportunity) заключается в состоянии дел с самой возможностью выполнить проект по созданию целевой системы. Целевая система будет разрабатываться, изготавливаться, эксплуатироваться только в том случае, когда

• Она будет кому-то нужна, и за неё смогут заплатить

• Её кто-то сможет сделать за разумную плату.

Это ведёт к следующим возможным подальфам возможностей:

• Потребности стейкхолдеров (нет потребностей – нет возможности сделать проект, никто не заплатит).

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

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

Альфа возможности важная альфа (нет возможности проекта – команда не должна его делать), но инженеры и операционные менеджеры часто о ней забывают после заключения контракта, она интересует предпринимателей, но те тоже склонны больше заниматься стейкхолдерами и их потребностями, чем балансировать эти потребности с потенциалом вооружённой технологиями команды эти потребности удовлетворить. Информация о том, сколько стейкхолдеры готовы отдать за целевую систему или предоставление сервиса, обычно доступна на самом старте проекта (хотя и не всегда: если речь идёт о выпуске продукта на массовый рынок, то с ценообразованием можно крупно промахнуться – информация о цене покупки может оказаться неверной). Но вот информация о том, сколько реально будет стоить система, включая её разработку, изготовление, наладку, испытания – вот эта информация будет меняться в ходе всего проекта. Поэтому команде нужно постоянно следить за альфой возможности, причём не только за подальфой потребности, но и за подальфами оценок выгодности.

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

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

Альфа возможности в ходе проекта проходит следующие состояния/контрольные точки (в формулировках в том числе подчёркивается связь состояния этой альфы с состояниями других альф):

• Выявлена (identified): найдена идея; найден как минимум один стейкхолдер, желающий сделать инвестицию в понимание возможности; определены другие стейкхолдеры.

• Нужно решение (solution needed): выявлено инженерное и/или культурное решение; установлены потребности стейкхолдеров; определены проблемы и их причины, подтверждено, что стейкхолдерам это решение нужно; было предложено как минимум одно архитектурное решение.

• Польза установлена (value established): польза возможности была определена количественно; влияние решения на стейкхолдеров понятно; польза системы стейкхолдерами понимается; критерии успешности ясны; результаты ясны и выражены количественно.

• Жизнеспособна (viable): решение обрисовано в общих чертах; решение возможно с учётом ограничений; риски приемлемы и управляемы; решение выгодно; причины для разработки решения понимаются; ясно, что реализация возможности жизнеспособна.

• Реализована (addressed): возможность реализована; решение достойно воплощения; стейкхолдеры удовлетворены;

• Извлекается выгода (benefit accrued): решение приносит выгоду; возврат на инвестиции приемлем.

 

Альфа стейкхолдеров

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

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

Хорошей практикой является сразу разделение альфы «стейкхолдеры» на отдельные подальфы «стейкхолдер» и раздельный учёт состояния этих подальф.

Вот состояния/контрольные точки для стейкхолдеров:

• Признаны (recognized): группы стейкхолдеров выявлены; ключевые группы стейкхолдеров представлены; ответственности представителей стейкхолдеров определены.

• Представлены (represented): стейкхолдеры согласились с ответственностью; представители получили полномочия; подход к сотрудничеству согласован; практики работы поддерживаются и уважаются.

• Вовлечены (involved): представители помогают команде; реагирование представителей на запросы своевременно и они предлагают решения; изменения сообщаются вовремя.

• В согласии (in agreement): минимальные ожидания согласованы; представители стейкхолдеров довольны своим вовлечением; вклад стейкхолдеров приносит пользу; вклад команды приносит пользу; приоритеты ясны и перспективы команды и стейкхолдеров сбалансированы.

• Удовлетворены для разворачивания (satisfied for deployment): имеется отклик/feedback стейкхолдеров; система готова для разворачивания.

• Удовлетворены в использовании (satisfied in use): отклик/feedback по использованию системы доступен; система отвечает ожиданиям.

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

 

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

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

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

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

• Замыслено (concieved): стейкхолдеры согласны, что система будет сделана; методы описания системы согласованы; способ согласования описаний со стейкхолдерами согласован; механизмы управления конфигурацией описаний согласованы.

• Непротиворечиво (coherent): определения системы документированы, и описания доступны команде и стейкхолдерам; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда понимает описания и соглашается их воплотить; соответствующая описаниям система принимается стейкхолдерами как заслуживающая воплощения.

• Используется для изготовления (in use for manufacturing): изготавливающая систему часть команды считает, что описаний хватает для начала изготовления; технологии изготовления определены и описаны; возникающие при изготовлении системы проблемы приводят к доработке и актуализации определения системы.

• Используется для проверки и приёмки воплощения (in use for V&V): есть все описания, нужные для проверки и приёмки; проверки, критерии их успешности и способ проведения определены; стейкхолдеры согласны с объёмом проверок.

• Используется для эксплуатации (in use for operations): определение системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); определение системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации.

• Используется для вывода из эксплуатации (in use for retirement): используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.

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

 

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

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

• В виде сырья (as a raw material): материалы для воплощения системы наличествуют и позволяют создать части системы с нужными характеристиками; оборудование для переработки материалов в детали наличествует; график производства и логистики частей системы согласован; возможны работы по изготовлению частей.

• В виде частей (as a parts): части воплощения системы созданы и/или закуплены и проверены; график интеграции (сборки, монтажа, строительства) из частей согласован; возможны работы по интеграции (сборке, монтажу, строительству).

• Демонстрируемо (demonstrable): воплощение системы может быть опробовано в отдельных функциях и ключевые характеристики могут быть измерены; ключевые характеристики могут быть продемонстрированы стейкхолдерам; критические интерфейсы были продемонстрированы; готова к проверке; необходимые стейкхолдеры согласны, что систему нужно проверять.

• Готово (ready): функциональность протестирована; уровни дефектов для стейкхолдеров приемлемы; установочная и другая пользовательская документация доступна; представители стейкхолдеров удовлетворены системой; состав передаваемой системы известен; представители стейкхолдеров готовы эксплуатировать систему; эксплуатационная поддержка наличествует.

• Эксплуатируется (operational): доступна стейкхолдерам для эксплуатации в рабочем окружении; есть как минимум один пример работающей системы; поддерживается на согласованном уровне сервиса.

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

 

Альфа работы

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

• Инициирована (initiated): требуемый результат работ ясен; ограничения ясны; известен стейкхолдер, который платит за работы; инициатор выявлен; принимающие работу стейкхолдеры известны; источник денег ясен; приоритеты ясны.

• Подготовлена (prepared): обязательства приняты; цена и потребные усилия оценены; доступность ресурсов понимается; правила и процедуры контроля ясны; критерии приёмки определены и согласованы; работы разбиты на части в достаточной для начала работ мере; задачи (tasks) определены, приоритеты для них расставляются; наличествует правдоподобный план; финансирование работ наличествует; как минимум, один человек из команды готов начать работу; моменты интеграции результатов работы определены.

• Начата (started): работа по разработке начата; прогресс работы отслеживается; работа разбита на единицы действий с ясными определениями того, что нужно сделать; члены команды принимают и выполняют задания.

• Под контролем (under control): количество завершённых задач растёт; незапланированная работа под контролем; риски под контролем; оценки пересматриваются, чтобы отражать реальную производительность команды; прогресс измеряется; переделки под контролем; обещания выполнения работ выполняются.

• Закончена (concluded): остались только административные задачи; результат работ был достигнут; стейкхолдеры приняли результирующую систему.

• Закрыта (closed): метрики были сделаны доступными для других проектов; всё было заархивировано; бюджет был сверен и закрыт; команда была освобождена; нет незавершённых недоделанных задач.

 

Альфа команды

Альфа команда представляет собой тех сотрудников, которые охотно и качественно выполняют роли внутренних стейкхолдеров. Ведущие дисциплины тут – управление персоналом (human resources management), управление талантами (talent management, занимающиеся обеспечением организации сотрудниками-актёрами и их подготовкой к выполнению внутренних стейкхолдерских ролей в командах проектов, а также практика лидерства (leadership), занимающаяся обеспечением сотрудничества в команде, т.е. качественного отыгрывания стейкхолдерских ролей и продуктивного взаимодействия с другими членами команды.

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

• Намечена (seeded): миссия команды определена; ограничения известны и явны; механизмы роста команды наличествуют; состав команды определён; обязанности команды обрисованы в общих чертах; уровень принятых командой обязательств ясен; требуемые компетенции определены; размер команды определён; правила надзора за деятельностью определены; вид/форма лидерства выбрана.

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

• Сотрудничает (collaborating): команда работает как одно сплочённое подразделение; общение в команде открытое и честное; команда сфокусирована на достижение миссии команды; члены команды знают друг друга.

• Производит (performing): команда постоянно выполняет обязательства; команда непрерывно адаптируется к изменяющемуся контексту; команда определяет и решает проблемы без внешней помощи; минимум возвращений к сделанному и переделок; работа впустую (waste) и причины для работы впустую постоянно устраняются.

• Распущена (adjourned): обязанности были выполнены; члены команды доступны для участия в других командах; миссия завершена.

 

Альфа технологии

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

Поэтому мы приняли решение для way of working говорить о том, что осталось от практики и разворачивается на самом предприятии – о технологии, но рекомендуем при этом не забывать о практике в целом, и это отражено в формулировках состояний альфы/контрольных точек. Конечно, говорить сразу о всех практиках и всех их технологиях не получится – поэтому лучше всего будет отслеживать в проекте связанные с технологиями подальфы отдельных практик/способов работы/технологий, а то и дробить их дальше на подальфы инструментов и отдельных рабочих продуктов.

Вот состояния/контрольные точки основной альфы «технологии»:

• Дисциплина установлена (principles established): команда активно поддерживает дисциплину/теорию/принципы; стейкхолдеры согласны с принципами; потребные для их поддержки инструменты согласованы; рекомендации по выбранному подходу доступны; рабочий контекст понимается; ограничения практики и выбранных в её составе инструментов известны.

• Основа положена (foundation established): ключевые практики и их инструменты выбраны; практики, необходимые для того, чтобы начать работу, согласованы; практики, по которым не будет обсуждений и их инструменты выявлены; разрыв между доступными и необходимыми оргвозможностями/capability определён; способ работы, в котором все практики удобно использовать, определён.

• Используется (in use): практики и их инструменты используются; использование практик и их инструментов регулярно проверяется; практики и их инструменты адаптированы к контексту; практики и их инструменты поддерживаются командой; механизмы получения откликов/feedback на практики и их инструменты работают; практики и их инструменты поддерживают общение команды и сотрудничество.

• Наличествует (in place): практики и их инструменты используются всей командой; оргвозможности доступны всей команде; проверяются и адаптируются всей командой.

• Работает хорошо (working well): делается предсказуемый прогресс; практики применяются естественным образом; инструменты естественным образом поддерживают принятую дисциплину работы; идёт постоянное совершенствование/подстройки.

• Вышла из употребления (retired): больше не используется; уроки использования практики опубликованы для использования в будущем.

 

За чем следить в проекте

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

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

Системная схема проекта представляет собой ровно такой чеклист: на верхнем уровне это альфы, которые необходимо удерживать во внимании всё время проекта. Если члены команды не задумывались о состоянии какой-то из альф, то возникают большие риски, что там что-то может пойти не так – просто потому, что не хватило внимания. Проект создания системы обычно не менее сложен и хлопотен, чем взлёт самолёта, поэтому можно ожидать отсутствия самых понятных и простых работ – например, можно в суете проекта забыть наладить коммуникацию со стейкхолдерами, или даже забыть провести проверку и приёмку системы.

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

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

Всего семи объектов внимания в проекте не будет хватать – тем более в больших проектах. Поэтому команде необходимо уделять внимание не только альфам, но и подальфам, на что мы обратили внимание, когда описывали основные альфы.

Но часто команда будет брать эти подальфы из дисциплин/теорий/принципов принятых ими практик. Например, в практике управления проектами методом критической цепи вводят альфу «буфер проекта» (project buffer) и отслеживают затем её состояние – сначала этот буфер проекта создаётся, потом потихоньку расходуется в ходе проекта. Essence предлагает, чтобы все эти подальфы обязательно были подальфами либо основных альф, либо друг друга (подальфы представляют собой направленный граф, в том числе подальфа может быть подальфой сразу нескольких основных альф или других подальф). Так, альфа «буфер проекта» может быть подальфой «работы». И ответ на вопрос «в каком состоянии работы проекта?» может включать в себя отдельный рассказ про состояние «буфера проекта».

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

 

Состояния альфы и рабочие продукты

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

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

«Стейкхолдеры признаны»

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

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

 

Как работают с системной схемой проекта

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

Альфы системной схемы проекта полезны не только для того, чтобы делать отчёт о ходе проекта, но и для того, чтобы давать полезный отклик по таким отчётам. Если в отчёте не сказано ни слова про команду, то обязательно нужно задать вопросы – в каком состоянии команда. Может выясниться много интересного. Это всё не будет случайными вопросами, альфы ведь эти выбраны не случайно, а отражают опыт многочисленных разработок, обобщённый авторами стандарта OMG Essence.

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

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

 

Подальфы

Подальфы и их состояния порождаются командой по потребности, когда команда понимает, что уровня контроля не хватает, и нужно внимание к частям ситуации, определяемой альфой. Подальфа – это просто альфа, только она не «верхнего уровня», не основная (essence), не из системной схемы проекта. Более того, у каждой альфы (в том числе у подальф) могут быть свои подальфы, а одна подальфа может быть подальфой нескольких альф и подальф. Примеры этих подальф можно брать в самом стандарте OMG Essence, можно брать в разнообразной литературе (прежде всего тут нужно указать на разработки Ivar Jacobson International по разработке альф для самых разных практик, особенно для гибких методологий).

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

• Признан – обоснование аутсорсинга есть; требования и ограничения для подсистемы есть; требования к гарантийному обслуживанию и ремонтным работам есть; требования к технологиям работы есть; сроки поставки определены; критерии приёмки результата есть; оценка возможной цены есть.

• Выбран – технико-коммерческие предложения получены; переговоры с кандидатами проведены; технико-коммерческие предложения оценены; подрядчик нами выбран.

• Привлечён – валютные, сроков поставки, качества и прочие риски оценены; договор с учтёнными рисками подписан; аванс перечислен; необходимая документация для начала работ передана; уведомление о начале работ получено; процедура коммуникации команды с исполнителями установлена.

• Работы идут – надзор за работами установлен; запросы обоих сторон учитываются; запросы обоих сторон своевременно решаются; график работ соблюдается; технология работ соответствует ожидаемой; коммуникация команды с исполнителем не прерывается.

• Работы приняты – уведомление об окончании работ получено; испытания проведены; претензий к качеству работ нет (претензии сформулированы и устранены); акты проведения успешных испытаний подписан; результаты работ доставлены на место; документация передана; монтажные работы произведены; пуско-наладочные работы проведены.

• Работы закрыты – акт приёмки-сдачи подписан; деньги перечислены; никаких дел к подрядчику нет; гарантийные и сервисные работы производятся; документация архивирована.

Регулярная проверка того, что сделано и что не сделано по такому чеклисту существенно снижает риски.

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

Как пользоваться постоянно раздувающимся списком подальф с их контрольными вопросами для прохождения контрольных точек может помочь практик работы с чеклистами, описанная в книге Атула Гаванде «Чеклист. Как избежать глупых ошибок, ведущих к фатальным последствиям».

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

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

 

Основной жизненный цикл

Горбатая диаграмма, использовавшаяся в RUP, получила своё развитие: в более современных версиях (например, из enterprise unified process, EUP, 2013) приводится другой набор практик и другой (полный, а не только стадии разработки и перехода к эксплуатации) набор стадий:

Интересно, что и тут есть трудности – попытка изобразить то, что происходит до момента запуска проекта как последовательности стадий работ, но в жизненный цикл попадает.

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

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

Дополнительное усложнение – это то, что у заказчика (владельца и часто разработчика использующей системы) и контракторов (разработчиков и производителей подсистем) свои жизненные циклы своих проектов, и их тоже нужно согласовывать.

 

Модели зрелости и модели готовности технологий

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

Например, для ISO 15288 (стандарта практик жизненного цикла системной инженерии) штатно предполагается использование модели зрелостей из ISO 1504 (стандарт проверки соответствия используемых практик описанным международными стандартами практик). Соответствие предполагает некоторые уровни, и вот эти уровни и есть «модель зрелости» (maturity model). Модели зрелости часто изображаются в виде «ступенек», по которым нужно «идти вверх»:

Модели готовности технологий (technology readiness) затрагивают как раз предыдущие по отношению стадиям модели зрелости группе стадий жизненного цикла технологии: о разработке. Например, Technology Readiness Level, разработанная 35 лет назад для аэрокосмоса, а затем распространившаяся в машиностроении нефтегазовой промышленности, где ступеньки-уровни для технологии ближе к классическому жизненному циклу в варианте 1.0, только речь идёт именно об инструментарии, «технологии»:

• TRL 1. Сформулирована фундаментальная концепция технологии и обоснование её полезности.

• TRL 2. Определены целевые области применения технологии и её критические элементы.

• TRL 3. Получен макетный образец и продемонстрированы его ключевые характеристики.

• TRL 4. Получен лабораторный образец, подготовлен лабораторный стенд, проведены испытания базовых функций связи с другими элементами системы.

• TRL 5. Изготовлен и испытан экспериментальный образец в реальном масштабе по полупромышленной технологии, проведена эмуляция основных внешних условий.

• TRL 6. Изготовлен полнофункциональный образец на пилотной производственной линии, подтверждены рабочие характеристики в условиях, приближенных к реальности.

• TRL 7. Прототип системы продемонстрирован в составе системы в реальных условиях эксплуатации.

• TRL 8. Окончательное подтверждение работоспособности образца. Разработка. функционирующей реальной системы завершена.

• TRL 9. Изделие удовлетворяет всем требованиям: инженерным, производственным, эксплуатационным, по качеству и надёжности. Возможна модификация по снижению себестоимости, развитию и эволюции системы. Функционирующая реальная система подтверждена в ходе реальной эксплуатации через успешное выполнение испытательных заданий.

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

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

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

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

 

Системные практики

Системное мышление не обещает, что его использование сразу решит все проблемы. Нет, его использование только позволит последовательно перемещать внимание с одной части ситуации на другую, ни в один момент не теряя из виду целого.

Системное мышление не даёт однозначный «объективный» ответ, оно требует организации коллективного мышления разных стейкхолдеров.

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

Нет, оно даёт только удобную нарезку мира на объекты внимания. Оно не столько помогает решать проблемы, сколько помогает эти проблемы выявлять чуть раньше, чем в жизни проявятся их последствия. Ибо в сложных системах причина и следствие часто разделены во времени и пространстве, типичная иллюстрация важности системного мышления (в котором непрерывно напоминается о том, что все отдельные рассмотрения только части целого) выглядит так:

Что делать после того, как выявлены проблемы? Включать мозг и решать эти проблемы, другого варианта нет. Системное мышление может только быстро подвести к проблемам чуть раньше, чем в жизни проявятся их последствия. Оно позволяет компактно и просто описывать сложный мир и выявлять риски непродуманности.

На протяжении всей книги мы учились только «как думать», если рассматривать мир состоящим из систем. Мы не учились ничего делать.

Для того, чтобы что-то делать, требуется отдельно потратить время на обучение практикам разных областей интересов – клиентской, инженерной, предпринятия. Это требует большого времени.

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

Но зачем тогда нужно системное мышление, если всем практикам нужно учиться отдельно?

Системное мышление нужно для того, чтобы разбираться со сложной коллективной деятельностью людей с самыми разными системами. Для каждой отдельной части системы системный мыслитель будет понимать её место в целой системе, для каждой отдельной практики системный мыслитель будет понимать её место в жизненном цикле системы, для всех своих умений системный мыслитель будет понимать ситуации, в которых возникает потребность в этих умениях. Системный подход нужен, чтобы упростить разбирательство со сложными ситуациями, сложными системами, не терять леса за деревьями отдельных специализированных практик. Системное мышление поможет специалисту ориентироваться в окружающей жизни, не теряться внутри своей частной работы, вписывать свой труд и свои знания в общий труд и знания для проекта, а также планировать своё личное развитие – возможность участвовать во всё новых и новых проектах.

 

Итоговое эссе

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

Эссе в нашем случае – это необязательно текст. Можно подготовить и устное выступление, а структуру содержания и диаграммы представить на слайдах. В любом случае это эссе нужно будет кому-то показать (менторам, коллегам, друзьям – желательно тем, кто уже как-то знаком с системным мышлением), чтобы получить отклик. Очень часто после подготовки эссе и получения отклика принимается решение перечитать учебник заново. И учебник затем читается как будто в первый раз, из него вычитывается много нового, не замеченного при первом чтении.

Потом вы в своей рабочей жизни постоянно будете готовить такие эссе: обзоры проекта следуют обычно именно этой логике.

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

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

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

Тем не менее, вот требования к содержанию эссе (но не к его форме):

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

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

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

Обратите внимание, что при описании нужно кратко характеризовать состояние альфы. Так, команда интересует не только на предмет закрываемых ей стейкхолдерских ролей (требуемых компетенций), но интересен вопрос – сотрудничает ли она? Продуктивна ли она? Помним про лидерство: как у вас с ним? Работы характеризуются прежде всего тем, как вы ими управляете: список работ тут бесполезен, он же будет меняться каждый день. Как вы определяете, какую работу из большого списка работ нужно делать прямо сейчас? Есть ли у вас какие-то ожидания по срокам окончания работ, по требуемым для этого ресурсам? Какие работы лежат на критическом пути, критической цепи? В каком состоянии буферы проекта? Технологии обязательно указывайте как поддерживающие какую-то дисциплину. Не знаете дисциплины? А что тогда поддерживают ваши технологии – работу по наитию?!

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

4. Рефлексия: случилась ли метанойя (помните материал первого раздела?) и по каким именно темам, что осталось непонятным в материале курса?

5. Планирование: какие у вас планы по продолжению образования в системном мышлении, системном менеджменте, системной инженерии, системном предпринимательстве, системным занятиям культурой, системном личном развитии?

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

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

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

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

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

 

Что дальше

Поздравляем, на этом учебник системного мышления закончен. Что делать дальше?

• Перечитайте учебник, в первой же главе довольно много рассказано о том, как обучаться мышлению: решать задачи, тренировать беглость, заняться ментальным фитнесом. Возможно, вам нужно позаниматься ментальным фитнесом перед перепрочтением учебника (например, разберитесь подробней, чем отличаются абстрактные объекты от индивидов, и как устроено мышление с использованием схем – как пользоваться полным спектром мышления от интуитивного через вероятностное до формального).

• Не просто перечитайте учебник, но и пройдитесь по ссылкам на литературу. В упомянутых в учебнике стандартах, публичных документах, книгах, статьях, энциклопедических справках для вас найдётся много интересного и полезного.

• Решайте задачи по системному мышлению (например, пройти курс на Coursera, где есть возможность решать эти задачи в интерактивном режиме, или курс в Школе системного менеджмента, где практикуется решение этих задач). При решении задач вы лучше поймёте значения разных понятий системного мышления.

• Если вы занимаетесь инженерией, то прочтите учебник «Системноинженерное мышление», в нём много дополнительного материала по системному мышлению, адаптированному именно для инженеров.

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

• Практикуйте системное мышление в каждой жизненной ситуации, в каждом своём проекте. Например, научитесь видеть в людях стейкхолдеров; начните сначала структурированно отслеживать внешнее окружение, а не сразу разбираться с внутренним устройством попадающих к вам в руки систем; ответы на самые разные вопросы самых разных людей делать только после уточнений «а какой стейкхолдер это сейчас спрашивает, и зачем это ему нужно?». И это будет только началом приобретения беглости в использовании системного мышления в вашей жизни.

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

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