Томный вечер конца декабря, тьма за окном и конечно чтение руководств МИМ располагают к осмыслению проблем в формате очень похожем на “нытинг”.
Поясню, “нытинг” в моем понимании, это краткий неформальный митинг\встреча на котором можно пообщаться на предмет проблем и затруднений, не входящих явно в твою зону\область ответственности, либо недостаточно “страшных\актуальных” что бы все бросать и начинать ими заниматься в первом приоритете. Однако жизнь при этом портящих.
И поэтому стоящих чтобы их обозначили и решили.
Чтение руководства по Системной инженерии, а именно описание роли Системного инженера, как раз к этому располагает 
На любом проекте, в любом коллективе все есть проблемы с кросс-функциональными, межмодульными, общими для всего проекта решениями.
Людям не интересно ничего за пределами их, достаточно узкой профессиональной области.
А если интерес есть, то часто не хватает второго компонента, смелости взять на себя инициативу, принять решение или даже просто предложить решение и взять на себя ответственность за обоснование его правильности, я уже не говорю о воплощении этого самого решения в жизнь.
Т.е. по сути вижу несколько барьеров\уровней проблем в проекте:
- “Мы работаем как положено, а положено у нас на все”
Равнодушие\зацикленность на своей нище, отсутствие любопытства. - “Как бы чего не вышло, а то вдруг по шапке дадут”
Страх выдвинуть предложение, настоять на своем, обосновать решение. Повзаимодействовать с внешними по отношению к команде ролями. Или даже просто четко и понятно описать проблему, хотя бы текстом, если не можешь\не хочешь сделать это устно и в реальном времени. Часто ни мышления письмом, ни мышления проговаривание у людей не видно. - “Я проблему обозначил, а решать ее, это не моя задача”
Взять на себя ответственность за решение проблемы, запланировать и отследить\протолкнуть все необходимые этапы\действия в средне\долгосрочной перспективе. - “А чё такого? И так пойдет”.
Отсутствие требуемого кругозора\уровня мастерства\культуры. Одна коллектива просто не видит каких то проблем, а другая не может их решить, даже если хочет. - “Стабилизец как он есть.”
Сопротивление изменениям. Часто люди не хотят меняться, и как следствие не хотят видеть изменения в внешнем мире.
Как с этим жить и что делать? А может это нормально? И вообще, сколько нужно системных инженеров или архитекторов, смотрящих на проект сверху? А в пропорции к разработчикам?
Иии.. в этот момент я вспомнил что гипотеза на эту неделю звучит примерно так - “нужно использовать AI везде где можно и где нельзя”.
Поэтому, взял приведенное выше описание ситуации и запихал в perplexity вместе с вопросами.
Да, да, да. Опять эти ср..ые нейросети. Сейчас будет кусок очередной бесполезной жвачки из “китайской комнаты”…
Но нет, не буду вставлять ответ бога из машины:))
Скажу лишь кратно, для сильных команд это не норм, и с этим можно бороться.
Как именно? Пока пропустим, сам еще не осмыслил.
Сама шпаргалка, аля надерганные из руководства цитаты - ниже. Вот их, как раз почитать полезно.
Системная инженерия - метод работы, который ответствен за обеспечение целостности системы и её графа создателей в инженерном проекте.
Системная инженерия помогает договориться, как в целом создать и развивать успешную систему и как в целом разделить труд в команде создателей этой системы.
Главный признак, отличающий системных инженеров «по роли» от всех других прикладных инженеров:
они отвечают за целевую систему в целом, как в части деталей-частей (разные системные уровни требуют разных методов для работы с типовыми для них системами — с микросхемами работают не так, как с компьютерами, а с компьютерами не так, как с системами управления, в состав которых входят компьютеры),
так и в части использования детальных знаний отдельных инженерных методов (разные свойства систем какого-то типа требуют знания разных методов: если вам нужно сделать корпус компьютера, то нужны и знания инженера-механика, чтобы корпус был прочным и лёгким, и знания инженера-теплотехника, чтобы компьютер не перегревался и корпус обеспечивал достаточную вентиляцию).
Главная задача создателя в роли системного инженера — чтобы не было пропущено какой-нибудь мелочи, ведущей к провалу.
Полезно задумываться, что вы меняете в окружающем мире, и происходят ли эти изменения к лучшему.
Все сегодняшние проекты по изменению мира к лучшему различаются и по их форме, и по их содержанию, но одновременно и все проекты оказываются в чём-то одинаковыми:
они являются разными вариантами инженерных проектов, проектами по созданию (часто не с нуля, но это дела не меняет) успешных систем.
Если оказалось, что речь идёт не о проектах по изменению мира к лучшему (то есть не об инженерных работах), то такие проекты выполнять не нужно.
Один человек, даже если он гений, не в состоянии удержать целостность в современных сложных проектах:
целостность удерживается в современном мире только командно и уж точно не людьми, а хорошо налаженными компьютерными моделями, которые точно не забудут ни одной детали, ни одной строчки ни одного документа.
То же самое относится к информационным системам и AI-системам: их потребуется множество, и нужны будут средства интеграции их работы в одно непротиворечивое целое. Универсальности не бывает, даже современные AI-системы приходится специализировать.
От играющих самые разные роли и поэтому имеющих самые разные интересы людей, AI-систем и даже больших организаций из людей и AI-систем с их коллективной памятью, поддержанной базами данных, в инженерном проекте требуются две вещи:
- Согласовывать свои решения. Не договорились — не делаем!
- Дисциплина всё записывать/учитывать: договорились и делаем — записать, о чём договорились, что делаем, что сделали, чем обосновывали. Не записали — это не договорились, так что — не делаем! Памяти не верим, верим записям, нужна не «ментальная собранность», нужна киберсобранность.
Каждый прикладной «по видам систем» инженер (авиатор, генный инженер, учитель) существенную часть времени проводит в роли системного инженера, озабоченного успешностью целевой системы и её проекта в целом, а не только по какой-то одной его прикладной характеристике.
Прикладная «по методу» инженерия (электрика, механика, теплопередача) так и вообще сдвигается на AI-copilots, которые оказываются всё более и более подготовленными к выполнению роли прикладных инженеров, решению каких-то узких задач.
Системный инженер - это роль.
«системный инженер» — это когда любой создатель вдруг занимается проектом (деятельностью графа создателей) и его системой как целым, то есть практикует фундаментальный метод мышления по мета-мета-модели из нашего руководства, а ещё это профессионализация прикладного инженера на составляющих метода его работы, нацеленных тоже на целостность системы и её проекта, чаще всего это связывают с архитекторами и инженерами внутренней платформы разработки, которые так и будут называться в инженерии киберфизических систем, но в предприятии это архитекторы предприятия и администрация, в обучении это архитекторы учебных программ и деканат.
В любом случае, «системный инженер» в названии должностей проявляется редко.
Создатели в роли системных инженеров не руководят («руками водят», то есть дают поручения на выполнение работ по развитию системы, начальствуют) прикладными разработчиками, но принимают решения по принципам их работы и структуре развиваемой/evolving разработчиками системы, а также создают условия (в том числе инфраструктуру) для работы всех разработчиков.
Это не руководство или управление/management, это:
- разработка какого-то технического решения: высказывание догадки, критика, рациональный выбор наименее плохого решения (ибо лучшего решения заведомо нет, оптимальность принципиально недостижима). Это чаще всего и называют инженерной работой — по роли инженера. Но это только начало инженерной работы над решением!
- принятие решения (по David Deutsch — «принятие всерьёз», то есть решение кладётся в основу для действия, а не просто «принимается к сведению»). Важно, что это самостоятельное, полномочное, инженерное принятие решения, а не как у аналитика «принятие решения по вынесению предложения» для того, чтобы «принятие всерьёз» сделал кто-то другой — начальник, который ничего не понимает в этом решении, не имеет достаточно времени на его рассмотрение и просто «верит аналитику».
- информирование всех о принятом решении (можно дальше долго обсуждать, принудительным уведомлением/push или по добровольной подписке/subscribe — тут это пока неважно, но нельзя принять решение так, чтобы о нём никто не знал), но затем разъяснение и обучение тому, в чём суть этого принятого инженерного решения и почему оно принято именно такое, а не какое-то другое. Тут используют разные слова для метода этой работы, чаще всего «техническое лидерство» (у классических «железных» системных инженеров), а у программных инженеров, следующих методам инженерной эволюционной разработки — «менторинг».
- надзор/governance за тем, чтобы решения реально выполнялись. И если не выполняются, то принятие мер (вплоть до увольнения сотрудников, которые эти решения саботируют).
Команды системных инженеров не столько руководят специализированными на работе в каких-то прикладных инженерных областях (domains) людьми, выполняющими ещё более узкие инженерные методы, сколько организуют их взаимодействие по поводу разделения их труда, выполняя свой кусок инженерной работы в части целевой системы и технологий, используемых в проекте создания (прежде всего технологии непрерывного ввода в эксплуатацию).
Повторим, что совсем необязательно называться системным инженером, чтобы им быть. Так, архитекторы софта (software architects) вполне себе системные инженеры, специализирующиеся на программных системах. Архитекторы предприятий — системные инженеры, специализирующиеся на организационных системах. Дело совсем не в названии должности или метода, не в членстве в ассоциации, дело в содержании: в реально выполняемых методах работы.
Термин «системная инженерия» используется в двух разных значениях:
- системная инженерия — это инженерный метод, задействующий системное мышление.
- системная инженерия — это метод поддержания целостности системы, в отличие от прикладных инженеров-разработчиков, системный инженер занимается системой в целом, а не какими-то частями системы или прикладными особенностями системы