Задание из Системного менеджмента 2023. МетаС-модель моего рабочего проекта

Написан пост, в котором деление практик менеджмента и ролей этих практик из предпоследнего абзаца предыдущего раздела курса (список из абзаца «Давайте ещё раз выпишем…») выписано в терминах, используемых в вашей организации, вашем рабочем проекте (метаС-модель). Следите, чтобы это были именно практики и выполняющие их роли, а не должности или организационные статусы. Откомментируйте ваши выборы терминов по каждой строчке, почему именно они, и какие были альтернативы. Отметьте вашу квалификацию (уровень мастерства) в выполнении каждой из этих практик или честно признайтесь, что ситуация с этим как в анекдоте «— Умеете ли вы играть на скрипке? — Нет, не пробовал, но думаю, что у меня получится».

Как предписывает задание, берём шаблон из предыдущей главы:

  • инженерия целевой системы — тут очень легко с должностью, обычно это главный конструктор. Но т. к. это должность, то часто главный конструктор не конструктор, а администратор, например. Но если говорить именно про нашу организацию, то главный конструктор и системный инженер тождественны. Системный инженер космической системы. Системная инженерия в аэрокосмических системах консервативная, но родная.
  • визионерство целевой системы (прогноз целесообразности создания целевой системы) — Интуитивно хочется сказать «Заказчик» :slight_smile: Но это, конечно не роль. Интересы рынка представляет коммерческий директор::тоже должность, а по роли маркетолог(?).
  • архитектурная деятельность для целевой системы — явно роль организацией не осознанна. Движемся к явному её выделению, но сейчас она «размазана между ролей»
  • разработка — разработчик. Да, у нас разработчики тоже называются разработчиками.
  • проектирование — такой роли явно не выделено, но по факту эту роль тоже выполняют разработчики(?)
  • изготовление/производство — инженер-технолог. Да, технологи так и называются технологами
  • эксплуатация — оператор космической системы. Чаще называем оператор группы управления. Потому что бывают ещё группы по подсистемам, которые как бы напрямую не управляют, но следят за цифровым двойником.
  • инженерия платформы разработки (DevOps) — у нас есть понятие платформы в космической системе. Но это понимание ближе к платформе в автомобильной промышленности. И у нас есть инженер платформы. Но такое впечатление, что он ближе по роли к архитектору. А инженер платформы разработки, который DevOps, это скорее ближе к тому, что у нас называется технический директор. Тоже должность. Но роль у него содержать в порядке орудия производства разработчиков в широком смысле.
  • менеджмент (инженерия организации) — менеджер в широком понимании (инженер организации). Подход в организации проектный, поэтому основная практика менеджмент проектов/программ.

А вот практики менеджмента у нас в состоянии хаоса и мы их только начали осознавать, вытаскивать в модели и распутывать. Очень часто роли играются одним агентом, от этого имеет место конфликт интересов. Который очень трудно распутывается.

  • стратегирования (для удержания стоимости бизнеса) — бизнесмен. У нас роль бизнесмена играет собственник, поэтому роль отдельно не выделена.
  • орг-архитектурная деятельность — хаос и стихия
  • организовывание — хаос и стихия
  • организационное развитие — хаос и стихия
  • оргпроектирование — хаос и стихия
  • лидерство — хаос и стихия
  • операционный менеджмент — хаос и стихия
  • администрирование — хаос и стихия
  • продвижение продукта или услуги (инженерия клиентуры: маркетинг, реклама, продажи) — продвиженец (там тоже разбиение на подпрактики и подроли!)
  • привлечение инвестиций (инженерия инвестуры, fundraising) — грантоед :smiley:

Собственно в моём проекте орг-развития я начал с моделирования отдела продаж, т. е. начал распутывать с ролей продвиженца. А по факту пришлось проектировать всю организацию из состояния as is. Но так как полномочий на перепроектирование всей организации никто не давал я исполняю эти роли в рамках своего отдела. Ну а на то, чтобы эти роли начали исполняться в масштабе всей организации начал просто влиять.

Моё мастерство в указанных ролях

Не очень понятно в чём измерять мастерство, поэтому как обычно опишу поэтично. )

  • инженерия целевой системы — какая-то определённо есть, потому что в менеджеры и потом предприниматели перебрался из инженера. Принимал участие в разработке нескольких космических систем как инженер.
  • визионерство целевой системы (прогноз целесообразности создания целевой системы) — сложно сказать, так как ни на одной придуманной космической системе пока не разбогател, но и в состояние «сумасшедшего изобретателя» не понятного миром не пришел.
  • архитектурная деятельность для целевой системы — около нулевое мастерство было, но на курсе системной инженерии много материала прочитал. Но ещё мало практики. Тут я в начале пути
  • разработка — очень низкая квалификация, но широкая по горизонтали. Т.е. имею представление по каждой из составных частей космической системы. Могу поговорить с настоящими разработчиками.
  • проектирование — ну т.к. уже писал, что часто тут у нас нет чёткого деления то тоже низкая, но размазана широко.
  • изготовление/производство — та же ситуация что и выше
  • эксплуатация — когда то был в составе оперативной группы управления серьёзными миссиями дальнего космоса. Какое-то мастерство имеется. Но не выдающиеся.
  • инженерия платформы разработки (DevOps) — достаточно высокое, как это ни странно. Так как в своём проекте пикоспутников (Принятые архитектурные решения в проекте пикоспутников) я существенную часть космической системы разработал и её же потом эксплуатировал.
  • менеджмент (инженерия организации) — менеджер в широком понимании (инженер организации). До 2020 года мастерство получал «в полях», на книжках и горьком опыте. Решил упорядочить хоть как-то и пошел в магистратуру. Магистратура привела меня в ШСМ. Где я вот это мастерство менеджмента сейчас и оттачиваю. Оцениваю как среднее. Коллективами а тысячи человек никогда не руководил. До таких проектов мне далеко. Но команды в несколько десятков да.
  • продвижение продукта или услуги (инженерия клиентуры: маркетинг, реклама, продажи) — продвиженец. Тоже со времён магистратуры совершенствую это мастерство. Пока сильно не преуспел. Решаю эту проблему набором мастеровитых сотрудников.
  • привлечение инвестиций (инженерия инвестуры, fundraising) — вот в части инвестуры опыт есть. А в части грантоедства мастерство выдающиеся. Гордится этим не хочется, от того и осваиваю рынок.
1 лайк

Обычно названия практики “проектирование” и “изготовление” используются для хардверных систем, “проектирование” и “разработка” - для софтверных. Для киберфизических - могут использоваться все три названия, но практики тогда - три или 4, разных.

Так же “инженер технолог” обычно занимается “проектированием изготовления”, а сама практика “изготовление” - это прямая работа с материалом, пайка, сборка, 3Д печать и т.п. Роли тут - монтажник, сборщик, оператор станка с ЧПУ, и т.п. Похожих ролей в списке нет вообще?

Ну инженер-технолог есть, буквально в виде технолога, он, собственно, способы производства выбирает.

Монтажник, пайщик и т.д. определённо есть, но мы фаблес, пожтому эти роли есть, но не у нас. За ними присматривает/govern инженер-технолог.

Хотя, конечно, что-то приходится “допиливать напильником”/подпаять на месте. Поэтому роли эти выполняются, но доля их не велика.

Но вообще, практики проектирования/описания, как КБ. И практики производства/воплощения, как завод делятся. Это вы правы. По шаблону в конце рабочего дня не вспомнил.

У вас, вероятно, в части софта всё более-менее соответствует приведённой в учебнике схеме - есть внутренняя платформа разработки, у неё есть архитектор и/или инженер платформы, и есть архитектор, проектировщик и разработчик софта, работающие на платформе.

А вот в части харда всё сложнее. Если вы фаблесс, то для вас мощности используемых фабов-подрядчиков - внешняя данность. То есть у них есть свои архитекторы и инженеры платформ, у них есть рабочие, а у вас есть к ним мостик - ваш инженер-технолог, который определяет, что можно куда отдать на воплощение. И, возможно, он же ещё на стадии архитектуры изделия определяет - что вообще можно воплотить силами подрядчиков. То есть эта роль участвует в очень ранних стадиях работы, и ее важно не потерять.

Кстати, интересно было бы побольше почитать про использование практики DevOps в вашей деятельности. Дело в том, что не всякая платформа разработки может быть названа DevOps. Если вы реально выкатываете на уже запущенный спутник версии нового софта - то это без вопросов DevOps. Если же нет, то нужны какие-то аргументы, чтобы показать, что вы уже отошли от старой доброй дискретной практики к непрерывным интеграции и запуску в эксплуатацию.

Если вы реально выкатываете на уже запущенный спутник версии нового софта - то это без вопросов DevOps.

Да, обновляем софт на спутниках, которые уже на орбите.

За основу берём модель Intel Тик-Так, только в отличии от Intel такты такие:

  • «Тик» — это обновление «железа». Обозначается поколениями платформы.
  • «Так» — доведение возможностей железа до максимума софтом уже в стадии эксплуатации.

Поэтому естественным образом получается, что в космос летят «сырые» спутники с минимальным софтом для обеспечения жизнедеятельности, а потом уже в космосе на цифровом двойнике и железном «тройнике» (Цифровая тень космической системы) отрабатывается прошивки. Прошивается уже спутник в эксплуатации.

Следующий «тик» запускается уже спутник с обновлённым железом и т. д.