Анатолий Левенчук – Системный менеджмент – 2023 (страница 9)

Если не вводить такого широкого класса какой-то практики (в нашем случае менеджмента) как «мета-модель из учебника», трудно перетаскивать знания не только между разными предприятиями, но и между проектами одного предприятия: практики менеджмента в отделе бухгалтерии и в отделе 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-service35. Если таки надо дорабатывать IDP, то это обеспечивают инженеры конвейера/платформы, то есть исполнители ролей DevOps, но они сами ничего не изготавливают в целевой системе, занимаются только «станочным парком». Кнопку «изготовить» нажимает сам разработчик, а не DevOps, и он же имеет дело с последствиями, это принципиально: you build it, you run it – ты это строишь, ты и эксплуатируешь36). Тут сразу сложно, ибо мы получаем «систему создания внутри системы создания», создатели-операторы целевой системы «холдинг из конструкторского бюро (КБ) и завода» и «создатели-операторы КБ плюс завода». При этом понимаем, что в большинстве случаев это совсем не похоже на «конструкторское бюро» и «завод», например, трудно говорить о «конструкторском бюро для оргсистем» и «заводе оргсистем», «конструкторском бюро мастерства» и «заводе мастерства» и даже для компьютерных программ это не так очевидно. Но структура производства и эксплуатации везде будет одинаковой.

Вот это всё мы должны найти сейчас в менеджменте, понимая, что создаётся организация::система. Сложности ещё и в том, что одни и те же люди::агенты создают организацию в роли создателей и работают в этой созданной организации как её части-сотрудники. Поэтому лишний раз подчеркнём, что говорим о ролях, исполняемых агентами (со всеми обычными оговорками, что это может быть одна роль, исполняемая несколькими людьми, один человек, исполняющий несколько ролей, некоторые роли можно отдавать компьютерам, но потом считать, что их выполняет владелец компьютера, владелец компьютера может оказаться оргзвеном из полусотни человек с самыми разными ролями и т.д.).

Напомним системную схему проекта:

В этой схеме мы видим в голубых областях интереса сразу три организации, которые требуют менеджмента: организацию инвестпроекта, организацию проекта развития, организацию проекта. И это минимальная схема, в реальности она более запутанна:

• В организации редко бывает один проект. Этих проектов множество. Они как иерархичны (проекты и подпроекты), так и множественны (заказная разработка: разные заказчики получают разные системы), и всё это сложным образом перепутано.

• Редко так мало звеньев в цепочке создания. На диаграмме три звена, а в жизни в типовых ситуациях 4—6 звеньев в не самых даже больших проектах. И там не цепочки, а «деревья», и они сложно перепутаны, если учитывать ещё и множественность самих проектов из предыдущего пункта.

• Схема используется для MVP системы, а затем для каждого инкремента/фичи в порядке «непрерывного всего»/continuous everything (разработки, введения в эксплуатацию). То есть нужно учитывать, что для каждого инкремента нужно порождать адаптированный экземпляр диаграммы (и напомним, что лучше бы это делать в табличных представлениях, а не графическом представлении диаграммы).

Помним, что эту схему нужно уточнять и конкретизировать в каждом проекте, ибо она дана в терминах самых общих, мета-мета-модели из учебников «Методология» и «Системная инженерия». Вот пример такой конкретизации до уровня мета-модели из учебника «Системная инженерия», схема проекта создания курса (и помним, что целевой системой в таком проекте будет не курс, а мастерство):

Эту схему мы прокомментируем чуть дальше, а пока заметим, что конкретизация из схемы «для всех случаев» в схему «для нашего проекта» ведётся на двух уровнях метамоделирования: