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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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