скачать книгу бесплатно
Конечно, менеджмент также поднимает множество этических вопросов, ответы на которые даются не столько на уровне самого менеджмента как прикладной дисциплины в интеллект-стеке, сколько на уровне экономики и права, и далее ещё ниже – уровне методологии (помним, что методологию в экономике и праве часто называют праксеология, но мы придерживаемся более общей терминологии, подробности в курсе «Методология»). Вот примеры:
Должна ли компания заботиться о каких-то социальных целях? То есть насколько нужно придерживаться идей Environmental, Social, and Governance (ESG) Investing[32 - https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp (https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp)]? Как всегда в таких случаях, когда речь идёт о социалистических идеях (примат кем-то озвучиваемых «общественных интересов» над любыми другими), то в период моды на такие идеи трудно получить какую-то взвешенную и уж тем более критическую оценку. Скажем, вам предлагается брать не лучших работников, которые вам доступны, а всех подряд, чтобы выполнить условие по достаточному для госорганов количеству работающих у вас инвалидов и «национальных кадров» (как говорили раньше про представителей национальных меньшинств) – надо ли это делать, ибо компания очевидно будет при этом работать хуже, зато это вроде как «правильно»? Или компания строит ещё один кусочек города на планете, вместо удержания Земли в первозданной дикости – тренд на урбанизацию разве не прогрессивен, а «назад к нетронутой природе» это разве не «назад к дикости»? Должна ли компания поддерживать тот или иной международный бойкот, не работая на какой-то «оккупированной территории» (что ещё больше ухудшит жизнь «оккупированных»)? Должна ли поддерживать «культуру отмены», исключая использование заведомо хороших продуктов и сервисов людей и компаний, которые чем-то не понравились тем или иным лидерам общественного мнения? Должна ли компания работать на военных?
И даже более простые вопросы типа исключать или не исключать человеческое поведение типа флирта в рабочее время, или считать это (как и любое другое проявление гендера) заведомо неприемлемым – на работе должны остаться бесполые роботы? Уместно ли увольнять человека, которому остался год до пенсии, но он не нужен компании? Должна ли компания нанимать детей, или это «эксплуатация детского труда»? И как вообще отличить «эксплуатацию» от «добровольной работы», все ж могут уволиться сами, если им более выгодно не эксплуатироваться, чем эксплуатироваться?
Ответы на эти вопросы сложны, они остаются за пределами нашего курса. В любом случае, разбирательство потребует системного мышления: заведомо на разных уровнях сложности (человека, команды внутри компании, компании, экосистемы с этой компанией, сообщества потребителей компании, общества и далее человечества) будут даваться разные ответы, при этом потребуется ещё и понимать отдалённые во времени последствия этих решений для самых разных внешних проектных ролей. В поддержку этих размышлений курс этики и полный интеллект-стек для разбирательства с конкретными ситуациями и их нюансами. Мы тут не будем этого касаться.
Например, насколько этично использование схем, описанных в текущем подразделе? Мы считаем, что абсолютно этично: нельзя признавать безумные требования (даже не гипотезы, как в инженерии), предъявляемые самыми разными проектными ролями, утверждающими, что они говорят от имени «народа», если вы понимаете, что эти требования всем делают только хуже, а лучше станет некоторым, и то ненадолго. Не надо делать итальянскую забастовку, не надо бездумно тратить деньги инвесторов, надо просто сконструировать подходящую схему, минимизирующую риски. Этично ли это? Авторы курса считают, что абсолютно этично: законность («что написано в законах и регламентах, то и справедливо», правовой позитивизм в его этатистской версии, легизм[33 - https://ru.wikipedia.org/wiki/Правовой_позитивизм (https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B0%D0%B2%D0%BE%D0%B2%D0%BE%D0%B9_%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%B8%D0%B2%D0%B8%D0%B7%D0%BC)], закон вполне может санкционировать и произвол и даже необоснованное никак насилие) и правозаконность (справедливо то, что справедливо – результат многоуровневой оптимизации конфликтов разных системных уровней, законы и приказы это отражают, а где не отражают, должны не исполняться).
Подробности будут в курсах этики, экономики, права. В нашем курсе мы только требуем не забывать об этичном поведении и помнить, что «записано в регламенте», «записано в законе», «записано в стандарте» не всегда означает, «это этично, надо именно так и делать». Каждый раз надо думать и принимать решения с учётом многоуровневой оптимизации, учитывая и отдалённые во времени последствия (это особо важно в экономике), и риски получить вред от людей, которые считают иначе, легистов и безумных законов ведь в мире довольно много.
Менеджмент и эволюция
Как и любые практики, менеджмент в организациях реализует набор идей-мемов (мемом менеджмента как все относящиеся к менеджменту мемы в организации), который
1. Не так уж очевиден, ибо определяет объекты, «невидимые» для необученного глаза. Даже «очевидные» объекты менеджмента не так уж и очевидны, если их не объяснять и просто уповать на опыт работы в организации. Скажем, «работа» и «практика» – это разные объекты, не так просто их научиться различать. Оргроли и оргзвенья с возможностью переназначения оргролей на разные оргзвенья выглядят естественным описанием для организации, но само понятие оргроли в его отличии от оргзвена и связка практики с оргролью и оргзвена с сервисом и потом понятие оргвозможности/capability – это тоже не так очевидно. Неочевидна даже сама идея инженерии организации как «машины, которую нужно спроектировать и построить», а не просто «менеджмента» как уговаривания людей дружно поработать вместе и связанным с этими способами уговаривания бесконечным последующим обсуждением авторитарного стиля управления, мыслительного стиля команд и прочих мемокомплексов (псевдотеорий), мало влияющих на гибкость (скорость изменения) и производительность организации.
2. Эволюционирует, реплицируясь с мутациями (иногда сознательными «умными мутациями», а иногда и просто с «ошибками передачи») между мемомами разных организаций. Этот мемом отличается от биологического генома следующим:
??2.1. Находится в мозгах сотрудников. Сотрудники
??перетаскивают отдельные идеи менеджмента,
??перемещаясь из одной организации в другую.
??2.2. Находится в софте, который поддерживает какие-то
??практики. Сотрудники задействуют какие-то
??менеджерские идеи (например, какие объекты
??считать важными в менеджменте, именно эти объекты
??будут отражены в базе данных софта).
??2.3. Находятся в учебниках менеджмента, материалах
??менеджерских курсов.
Это означает, что люди и организации в той мере, в которой они выполняют практики менеджмента (в том числе и системного менеджмента как части всех возможных менеджерских практик, ведь есть же и много других вариантов менеджмента – например, упование на божественную силу, которая как-то сама всё наладит, или упование на страх насилия, который сам всё наладит, если речь идёт о преступных организациях) являются феномами (аналоги взрослых «организмов» и «популяций» в биологии, которые «изготавливаются» из геномов, но тут у нас мемомы). И тут два варианта эволюции:
• Эволюция идей менеджмента, которая идёт на планете. Мемы разных практик менеджмента осознаются или не осознаются, но переносятся людьми из организации в организацию, при этом удачные переносятся многократно (ибо задействующие их организации успешны), а неудачные приводят к гибели организации, эта зависимость неудачи от использования каких-то определённых мемов осознаётся, и дальше эти мемы не переносятся. Если мем приводит к гибели организации как фенома, то причинно-следственная связь с плохими практиками менеджмента может не осознаваться, а в головах сотрудников эти мемы могут оставаться и нестись дальше, в другие организации. Но если это будут устойчивые неудачи, то эти сотрудники просто не будут в новых организациях начальниками и не смогут распространить эти мемы сильно. Так что всё плохое будет глохнуть в ходе эволюции, а хорошее накапливаться. Но это медленно, кроме тех мемов, которым удалось попасть в образование. Тогда хорошее действенное знание менеджерских практик подвержено «умным мутациям» и удачные мутации накапливаются, это быстрее. Так что мы сейчас говорим об эволюции менеджмента в целом, а как части этой эволюции всего менеджмента – эволюции системного менеджмента, которая в том числе может считаться и частью эволюции системной инженерии.
• Развитие (по-русски так передаём evolving, continuous development, continuous improvement, то есть те же идеи «эволюции, постоянного улучшения, прогресса, развития») менеджмента в одной организации. Одни мемы/идеи практик менеджмента, которые используются в разных частях организации или во всей организации в целом становятся обязательными в использовании, а другие наоборот – объявляются вредными. В организациях идёт процесс постоянного улучшения, постоянного развития компании как замены одних практик другими. За это развитие как раз ответственны практики менеджмента, этому посвящён наш учебник. Но в число практик, которыми занята организация, входят как практики собственно организации работы (время создания и развития организации), так и практики планирования и отслеживания работ и других ресурсов (например, финансовых ресурсов), это практики операционного менеджмента (время эксплуатации организации). Так что менеджмент помогает эволюции/бесконечному развитию практик как инженерии целевых систем, так и практик развития самого менеджмента: менеджеры организуют как других, так и организуют себя. Менеджмент как практика, которой должна заниматься организация, просто обязан становиться всё лучше и лучше. Менеджмент меняется не только в глобальных масштабах дисциплины, но и в локальных масштабах практики работы организации.
Эволюция менеджерских практик как инженерии организаций, конечно, связана с эволюцией практик инженерии личности, эволюцией практик инженерии сообществ, эволюцией практик инженерии обществ. Эволюционный характер практик менеджмента означает, что это всегда квазиоптимальные практики в силу неустроенности/frustrations от конфликтов между системными уровнями:
• Есть множество вариантов, которые на данном этапе эволюции можно назвать «лучшими» (множество вариантов SoTA примерно одной результативности и эффективности)
• Эти варианты будут хвалиться на каких-то одних уровнях (личности, организации, сообщества, общества и т.д.), и ругаться на других за неэтичность, неэффективность, некультурность и т.д., ибо конфликты между системными уровнями неизбежны, что в мутации/изменении мемов кажется хорошо на одном уровне, явно будет выглядеть плохо на другом уровне.
• Время от времени будут появляться эволюционные скачки, которые будут приводить к резкой оптимизации. Например, египетские писцы с их записями позволяли налаживать какую-то организационную собранность (управление вниманием коллектива по понятийному наведению внимания и удержанию внимания на важных объектах) для больших коллективов ещё во времена фараонов. Но вот пришли компьютеры, и с ними софт issue trackers, реализованный как low code системы – и массово наладилось управление работами в случае case management. Конфигурация работ стала иметь меньше коллизий, менеджмент улучшился. Всё это как раз предмет нашего учебника, это будет разъясняться в последующих разделах (и мы даже не даём пока русскоязычных переводов: это всё приходит из мировой культуры, эволюция менеджмента глобальна).
Неважно, назовёте ли вы происходящее при сочетании лучших приёмов менеджмента на уровне организации и лучших приёмов происходящего при этом с личностями, сообществами, обществом «инженерией» или «самоинженерией», «организацией» или «самоорганизацией», «спонтанным порядком» или «наведённым порядком». Ребёнок пыхтит, завязывает шнурки, его родители радуются: «самозавязывание шнурков, наконец-то!», а ребёнок думает ровно наоборот: «чёрт, раньше шнурки как-то самозавязывались, а теперь вот приходится их мне завязывать». Аккуратней со словом «само», это часто чья-то работа по планированию, воплощению, развитию, и даже когда в этом «само» участвует много людей, это не означает «само делается», это «они делают», или «они создали условия, где это смогло произойти»).
Эта эволюция рассматривается нами как специализация практик системной инженерии, так что можно ожидать какого-то развития практик менеджмента по тому пути, который проходят практики системной инженерии в других прикладных инженериях, прежде всего программной инженерии – с учётом, конечно, особенностей оргсистем. Так организационные системы, конечно, нельзя «изготовить и собрать» (процесс DevOps) ни как программные системы, ни как «железные системы».
Менеджмент также занимает особое место в прикладных практиках: им нужно заниматься практически во всех проектах, ибо большинство деятельностей коллективны. Даже если считать личность оргзвеном, всегда можно выделить вниманием команду из ролей, исполняемых субличностями, которые в целом составляют эту личность, и этот ход довольно продуктивен (даже некоторые психотерапии его используют, например internal family systems, IFS[34 - https://ifs-institute.com/ (https://ifs-institute.com/)]).
Поэтому менеджмент в части его прикладности рассматривается по-разному:
• Менеджмент – это прикладная практика системной инженерии, находится вне трансдисциплин интеллект-стека. Эта практика приложима к системам определённого масштаба и вида (организациям). Есть специализация агентов (людей, усиленных компьютерами или даже команд людей с их компьютерами) на выполнение ролей этой практики, есть должности в организациях, где практики менеджмента будут ведущими (разного сорта «начальники»). При этом если рассматривать части личности, исполняющие роли внутри одного человека, то менеджмент можно в какой-то мере использовать и для организации работы в такой «внутренней команде личности».
• Используется во всех проектах, поэтому менеджмент хорошо бы хотя бы на кругозорном уровне знать всем людям, чтобы понимать происходящее в их проектах в части организации труда. Он должен входить в обязательный кругозор (в отличие от разных других прикладных инженерных дисциплин, например, кулинарии, врачебного дела, робототехники).
• Условно применим и к себе самому, но это требует определённых представлений о концепции использования личности, концепции личности, архитектуре личности в общеинженерном смысле концепции использования, концепции системы и архитектуры личности как системы.
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) приносит прибыль, а не убыток.
• Архитектурная практика (выполняет архитектор, ответственный за архитектурные характеристики): установить приоритетные архитектурные характеристики, принять решения по способам их достижения путём предписания деления системы на части и указания способа взаимодействия этих частей, а также отслеживать, что создание системы в целом улучшает эти характеристики (то есть, что не накапливается «технический долг» как долг по проведению работ, предотвращающих ухудшение архитектурных характеристик в долгосрочной перспективе)
• Инженерия «производственного конвейера» (выполняет 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[35 - https://humanitec.com/blog/what-developer-self-service-shouldnt-look-like (https://humanitec.com/blog/what-developer-self-service-shouldnt-look-like)]. Если таки надо дорабатывать IDP, то это обеспечивают инженеры конвейера/платформы, то есть исполнители ролей DevOps, но они сами ничего не изготавливают в целевой системе, занимаются только «станочным парком». Кнопку «изготовить» нажимает сам разработчик, а не DevOps, и он же имеет дело с последствиями, это принципиально: you build it, you run it – ты это строишь, ты и эксплуатируешь[36 - Особенности, отличающие platform engineering от традиционных DevOps и SRE ровно в этом: кто строит конвейер и кто нажимает кнопки на оборудовании конвейера – https://thenewstack.io/how-is-platform-engineering-different-from-devops-and-sre/ (https://thenewstack.io/how-is-platform-engineering-different-from-devops-and-sre/)]). Тут сразу сложно, ибо мы получаем «систему создания внутри системы создания», создатели-операторы целевой системы «холдинг из конструкторского бюро (КБ) и завода» и «создатели-операторы КБ плюс завода». При этом понимаем, что в большинстве случаев это совсем не похоже на «конструкторское бюро» и «завод», например, трудно говорить о «конструкторском бюро для оргсистем» и «заводе оргсистем», «конструкторском бюро мастерства» и «заводе мастерства» и даже для компьютерных программ это не так очевидно. Но структура производства и эксплуатации везде будет одинаковой.
Вот это всё мы должны найти сейчас в менеджменте, понимая, что создаётся организация::система. Сложности ещё и в том, что одни и те же люди::агенты создают организацию в роли создателей и работают в этой созданной организации как её части-сотрудники. Поэтому лишний раз подчеркнём, что говорим о ролях, исполняемых агентами (со всеми обычными оговорками, что это может быть одна роль, исполняемая несколькими людьми, один человек, исполняющий несколько ролей, некоторые роли можно отдавать компьютерам, но потом считать, что их выполняет владелец компьютера, владелец компьютера может оказаться оргзвеном из полусотни человек с самыми разными ролями и т.д.).
Напомним системную схему проекта:
В этой схеме мы видим в голубых областях интереса сразу три организации, которые требуют менеджмента: организацию инвестпроекта, организацию проекта развития, организацию проекта. И это минимальная схема, в реальности она более запутанна:
• В организации редко бывает один проект. Этих проектов множество. Они как иерархичны (проекты и подпроекты), так и множественны (заказная разработка: разные заказчики получают разные системы), и всё это сложным образом перепутано.
• Редко так мало звеньев в цепочке создания. На диаграмме три звена, а в жизни в типовых ситуациях 4—6 звеньев в не самых даже больших проектах. И там не цепочки, а «деревья», и они сложно перепутаны, если учитывать ещё и множественность самих проектов из предыдущего пункта.
• Схема используется для MVP системы, а затем для каждого инкремента/фичи в порядке «непрерывного всего»/continuous everything (разработки, введения в эксплуатацию). То есть нужно учитывать, что для каждого инкремента нужно порождать адаптированный экземпляр диаграммы (и напомним, что лучше бы это делать в табличных представлениях, а не графическом представлении диаграммы).
Помним, что эту схему нужно уточнять и конкретизировать в каждом проекте, ибо она дана в терминах самых общих, мета-мета-модели из учебников «Методология» и «Системная инженерия». Вот пример такой конкретизации до уровня мета-модели из учебника «Системная инженерия», схема проекта создания курса (и помним, что целевой системой в таком проекте будет не курс, а мастерство):
Эту схему мы прокомментируем чуть дальше, а пока заметим, что конкретизация из схемы «для всех случаев» в схему «для нашего проекта» ведётся на двух уровнях метамоделирования:
• Мета-модель domain «как в учебниках предметной области» (где самая общая терминология, иногда на иностранном языке, а ещё перечисляются альтернативные варианты представления предметной области, разные школы мысли с предложением разных практик и способов их описания). Для краткости можем называть её метаУ-модель (как в Учебниках)
• Мета-модель domain ситуационная, как это принято в вашей организации, где термины могут быть совсем не «из учебника», а исторически сложившимся сленгом, изо всего разнообразия практик выбраны какие-то конкретные практики (необязательно SoTA, а уж какие исторически сложились, при этом адаптированные под конкретный подвид систем или особенности систем создания – скажем, не просто жарка картошки, а жарка картошки особых сортов, как в McDonalds). Для краткости можем называть её метаС-модель (Ситуационная).
Предметная область/domain в каждом звене цепочки создания, представленном отдельной зоной интересов своя! Где-то это domain целевой системы, где-то это domain менеджмента, где-то будет domain маркетинга как работы с сообществами, и т. д. Когда у вас не мета-мета-модель, а просто мета-модель с одним «мета» – это уже не «безмасштабно» и «беспредметно» типа «каких угодно систем», а для какого-то масштаба, какой-то предметной области работы с какими-то конкретными типами систем.
Примеры ошибок, которые делают практически все наши студенты, проверьте, что вы их не делаете (тут приведены, конечно, не все ошибки, люди очень изобретательны в ошибках, но вот эти делают практически все новички в системном менеджменте):
• Число звеньев цепочки создания (включая то, что разветвления цепочек создания даже не рассматривается, там ведь дерево, а в общем случае направленный граф из таких цепочек) ровно такое, как на наших картинках. Нет, выше было написано, что там граф, и даже в линейном случае очень часто 5—6 звеньев в такой цепочке. Поэтому нельзя копировать схему из учебника, в ней просто другое число элементов! А почему случай не будет линейным? Например, вы тут не видите организации, которая создаёт клиентуру (команда, выполняющая практику продвижения), а она обычно есть.
• Поскольку наш этот единственный пример с курсом (мета-модель, как раз пример конкретизации) явно не подходит для проекта студента, студент вздыхает и берёт диаграмму общего вида (мета-мета-модель), прямо из курса «Методология», где она приводится впервые. И рассуждения ведутся для мета-модели предметной области устно, а на диаграмме так и остаются нетронутыми типы мета-мета-модели в надежде, что «когда-нибудь потом, не сейчас» будет проведена адаптация для предметной области и «когда-нибудь потом всё перерисуем, и даже переложим в таблички». Это откладывание «на потом» ошибка: в этом и смысл всей работы с мета-мета-моделью, что надо проводить адаптацию, это же поиск важных объектов внимания в вашем проекте, которые вы будете отслеживать! Найдите их, выясните их имена! Честно стройте вашу собственную схему, адаптированную для вашей системы, и в которой другое число элементов, чем на диаграмме из наших учебников (может быть и то же самое, но такое бывает редко, не промахнитесь – если визуально ваш труд «по картинке» и по именам основных альф похож на то, что в наших учебниках, то вы уже ошиблись, хватает пары секунд взгляда на результаты вашего моделирования, чтобы это понять).
• Эти диаграммы распухают, графически их поддерживать становится невозможно. Графическая форма не позволяет легко вносить изменения, диаграммы плохо эволюционируют, они хороши для случая «один раз красиво нарисовал, потом показал начальству, потому что это красиво», а вот редактировать их – замучаетесь, их долго править. Вы уже знаете, что для альф придётся добавлять подальфы, для альф и подальф задать ожидаемые состояния, для них сформулировать контрольные вопросы и превратить всё это в кейс в управлении работами – но вместо того, чтобы делать это в табличках какого-нибудь универсального low code моделера, делаете очень долго в графическом виде. А поскольку изменения вносить в диаграмму трудно, то не вносите изменения, и диаграмма теряет актуальность и потом не превращается в исполняемую модель управления кейсами. Поэтому не увлекайтесь рисованием, вовремя переходите к табличному моделированию.
• Обращается внимание не на понятие, а на термин, «совпадение слов», а не совпадение значений – это грубая ошибка. Так, на первом уровне создания «организация», «организация проекта», «предприятие», «инженерная команда», «поток студентов на курсе» – это всё про одно и то же: организованную группу людей.
Теперь надо показать, как оргпроект (создание организации какого-то звена в цепочке создания, плавно переходящее в бесконечное развитие этой организации – мы будем называть это «проектом оргразвития», с акцентом не столько на момент создания, сколько на момент continuous delivery новых оргвозможностей/capabilities и фич в этих оргвозможностях) раскладывается на вышеописанные роли из «Системной инженерии». Различаем при этом время развития организации/«организационных изменений»/«change management» (не путаем «organizational change management»/«управление организационными изменениями»/организовывание с «configuration and change management» из инженерии целевой системы) и время работы/функционирования/operations организации/оргзвена/предприятия/проекта (тут мы показываем эти термины как синонимы: организации/оргзвена/предприятия/проекта, но в реальности за ними могут скрываться разные сущности, будьте внимательны).
Итак, менеджмент как инженерия предприятия включает в себя следующие практики и роли:
• Организатор (аналог 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 и прочих администраторов, которые явно не справляются с должностями, требующими компетенций в других ролях. Они «работники производственного конвейера для поддержки жизни организации, поддержки развития», а после приобретения какого-то опыта могут пытаться ещё и строить такой конвейер. Но вот использование этого конвейера для развития организации в целом требует других специализаций: организатора, бизнесмена, архитектора организации. И мы понимаем, что слово «администратор» очень широкое, но всё-таки означает чаще «исполнительные» роли поддержки какого-то конвейера, а не роли, занятые использованием этого конвейера для какого-то дела (при всём понимании, что «всё со всем связано, конвейер должен быть согласован с типом тех систем, которые по нему проходят»).
Примеры соответствия системноинженерных и прикладных ролей
Давайте попробуем изложить всё то же самое в виде таблички, в которой пропишем роли (но за каждой ролью обязательно скрывается практика этой роли, её просто не будем писать для экономии места):
Как совместить эту табличку с системной схемой проекта? В первой же зоне интересов создателя есть альфа организации проекта создания целевой системы (её могут называть в каких-то вариантах диаграммы альфой «организация» без упоминания «проекта создания», альфой «команда», альфой «инженерная команда»), это и есть оргроль «инженера», и в ней можно выделять практики визионера, архитектора, разработчика (проектировщика, технолога, оператора), инженера платформы разработки. Если берём «создателя создателя», то там тоже есть организация развития – развития той самой команды инженеров, это оргроль «менеджер».
Это редко называют «организация менеджеров», но вот «менеджерская команда» вполне можно услышать, равно как и просто множественное число «менеджеры», равно как и «служба развития», хотя бы часть этой команды, например, люди в подролях оргроли менеджера развития. У оргроли «менеджер» (помним, что в жизни эта роль обычно исполняется целой организацией, а не одним человеком) множество подролей, это будут подальфы – бизнесмен, орг-архитектор, организатор (с его подролями, которые в проекте могут быть отслеживаемы как подальфы, проходящие каждая свои состояния), администратор.
Для примера адаптированного варианта системной схемы проекта, а именно учебного проекта курса системной инженерии (целевая система «мастерство системной инженерии») мы можем обсудить особенности нахождения вот этих ролей. В зоне интересов создателя мастерства мы видим альфу самого создателя: это поток/группа курса системной инженерии, состоящая из студентов, преподавателей, инструкторов, студентов. Этот поток должен изготовить описание мастерства системной инженерии (во время обучения), причём в голове студента. Потом это актуальное мастерство должно проявиться в момент работ уже бывшего студента, а теперь мастера, то есть в момент эксплуатации мастерства. Как это происходит? Должны ли мы искать все инженерные и менеджерские роли в каждой команде, смена состояний которой в ходе её создания должна отслеживаться в проекте? Например, в создании мастерства должны обязательно поучаствовать культуртрегер, архитектор учебной программы, автор курса (и там подроли методолога и методиста), преподаватель (и там подроли предметника и лидера), за выполнением всех учебных работ студента должен отвечать тьютор, а также должна работать инструментальная платформа создания мастерства (помещения, софт), за которую отвечает декан.
И мы действительно видим в проекте создания курса места для этих ролей, но эти роли задействованы в разных командами, находящимися в разных местах цепочки создания, в разных областях интересов. Главное, чтобы мы не пропустили за многочисленными командами наличие этих ролей. Например, «курс системной инженерии» легко представляется, как нечто, соответствующее его описанию, «проекту курса», который создали авторы курса. Но реальным объектом «курса» будет его прохождение, а оно организовано в форме занятий студенческой группы с преподавателями – потока. То есть команды создания курсов в рамках какой-то учебной программы (над которой работает архитектор как автор куррикулума, он отслеживает относительную автономность потоков и команд создания курсов) по сути дела создают проект курса (то есть в этих командах предусмотрены роли культуртрегера, автора курса), а затем преподаватели как части этих команд (они «инженеры-технологи», работают во время изготовления мастерства) создают мастерство в рамках работы команд потоков, тьюторы отслеживают при этом общее прохождение работ по изготовлению мастерства разными командами, пытаясь ускорить прохождение обучения студентами (например, давая указания, какая стадия обучения должна быть оптимизирована методистами, ибо студенты застревают именно на ней).
Можно, конечно, обсуждать – в каких именно командах и как должны работать все указанные роли, но уже понятно, что такие быстрые прикидки («кто такой преподаватель? Он инженер-технолог, стадия изготовления. Это не автор курса? Сколько нам надо иметь преподавателей? Сколько авторов курса? Понимаем ли мы, что преподаватели по конкретному предмету/курсу – по роли это не столько члены «потоков», сколько члены команды создания курсов, подроль «разработчика»? Получается, что команда потока состоит из людей, которые частично пришли в неё из другой команды!
То есть «поток» представляет собой не столько «команду разработки мастерства», сколько банальный станок изготовления мастерства (предоставляется деканом как «инженером платформы», ответственным за «станочный парк»), а инженер-технолог/преподаватель просто использует студенческую группу как конвейер со станками, изготавливающий мастерство в мозгах студентов в ходе занятий. Но точно так же можно использовать и компьютерную систему, и даже вообще обойтись без преподавателя, если у нас «завод-автомат» (скажем, так устроены онлайн-курсы).
То, что вы должны делать, когда адаптируете системную схему проекта – это проводить вот такие рассуждения. И, конечно, поскольку каждый раз речь идёт о каких-то командах и налаживании их работы, нужно задавать вопрос – а кто и как эти команды организует? Это уже будет обсуждением менеджерских ролей. Команду создания курса надо организовать, команду потока надо организовать – первую как команду разработчиков/авторов курса и преподавателей этого курса, вторую как учебную группу (куда будут входить в том числе и люди первой команды – преподаватели). Число рассматриваемых ролей быстро начинает расти, и даже для небольшого проекта вы будете находить не только от 15 внешних ролей проекта, но и чуть ли ни несколько десятков внутренних ролей, нужных для создания самых разных встречающихся в проекте систем, и эти роли будут раскиданы по самым разным командам (да ещё и люди в этих командах будут пересекаться, но орг-архитекторы будут приглядывать, чтобы команды всё-таки были по возможности автономны).
Как это всё увязать вместе? Понимая, что в учебниках даны только типы мета-мета-модели интеллект-стека (включая практику системной инженерии), а в нашем учебнике «Системного менеджмента» только метаУ-модель менеджмента, при этом даже если вы будете пытаться моделировать очень простую организацию, вам придётся сразу рассматривать довольно сложные раскладки разных ролей по командам (хотя все эти роли могут играться даже одним человеком, он же и будет единственной «командой»). Так, фирма должна «изготовить» целевую систему, инвестуру (привлечь инвестиции), клиентуру (заполучить клиентов). Вот пример[37 - https://ic.pics.livejournal.com/ailev/696279/212554/212554_original.png (https://ic.pics.livejournal.com/ailev/696279/212554/212554_original.png)] объектов, которые нужно при этом отслеживать: системная схема предприятия, и это опять-таки только пример! Не пытайтесь скопировать его для вашей фирмы, для вашего проекта! Чётко видно, что визуальное представление «не работает» – вам его будет довольно сложно адаптировать для вашей фирмы (хотя рассматривать в учебнике довольно просто, но непросто будет редактировать[38 - Диаграмма в формате. graphml для редактора графов yEd —]), нужно сразу переходить на табличное моделирование. «Фирма» – это альфы в голубых областях интереса, клиентура и инвестура – внешние проектные роли для разных команд в фирме, показаны в зелёных областях интереса надсистем, связанные с целевой системой альфы показаны в её жёлтой области интереса. Ориентируемся всегда на жёлтенькое – область интересов целевой системы, всё остальное разворачиваем вокруг неё. В большинстве основных альф показаны через перечисления ещё и их возможные подальфы (см. схему ниже).
Вопрос: а зачем всё так сложно? Наоборот, всё просто: на диаграмме просто много раз повторённый блок области интересов на три альфы, только каждый из этих блоков связан с соседними, ибо сам что-то создаёт и его кто-то создаёт. Даже целевая система тоже создаёт какие-то изменения в своём окружении, про неё тоже можно так же думать, но это не показано. Удивительная компактификация мышления, в каждой точке этой диаграммы рассуждения почти одинаковы, хотя слова везде разные, в этом и суть адаптации системной схемы проекта для разных предметных областей.
Вам надо научиться вот такому «одинаковому мышлению в каждом месте цепочки создания» для организаций, в которые вы попадаете. Не надо копировать эти сложные картинки из учебника, моделируйте табличками, обсуждайте длинные цепочки создания. Тут специально вставлена для примера дилерская сеть/агентура, просто чтобы показать, как удлиняется цепочка создания от принятых организационных решений цепочки создания. Если вы инженер и вам не интересно инвестирование, не моделируйте его. Это не всегда цепочки, цепочки тут как один из маршрутов на более сложных графах, в вашем проекте всё может быть по-другому. В разных командах могут быть и одинаковые роли, и разные. Планируйте множество команд в сложных цепочках, не забывайте проектировать фирму в целом, если вас интересует менеджмент, учитывайте разные команды с разными ролями внутри фирмы, не забывайте учитывать ещё и работы этих команд, помнить о необходимости управлять этими работами. Не забывайте кроме целевой системы (а продуктов может быть несколько! И их могут делать разные команды в рамках разных цепочек создания в одной фирме) ещё и о клиентуре (и там могут быть разные сегменты! С ними могут работать разные команды продвижения!), и об инвестуре. Адаптируйте материал учебника для своего проекта, вам тут рассказывается только о типах объектов в организации, а не даются шаблоны устройства организации. Устройство организации везде будет разным, одинаковых организаций не бывает. Но думать об этих самых разных организациях можно более-менее одинаково, вот об этом наш учебник.
Широкое, узкое и слишком узкое понимание менеджмента. Менеджерские (под) практики и (под) роли
Только что мы определили, что если создаём и развиваем организацию, то нам нужны следующие роли для инженерии организации как общей практики: организатор::разработчик, бизнесмен::визионер, орг-архитектор::архитектор, администратор::DevOps/«organizational platform engineer» (и сюда же неявно относим и сотрудников этой организационной платформы). Эту инженерию организации мы затем назвали менеджментом, а подход к такому же описанию менеджмента::инженерия, как в системной инженерии – системным менеджментом.
Зачем разбираться в том, как мы получили описание практики менеджмента из описания практики инженерии? Затем, что в жизни никогда не будет «как в учебнике», и вам придётся самостоятельно «дорабатывать учебник», это неизбежно. Так что хорошо бы вам знать, каким образом (какой практикой) этот наш учебник «Системный менеджмент», содержащий метаУ-модель с «типами учебника», создан, чтобы знание из учебника не оказалось плохо применимой в жизни догмой. Вы всё время будете сталкиваться с новыми и новыми ситуациями, где нужно будет не только конкретизировать метаУ-модель менеджмента до метаС-модели для типов важных объектов во впервые встреченной вами организации, но и адаптировать саму метаУ-модель – начиная с таких маленьких адаптаций, как смена терминологии. Вы-то будете понимать, что «роза пахнет розой, хоть розой назови её, хоть нет», что термины и важны, но и неважны тоже, а для окружающих вас людей терминология может вдруг оказаться принципиальной. И вы тогда организатора назовёте не организатором, а вожатым, вожаком, вождём, начальником, шефом, боссом или ещё как-нибудь. Но мышление у вас останется прежним, в терминах метаУ-модели, ибо вам жизнь в вашей организации придётся всё время состыковывать с жизнью в других организациях, и нужно будет поддерживать некоторый общий для них всех язык размышлений, «знание принципов освобождает от знания фактов», мышление надо экономить. В некоторых же случаях вам придётся разбираться на боле глубоком уровне, например, вы можете встретить книгу по классической системной инженерии, где инженерия целевой системы и менеджмент инженерной организации серьёзно перепутаны вместе до полного неразличения, плюс остались какие-то старые идеи (типа инженерии требований и водопадного проектного управления). Что вы будете делать? Вам потребуется понимание, как использовать фундаментальную мета-мета-модель интеллект-стека и прикладную мета-модель (в нашем учебнике это метаУ-модель менеджмента). И ещё надо будет докрутить самостоятельно это знание до более приземлённого вида метаС-модели менеджмента в вашей конкретной организации. Это всё практики метамоделирования как подпрактики онтологической инженерии (создания онтологий, подробнее проходится в курсе «Онтология и коммуникации», а затем работа с онтологиями проходится во всех курсах: все мета-уровни моделирования какой-то системы, в данном случае организации как системы создания целевой системы – это и есть онтология. Её нужно создать, просто это создание разнесено по очень разным сообществам. Интеллект-стеком и мета-мета-моделью занимается одно сообщество (условно «системные мыслители», «философские логики»), метаУ-моделью другое (профессиональное сообщество, создатели body of knowledge), метаС-моделью третье (работники организации и все, кто с этой организацией сталкиваются и хотят лучше понять там происходящее), моделью (операционной) – работники организации, но уже во время operations, а не во время construction, как в случае с метаС-моделью.
С точностью до довольно запутанных цепочек создания (то есть в предельном упрощении) в организации вы найдёте множество самых разных ролей:
• Все, кто занимаются инженерией (созданием и развитием) целевой системы – инженеры целевой системы. Мы оставляем тут общее слово «инженеры», понимая, что для каждой предметной области это слово будет меняться. Например, если целевая система – это тело человека, то это «врачи». Помним, что нас тут интересуют не слова, а роли в деятельности. Если интересно, как должны работать эти люди, надо брать учебник «Системная инженерия» и адаптировать его для предметной области примерно так же, как мы это делаем для системы-организации. Среди прикладных инженеров, например, корпоративных информационных систем можно найти разработчиков, визионеров, архитекторов, DevOps. И мы дальше для краткости будем говорить, что прикладные инженеры создают целевую систему (а длинно – создают и развивают, continuous everything).
• Все, кто создаёт и развивает клиентуру целевой системы (инженерия клиентуры: маркетинг, реклама, продажи) – это продвиженцы по их роли, а практика – продвижение продукта или услуги. Важно понимать, что клиентура::сообщество это не целевая система, а внешние проектные роли в проектах системного окружения целевой системы (прежде всего проект надсистемы). В менеджменте мы найдём и частный вид клиентуры: инвестуру, потенциальных собственников, покупателей долей в самой компании. Так что обсуждение тут опять уровня мета-мета-модели, общей для самого разного вида систем. Конечно, агент, выполняющий роль прикладного инженера, может хорошо объяснить, чем его система лучше систем конкурентов, но всё-таки продажей занимается обычно не он: главное ведь найти среди всех людей на Земле тех немногих людей, кому это надо объяснять, и вот этот «поиск людей в окружении целевой системы, которым нужна наша система» совсем другая практика, чем разбирательство с самой целевой системой. Но и тут вы можете найти разработчиков, визионеров, архитекторов, DevOps (тут даже не будем давать примеров, но обычно «конвейер», который тут строится DevOps, сегодня часто называется «воронка продаж», отдельные «инкременты» создаваемой клиентуры – это сегменты целевой аудитории, обрабатываемые «маркетинговыми/рекламными кампаниями» – всё то же самое на уровне типов мета-мета-модели системной инженерии, но другие слова для других типов систем). Для краткости мы будет говорить, что продвиженец развивает клиентуру, а не создаёт и развивает клиентуру, упор на бесконечное развитие, а не на однократное создание. Слово-термин для «продвиженца» везде будет другое, терминология тут совсем ещё не устоялась. Например, бизнесмен как агент в роли «продвиженца» продаёт организацию потенциальным акционерам/собственникам/инвесторам/«инвестуре». И всё чаще и тут используется термин «воронка продаж», всё выглядит очень похоже: изо всех людей планеты нужно найти тех, кто заинтересован в его «товаре» и сервисе этого «товара» по добыче из него денег либо через дивиденды, либо в форме последующей перепродажи по более высокой цене.
• Все, кто занимаются инженерией организации как созданием и развитием организации-создателя целевой системы – инженеры организации. Это и есть менеджеры в широком понимании, описанные выше: организатор::разработчик, бизнесмен::визионер/стратег, орг-архитектор::архитектор, администратор::DevOps/«инженер оргплатформы». Тут мы тоже для краткости будем говорить «развитие организации», а не полностью и точно «создание и развитие организации», называя функцию (обще) менеджерской роли, но для самого функционального объекта/роли «менеджер» по отношению к организации будем говорить «создатель», а не «создатель и развиватель» и не «развиватель». Кратко получится «создатель организации её развивает», а не «создатель и развиватель организации её создаёт и развивает». При этом интуитивно понимаем, что MVP организации – это когда она не распалась, исчерпав деньги инвестора, а как-то функционирует, получая рыночный доход (в том числе и до момента break even[39 - https://en.wikipedia.org/wiki/Break-even (https://en.wikipedia.org/wiki/Break-even)] – то есть организация что-то зарабатывает). Дальше в ней в ходе по возможности бесконечного развития появляются новые capability, которые позволяют ей сначала зарабатывать больше, чем расходовать, а потом и начинать возвращать инвестированные деньги, это может продолжаться и несколько лет, а в случае удачи и сотни лет.
Проблема в том, что «в быту» не всех агентов, преимущественно выполняющих роли создателей организации на своих должностях будут признавать менеджерами. Все будут согласны, что администраторы (бухгалтеры, юристы, HR, офис-менеджеры и т.д.) занимаются не столько целевой системой, сколько самой организацией, и поэтому «вроде как менеджеры». Предъявление архитектора будет ставить в тупик: с одной стороны он вроде «не работает, а командует, значит менеджер», с другой стороны, «вроде на интуитивно понимаемого менеджера не похож». Но безусловно менеджером будут называть организатора::разработчик, но и тут не всё гладко: аналитик, который «понимает» что-то в организации, пишет своё понимание в аналитическом отчёте, но никаких решений не принимает – он не воспринимается менеджером, равно как и инженером организации. «Серым кардиналом» признаётся, но не менеджером. Это всё интуитивные «бытовые» оценки типа роли, но хорошо бы, чтобы наши определения тоже были культурно-обусловленные, опирались на распространённые мемы, а не были бы тут сочинённые авторами учебника вне зависимости от того, что и как понимается «нейронной сетью нейронных сетей» сотрудников самых разных организаций. Менеджмент в этом плане не математика, нельзя сказать «пусть бухгалтер будет менеджером-администратором». Сказать, конечно, можно, но в некоторых организациях это будет понято и принято, а в некоторых – нет. И опираться на такое понимание поэтому будет нельзя, слишком многим людям придётся слишком много объяснять.
В принципе, это же верно и для прикладной инженерии. Если взять ту же разработку корпоративного софта, то разработчика вполне назовут software engineer, а вот DevOps так уже не назовут. Понятие platform engineer для создаваемого DevOps «конвейера самообслуживания разработчиками»/«internal development platform» появилось совсем недавно, и хотя эти инженеры вроде бы такие же software engineers, только софт у них другой, за ними не признаётся полноценное «инженерство» и «разработка», когда идёт коммуникация внутри компании. Но это такие же разработчики софта для pipeline разработки, как и разработчики целевого софта для поддержки практик целевой компании, для которой разрабатывается этот корпоративный софт. Всё везде «одно и то же», «инженерия», поэтому в языке постоянно появляются различения «нашей инженерии» и «не нашей инженерии».
Так что при малейших затруднениях в коммуникации (в том числе при коммуникации с самим собой, к новым понятиям ведь привыкается трудно) всегда отступайте в терминологии – называйте роли, которые вам или кому другому трудно назвать «менеджер» «инженерами организации» или вообще меняйте терминологию, если в вашей организации не готовы инженеров организации называть инженерами организации или менеджерами. Например, в субкультуре («художественное творчество») менеджеров называют «оргами» как сокращение от «организатор». Орг фестиваля, орг вечеринки – это менеджеры, они создают и развивают организацию/команду, которая и проводит мероприятие. Вот и называйте их так. Но тип у них всех будет «менеджер» из нашего учебника, поэтому от организаторов можно будет ожидать, что они будут выполнять все менеджерские практики, находясь во всех менеджерских ролях – даже если они эти практики не будут никак называть, даже если эти практики будут не SoTA, а искренне с нуля изобретённым велосипедом из прошлого века. И если что-нибудь эти по названию не «менеджеры», но играющие роль менеджеров агенты (в том числе с их компьютерами) забудут выполнить из менеджерских практик, то с организацией будет беда.
Безусловно «менеджером» назовут организатора:: «разработчик предприятия», который организует людей в организацию. Это и есть узкое понимание менеджмента, разделяемое большинством людей, не погружённых в специфику создания и развития организаций. То, что «организация» это и имя функции::поведение организатора::роль, и результат работы организатора, нас не смущает, но для надёжности мы иногда будем функцию обозначать словом «организовывание», чтобы не путать с организацией::системой как результатом организовывания.
Организатор, выполняющий практику организовывания/организаторства – это слишком крупная роль для слишком крупной практики. В жизни она бьётся на менее крупные, среди которых обычно выделяют подроли, попадающие чаще всего к разным людям, развивающим какие-то виды мастерства:
