Системные разбиения для разных проектных ролей оказываются тоже разными, ибо «система в глазах смотрящего»: каждое разбиение с его способом выделения из мира объектов внимания удобно для обсуждения каких-то одних предметов интереса, и неудобно для обсуждения других.
В проектах границы систем обычно стараются выбрать таким образом, что они как функциональная/ролевая часть, продуктная/конструктивная часть и размещение занимают одно и то же место в пространстве-времени, как изображено на картинке целым кубиком. Но если начинать одновременно разбираться с тем, как такая система работает (её функциональные части), из чего её сделать (модули, продуктные/конструктивные части), как она скомпонована (места/размещения), и сколько всё это будет стоить, то окажется, что иногда функциональные части, продуктные части, места в ней полностью совпадают (их и назовут «подсистемы» — подсистемы ведь тоже системы), но иногда такого совпадения не будет — и это намеренно, это нормально!
Так, ТРИЗ (теория решения изобретательских задач) повышает идеальность изобретаемых в ней систем тем, что несколько разных функций (помним: функция — это поведение функциональной/ролевой части системы в ходе работы надсистемы) выполняются в ней меньшим числом конструктивных частей — в идеальной системе все функции выполняются нулевым числом частей конструкции (конструкции вообще нет, а функции выполняются!), ТРИЗ стремится к этому. Так что нельзя гарантировать, что системное/функциональное разбиение, а также продуктное/конструктивное разбиение и пространственное разбиение совпадают. В 9 случаях из 10 они могут совпасть, но у вас будут огромные проблемы в проекте с оставшимся одним случаем, если вы не будете его учитывать!
Нельзя путать функциональные части и продукты/модули. Нельзя путать ролевого Принца Гамлета и конструктивного Василия Пупкина, даже если во время спектакля это одно и то же, они совпадают 1:1. Если вы будете за кулисами говорить Василию Пупкину «Ваше Высочество», а на сцене говорить Принцу Гамлету «как там твои жена и дети?», то окружающие на вас будут смотреть странно, а Василий Пупкин сильно озадачится в обоих случаях.
Мы уже рассматривали заварочный чайник, в котором всего два продукта/модуля (корпус и крышка) и довольно много функциональных частей (емкость, носик, заливочное отверстие в ёмкости, ручка ёмкости, крышка, ручка крышки, паровыпускное отверстие).
Кажется, что трудно перепутать в чайнике функциональные и конструктивные части? Увы, легко!
Рассмотрим на примере ножниц, что бывает, если люди путают функциональные (ролевые времени эксплуатации, работающие с окружением по их назначению) и конструктивные/продуктные/модульные (времени создания, над которыми работают системы создания для их проектирования и изготовления) части.
Для ножниц инженеры придумывают разные формы ручки и ножевого блока, думая о ручке и ножевом блоке как о функциональных частях. Они обсуждают ручки и ножевой блок как физически существующие (за ручку держат, считаются её размеры и гладкость, ножевым блоком режут — считаются его прочность и острота, угол раскрытия). Если менеджеры отдела закупок будут воспринимать ножницы состоящими из таких функциональных частей как из продуктов/изделий/модулей, то они попытаются заказать работы по изготовлению ручек и ножевого блока раздельно: ручки фирме, понимающей в эргономике, а режущий блок заводу, который умеет делать ножи («ножницы» как раз происходят от слова «нож»!). Инженеры от этого будут в шоке, поскольку они для целей изготовления и сборки начинают думать про ножницы как состоящие из модулей/рабочих продуктов: двух цельных кусков металла специальной формы, скреплённых винтиком. Заказать можно только продукты, а ручка и ножевой блок у ножниц только ролевые/функциональные элементы — их роль никто не играет, если нет назначенных на эти роли продуктов/модулей! Модулями в ножницах будут только две половинки ножниц (а ещё винтик). Если делать ручки и ножевой блок отдельно как модули, а потом их как-то скреплять, то это будет плохое и ненадёжное инженерное решение. Вот ножницы на момент «как делать» (модульное разбиение):
image1420×511 93.4 KB
Менеджеры же сначала внимают доводам инженеров, но потом… смотрят на ножницы в сборе, видят в действии (эксплуатации, operations) ручку и ножевой блок — и опять пытаются с ними сделать что-то по отдельности не в момент «спектакля» (когда ножницы в сборе и работают — режут), а в момент изготовления. Например, разделить работы по сборке ручки и ножевого блока, хотя при соединении половинок ножниц винтиком разделить работы по ручке и ножевому блоку принципиально невозможно. Или сделать каталог ручек и каталог ножевых блоков и потом пытаться заставить инженеров выпускать эти якобы «детали ножниц» в виде запчастей. Список ошибок и заблуждений тут бесконечен, и эти ошибки не прекратятся: менеджеры постоянно находят «ножевой блок» и «ручки» в инженерной документации и пытаются поступать с ними как со сборочными единицами.
Правда в том, что в ножницах разные проектные роли усматривают два разных разбиения: одна функциональной декомпозиции («аналитическая»), а вторая модульной сборки («синтетическая»):
image765×309 9.09 KB
Целевая система едина как функциональная часть и она же конструктивная (полностью совпадают), но вот дальше «функциональная структура»/«системное разбиение» «модульная структура»/«продуктная декомпозиция»/«конструктивное разбиение» могут существенно различаться.
В инженерных языках моделирования «железной» концепции системы (раньше говорили «архитектуры», до появления у архитектуры своего собственного предмета работы по оптимизации связности модулей с целью получения приемлемых архитектурных характеристик системы), равно как и в языках моделирования предприятия, функциональные и конструктивные части имеют различные значки, обозначающие разные типы этих объектов. Если не понимать между ними разницу, то использование этих языков становится ошибочным.
Если в проектном управлении сделать графики реализации модулей (скажем, финализации описаний модулей-контейнеров в программной инженерии) и реализации функциональных частей (в программировании они, например, могут называться «фичи», features) — то они будут абсолютно различными, но оба могут иметь смысл! Главное при этом — это решения создателей системы, какие элементы конструкции реализуют какие необходимые для работы системы поведения/функции. Обычно для этого нужно описать и функции (поведение), и функциональные части (ролевые части, которые выполняют поведение/функцию), и конструктивные части/модули/продукты/изделия, и где это всё размещено (компоновка), и стоимостные части (как распределена полная стоимость владения, а заодно и стоимость создания). В сложных случаях моделируют отдельно и функции (поведение), и функциональные части (ролевые объекты, которые как-то себя ведут). В более простых случаях обходятся либо функциями/поведением, либо функциональными/ролевыми частями — но никогда только конструктивными частями/продуктами/модулями, ибо предмет интереса «как работает» обязательно должен обсуждаться, его нельзя пропускать. «Как работает», функциональность как область интересов — это главная область/зона интересов в современном системном мышлении, главный предмет интереса, важнейшая характеристика системы!
#моделирование
#интересное
#системное мышление
#познавательное
#система
