Давайте попробуем изложить всё то же самое в виде таблички, в которой пропишем роли (но за каждой ролью обязательно скрывается практика этой роли, её просто не будем писать для экономии места):

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

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

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

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