Системная инженерия – 2022

Проект создания мастерства должен предусмотреть и более-менее автономное рассмотрение системы целевого уровня (а часто и не только целевого). И тут окажется, что для такого сорта систем как мастерство, даже если принять «инженерный подход к делу», а не «педагогический» или какой-нибудь менее определённый «культурных изменений» или чего чего-то более размытого в плане указания на цели и способы работы, есть много особенностей. Чтобы научиться такой «инженерии уровня личности», нужно освоить какую-то довольно специфическую практику инженерии (инженерия мастерства, которая даже называться будет «обучение», а не «инженерия»). Обучение, в свою очередь, как метод изготовления мастерства, будет разбито на множество разных практик. Это практики культуртрегерства как создание концепции использования мастерства в его «личностном окружении» (начало разработки – старт проекта, культуртрегер тут как product-manager), методологии и методики как разработки мастерства, преподавания как DevOps (изготовление и проверка частей, сборка из частей и проверка целого, введение в эксплуатацию – вынос в жизнь), мастерского выполнения деятельности как эксплуатация мастерства. И это не разовое прохождение жизненного цикла: нужно ещё и обновлять мастерство в уже выученных мастерах, как сейчас обновляют прошивки телефонов в давно изготовленных телефонах.

Эта адаптация методов системной инженерии для самых разных её приложений происходит для всех масштабов систем, всех видов систем одного масштаба. Концепция использования, а также use cases к театральной постановке, ледоколу, парламенту будут обязательно нужны (и это говорится в системной инженерии, мы особо отметим это в нашем курсе), но они и называться будут все по-разному, и разрабатываться по-разному (и это будет говориться в прикладных «инженерных» курсах. Слово «инженерный» тут в кавычках, чтобы напомнить: не все эти инженеры будут соглашаться на то, что они будут называться именно «инженерами». Но мы будем их называть именно так).

По каждой такой конкретизации/адаптации, в каждом приложении системной инженерии к какому-то виду целевых систем нужно владеть прикладной практикой инженерии, часто называемой «инженерия таких-то систем» в случае уровней косного вещества и киберфизических систем (например, инженерия систем управления, control systems engineering, и помним, что systems engineering отличается от engineering of systems[31 - If there is an issue between SE and EoS, it may be semantic, rather than grammatical. Classically, the first word moderates the second: so, in SE, ’systems’ appears to moderate (describe the type or flavour of) engineering; and in EoS, ’engineering’ appears to moderate (describe the type and flavour of) systems. – из prof. Dereck Hitchins, «SYSTEMS ENGINEERING VS. ENGINEERING OF SYSTEMS – SEMANTICS?», https://systems.hitchins.net/profs-blog/systems-engineering-vs.html (https://systems.hitchins.net/profs-blog/systems-engineering-vs.html)]) и уж совсем по-разному в случае более высоких системных уровней. Например, курс по инженерии мастерства (с неминуемым охватом не только ведения учебного процесса как создания мастерства, но и создания учебного курса со всеми его материалами как системы в цепочке создания мастерства) является именно конкретизацией/адаптацией курса системной инженерии. Пример такой конкретизации для курса инженерии нового мастерства как части общего мастерства уже образованных людей доступен в Школе системного менеджмента под названием «Мастерство обучать образованных»[32 - https://system-school.ru/teaching (https://system-school.ru/teaching)] (по названию инженерного мастерства, которому учит курс – «обучение образованных»). Конечно, эта конкретизация тоже не «законченный продукт», курс постоянно обновляется, «непрерывная инженерия».

3. Уровень специализации инженерии конкретной системы

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

Скажем, игра на фортепиано – это мышечная практика и по факту она может быть надстроена над мастерством системного фитнеса, но не только – в это мастерство входит как минимум ритмика, которой нет в системном фитнесе и можно ещё обсуждать промежуточную практику музицирования, которая неразличима для вокала, игры на фортепиано и игры на скрипке, и учёт всех этих особенностей даст совсем разные практики игры на фортепиано, которые по-разному могут преподаваться в музыкальных школах, но неизбежно приведут к более-менее похожим результатам. Помним про неустроенности и эволюцию: есть множество выживающих почти одинаковых вариантов оптимизаций для межуровневых конфликтов, а резкие улучшения довольно редки. Это означает, что есть множество самых разных вариантов «инженерии музыки на инструментальной базе фортепиано», они дают все примерно одни и те же результаты, плохие варианты рыночно вымрут, а улучшения будут, но крайне редки. Скажем, улучшение типа игры на клавишном синтезаторе, или магнитофон, а затем и плеер, который позволяет не играть пьесу каждый раз, а просто воспроизводить записанное. Эволюция практик происходит постоянно, а практики – это и есть деятельности/виды труда, и они же – виды инженерии. И если какая-то команда занялась инженерией такого вида систем, то она будет заниматься этим видом систем непрерывно, подстраивая варианты целевой системы под изменения окружения и используя всё новые появляющиеся альтернативы по концепции системы как способы реализации функций какими-то интересными новыми конструктивными элементами.

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

Скажем, для создания текущего курса «Системная инженерия» можно использовать конкретизированную схему «образовательного проекта»:: «проекта создания»/«инженерного проекта» (и тут даже приведены названия конкретных организаций, которые связаны с проектом, ШСМ и INCOSE RUS, при этом в области интересов надсистемы/окружения могут находиться альфы, как-то связанные с разными системами в окружении, например альфы и связанные с ШСМ, и связанные с INCOSE RUS):

Эта схема также может читаться двумя способами:

• создание и непрерывное ведение курса (иногда такое называют «вечная бета») в целом, со всеми его версиями

• создание и введение в эксплуатацию какого-то одного инкремента курса в порядке его развития. Тогда при желании можно выполнить ещё такт адаптации, дав название этому инкременту. Помним, что диаграммы в части их модификации – это зло, поэтому такие схемы в жизни будут существовать в табличном виде, и каждый инкремент легко может получить своё название. С диаграммами такое не пройдёт, если вы выпускаете по паре инкрементов в день, просто сил на перерисовку не хватит!

Если вы будете создавать «систему найма сотрудников»:: «проект оргразвития», то это третий уровень конкретизации, конкретный проект в организации, ситуационная мета-модель уровня стандарта предприятия и модель конкретной проектной ситуации с учётом экземпляров (операционным учётом). На втором уровне конкретизации (культурная мета-модель) это будет предметная область на каком-то достаточно абстрактном уровне учебников менеджмента как прикладной дисциплины инженерии предприятия, то есть «проект оргразвития»:: «проект создания»/«инженерный проект». А сам «проект создания»/«инженерный проект» – это самый общий уровень, наименее конкретный, безмасштабный/фундаментальный, то есть создание чего угодно, уровень рассмотрения нашего курса системной инженерии, уровень мета-мета-модели. И не путайте системные уровни (отношение часть-целое) и уровни абстракции (отношение принадлежности к классу, конкретизация как противоположная направленность абстрагирования как раз тут).

Такой подход многоуровневой конкретизации инженерного метода решает и традиционные проблемы классического подхода к инженерии как отдельной от менеджмента. В классической системной инженерии как инженерии сложных киберфизических систем обычно вынуждены описывать менеджмент проектов создания самолётов и подводных лодок как «системноинженерный менеджмент». Если понимать, что речь идёт об инженерии организации, которая будет заниматься созданием киберфизической системы, то это просто описание двух инженерных проектов в цепочке создания: создание киберфизической системы (самолёта или подводной лодки – концепция использования, use cases для них, архитектурные решения, и т.д.) и создания организации проекта (стратегия этой организации как концепция использования и use cases организации/команде/коллективу/предприятия/«производственной кооперации» проекта, решения по концепции системы, архитектурные решения для предприятия как архитектурные решения по организации проекта, и т.д.). Эти проекты существенно связаны в части архитектуры целевой системы и организации (через закон Конвея и обратный манёвр Конвея), и эту связь реализуют архитекторы. Архитекторы целевой системы и организации согласуют их архитектуры и меняют их по мере развития целевой системы.

А чему учить тогда системных инженеров, например, классических киберфизических систем? Учить нужно так же многоуровнево:

• общей безмасштабной и непрерывной системной инженерии, это и есть предмет нашего курса/книги

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

• затем конкретизации этой инженерии для самолётов (конкретная предметная область, и это будет весьма разная инженерия для одномоторного одноместного самолёта и авиалайнера на три сотни пассажиров – domain), и доводят это до узкой практики, которая используется в конкретном проекте (и тут говорят про ограниченную предметную область, workflow/practice как bounded domain).

• и обязательно менеджменту, то есть организационной инженерии с конкретизацией для инженерных организаций в авиации.

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

Ответственность системных

инженеров за целокупность систем. Фундаментальность/трансдисциплинарность системной инженерии

Ответственность за всю систему на многих уровнях как целое (whole system) и связанная c этим фундаментальность/трансдисциплинарность/transdisciplinarity подхода к другим инженериям (механической, электрической, программной, предприятия и т.д.) отличают системную инженерию от всех её частных/предметных/domain конкретизаций. Представим себе ледовую буровую платформу:

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

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

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

Это главный признак, отличающий системных инженеров «по роли» от всех других прикладных инженеров: они отвечают за целевую систему в целом, как в части деталей-частей (разные системные уровни требуют разных практик для работы с типовыми для них системами – с микросхемами работают не так, как с компьютерами, а с компьютерами не так, как с системами управления, в состав которых входят компьютеры), так и в части использования детальных знаний отдельных инженерных практик (разные свойства систем какого-то типа требуют знания разных практик: если вам нужно сделать корпус компьютера, то нужны и знания инженера-механика, чтобы корпус был прочным и лёгким, и знания инженера-теплотехника, чтобы компьютер не перегревался и корпус обеспечивал достаточную вентиляцию). Главная задача системного инженера – чтобы не было пропущено какой-нибудь мелочи, ведущей к провалу.

Авиалайнер – это много-много кусков металла и пластика, синхронно летящих вместе с людскими телами и чемоданами на скорости 900км/час (0.85 от скорости звука, это типовая скорость Boeing 787 Dreamliner) на высоте 11км. Системный инженер в его прикладной специализации «авиационный системный инженер» – это тот::роль, кто придумал, как обеспечить их надёжный и экономичный совместный полёт, увязав самые разные интересы самых разных ролей (грузоподъёмность, расход топлива, дальность полёта, шум при взлёте и посадке, ограничения по длине разбега и посадки, необходимость лёгкого обслуживания на земле, отсутствие обледенения, безопасность людей на борту, и т. д. и т.п.), при этом эти интересы отстаивались самыми разными исполнителями внешних проектных ролей, представлявшими самые разные профессиональные и общественные группы исполнителей тех или иных практик (экологи, военные, урбанисты, коммерсанты, и т.д., и т.п.). Для авиалайнера примерно шесть миллионов деталей замысливаются, проектируются, именуются, изготавливаются, проверяются, доставляются в одно место, собираются в одно изделие, принимаются как целый авиалайнер и продаются, в аэропорту эти собранные детали как одно целое обслуживаются, заправляются топливом и едой, заполняются пассажирами и грузом, диспетчируются на взлёт – и вот эти шесть миллионов деталей летят, обеспечивая комфорт пассажирам и прибыль владельцам.

Но это даже не вся история: авиазавод тоже делает и дальше развивает системный инженер! Элон Маск не боится компаний, которые делают прототипы электромобилей. Даже для ракет создать серийное производство ракет вдесятеро трудней, чем создать саму ракету. Для автомобилей создать производство автомобилей в сто раз трудней, чем создать автомобиль[33 - «It’s relatively easy to make a prototype but extremely difficult to mass manufacture a vehicle reliably at scale. Even for rocket science, it’s probably a factor of 10 harder to design a manufacturing system for a rocket than to design the rocket. For cars it’s maybe 100 times harder to design the manufacturing system than the car itself. The issue is not about coming up with a car design – it’s absolutely about the production system,» Musk said. «You want to have a good product to build, but that’s basically the easy part. The factory is the hard part.» – https://www.businessinsider.com/elon-musk-says-building-factory-100-times-harder-than-making-car-2019-3 (https://www.businessinsider.com/elon-musk-says-building-factory-100-times-harder-than-making-car-2019-3)]. Это тоже делают (системные) инженеры::роль. Для любого производства киберфизической системы нужно учесть потребности внешних проектных ролей, разработать концепцию использования и концепцию системы, принять архитектурные решения, создать информационную модель с детальностью, достаточной для изготовления, далее выполнить все закупки комплектующих, построить завод, запустить/наладить его оборудование, нанять и обучить людей, потом управлять тем, чтобы этот завод работал «как машина» (несмотря на то, что работают на нём не только машины, но и люди). Это всё требует многоуровневого (системного) учёта мельчайших деталей нижних уровней.

Если где на конвейере завода неудачно выпадет винтик из-за того, что что-то там было плохо спроектировано, потом плохо смонтировано, поломка плохо диагностирована, может неожиданно остановиться весь завод. Ну, или работники завода могут забывать вести учёт изменений оборудования этого завода – и будет непонятно уже, какое там стоит оборудование, и как его ремонтировать. Это кажется не таким важным для автомобильного завода, но в США как-то была закрыта атомная станция из-за того, что состав оборудования «в жизни» через несколько лет работы стал существенно отличаться от состава оборудования «по документам»: никто не давал гарантии, что будет понятно, как быстро отреагировать на проблемную аварийную ситуацию, разобраться «по чертежам» уже стало невозможно, эксплуатацию сочли далее очень опасной, атомную станцию закрыли. Это проблема в организации труда инженерной бригады, и в конечном итоге это тоже проблема инженерии, но инженерии предприятия, называемой обычно «менеджментом» («организационным менеджментом» в части создания и модификации/модернизации организации, «операционным менеджментом» в части эксплуатации созданной организации).

Всё то же самое относится к «нежелезным» системам. Если вы работаете с генной инженерией, то используете вирусы. Это означает, что вам нужно соответствующим образом простроить работу исследовательской лаборатории, работу производственных мощностей, организовать работу с персоналом и ещё отвечать на многочисленные вопросы по биоэтике, а также делать это достаточно долго, всё не закончится первым же продуктом, будь он удачным или не очень удачным. То есть работать нужно отнюдь не только с самими вирусами! Это всё проблемы «системного инженера»:: роль (роль, а не «должность»! ). Такую роль могут выполнять десятки людей в большом проекте. Системный инженер держит все (и в окружении, и в цепочках создания) системы в проекте взаимоувязанными, ибо именно у него (или у них, если проект большой) в голове и компьютерах (основной инструмент – моделер для системного моделирования) практика раскладки всей сложной производственной системы в её окружении на уровни, а также раскладки рассмотрения разных интересов в рамках одного уровня на разные практики, многоуровневой оптимизации решений для удовлетворения всех интересов (конфликтов/противоречий между решениями разных уровней избежать нельзя, нужно проявлять изобретательность, и всё равно в результате будет неустроенность/неустаканенность в конструкции системы, будет проявляться субоптимальность в решении этих конфликтов). В помощь системным инженерам тут компьютеры, позволяющие удерживать всю эту сложность в усиленной компьютером памяти, проводить имитационное моделирование для экономии времени и материалов по сравнению с пробами и ошибками в реальной жизни. Компьютеры помогают удерживать коллективную собранность: проявлять коллективное внимание к каждой мелочи нижних уровней разбиения систем, не теряя коллективного внимания ко всему огромному целому на верхних уровнях, глубоко уходящих в окружение, и это коллективное внимание будет удерживаться компьютерами также и на этих верхних, надсистемных уровнях окружения, а также по необходимости на всех уровнях систем и их окружения по цепочке создания. Ответственный за организацию коллективного многоуровневого внимания к самым разным системам как раз системный инженер. «Системный» тут как раз отсылает к многоуровневости внимания, в отличие от внимания прикладных инженеров к одной предметной области какого-то одного системного уровня для систем какого-то одного вида.

Роль (системного) инженера

Все рассуждения про роли и агентов/IPU как актёров/деятелей/практиков:: «исполнителей ролей» полностью применимы к системным инженерам как деятелям/практикам, занимающимся практиками системной инженерии. Причём для системных инженеров как «деятелей/практиков вообще» будет два вида конкретизации, если нужно разбираться с ролями в жизни:

• Конкретизация по линии масштабов и видов систем в каждом масштабе.Системный инженер обычно занимается несколькими масштабами системы/продукта в её окружении, а прикладные инженеры по конкретным системам занимаются каким-то одним видом системы, одной предметной областью. То есть системный инженер – инженер-робототехник (скажем, должность «ведущий робототехник»), врач (инженер человеческого организма, чаще всего на стадии жизненного цикла «ремонт» и в случае паталогоанатома – «вывод из эксплуатации»), инженер предприятия (скажем, на должности «директор по развитию» или «менеджер проекта»), инженер общества (скажем, должность «депутат Госдумы»). Эта конкретизация требует, конечно, обучения особенностям каких-то конкретных систем, в приведённых примерах нужно хорошо разбираться с дисциплинами, объясняющими работу роботов, предприятий, общества. Если ограничиваться только общими знаниями по безмасштабной системной инженерии (например, знанием текущего курса) и ничего не знать про особенности целевой системы, то будет «хотели как лучше, а получили как всегда». Уже давно нет «врачей вообще», ровно так же как и «инженеров вообще» (хотя сто лет назад были и просто врачи, и просто инженеры) а есть врачи по отдельным подсистемам человеческого организма: отоларинголог, уролог, стоматолог, клинический психолог или даже психиатр. Ещё есть варианты тоже по линии изменения состояния целевой системы (педиатры, патологоанатомы), или состава целевой системы (семейный врач). Вот это деление врачей по их целевым системам, как ни странно, ровно такое же, как и инженеров по их видам целевых систем (подсистем: например, специалисты по фюзеляжам самолёта или инженеры-двигателисты в авиапромышленности). Врачи – это тоже инженеры, они тоже меняют физический мир к лучшему!

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

• У врачей тоже есть подобное разделение. Например, по типам практик вмешательства (стадия «изготовление»): терапевт (неинвазивные вмешательства и сборка разных других видов вмешательств в работающее целое, «ввод в эксплуатацию»), хирург (инвазивные вмешательства), врач функциональной диагностики (нет вмешательства, только диагностика как часть проектирования будущего вмешательства). И тут обычно обязательно будет добавляться вид системы, ибо вид вмешательства/изготовления существенно может отличаться в зависимости от вида целевой системы. Без того, с какой системой работаешь, о практике мало что можно сказать, хотя и тут можно вывести за скобки немало. Так, хирург лет двести назад ещё не был ярко выраженной подролью врача, это была просто одна из врачебных практик, лет пятьдесят назад хирургия была уже отдельной практикой, а сейчас практически независимо практикуется нейрохирургия и кардиохирургия, да и в целом уже не встретишь «хирурга общего профиля», кроме самых захудалых сельских больниц. Конечно, на какой-нибудь подводной лодке можно встретить даже «врача» по всем вопросам, а в деревне «фельдшера» (даже не совсем врача, но тоже по всем вопросам), но это уже не типичная ситуация, не отражает «лучших известных на сегодня практик»/state-of-the-art (SoTA). В инженерных проектах по созданию киберфизических систем можно встретить инженера-электротехника, инженера-теплотехника, инженера-электронщика, но в маленьком стартапе на трёх человек можно встретить и просто «инженера», а исполнитель этой роли ещё будет прихватывать и другие роли – продавца, проектного менеджера и даже уборщика помещения. Так и в системной инженерии бывает «просто системный инженер», а бывает системный архитектор или девопс (по-старинке иногда называемый системным администратором, хотя он давно уже ничего не администрирует, а создаёт «автоматического администратора»).

Всё разнообразие ролей, которые получаются конкретизацией по обеим линиям (масштабов и видов систем, а также видов инженерных практик) будет выполняться какими-то агентами (обычно людьми и их организациями), имеющими должности или составляющими какие-то оргзвенья. Не нужно думать, что системный инженер будет называться именно так. Он может быть на должности «ведущий инженер», может называться «завуч» в случае образовательных учреждений, может быть «координатором», смотреть нужно на содержание его деятельности/практики. Если это практика, описанная в нашем учебнике как архитектурная или DevOps, то она идёт с целой системой, так что это системный инженер.

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

Позиция единства инженерного взгляда как минимум на инженерию и менеджмент уже давно признаётся системными инженерами. Вот в журнале «Project Performance Engineering Systems Engineering News» в апреле 2022 это даётся на седьмой странице обведённым в рамочку[34 - https://issuu.com/ppisyen/docs/ppi_syen_111_april_2022/29 (https://issuu.com/ppisyen/docs/ppi_syen_111_april_2022/29)], чтобы системные инженеры об этом не забывали:

Человек на должности инженера может сутки напролёт играть роль менеджера, планируя работы, и наоборот, человек на должности менеджера может сутки напролёт разбираться в инженерных задачах. Элон Маск сообщает о себе, что 70% времени занят решением инженерных задач «по железу», то есть играет роль инженера киберфизических систем, и даже необязательно системного инженера, но и просто инженера-разработчика, который что-то изобретает и принимает трудные проектные решения по концепции системы. Элон Маск – это агент/актёр, и оказывается, что роль предпринимателя и менеджера (он ведь CEO и в Tesla, и в SpaceX) он исполняет меньше времени, чем роль инженера «по железу»! Да и эти 30% «менеджмента и предпринимательства» оказываются инженерией предприятий, то есть инженерией всевозможных цепочек создания.

Если вы понимаете, как устроена инженерия на самом высоком уровне абстракции (наш курс как раз про это), вам будет легче разобраться в неизбежном разнообразии видов деятельности по созданию самых разных видов целевых систем и их частей в сложно устроенном окружении, в длинных и запутанных цепочках создания этих систем. Оказывается, все виды деятельности по созданию чего бы то ни было, если брать их в более-менее субоптимальном варианте (SoTA, а не любом варианте!), выдержавшем эволюционный отбор, похожи друг на друга, это просто варианты безмасштабной непрерывной системной инженерии, которую вы проходите в нашем курсе. Те же объекты внимания, те же операции с ними, хотя и по-разному называемые и данные в некотором разнообразии. Разные виды одного рода!

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

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

Конечно, в этом разделе мы кратко описываем ещё и процесс непрерывного углубления разделения труда, ибо появляются всё новые и новые способы изменить мир к лучшему – инженеры придумывают всё новые и новые способы удовлетворять интересы, которых раньше и не было. Так, у неандертальцев не было интереса к мастерству системной инженерии, да и самой системной инженерии ещё не было, а затем появилась «просто инженерия», потом в середине прошлого века появилась системная инженерия, в конце 20 и начале 21 века она сосредоточилась на киберфизических системах, а в последний десяток лет оказалось, что речь идёт об огромном разнообразии прикладных инженерных практик для самых разных масштабов и видов систем. Развилась методология, и стало очевидно, что все эти практики изменения мира чем-то похожи (как минимум, все они работают с какими-то системами), но в чём-то и радикально непохожи. Это происходит и у «железных» инженеров, и у программных инженеров, и у врачей, и у деятелей искусства. Достаточно посмотреть на титры какого-то кинофильма, чтобы оценить масштаб разделения труда в киноискусстве. Конечно, при создании «железных» систем разделение труда не меньше, просто не принято так подробно выписывать участников инженерной работы, как это принято в кинопроизводстве.

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

Системный инженер

как технический лидер

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

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

Понятие технического лидерства (technical leadership, отличается от организационного лидерства, organizational leadership) означает помощь в организации коллективной мыслительной работы по отношению к той или иной технической идее: все участники проекта должны делать одну и ту же систему, а не разные. Отличия технических лидеров от «технических евангелистов»: евангелисты – это проповедники чужих идей на предмет их воплощения в самых разных проектах инженерной компании или даже отрасли, а системные инженеры как технические лидеры – сами себе «технические иисусы христы» в отдельных конкретных проектах, они сами поставщики тех технических решений, в которых потом они должны уметь убедить других людей в их конкретном проекте. Системные инженеры не просто берут идеи от одних инженеров, а потом убеждают других инженеров их принять.

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