Развитие (по-русски так передаём evolving, continuous development, continuous improvement, то есть те же идеи «эволюции, постоянного улучшения, прогресса, развития») менеджмента в одной организации. Одни мемы/идеи практик менеджмента, которые используются в разных частях организации или во всей организации в целом становятся обязательными в использовании, а другие наоборот объявляются вредными. В организациях идёт процесс постоянного улучшения, постоянного развития компании как замены одних практик другими. За это развитие как раз ответственны практики менеджмента, этому посвящён наш учебник. Но в число практик, которыми занята организация, входят как практики собственно организации работы (время создания и развития организации), так и практики планирования и отслеживания работ и других ресурсов (например, финансовых ресурсов), это практики операционного менеджмента (время эксплуатации организации). Так что менеджмент помогает эволюции/бесконечному развитию практик как инженерии целевых систем, так и практик развития самого менеджмента: менеджеры организуют как других, так и организуют себя. Менеджмент как практика, которой должна заниматься организация, просто обязан становиться всё лучше и лучше. Менеджмент меняется не только в глобальных масштабах дисциплины, но и в локальных масштабах практики работы организации.
Эволюция менеджерских практик как инженерии организаций, конечно, связана с эволюцией практик инженерии личности, эволюцией практик инженерии сообществ, эволюцией практик инженерии обществ. Эволюционный характер практик менеджмента означает, что это всегда квазиоптимальные практики в силу неустроенности/frustrations от конфликтов между системными уровнями:
Есть множество вариантов, которые на данном этапе эволюции можно назвать «лучшими» (множество вариантов SoTA примерно одной результативности и эффективности)
Эти варианты будут хвалиться на каких-то одних уровнях (личности, организации, сообщества, общества и т.д.), и ругаться на других за неэтичность, неэффективность, некультурность и т.д., ибо конфликты между системными уровнями неизбежны, что в мутации/изменении мемов кажется хорошо на одном уровне, явно будет выглядеть плохо на другом уровне.
Время от времени будут появляться эволюционные скачки, которые будут приводить к резкой оптимизации. Например, египетские писцы с их записями позволяли налаживать какую-то организационную собранность (управление вниманием коллектива по понятийному наведению внимания и удержанию внимания на важных объектах) для больших коллективов ещё во времена фараонов. Но вот пришли компьютеры, и с ними софт issue trackers, реализованный как low code системы и массово наладилось управление работами в случае case management. Конфигурация работ стала иметь меньше коллизий, менеджмент улучшился. Всё это как раз предмет нашего учебника, это будет разъясняться в последующих разделах (и мы даже не даём пока русскоязычных переводов: это всё приходит из мировой культуры, эволюция менеджмента глобальна).
Неважно, назовёте ли вы происходящее при сочетании лучших приёмов менеджмента на уровне организации и лучших приёмов происходящего при этом с личностями, сообществами, обществом «инженерией» или «самоинженерией», «организацией» или «самоорганизацией», «спонтанным порядком» или «наведённым порядком». Ребёнок пыхтит, завязывает шнурки, его родители радуются: «самозавязывание шнурков, наконец-то!», а ребёнок думает ровно наоборот: «чёрт, раньше шнурки как-то самозавязывались, а теперь вот приходится их мне завязывать». Аккуратней со словом «само», это часто чья-то работа по планированию, воплощению, развитию, и даже когда в этом «само» участвует много людей, это не означает «само делается», это «они делают», или «они создали условия, где это смогло произойти»).
Эта эволюция рассматривается нами как специализация практик системной инженерии, так что можно ожидать какого-то развития практик менеджмента по тому пути, который проходят практики системной инженерии в других прикладных инженериях, прежде всего программной инженерии с учётом, конечно, особенностей оргсистем. Так организационные системы, конечно, нельзя «изготовить и собрать» (процесс DevOps) ни как программные системы, ни как «железные системы».
Менеджмент также занимает особое место в прикладных практиках: им нужно заниматься практически во всех проектах, ибо большинство деятельностей коллективны. Даже если считать личность оргзвеном, всегда можно выделить вниманием команду из ролей, исполняемых субличностями, которые в целом составляют эту личность, и этот ход довольно продуктивен (даже некоторые психотерапии его используют, например internal family systems, IFS34).
Поэтому менеджмент в части его прикладности рассматривается по-разному:
Менеджмент это прикладная практика системной инженерии, находится вне трансдисциплин интеллект-стека. Эта практика приложима к системам определённого масштаба и вида (организациям). Есть специализация агентов (людей, усиленных компьютерами или даже команд людей с их компьютерами) на выполнение ролей этой практики, есть должности в организациях, где практики менеджмента будут ведущими (разного сорта «начальники»). При этом если рассматривать части личности, исполняющие роли внутри одного человека, то менеджмент можно в какой-то мере использовать и для организации работы в такой «внутренней команде личности».
Используется во всех проектах, поэтому менеджмент хорошо бы хотя бы на кругозорном уровне знать всем людям, чтобы понимать происходящее в их проектах в части организации труда. Он должен входить в обязательный кругозор (в отличие от разных других прикладных инженерных дисциплин, например, кулинарии, врачебного дела, робототехники).
Условно применим и к себе самому, но это требует определённых представлений о концепции использования личности, концепции личности, архитектуре личности в общеинженерном смысле концепции использования, концепции системы и архитектуры личности как системы.
2. Практики менеджмента и роли менеджеров
⠀
Конкретизация мета-мета-модели инженерии до мета-модели прикладной практики
⠀
Основная проблема, решаемая предложением типовой структуры практик и выполняющих их ролей в какой-то прикладной инженерии (у нас это менеджмент как инженерия организации) это нейтральная по отношению к специфике системы мета-модель «из учебника» (метаУ-модель), позволяющая описать разнообразие практик и ролей, а также разнообразие оргзвеньев и организационных мест (должностей), которые отражают всевозможные сочетания этих практик в мета-модели «из организации». Эта мета-модель «из учебника» должна быть:
Культурно-обусловленной, то есть не придуманной. Понятия, выражаемые этой мета-моделью, и термины, которыми они выражаются, должны браться из текущей организационной культуры, а не просто придумываться. Эти объекты внимания должны легко находиться в жизни, о них должна легко находиться литература.
Нарезка на объекты (роли и их функции-практики) должна быть достаточно мелкой, чтобы отражать самые разные причудливые сочетания функций, которые выполняют самые разные универсальные аффордансы (конструктивные части, которые можно приспособить под выполнение тех или иных функций). Как компьютер может выполнять огромное количество функций, так и оргзвено может выполнять огромное количество функций. Функции должны быть достаточно мелкими, чтобы указать, какие функции какой аффорданс (конструктивный объект, который мы задействовали) выполняет. Поэтому берём какого-нибудь product-manager или product owner в конкретной организации, понимаем, что в этой организации имеют свои особенные представления, чем работа на этих должностях отличается друг от друга, а также отличается от представлений, которые описаны в самой разной литературе самых разных лет издания, написанной людьми, вышедшими из самых разных школ инженерии и менеджмента, и понимаем, что в нашей мета-модели уровня «учебник менеджмента» (вы читаете именно его) есть какие-то роли, которые вы в разных сочетаниях можете найти у агентов, занимающих эти должности (это могут быть не только люди!). Далее вы понимаете, что происходит, каких ролей не хватает, какие дублируются, какие роли выполняются для разных системных уровней и поэтому неминуемо конфликтуют, и так далее.
Названия ролей не должны провоцировать ошибки типизации. Если вы назовёте узкую роль очень похожей на распространённое название широкой должности, у вас дальше будут проблемы в понимании разными людьми, ибо в разных организациях одинаково называемые должности (их популярных названий не так много, например «менеджер проектов») назначаются на удивительно разные наборы ролей. При этом должность это оргместо и ещё упоминание относится ко времени организовывания/создания организации, ибо во время эксплуатации вас будет волновать не должность (агент-сотрудник:: «конструктивный объект», размещённый на должности::оргместо, дающий оргзвено в оргструктуре), а (орг/проектная/деятельностная/практическая/трудовая/инженерная) роль это функциональный объект, важный для времени выполнения работ по практикам, operations time. Если слово будет провоцировать путать агентов-в-должности (оргзвенья) и роли с их мастерством делать что-то в целевом для них domain, будут проблемы или в обсуждении организовывания (кто куда, кому подчиняется в организовывании), или в обсуждении собственно работы (что они делают, а не кому подчиняются), а также в обсуждении концепции организации и архитектуры организации (как связано то, что делают с тем, кто на какой должности). Поэтому такие «общераспространённые для должностей» слова надо табуировать в мета-модели ролей. Пример: слово «стейкхолдер» понималось иногда как агент, а иногда как роль, что приводило к путанице (и Вася Пупкин, играющий Принца Гамлета, «стейкхолдер», и Принц Гамлет «стейкхолдер» оба варианта звучат хорошо, поэтому табуируем «стейкхолдера» и Васю называем агентом, а Принца ролью. Принц-агент звучит не очень хорошо, но Принц-роль ОК, Вася-роль не звучит, Вася-агент ОК. Про табуирование понятий, которые вносят путаницу, рассказывается в курсе «Онтологика и коммуникация», а затем повторяется в курсе «Практическое системное мышление». Дальше в нашем учебнике мы дадим примеры табуирования «системного инженера» и «предпринимателя».
⠀
Мета-модель уровня учебника (метаУ-модель) в нашем учебнике системного менеджмента получается конкретизацией мета-мета-модели системной инженерии из интеллект-стека, при этом учитываются указанные выше принципы культурной обусловленности, мелкой нарезки и непровоцирования ошибок типизации.
Почему выделяем «мета-модель из учебника» и «мета-модель из организации» обе как один уровень «мета-модель»? Они ж уточняют друг друга, не проще ли дать два разных уровня мета-модели? Нет, мета-мета-модель интеллект-стека относится ко всей деятельности применима к менеджменту, пилотированию космических кораблей, разработке оснастки небоскрёбов, обучению мастерству игры на гитаре, и так далее. Она универсальна. А вот мета-модель какой-то практики, даже довольно обширной (в нашем случае менеджмент как инженерия организации) относится к одному выделенному domain, одному набору предметов окружающего мира, одному набору объектов внимания. И вот уже этот более узкий, чем «любая деятельность по созданию-развитию чего бы то ни было», круг предметов/объектов типизируется в виде мета-моделей более низких уровней абстракции. Просто дальше надо смотреть два варианта таких мета-моделей: «как в учебнике практики» (в нашем случае это учебник системного менеджмента, метаУ-модель) и «как на предприятии» (в нашем случае это менеджерские регламенты, части корпоративного софта, какие-то представления/мемы из разных школ менеджмента, которые оказались в головах или компьютерах агентов, выполняющих менеджерские роли в конкретном предприятии, ситуационная мета-модель, метаС-модель). Можно это рассматривать не как отношение «классификация» (между уровнями «мета» класс-экземпляр, даже когда «экземпляр» тоже класс, это рассматривалось на курсе онтологики как «класс классов»), а как отношение специализации/конкретизации (внутри одного уровня, «класс-подкласс»).
Если не вводить такого широкого класса какой-то практики (в нашем случае менеджмента) как «мета-модель из учебника», трудно перетаскивать знания не только между разными предприятиями, но и между проектами одного предприятия: практики менеджмента в отделе бухгалтерии и в отделе IT-разработки могут оказаться драматически разными на уровне мета-модели уровня абстракции конкретной менеджерской ситуации, но они могут представляться одинаковыми на уровне мета-модели из учебника. Так что можно унифицировать мышление менеджера в этих ситуациях, если он будет использовать метаУ-модель. Это очень удобно: менеджеры попадают в новые менеджерские ситуации, уже имея о них довольно подробные представления, а не начинают разбираться в каждой организации с нуля, «всё новое, ничего не знаю, ничего не понимаю». Нет, в голове (и экзокортексе, просто головой люди сейчас не работают) будет уже много знаний про эту ситуацию: на что обратить внимание, каких целей достигать, какими методами достигать этих целей. И дальше нужно будет только выполнять привязку этих знаний к конкретной ситуации, то есть использовать интеллект для разбирательства с новой ситуацией и приобретать уже совсем прикладные знания.
Вы узнаете в «Системной инженерии»:: мета-мета-модель, что системы создают разработчики::инженеры::роль, а из нашего учебника «Системный менеджмент»:: метаУ-модель вы узнаете, что систему-организацию создают организаторы::разработчики::инженеры::роль, а придя в одну конкретную организацию вы узнаете, что роль организаторов там у агентов, которые находятся в офисе CTO (все эти «офицеры» СTO, CIO и даже CEO в крупных фирмах имеют «офисы», работают-то они не в одиночку, а задействуя множество сотрудников в своих офисах). А вот в другой организации вы найдёте, что организаторы в отдельном оргзвене «Служба развития», а CTO и его офис заняты совсем другими вопросами. В третьей организации организаторами становятся кто угодно, просто создаются рабочие группы оргпроектов, и членство в них определяется не штатным расписанием. Вы приходите в новую для вас организацию (проект, предприятие, команду) не с пустой головой, вы что-то об этой организации уже знаете перед тем, как в ней оказаться. Например, вы знаете, что искать в любой организации, это известно из метаУ-модели нашего учебника: роль организатора должна быть, и она должна заниматься теми практиками, которые описаны в учебнике менеджмента!
⠀
Конкретизация системноинженерных практик и ролей для менеджмента
В курсе «Системная инженерия» были введены следующие практики и выполняющие их роли, которые мы конкретизируем для менеджмента как инженерии организации:
Разработка (выполняет разработчик/developer): изучить предметную область и предложить концепцию использования (инкремент, «фича», новая функция), концепцию системы (как и из чего сделать систему с ограничениями от архитектора), затем спроектировать с точностью, достаточной для изготовления (используем моделеры), затем изготовить на конвейере/платформе, подготовленном технологом производства (DevOps/platform engineering) и ввести в эксплуатацию, а затем эксплуатировать и всё это непрерывно.
Надзор/governance за выгодностью (выполняет визионер, часть роли product manager, ответственный за business case): установить приоритеты для реализации фич/инкрементов и отслеживать, что создание системы в целом (всеми автономно работающими разработчиками, архитектором и DevOps) приносит прибыль, а не убыток.