Системные инженеры как люди, занимающие позицию в проекте в профессиональной роли отвечающего за какую-то целокупность всей системы (помним, что мы говорим о системе самых разных уровней – это может быть бактерия для генного системного инженера, или городской квартал в «умном городе» для инженера-строительного девелопера, или общество какой-то страны для политика) специализируются тем самым до лидеров инженерной разработки/development (самый верхний уровень, концепция использования и самые верхние уровни концепции системы), и часто на этом самом верхнем уровне это неотличимо от работы инженеров-разработчиков, инженеров-архитекторов и DevOps (разработчиков инфраструктуры непрерывного введения в эксплуатацию, аналог «управления жизненным циклом» в ситуации множественности этих жизненных циклов). Системные инженеры не руководят («руками водят», то есть дают поручения на выполнение работ по развитию системы) прикладными разработчиками, но принимают решения по принципам их работы и структуре развиваемой/evolving разработчиками системы, а также создают условия (в том числе инфраструктуру) для работы всех разработчиков. Это не руководство или управление/management, это governance.

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

Вместо «дирижёрской» поэтому лучше использовать «джазовую» метафору описания деятельности, это подробней будет изучаться в курсе системного менеджмента/инженерии предприятия. Так, звукорежиссёр из записанных в студии разными музыкантами в разное время отдельных треков делает окончательную запись. Но он не предписывает, какую музыку играть музыкантам. Звукорежиссёр тут – DevOps. Или руководитель джазового ансамбля, который выбирает, какую мелодию будут играть – но он не командует кому, когда и что играть, и не выдаёт точные ноты мелодии, не указывает точную гармонию или ритмический паттерн. Это разработчик концепции использования. Или художественный руководитель, который определяет, кто вообще будет играть в ансамбле и устраивающий разнос музыкантам по поводу плохого качества их игры. Это архитектор. Люди, исполняющие роли системных инженеров в команде тоже имеют различающиеся функции, в самых разных их сочетаниях. Но как музыкантов из ансамбля называют «музыкант» (исполнителей ролей музыкантов, отождествляя их с ролями), так и мы системных инженеров из команды/коллектива проекта будем называть «системный инженер» для краткости. Курсы «Онтологика и коммуникация», «Практическое системное мышление», «Методология» помогут вам тут разобраться с различиями ролей, должностей, исполнителей ролей (как отдельных людей, так и организованных в плане распоряжения своим и чужим трудом, инструментами и материалами групп людей). В курсе системного менеджмента как инженерии организации вы получите дополнительный опыт того, как строить системы из людей так, чтобы в их состав входили все нужные виды инженеров (входили люди, исполняющие все необходимые для создания целевой системы практики, исполняя все нужные инженерные роли, включая роли в системах цепочек создания).

Разные виды системных инженеров имеют и разные акценты в их образовании. Так инженер-архитектор знает множество архитектурных паттернов для того вида целевых систем, который развивается в проекте. И ещё он имеет опыт разработки, чтобы не отрываться от реальности и не требовать от разработчиков невыполнимого. DevOps хорошо понимает в операционном менеджменте, ибо его главная задача – уменьшать Lead Time (этих Lead Time есть ещё и много разных вариантов), в общем случае определяемого как время от момента, когда появилась идея очередного инкремента системы (например, реализующего какой-то запрос клиентов на новую фичу) до момента, когда потребители смогут воспользоваться этим инкрементом в составе эксплуатируемой системы, и всё это должно происходить быстро, но без роста числа дефектов эксплуатирующейся системы (да, это умение выполнять модернизацию двигателя автомобиля не выключая двигатель, и даже не прекращая движения! И тут только доля шутки).

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

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

Главным же критерием отнесения какой-то инженерной специальности к (безмасштабной/фундаментальной/трансдисциплинарной) системной инженерии, а не (прикладной) инженерии систем является то, что системный инженер думает о всей системе на многих системных уровнях в целом, а не о каком-то её аспекте (механическом, электрическом, программном и т.д.) на каком-то одном системном уровне. Именно этот критерий даёт основание David Firesmith относить инженеров по безопасности и защите (вроде как прикладных инженеров) к системным инженерам: несмотря на то, что инженеры по безопасности имеют свои ВУЗы, профессиональные организации и конференции, они думают обо всей системе в целом, и на этом основании их вполне можно считать системными, а не прикладными инженерами. В нашем курсе не обсуждается их практика, но она оказывается в чём-то похожа на практику архитекторов, только набор характеристик там другой (не архитектурные, а безопасности и защиты). Всё это, конечно, более-менее условно, в том числе и потому, что в проекте люди обычно выполняют множество ролей и быстро переключаются между ними.

В любом случае, название «системный инженер» будет использоваться в курсе как название роли (тип мета-мета-модели, объект из нашего курса, а не из жизни), но нужно учитывать, что в жизни в разных предметных областях (культурная мета-модель, отражающая domain и ситуационная мета-модель, отражающая принятый способ работы в конкретном проекте) вы будете слышать самые разные другие имена и ролей и тем более должностей. Вы должны будете догадаться, что речь идёт о системной инженерии (вообще-то всегда идёт речь о системной инженерии!), и тогда вам пригодится знание материала нашего курса, в самых разных проектах. И это может быть отнюдь не SoTA версия инженерии, то есть инженерия в вашем проекте может оказаться не системной, не безмасштабной, не непрерывной (зато люди будут гордиться, что они заняты «искусством», проявляют находчивость и изобретают велосипеды, а лучшие из них будут считать себя «ремесленниками», а не инженерами. Десяток лет в программной инженерии такое отношение к методам собственной работы было даже модно, сейчас об этом предпочитают не вспоминать).

В мире существует несколько профессиональных организаций системных инженеров, из них наиболее значительной является международный совет по системной инженерии (INCOSE, International Counsil of Systems Engineering, http://incose.org).

В этой организации есть индивидуальное членство ($50-$160 в год) и корпоративное членство ($4750—7250 в год), в 2022 году примерно 19 тысяч индивидуальных членов во всех стран мира³⁹.

Цели INCOSE – распространять знания по системной инженерии, обеспечивать международное сотрудничество и обмен опытом системных инженеров, устанавливать стандарты профессионального мастерства и проводить сертификацию системных инженеров на соответствие этим стандартам, обеспечивать поддержку корпоративных и правительственных образовательных программ в области системной инженерии.

Деятельность INCOSE проходит главным образом в рамках деятельности региональных (уровня штата или города в США, страны или даже группы стран в Европе и Азии) отделений.

Есть Русское отделение INCOSE (INCOSE Russian Chapter). Русское – это название по языку, а не по стране. Члены этого отделения из России, Украины, Белоруссии. Это похоже на Немецкое отделение (INCOSE German Chapter), где члены из Германии и Австрии. Русское отделение входит в INCOSE EMEA sector (отделения INCOSE из стран Европы, ближнего Востока и Африки). Русское отделение INCOSE проводит заседания раз в две недели, на этих заседаниях заслушиваются доклады о современных практиках системной инженерии, прорабатывается использование русской терминологии, ведётся обсуждение исследований⁴⁰. Раз в год в подмосковном Бекасово проходит трёхдневная Рабочая встреча Русского отделения INCOSE по проблемам системной инженерии (до 2022 года было проведено 12 таких встреч⁴¹).

INCOSE разработало этический кодекс системных инженеров⁴², активно участвует в разработке международных стандартов, сертифицирует системных инженеров (по факту – инженеров киберфизических систем, хотя это явно не декларируется).

Тем не менее у этой организации есть существенные проблемы:

• Исторически там собрались системные инженеры киберфизических систем, и значительная часть их занимается государственными инфраструктурными и военными проектами. Это означает, что меньше всего там используются принципы lean, ведущие к минимальному дублированию работ (госбюджет заплатит! Это не рынок!) и agile (государство строго планово! Никакого «планирования на лету» и тем более «неудачных экспериментов»! ). По факту варианты системной инженерии, поддерживаемые этой организацией, базируются на идеях «водопада» и не учитывают идей непрерывной инженерии (в общих словах – признают и учитывают, но при рассмотрении сути практик в публикуемых учебниках, документах, стандартах – нет). Ровно по этой причине частная компания SpaceX смогла за несколько лет сделать в космических проектах больше, чем все традиционные контракторы NASA (достаточно сравнить проект Starship с проектом SLS по скорости разработки и новациям). И таких «частных компаний» в организации явно недостаточное представительство, больше представителей компаний с крупными военными проектами. SpaceX активна в INCOSE была где-то в 2007 году, но не сейчас.

• INCOSE признаёт, что системная инженерия безмасштабна и используется для всех системных уровней (это ясно видно по INCOSE Vision 2035⁴³). Но исторически всё равно центрируется на системно-эволюционном уровне киберфизических систем как основных для членов этой организации.

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

Повторим, что совсем необязательно называться системным инженером, чтобы им быть. Так, архитекторы софта (software architects) вполне себе системные инженеры, специализированные на программных системах. Архитекторы предприятий – системные инженеры, специализированные на организационных системах. Дело совсем не в названии должности или практики, не в членстве в ассоциации, дело в содержании инженерной практики.

Мы тут использовали термин «системная инженерия» в двух разных значениях, так он используется и в жизни:

• Любая инженерия, ибо без системного подхода, учёта самых разных систем в окружении и цепочках создания, учёта эволюции и непрерывной подстройки под изменения нельзя менять мир. Как бы ни называлась практика, она оказывается инженерной, тем самым системноинженерной. Любой инженер – это системный инженер. Это соответствует определению «системная инженерия – это практика инженерии с системным мышлением в голове инженера».

• Те практики системной инженерии, которыми занимались люди, считавшиеся системными инженерами в инженерии киберфизических систем: на сегодня это главным образом архитекторы и DevOps, а также создатели концепции использования (ConOps, OpsCon). Эти люди получают специальное обучение по своим поддисциплинам. Это соответствует определению «системная инженерия – это практика поддержания целостности системы, в отличие от прикладных инженеров-разработчиков, системный инженер занимается системой в целом, а не какими-то частями системы или прикладными особенностями системы».

Какое значение правильное? Оба, и жизнь покажет, какое из них выживет. Пока же используются оба значения, в нашем курсе/книге тоже так.