Читать книгу Системный менеджмент – 2023 - Анатолий Левенчук - Страница 10

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

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

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

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

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

Можно, конечно, обсуждать – в каких именно командах и как должны работать все указанные роли, но уже понятно, что такие быстрые прикидки («кто такой преподаватель? Он инженер-технолог, стадия изготовления. Это не автор курса? Сколько нам надо иметь преподавателей? Сколько авторов курса? Понимаем ли мы, что преподаватели по конкретному предмету/курсу – по роли это не столько члены «потоков», сколько члены команды создания курсов, подроль «разработчика»? Получается, что команда потока состоит из людей, которые частично пришли в неё из другой команды!

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

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

Как это всё увязать вместе? Понимая, что в учебниках даны только типы мета-мета-модели интеллект-стека (включая практику системной инженерии), а в нашем учебнике «Системного менеджмента» только метаУ-модель менеджмента, при этом даже если вы будете пытаться моделировать очень простую организацию, вам придётся сразу рассматривать довольно сложные раскладки разных ролей по командам (хотя все эти роли могут играться даже одним человеком, он же и будет единственной «командой»). Так, фирма должна «изготовить» целевую систему, инвестуру (привлечь инвестиции), клиентуру (заполучить клиентов). Вот пример37 объектов, которые нужно при этом отслеживать: системная схема предприятия, и это опять-таки только пример! Не пытайтесь скопировать его для вашей фирмы, для вашего проекта! Чётко видно, что визуальное представление «не работает» – вам его будет довольно сложно адаптировать для вашей фирмы (хотя рассматривать в учебнике довольно просто, но непросто будет редактировать38), нужно сразу переходить на табличное моделирование. «Фирма» – это альфы в голубых областях интереса, клиентура и инвестура – внешние проектные роли для разных команд в фирме, показаны в зелёных областях интереса надсистем, связанные с целевой системой альфы показаны в её жёлтой области интереса. Ориентируемся всегда на жёлтенькое – область интересов целевой системы, всё остальное разворачиваем вокруг неё. В большинстве основных альф показаны через перечисления ещё и их возможные подальфы (см. схему ниже).

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

Вам надо научиться вот такому «одинаковому мышлению в каждом месте цепочки создания» для организаций, в которые вы попадаете. Не надо копировать эти сложные картинки из учебника, моделируйте табличками, обсуждайте длинные цепочки создания. Тут специально вставлена для примера дилерская сеть/агентура, просто чтобы показать, как удлиняется цепочка создания от принятых организационных решений цепочки создания. Если вы инженер и вам не интересно инвестирование, не моделируйте его. Это не всегда цепочки, цепочки тут как один из маршрутов на более сложных графах, в вашем проекте всё может быть по-другому. В разных командах могут быть и одинаковые роли, и разные. Планируйте множество команд в сложных цепочках, не забывайте проектировать фирму в целом, если вас интересует менеджмент, учитывайте разные команды с разными ролями внутри фирмы, не забывайте учитывать ещё и работы этих команд, помнить о необходимости управлять этими работами. Не забывайте кроме целевой системы (а продуктов может быть несколько! И их могут делать разные команды в рамках разных цепочек создания в одной фирме) ещё и о клиентуре (и там могут быть разные сегменты! С ними могут работать разные команды продвижения!), и об инвестуре. Адаптируйте материал учебника для своего проекта, вам тут рассказывается только о типах объектов в организации, а не даются шаблоны устройства организации. Устройство организации везде будет разным, одинаковых организаций не бывает. Но думать об этих самых разных организациях можно более-менее одинаково, вот об этом наш учебник.