Ещё несколько выдержек из курса "Системный менеджмент": иллюстрация к приёму, облегчающему понимание инженерами менеджмента как варианта системной инженерии, только для специфического типа систем -- организации. Расскажем тут о соответствии ролей инженеров и менеджеров. Найдите свои часто выполняемые роли в этом тексте и отметьте, сколько рабочего времени занимает у вас выполнение этих ролей, и что могло бы ожидаться в плане вашей занятости по этим ролям, если судить по наименованию вашей должности (а ведь другие люди судят о вас как раз по должности, в том числе и вы сами). Обратите внимание на те роли, которые надо бы выполнять -- но руки не доходят, а также те роли, которые не надо выполнять, но почему-то оказывается, что выполняете. Обратите внимание на роли, которые в вашем проекте (как в его инженерной части, так и в его менеджерской части) непонятно кто выполняет -- и из-за этого проект лихорадит. И таких вопросов после понимания нижеприведённого отрывка можно задавать множество. Конечно, в курсах "Системная инженерия" и "Системный менеджмент" все эти вопросы обсуждаются много подробней.
Требования к мета-модели "из учебника" (метаУ-модель)
Основная проблема, решаемая предложением типовой структуры практик и выполняющих их ролей в какой-то прикладной инженерии (у нас это менеджмент как инженерия организации) — это нейтральная по отношению к специфике системы мета-модель «из учебника» (метаУ-модель), позволяющая описать разнообразие практик и ролей, а также разнообразие оргзвеньев и организационных мест (должностей), которые отражают всевозможные сочетания этих практик в мета-модели «из организации». Эта мета-модель «из учебника» должна быть:
-- Культурно-обусловленной, то есть не придуманной. Понятия, выражаемые этой мета-моделью, и термины, которыми они выражаются, должны браться из текущей организационной культуры, а не просто придумываться. Эти объекты внимания должны легко находиться в жизни, о них должна легко находиться литература.
-- Нарезка на объекты (роли и их функции-практики) должна быть достаточно мелкой, чтобы отражать самые разные причудливые сочетания функций, которые выполняют самые разные универсальные аффордансы (конструктивные части, которые можно приспособить под выполнение тех или иных функций). Как компьютер может выполнять огромное количество функций, так и оргзвено может выполнять огромное количество функций. Функции должны быть достаточно мелкими, чтобы указать, какие функции какой аффорданс (конструктивный объект, который мы задействовали) выполняет. Поэтому берём какого-нибудь product-manager или product owner в конкретной организации, понимаем, что в этой организации имеют свои особенные представления, чем работа на этих должностях отличается друг от друга, а также отличается от представлений, которые описаны в самой разной литературе самых разных лет издания, написанной людьми, вышедшими из самых разных школ инженерии и менеджмента, и понимаем, что в нашей мета-модели уровня «учебник менеджмента» (вы читаете именно его) есть какие-то роли, которые вы в разных сочетаниях можете найти у агентов, занимающих эти должности (это могут быть не только люди!). Далее вы понимаете, что происходит, каких ролей не хватает, какие дублируются, какие роли выполняются для разных системных уровней и поэтому неминуемо конфликтуют, и так далее.
-- Названия ролей не должны провоцировать ошибки типизации. Если вы назовёте узкую роль очень похожей на распространённое название широкой должности, у вас дальше будут проблемы в понимании разными людьми, ибо в разных организациях одинаково называемые должности (их популярных названий не так много, например «менеджер проектов») назначаются на удивительно разные наборы ролей. При этом должность — это оргместо и ещё упоминание относится ко времени организовывания/создания организации, ибо во время эксплуатации вас будет волновать не должность (агент-сотрудник::«конструктивный объект», размещённый на должности::оргместо, дающий оргзвено в оргструктуре), а (орг/проектная/деятельностная/практическая/трудовая/инженерная)роль — это функциональный объект, важный для времени выполнения работ по практикам, operations time. Если слово будет провоцировать путать агентов-в-должности (оргзвенья) и роли с их мастерством делать что-то в целевом для них domain, будут проблемы или в обсуждении организовывания (кто куда, кому подчиняется в организовывании), или в обсуждении собственно работы (что они делают, а не кому подчиняются), а также в обсуждении концепции организации и архитектуры организации (как связано то, что делают с тем, кто на какой должности). Поэтому такие «общераспространённые для должностей» слова надо табуировать в мета-модели ролей. Пример: слово «стейкхолдер» понималось иногда как агент, а иногда как роль, что приводило к путанице (и Вася Пупкин, играющий Принца Гамлета, «стейкхолдер», и Принц Гамлет «стейкхолдер» — оба варианта звучат хорошо, поэтому табуируем «стейкхолдера» и Васю называем агентом, а Принца — ролью. Принц-агент звучит не очень хорошо, но Принц-роль — ОК, Вася-роль не звучит, Вася-агент — ОК. Про табуирование понятий, которые вносят путаницу, рассказывается в курсе «Моделирование и коммуникация», а затем повторяется в курсе «Практическое системное мышление». Дальше в нашем учебнике мы дадим примеры табуирования «системного инженера» и «предпринимателя».
Мета-модель уровня учебника (метаУ-модель) в нашем учебнике системного менеджмента получается конкретизацией мета-мета-модели системной инженерии из интеллект-стека, при этом учитываются указанные выше принципы культурной обусловленности, мелкой нарезки и непровоцирования ошибок типизации.
Почему выделяем «мета-модель из учебника» и «мета-модель из организации» обе как один уровень «мета-модель»? Они ж уточняют друг друга, не проще ли дать два разных уровня мета-модели? Нет, мета-мета-модель интеллект-стека относится ко всей деятельности — применима к менеджменту, пилотированию космических кораблей, разработке оснастки небоскрёбов, обучению мастерству игры на гитаре, и так далее. Она универсальна. А вот мета-модель какой-то практики, даже довольно обширной (в нашем случае менеджмент как инженерия организации) относится к одному выделенному domain, одному набору предметов окружающего мира, одному набору объектов внимания. И вот уже этот более узкий, чем «любая деятельность по созданию-развитию чего бы то ни было», круг предметов/объектов типизируется в виде мета-моделей более низких уровней абстракции. Просто дальше надо смотреть два варианта таких мета-моделей: «как в учебнике практики» (в нашем случае это учебник системного менеджмента, метаУ-модель) и «как на предприятии» (в нашем случае это менеджерские регламенты, части корпоративного софта, какие-то представления/мемы из разных школ менеджмента, которые оказались в головах или компьютерах агентов, выполняющих менеджерские роли в конкретном предприятии, ситуационная мета-модель, метаС-модель). Можно это рассматривать не как отношение «классификация» (между уровнями «мета» — класс-экземпляр, даже когда «экземпляр» тоже класс, это рассматривалось на курсе онтологики как «класс классов»), а как отношение специализации/конкретизации (внутри одного уровня, «класс-подкласс»).
Если не вводить такого широкого класса какой-то практики (в нашем случае менеджмента) как «мета-модель из учебника», трудно перетаскивать знания не только между разными предприятиями, но и между проектами одного предприятия: практики менеджмента в отделе бухгалтерии и в отделе IT-разработки могут оказаться драматически разными на уровне мета-модели уровня абстракции конкретной менеджерской ситуации, но они могут представляться одинаковыми на уровне мета-модели из учебника. Так что можно унифицировать мышление менеджера в этих ситуациях, если он будет использовать метаУ-модель. Это очень удобно: менеджеры попадают в новые менеджерские ситуации, уже имея о них довольно подробные представления, а не начинают разбираться в каждой организации с нуля, «всё новое, ничего не знаю, ничего не понимаю». Нет, в голове (и экзокортексе, просто головой люди сейчас не работают) будет уже много знаний про эту ситуацию: на что обратить внимание, каких целей достигать, какими методами достигать этих целей. И дальше нужно будет только выполнять привязку этих знаний к конкретной ситуации, то есть использовать интеллект для разбирательства с новой ситуацией и приобретать уже совсем прикладные знания.
Вы узнаете в «Системной инженерии»::мета-мета-модель, что системы создают разработчики::инженеры::роль, а из нашего учебника «Системный менеджмент»::метаУ-модель вы узнаете, что систему-организацию создают организаторы::разработчики::инженеры::роль, а придя в одну конкретную организацию вы узнаете, что роль организаторов там у агентов, которые находятся в офисе CTO (все эти «офицеры» СTO, CIO и даже CEO в крупных фирмах имеют «офисы», работают-то они не в одиночку, а задействуя множество сотрудников в своих офисах). А вот в другой организации вы найдёте, что организаторы в отдельном оргзвене «Служба развития», а CTO и его офис заняты совсем другими вопросами. В третьей организации организаторами становятся кто угодно, просто создаются рабочие группы оргпроектов, и членство в них определяется не штатным расписанием. Вы приходите в новую для вас организацию (проект, предприятие, команду) не с пустой головой, вы что-то об этой организации уже знаете перед тем, как в ней оказаться. Например, вы знаете, что искать в любой организации, это известно из метаУ-модели нашего учебника: роль организатора должна быть, и она должна заниматься теми практиками, которые описаны в учебнике менеджмента!
Практики системной инженерии и выполняющие их роли
В курсе «Системная инженерия» были введены следующие практики и выполняющие их роли, которые мы будем конкретизировать для менеджмента как инженерии организации:
-- Разработка (выполняет разработчик/developer): изучить предметную область и предложить концепцию использования (инкремент, «фича», новая функция), концепцию системы (как и из чего сделать систему — с ограничениями от архитектора), затем спроектировать с точностью, достаточной для изготовления (используем моделеры), затем изготовить на конвейере/платформе, подготовленном технологом производства (DevOps/platform engineering) и ввести в эксплуатацию, а затем эксплуатировать — и всё это непрерывно.
-- Надзор/governance за выгодностью (выполняет визионер, часть роли product manager, ответственный за business case): установить приоритеты для реализации фич/инкрементов и отслеживать, что создание системы в целом (всеми автономно работающими разработчиками, архитектором и DevOps) приносит прибыль, а не убыток.
-- Архитектурная практика (выполняет архитектор, ответственный за архитектурные характеристики): установить приоритетные архитектурные характеристики, принять решения по способам их достижения путём предписания деления системы на части и указания способа взаимодействия этих частей, а также отслеживать, что создание системы в целом улучшает эти характеристики (то есть, что не накапливается «технический долг» как долг по проведению работ, предотвращающих ухудшение архитектурных характеристик в долгосрочной перспективе)
-- Инженерия «производственного конвейера» (выполняет DevOps/инженер «производственного конвейера»/internal development platform, ответственный за средства/технологию воплощения проектных и архитектурных решений, а также технологию эксплуатации результата): создание условного завода-автомата/pipeline/internal development platform («конвейер»: оборудование и софт в компьютерах, но иногда это всё не работает без людей-операторов — и это не совсем «автомат», а «обычный завод»), который используется разработчиками и архитекторами, чтобы воплотить проектные и архитектурные решения, провести инженерное обоснование (испытания, проверка соответствия архитектурным решениям и т.д.), а затем выдать пользователям/клиентам для эксплуатации. Современный взгляд на это — «изготавливают» фичи системы разработчики, а DevOps только предоставляют им полностью работающее и обслуживаемое «заводское оборудование»/конвейер/pipeline/IDP (internal development platform). DevOps становится инженером конвейера, он осуществляет platform engineering, разрабатывает тот самый «завод-автомат», «конвейер», internal development platform. Редко бывает, что это именно завод/фабрика с настоящим конвейером или трубопроводом, ибо системы бывают крайне разные. Конвейер/platform начинается с правильной системы автоматизации проектирования, заканчивается системой поддержки цифрового двойника и не требует от разработчика никаких специальных знаний по его запуску и наладке, разработчики его просто используют. Вы как разработчик сами пользуетесь лопатой, чтобы копать, и точно так же сами пользуетесь internal development platform, чтобы создавать системы. Эту платформу вы сами их не создаёте, её создают инженеры производственного конвейера/DevOps/инженеры платформы разработки, но пользуетесь платформой вы сами, это называется «самообслуживание»/self-service . Если таки надо дорабатывать IDP, то это обеспечивают инженеры конвейера/платформы, то есть исполнители ролей DevOps, но они сами ничего не изготавливают в целевой системе, занимаются только «станочным парком». Кнопку «изготовить» нажимает сам разработчик, а не DevOps, и он же имеет дело с последствиями, это принципиально: you build it, you run it — ты это строишь, ты и эксплуатируешь ). Тут сразу сложно, ибо мы получаем «систему создания внутри системы создания», создатели-операторы целевой системы «холдинг из конструкторского бюро (КБ) и завода» и «создатели-операторы КБ плюс завода». При этом понимаем, что в большинстве случаев это совсем не похоже на «конструкторское бюро» и «завод», например, трудно говорить о «конструкторском бюро для оргсистем» и «заводе оргсистем», «конструкторском бюро мастерства» и «заводе мастерства» и даже для компьютерных программ это не так очевидно. Но структура производства и эксплуатации везде будет одинаковой.
Практики менеджмента и выполняющие их роли
Вот это всё мы должны найти сейчас в менеджменте, понимая, что создаётся организация::система. Сложности ещё и в том, что одни и те же люди::агенты создают организацию в роли создателей и работают в этой созданной организации как её части-сотрудники. Поэтому лишний раз подчеркнём, что говорим о ролях, исполняемых агентами (со всеми обычными оговорками, что это может быть одна роль, исполняемая несколькими людьми, один человек, исполняющий несколько ролей, некоторые роли можно отдавать компьютерам, но потом считать, что их выполняет владелец компьютера, владелец компьютера может оказаться оргзвеном из полусотни человек с самыми разными ролями и т.д.).
Менеджмент как инженерия предприятия включает в себя следующие практики и роли:
-- Организатор (аналог developer в системной инженерии) выполняет организовывание. Он предлагает концепцию использования организации (зачем её делать, каких изменений в мире ожидать, какие оргизменения нужно сделать, какие практики нужно освоить организации как development и затем превратить их в оргвозможности/capability как delivery, чему научиться новому). Предлагает, ибо это «гипотеза», организационная гипотеза/guess. Он затем разрабатывает концепцию организации (как и из чего сделать организацию — с ограничениями от архитектора), затем проектирует (моделеры! Корпоративный софт!) с точностью, достаточной для «изготовления» (конечно, это не заводское изготовление! Потребуются закупки оборудования, найм сотрудников, лидерство и т.д.), будет работать администрация (аналог DevOps/internal development platform engineering), затем введение в эксплуатацию — и всё это непрерывно, цикл непрерывного оргразвития.
-- Практику прибыльности осуществляет бизнесмен, ответственный за отношения с инвесторами (IR, investor relations) и надзор за прибыльностью. Так же как визионер/стратег (например, как одна из ролей должности product manager) отслеживает, что клиентура «покупает» целевую систему дороже, чем затрачивается на её изготовление, бизнесмен отслеживает, что инвестура (все владельцы, их часто называют одним словом «инвесторы») «покупает» организацию не дешевле, чем нужно для начала зарабатывания, выхода на break even. Если денег от инвесторов не удалось собрать, то организация никому не нужна, её не будет. При этом инвесторы сами контролируют то, что на эти деньги будет прибыль в рамках corporate governance (это как бы «потребительский надзор», «клиентский контроль за качеством целевой системы» — только этой системой тут будет организация, а «клиентом» будет «инвестор»)! Бизнесмен компании отслеживает обратную ситуацию: чтобы инвестиций хватило для организации нового дела, он должен проверить идею/орггипотезу организатора, которая достаточно убедительна для инвесторов. Отдельно можно обсуждать, как все упомянутые роли разложены по должностям в некоммерческих организациях, в небольших стартапах, в крупных холдингах, государственных/правительственных организациях, и даже командах агентов внутри личности (internal team в практике ролевого мастерства личности, команды из частей личности с интеллектом меньше, чем у полной личности). При этом как визионер сам не осуществляет продвижения (маркетинг, реклама, продажа), а лишь выполняет оценку выгодности производства продукта, сервиса, фичи, так и бизнесмен не сам выполняет практику привлечения инвестиций, но он занимается стратегированием: согласует все идеи о том, как компания может зарабатывать деньги для инвесторов. И если эти идеи будут убедительными, то как «в основе хорошей рекламы лежит хороший товар», то и тут «в основе хорошего привлечения инвестиций лежит прибыльная фирма». Вот бизнесмен и озабочен этой прибыльностью.
-- Практика архитектуры выполняется архитектором организации (часто орг-архитектора выделяют на уровне предприятия, самой верхушке организации, поэтому называют архитектор предприятия. Но легко вообразить роль архитектора какой-нибудь службы предприятия, а не всего предприятия): установить приоритетные архитектурные характеристики, принять решения (с учётом обратного манёвра Конвея) по способам их достижения через предписание деления организации на отдельные максимально автономные/независимые оргзвенья и указания способа взаимодействия оргзвеньев, а также отслеживания/надзора/governance, что оргизменения как результат работы разных организаторов улучшают эти характеристики организации в целом (то есть, что не накапливается «технический долг» из системной инженерии, когда система — организация): «организационный долг» — это работы, которые надо выполнить для предотвращения ухудшения архитектурных характеристик организации в долгосрочной перспективе.
-- Администрирование (аналог DevOps/internal development platform engineering) как практика, выстраивающая и эксплуатирующая «организационный конвейер», позволяющий организаторам проводить изменения. Администраторы довольно разнообразны, ибо тут идёт довольно дробное разделение на подроли: финансисты, снабженцы (административно-хозяйственная часть, закупки), HR, офис-менеджеры, хелп-деск и ресешпн, и т.д. Администратор (который как врач, давно специализирован в своих подролях, и эти подроли выполняются разными даже не людьми, а часто целыми службами) предоставляет разработчикам «конвейер», по которому организаторы проводят изготовление оргвозможностей: получают необходимые «сырые ресурсы» и проводят их превращение в оргвозможности согласно разработанным ими оргпроектам/orgdesign при надзоре со стороны архитектора, следящего за общими архитектурными характеристиками организации. Тут та же сложность, что в определении «производственного конвейера» в более общем случае системной инженерии — этот конвейер сначала надо построить, а затем только эксплуатировать. То есть обсуждаем и время создания целевой организации, и работающий в это время «конвейер» администратора создателя организации, но перед временем создания организации нужно предусмотреть ещё время создания этого «конвейера» его разработчиком/«создателем создателя организации»/«создателем администрации». Сложность в том, что в жизни всё это происходит одновременно в физическом времени, а «логические» времена создания выделяются исключительно вниманием: и производится целевая система, и производятся организационные изменения в организации-создателе, и производятся организационные изменения в администрировании. Эта цепочка создания каждый раз продумывается — и таки дотягивается до целевой системы в конечном итоге, или до клиентуры, или до инвестуры (фирма создаёт минимально три системы). Пока мы будем называть администраторами и создателей (включая разработчиков/организаторов) конвейера (platform engineers) и его работников (не всё там удаётся автоматизировать, хотя даже HR практики сегодня пытаются автоматизировать), но если в вашем внимании создание самого этого конвейера, вам придётся их различить. К цепочкам создания надо быть внимательным, они в жизни не такие простые, как на примерах диаграмм из нашего учебника! Сам термин взят из критики Henry Mintzber программ MBA (master of business administration): они вроде нацелены на подготовку организаторов и стратегов в целом, но по факту готовят глав финансовых служб, глав служб HR и прочих администраторов, которые явно не справляются с должностями, требующими компетенций в других ролях. Они «работники производственного конвейера для поддержки жизни организации, поддержки развития», а после приобретения какого-то опыта могут пытаться ещё и строить такой конвейер. Но вот использование этого конвейера для развития организации в целом требует других специализаций: организатора, бизнесмена, архитектора организации. И мы понимаем, что слово «администратор» очень широкое, но всё-таки означает чаще «исполнительные» роли поддержки какого-то конвейера, а не роли, занятые использованием этого конвейера для какого-то дела (при всём понимании, что «всё со всем связано, конвейер должен быть согласован с типом тех систем, которые по нему проходят»).
Разные формы представления соответствия инженерных и менеджерских ролей
Вот компактно про соответствие ролей в виде многоуровневого списка с ролями и подролями:
-- инженерия целевой системы — инженер целевой системы
-- -- визионерство целевой системы (прогноз целесообразности создания целевой системы) — визионер
-- -- архитектурная деятельность для целевой системы — архитектор
-- -- разработка — разработчик
-- -- -- проектирование — проектировщик
-- -- -- изготовление/производство – инженер-технолог
-- -- -- эксплуатация — оператор целевой системы
-- -- Инженерия платформы разработки (DevOps) — инженер платформы разработки
-- Менеджмент (инженерия организации) — менеджер в широком понимании (инженер организации)
-- -- стратегирование (для удержания стоимости бизнеса) — бизнесмен
-- -- орг-архитектурная деятельность — орг-архитектор
-- -- организовывание — организатор, менеджер в узком понимании
-- -- -- организационное развитие — менеджер по оргразвитию
-- -- -- -- оргпроектирование — оргпроектировщик
-- -- -- -- лидерство — лидер, менеджер в слишком узком понимании
-- -- -- операционный менеджмент — операционный менеджер
-- -- администрирование — администратор
-- продвижение продукта или услуги (инженерия клиентуры: маркетинг, реклама, продажи) — продвиженец (там тоже разбиение на подпрактики и подроли!)
-- привлечение инвестиций (инженерия инвестуры, fundraising) — фандрайзер
Вот это же, но с примерами и других наборов ролей из других деятельностей, табличкой (кликабельно):
А вот картинка тех же инженерных и менеджерских ролей, но короткой диаграммой графа создания (кликабельно):
Вот эта же диаграмма для графа с цепочками создания в полном виде. В курсе "Методология" рассказывается, как от диаграммного представления перейти к спискам, а списки потом переделать в таблички и превратить эти таблички в чеклисты, чтобы иметь возможность как-то отслеживать прохождение оргпроекта (кликабельно):
