2. Архироль создателя/инженера и разделение инженерного труда

Роль системного инженера в её отличии от роли прикладного инженера

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

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

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

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

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

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

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

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

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

Элон Маск не боится компаний, которые делают прототипы электромобилей. Для автомобилей создать массовое производство автомобилей в сто раз трудней, чем создать автомобиль¹. Для ракет, для чего угодно: создать рентабельное серийное производство ракет и чего угодно вдесятеро или даже в сто раз трудней, чем создать саму ракету. Безопасные бритвы получили широкое распространение только после того, как Жиллет наладил массовое производство дешёвых одноразовых лезвий, которые были острыми (то есть были массово изготовлены с большой точностью), но их можно было просто выбросить после использования².

Можно создать восхитительный проект компьютерного чипа силами десяти человек и пары искусственных интеллектов, а вот чтобы изготовить этот чип, потребуется завод чипов, для этого завода потребуется оборудование для изготовления чипов — и тут выяснится, что чипы могут разработать инженеры почти в каждой стране мира, но разработать оборудование для производства и построить завод для современных чипов, а не чипов двадцатилетней давности могут буквально в нескольких странах. Компания ASML³ является много лет почти полным монополистом в производстве оборудования для современных, а не давно устаревших микросхем, и эта ситуация не спешит меняться.

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

Как об этом думать? Традиционно: как о разделении труда, причём часть труда — это мышление, оно трансдисциплинарно. Какой-то человек (или даже AI) когда думает о своём проекте, выполняет огромное число ролей:

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

• Системного инженера, который озабочен успешностью системы в целом, успешностью графа создателей в целом.

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

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

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

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

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

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

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

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

Скажем, если вы работаете с генной инженерией, то как раз будете заниматься вирусами. Это означает, что вам нужно соответствующим образом простроить работу исследовательской лаборатории (инженеры-разработчики), работу производственных мощностей (выпуск вируса), организовать работу с персоналом и ещё отвечать на многочисленные вопросы по биоэтике, а также делать это достаточно долго: проект не должен закончиться первым же генным продуктом, будь он удачным, или даже не очень удачным — надо будет выпускать новые и новые вирусы. То есть работать нужно отнюдь не только с самими вирусами! Какая роль удерживает все эти различные системы, над которыми надо работать, в их сложных взаимосвязях, договаривает всех вокруг по поводу взаимодействия всех этих систем? Это роль (не должность!) системного инженера.

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

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

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

Разделение инженерного труда

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

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

• Конкретизация по линии разных составляющих методов создания и развития одного и того же сорта систем —тут часто системными инженерами называют вполне прикладных архитекторов, занятых архитектурой системы в целом, а также инженеров внутренней платформы разработки (internal development platform), тоже вполне прикладных. Об архитекторах и инженерах внутренней платформы разработки тоже будут большие разделы руководства. Получается так, что «системным инженером» часто называют прикладного инженера, который занят увязыванием в одно целое работ многочисленных прикладных инженеров проекта. Это не случайно, ибо такой вроде бы прикладной инженер существенно задействует системное мышление. Интересно, что раньше сюда относили и инженера по требованиям — ибо требования вроде бы определяли всю систему в целом. Сейчас это не так, ибо сбор вместе всех требований оказался непродуктивным. Инженеры реализуют гипотезы по разным фичам/возможностям (в биологии это traits, признаки) системы, по возможности асинхронно друг от друга, это уже не требования, и согласования требований «всей пачкой» уже нет, об этом тоже будет рассказано. Деятельность методологов тоже не считается системной, ибо для разных фич/возможностей их функциональность обсуждается по-возможности независимо, а не совместно. Методологи поэтому «более прикладные» (хотя методология в целом, конечно, присутствует в мышлении всех инженеров — это же один из фундаментальных методов мышления в составе интеллект-стека).

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

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

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

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

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

Чтобы сочетать самые разные составляющие роли самых разных инженеров, делают гибридные должности типа «продакт-менеджер» или сокращённо «продакт», который

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

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

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

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

Позиция единства инженерного взгляда как минимум на инженерию и менеджмент уже давно признаётся системными инженерами киберфизических систем (иногда их называют «классическими системными инженерами»). Вот в журнале «Project Performance Engineering Systems Engineering News» в апреле 2022 это даётся на седьмой странице обведённым в рамочку⁶, чтобы классические системные инженеры об этом не забывали:

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

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

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

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

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

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

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

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

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

Системная инженерия в основе сотрудничества

Напомним, что в руководстве по методологии крайне упрощённо обсуждались степени взаимодействия агентов/создателей в организации⁷:

• Игнорирование (ignorance) того, что делают другие агенты, можем даже нанести им вред. При этом иногда заявляют «ничего личного, это бизнес» — и что самое интересное, и заявитель такого верит, что это отличное оправдание, и даже те, кому вредят, вроде как «понимают мотивы». А поскольку игнорируем, то никакого общения, делами других не интересуемся, свои дела никому не показываем.

• Информирование и общение (networking): готовы общаться, но не готовы ничего менять в своих планах и действиях. Если кто-то готов подстроиться под нас, то и хорошо. Но сами работаем, как работаем. Скажем, вывешиваем часы своей работы — но не готовы их менять даже когда кому-то очень надо.

• Координация (coordinated networking): готовы поменять какие-то свои планы и действия. Например, поглядеть на часы работы соседа и прийти в его рабочие часы. Заполнить форму, какую от меня требуют в той системе, в которой требуют, а не написать заявку в произвольном формате и отослать личным письмом.

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

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

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

Системные инженеры-генералисты в отличие от инженеров по более узким инженерным специальностям должны технически направлять инженерные коллективы, так прописано в документах системных инженеров для киберфизических систем (скажем, в systems engineering body of knowledge⁸). При этом помним, что по факту в документах инженеров киберфизических систем речь идёт о прикладных инженерах по конкретным видам систем, которые заняты целостностью целевой системы и инженерным процессом, а обсуждение чаще идёт не про роль, а про людей на этой роли.

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

• технические евангелисты — это проповедники чужих идей на предмет их воплощения в самых разных проектах инженерной компании или даже отрасли,

• технические лидеры — сами себе «технические иисусы христы» в отдельных конкретных проектах, они сами поставщики тех технических решений, в которых потом они должны уметь убедить других людей в их конкретном проекте.

Создатели в роли системных инженеров должны брать на себя ответственность за целостность системы, а не просто думать об этой целостности. Системные инженеры не просто берут идеи от одних инженеров, а потом убеждают других инженеров их принять. Системные инженеры генерируют технические идеи самостоятельно. Как мы уже говорили, среди прикладных инженеров системными инженерами чаще всего называют архитекторов и инженеров внутренней платформы разработки, берущих часто на себя ещё и функции организаторов процесса непрерывной разработки. Поэтому у системных инженеров чаще всего это архитектурные идеи и идеи организации непрерывного выпуска. Системные инженеры встают в отношение менторства по отношению к инженерам-разработчикам. Они принимают решения, разъясняют их инженерам-разработчикам и добиваются их понимания — это менторство. Но затем там отношение надзора, governance (не путать с управлением, management): менеджер поручает работы/works, а надзирающий не может дать такого поручения, но он отслеживает выполнение метода — в том числе соблюдение принятых архитектурных решений и принятых решений по организации инженерного процесса. Техническое лидерство состоит в убедительном менторстве по поводу принимаемых решений, а затем эффективном надзоре за выполнением технических решений. Если прикладным инженерам трудно работать согласно принятым решениям, то их дополнительно менторят. Но если уж совсем не умеют работать, или упёрлись в своём упрямстве и саботируют принятые технические решения — их увольняют без сожаления, хорошо проекту не будет.

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

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

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

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

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

В давней (это статья 2009 года. Помним, что первый iPhone появился в 2007 году. В инженерии 2009 год — это очень давно! Всё в инженерии происходит быстро, и не только в железной инженерии) статье «Наука и искусство системной инженерии»⁹, отражающей опыт космической системной инженерии NASA, приводится сравнение системного инженера со специально обученным и талантливым дирижёром симфонического оркестра, который творит Симфонию. Системный инженер, как дирижёр, налаживает работу «симфонического оркестра» из многих инженеров-разработчиков, и даже часто не отдельных людей-разработчиков, а целых команд разработчиков. Это одновременно и правда, и неправда. Правда в том, что системные инженеры — это технические лидеры. Неправда в том, что системный инженер — это один человек, «рулящий» огромными коллективами других инженеров. Это не человек, это роль — а роль может исполняться и одним человеком, причём необязательно full time, но может исполняться и целым коллективом. Всё зависит от масштаба проекта, от принятых в проекте технических и организационных решений, от таланта работников (включая «талант» AI-систем).

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

Инженеров разной специализации может быть в одном проекте целая команда, которая делится, как мы помним

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

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

Вспомните ситуацию начала времён WWW (это сейчас говорят просто «интернет»), когда появилась и начала бурно развиваться профессия веб-мастера в середине 90х прошлого века. Трудно уже вспомнить, но всего тридцать лет назад был один человек, который занимался для вебсайтов всем: программировал «программный движок» (web framework), разрабатывал арт-дизайн, пришивал его к движку, наполнял вебсайт материалом, продвигал его в Сети и т.д. Один человек, который совмещал в себе всё разнообразие прикладной инженерии для сайтостроения. Сейчас «вебмастера» уже нет, а есть отдельно программисты фронт-энда и бэк-энда, дизайнеры, тимлиды, инженеры внутренней платформы разработки (иногда их ещё по-старинке называют DevOps), редакторы (в вариантах editor и content manager, причём второго уже и редактором не называют, а раньше называли), администраторы, модераторы, специалисты по пользовательским интерфейсам и по пользовательским впечатлениям (раньше их не различали, теперь даже пишут UI/UX), SEO (search engine optimization), уже давно появившиеся спецы по SMM (social media marketing), и это ещё не полный список (вы заметили, что в этом списке не хватает методолога, не хватает архитектора? Они обязательно должны быть, просто часто их роли выполняют какие-то другие инженеры, эта работа делается — но неявно, никем не замечаемая, маркируется обычно как «важные решения опытных разработчиков»). Это всё разные роли, которые мог бы выполнять и один человек, особенно если он пользуется поддержкой AI.

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

Разложение новых методов работы, когда они становятся массовыми, практически неизбежно приводит к тому, что знания/теории/модели составляющих этих методов становятся обширными, требуют добавочного времени для достижения мастерства в их SoTA, и это приводит к раздроблению итогового труда по разным его видам у разных создателей. Для объединения всего разложенного по составляющим и сдвинутого на разных людей труда используются различные кибер-методы обеспечения коллективной собранности, например, чеклисты (сегодня практически повсеместно компьютерные, а не бумажные). Поэтому отличным учебником по разделению труда может выступать книга Atul Gawande «The Checklist Manifesto. How to Get Things Right»¹¹, это обязательная литература для изучения инженерами-менеджерами в программе рабочего развития. Мало разделить какой-то вид инженерного процесса по людям, надо потом уметь его собрать в непротиворечивое целое — чеклисты как раз помогают это делать.

Один человек, даже если он гений, не в состоянии удержать целостность в современных сложных проектах: целостность удерживается в современном мире только командно и уж точно не людьми, а хорошо налаженными компьютерными моделями, которые точно не забудут ни одной детали, ни одной строчки ни одного документа. То же самое относится к информационным системам и AI-системам: их потребуется множество, и нужны будут средства интеграции их работы в одно непротиворечивое целое. Универсальности не бывает, даже современные AI-системы приходится специализировать.

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

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

• Дисциплина всё записывать/учитывать: договорились и делаем — записать, о чём договорились, что делаем, что сделали, чем обосновывали. Не записали — это не договорились, так что — не делаем! Памяти не верим, верим записям, нужна не «ментальная собранность», нужна киберсобранность. Современная инженерия без компьютеров не делается! Внимание людей к деталям проекта и целокупности проекта поддерживается компьютерами! И личная собранность, и организационная/командная/коллективная собранность сегодня держится не на биологической памяти, а на компьютерной памяти! Голыми руками и голым мозгом не работаем, используем инструменты! И даже если речь идёт о выполнении работы компьютерами, то тоже всё записываем — ведём компьютерные журналы, logs¹². То, что «все ходы записаны» и легко разобраться в ситуации, за это отвечают инженеры внутренней платформы разработки (управление версионированием и конфигурацией у них).

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

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

Вспомним ещё раз сравнение по факту несуществующей должности «системный инженер» с должностью дирижёра симфонического оркестра, которое приводилось в статье NASA (и не будем тут даже обсуждать, что NASA представляет тут крайне медленную и неэффективную системную инженерию — что не было видно, пока не появилась быстрая и эффективная системная инженерия в компаниях типа SpaceX или Relativity Space). Это сравнение системного инженера с дирижёром можно прокритиковать и с другой стороны. Метафора симфонического оркестра соответствует административной модели управления, «писанной музыке», и чуть ли не «руководству» как буквально «руками водству». Может возникнуть впечатление, что системный инженер — это человек с должностными полномочиями командовать какими-то «несистемными» инженерами, то есть прикладными инженерами-разработчиками разных специализаций, которые слыхом не слыхали о системных уровнях, архитектуре и непрерывном вводе в эксплуатацию. Вроде как это такой «дирижёр», который прямо диктует музыкантам, когда и какую ноту играть каждому, как это происходит иногда в симфонических оркестрах с авторитарным дирижёром, заботящимся о каждой ноте, чтобы она соответствовала именно его дирижёрскому замыслу, или его пониманию замысла автора. И да, раньше и в инженерии (помните Туполева, Королёва, Мессершмита?), и в политике (вождизм — это как раз от этого, несменяемые цари-диктаторы как раз таковы) так и было. Но ведь ещё в прошлом, XX веке музыка по факту пошла другими путями:

• в симфонической музыке за счёт компьютерной поддержки композитора оказались выкинутыми и дирижёр, и его оркестр, а «симфонические» фонограммы к современным фильмам и играм готовятся самим композитором буквально в одиночку — но на компьютере. Компьютер настолько увеличивает возможности одного человека, у которого есть в голове полный замысел, что других людей можно смело выкинуть из процесса. Музыка оказалась несложной, умещается в одной голове, если ей помогает компьютер. Симфонический оркестр с нотной записью партитуры для каждого музыканта и дирижёром по факту оказался не нужен. В мире также добавились люди, которые умеют делать компьютеры, которые помогают в музыке, труд перераспределился, стал более эффективным. В 21 веке вообще оказывается не нужным человек-профессионал, пользующийся компьютером, ибо музыкальный AI делает сложную музыку «под ключ» по индивидуальным заказам. Музыкальный завод-автомат, включая не только изготовление, но и проектирование, и даже замысел музыкальных треков. Труд опять перераспределился.

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

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

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

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

Эта эволюционность, непрерывное развитие (необязательно при этом всегда «прогресс», помним про динамический ландшафт приспособленности — это может быть легко «развитие в эволюционный тупик») и понимается как «гибкость», непредзаданность последовательности шагов, уменьшение размера планируемой заранее работы по принципу small batch size¹³ и с возможностью небольших изменений для каждой партии/batch, введение в эксплуатацию (delivering) не всей долго разрабатываемой системы с тысячей функций одним шагом (и этот шаг с подписанием акта приёмки-сдачи будет последним шагом проекта), а непрерывно инкрементами, функция за функцией. Как ни странно, такой «постепенный» подход заодно улучшает скоростные характеристики разработки за счёт того, что раньше получается отклик от задействования целевой системы в её окружении и поэтому раньше исправляются ошибки, меньше тратится времени на проработку заведомо неудачных идей.

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

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

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

Разделение труда — это ещё и разделение ответственности за результат труда, ибо виды труда (методы) распределяются по оргзвеньям, чтобы быть выполненными в работах, и вот оргзвенья при этом становятся ответственны за результаты этих работ. Эти работы или кому-то помогают (и вот этот «взгляд наружу», в глобальные результаты — это и есть взгляд системного инженера), или наоборот, вредят, и даже не могут быть просто «безвредными», ибо тогда они вредят тем, что съедают ресурсы, которые могли бы быть потрачены на полезную работу.

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

Разделение труда как многоуровневое разделение всего инженерного процесса на составляющие, выполняемые различными создателями в графе создания полностью соответствует и идеям, о которых говорит John Doyle в его работах по системам управления¹⁴: для устойчивого (не срывающегося на ошибки в широком разнообразии режимов) точного и скоростного не в ущерб точности управления нужно иметь множество датчиков, актуаторов, обработчиков информации, которые организованы многоуровнево, системно, и что важно — они должны иметь разные характеристики (прежде всего они должны быть разные по точности и скорости). В структуре управления при этом должно быть множество самых разных сложно устроенных обратных связей и просто устроенных прямых связей. Так, прямые связи простые — команды контроллеров «просто исполняются», а вот информация от датчиков обрабатывается сложно. Крупные быстрые силовые элементы дают скорость, мелкие медленные малосильные — точность, и оптимум скорости-точности будет достигнут только при сочетании достаточного числа вот этих разных масштабов систем, появлении множества мест принятия решений, то есть множества контроллеров для отслеживания множества датчиков и выдачи сигналов управления множеству контроллеров. Быстрое и точное управление обязано быть многоуровневым¹⁵.

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

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

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

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

• принятие решения (по David Deutsch — «принятие всерьёз», то есть решение кладётся в основу для действия, а не просто «принимается к сведению»). Важно, что это самостоятельное, полномочное, инженерное принятие решения, а не как у аналитика «принятие решения по вынесению предложения» для того, чтобы «принятие всерьёз» сделал кто-то другой — начальник, который ничего не понимает в этом решении, не имеет достаточно времени на его рассмотрение и просто «верит аналитику».

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

• надзор/governance за тем, чтобы решения реально выполнялись. И если не выполняются, то принятие мер (вплоть до увольнения сотрудников, которые эти решения саботируют).

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

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

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

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

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

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

При этом вам может встретиться отнюдь не SoTA версия инженерии, то есть инженерия в вашем проекте может оказаться не системной, не безмасштабной, не эволюционной/непрерывной — и ещё люди будут гордиться, что они заняты «искусством», проявляют находчивость и изобретают велосипеды, а лучшие из них будут считать себя «ремесленниками», а не инженерами. Десяток лет в программной инженерии такое отношение к методам собственной работы было даже модно, «инженерия как кустарное ремесло, craft» сейчас об этом предпочитают не вспоминать.

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

В этой организации есть индивидуальное членство ($50-$160 в год) и корпоративное членство ($4750-7250 в год), в 2023 году более 22 тысяч индивидуальных членов во всех стран мира¹⁷ и 134 коллективных члена.

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

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

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

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

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

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

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

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

Какое значение правильное? В жизни используются оба, в нашем руководстве тоже так.

Инженерия и наука

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

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

Конечно, инженерия и исследования тесно переплетены:

• когда инженер получает инженерную систему, поведение которой не отвечает его замыслу, он исследует проблему: пытается найти наиболее компактное описание работы этой инженерной системы (модель/теорию/алгоритм), из которого было бы понятно, в чём он ошибся при замысле системы и её воплощении. Затем исправляет ошибку: меняет систему.

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

Тем самым инженерная и исследовательская деятельности оказываются связаны в цикл, и в каждом исследовательском или инженерном проекте обычно приходится много раз этот цикл повторять:

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

Главное тут — цель объемлющей деятельности, а не собственно сама работа «исследований» или «инженерии» и её отнесение к какому-то классу. Цель этой объемлющей деятельности обычно — изменение мира к лучшему, то есть либо появление какой-то материальной системы, приносящей пользу каким-то внешним проектным ролям, либо появление какого-то компактного описания/объяснения/«generative model» того, как устроен мир, чтобы на следующем шаге иметь возможность изменить этот мир к лучшему. В любом случае, либо инженерия оказывается спрятана в исследованиях/познании, либо познание/исследования спрятаны в инженерии. Они неразрывны. Познание деятельно, деятельность познающа.

Вот ещё раз тот же цикл, при этом инженерная часть — это там, где на основе выигравшей догадки делается «принятие всерьёз», теория берётся для действия. Если вы не можете опровергнуть, что с ростом ресурсов умность нейронной сетки растёт, вы собираете много миллиардов долларов от инвесторов и делаете условно-некоммерческую OpenAI — и да, вложение многих миллионов долларов в обучение большой языковой модели на основе нейросети приносит свои инженерные плоды, получаем ChatGPT¹⁹. Если вы не можете опровергнуть, что энергия равна массе, умноженной на скорость света в квадрате, то понимаете, что уменьшение массы урана за счёт ядерного распада должно давать огромное количество энергии — принимаете это всерьёз и организуете Манхэттенский проект, который на выходе дал работающую атомную бомбу.

Вот ещё одна, более подробная диаграмма кольца познания, оно же — кольцо инженерии. Это отражение теории эволюции, красные стрелочки показывают, что генерируется множество гипотез, и они могут дать старт новым подобным циклам. Теории эволюции знаний (включая эволюционную эпистемологию Karl Popper с доработками David Deutsch других исследователей эволюции знаний) очень похожи на любые другие эволюционные теории. После принятия всерьёз — как раз будет «выход в практику», «выход в инженерию»: создание инженерных систем на базе положений теории, но цикл продолжает крутиться!

Особо надо отметить, что нейросети (и мокрые, и сухие) тоже могут (хотя и крайне неэффективно!) выполнять роль критика: это универсальные алгоритмы, поэтому они вполне могут выполнять и операции сложения по очень хитрому тригонометрическому алгоритму²⁰ — это медленно, энергетически неэффективно, но возможно! Нейросети могут выполнять и длинные цепочки чисто логических рассуждений (собранность — удерживание во внимании длинных цепочек логических рассуждений), причём примерно одинаковая общая результативность собственно «нейросетевого» ассоциативного поиска новых идей как при удержании длинных цепочек логических рассуждений внутри нейросети, так и при сдвиге этих длинных цепочек логических рассуждений на внешние вычислители («киберсобранность», когда собранность кибер-нейросети удерживается сдвигом рассуждений на внешние классические, не нейросетевые логические вычислители), это проверено экспериментально²¹. Нейросети не слишком хороши в длинных логических и математических выкладках, их правильно сдвигать на классические компьютеры, математический софт. Но нейросети вполне могут делать эти выкладки, с трудом и ошибками. Так что опора инженерии на математику и физику поддерживается не просто «голым мозгом», она существенно поддерживается компьютерным инструментарием, и даже просто карандашом-бумажкой, как средством удержания собранности — сосредоточенности на ведении длинного рассуждения, многих оборотов цикла познания/learn/моделирования/обучения/исследований (синонимов с нюансами тут много). И в этом цикле есть один замечательный момент: наука/исследования/познания выходят в инженерию в момент «принятия всерьёз».

Перепутанность и неразрывность инженерии и науки отражается в жизни, с ними не нужно бороться:

• В большинстве мультфильмов «учёный» в белом халате меньше всего учёный-исследователь, это «инженер-изобретатель». Эти якобы «учёные» не ставят эксперименты: они придумывают какие-то необходимые для их целей системы, в быту называемые «inventions/изобретения» как синоним «будущего продукта», и затем воплощают эти системы в реальности как системы-прототипы или системы-опытные образцы. Это «лаборатории Эдисона», где «лаборатории» не столько исследовательские, сколько инженерные, в которых происходит возня/tinkering (другое название — trial and error method), инженерная работа путём проб и ошибок, инженеры пробуют свои разные «догадки» для физического состава системы так же, как исследователи пробуют свои «догадки» в части объяснительных моделей. Большинство не срабатывают, но некоторые — срабатывают, иногда сразу, иногда после существенных доработок. Это по факту эволюционный процесс руками инженеров, это не «наука», поскольку не производятся объяснения.

• «Прикладные исследования» (applied research, прикладная наука) тоже не «исследования», несмотря на явное употребление термина «исследования». Никаких объяснительных теорий от прикладных исследований ожидать не приходится, а результаты НИР (научно-исследовательских работ, но в ходе этих работ часто создаются не только какие-то описания, но и макеты изделий) и НИОКР (научных и опытно-конструкторских разработок, в ходе них создаются не просто макеты, но опытные образцы) нацелены на получение в конечном итоге «инноваций» как систем, которые определяются как новые системы, успешно выведенные на рынок, то есть достаточно конкурентноспособные, чтобы продаваться (а не просто любые «новые системы»). Между «работающим прототипом» и «выпускаемым продуктом» могут быть годы и годы разработки/development. И это рассуждение работает не только с системами уровня сложности косного вещества или киберфизическими системами, но и системами других уровней системной эволюционной сложности, хотя даже о сообществе не скажешь «вот мы тут сделали опытный образец, сейчас выведем его в серию», приходится адаптировать рассуждение к разным системным уровням.

• Очень часто прикладные исследования (research) и классическую разработку вообще не разделяют, отсюда устойчивое сокращение R&D (research and development). Есть ли разница? Есть: «лаборатории Эдисона» (лаборатория Bell Labs, лаборатория IBM и т.д.) всё-таки отличаются существенно по организации труда и проходящим в них работам от классической инженерной разработки в конструкторском бюро или проектном институте. Но они не отличаются принципиально! Оргинженерией (то есть менеджментом) R&D как раз и занимается метод technology and innovation management как метод инженерии организационной системы, занимающейся разработкой технологий и инновациями.

Настоящая «наука», исследования в чистом виде — это «basic research», которые ведутся в условных «лабораториях Эйнштейна». На выходе исследований не «опытные образцы», а объяснительные теории — компактные и довольно формальные описания физического мира/природы.

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

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

Системная инженерия вполне может включать R&D, изобретения, создание прототипов. И в ходе занятий системной инженерией вполне можно ожидать проведения каких-то научных исследований, дающих результатом теорию. Скажем, в области искусственного интеллекта огромное число научных работ сейчас делается в лабораториях крупных инженерных фирм. Вот вывод AI report 2024²²: в 2023 инженеры из коммерческих компаний выдали 51 значимую модель машинного обучения, а университеты выдали только 15. И ещё была 21 значимая модель как результат коллаборации между инженерами и учёными.

Это просто продолжение тренда ухода исследований из университетов в промышленность в самых острых направлениях. Вот что было на пару лет раньше, посмотрите, как соотносилось число докладов от университетов и от коммерческих компаний на конференции ICML по искусственному интеллекту в 2021 году²³:

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

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

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

• методы мышления для описания объектов инженерии, поддержанные соответствующими инструментами в виде разного сорта моделеров — методы механики, электрики, информатики/компьютерной науки/computer science и т.д., то есть методы описания поведения не создателей, а самой целевой системы.

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

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

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

Особенностью сегодняшней инженерии будет то, что она претендует не только на описание методов создания механических или киберфизических (механических с универсальным компьютером в их составе) систем, но и вообще любых систем, включая и общества, и даже человечество: утверждается, что методы создания этих систем на самом абстрактном уровне одинаковы, то есть все эти системы (или модификации этих систем, если речь идёт о brownfield, то есть доработках уже существующих систем) создателями в их графах создаются и развиваются в постоянной адаптации к изменениям в окружении и целевой системы (часто прямо по ходу эксплуатации), и в самой целевой системе (автомобиль ломается потому как в нём происходят изменения, не предусмотренные инженерами), и даже в организациях графа создателей (люди и AI там получают новые знания, им становится доступно новое оборудование, или наоборот — неожиданно заканчиваются ресурсы). Для всех таких проектов надо готовить концепцию использования, концепцию системы, архитектуру системы, непрерывно их уточнять, готовить конвейер/завод/«внутреннюю платформу разработки»/«internal development platform»/pipeline для непрерывного введения в эксплуатацию релизов/инкрементов системы, которые одобряют визионеры, а готовят разработчики под надзором архитекторов. Разница в масштабах систем, конкретных методах работы, разнообразии дисциплин, описывающих системы той или иной природы, особенностях скоростей их эволюции, а разница терминологии не должна заслонять этой общности.

Обучить инженерному делу как таковому (именно это цель настоящего руководства, хотя руководство делает это на кругозорном, весьма абстрактном уровне) — это обучить тому, как устроен ход эволюционной (другой уже сегодня не бывает) инженерной разработки, какие основные понятия предметной области самой инженерии (а не предметной области, описывающей физику и алгоритмику создаваемого инженерного объекта): как устроен инженерный проект в целом и как разворачивается во времени проектирование/конструирование/программирование, изготовление и ввод в эксплуатацию целевой системы, а не только как устроена создаваемая система.

Методология предлагает как результат «инженерной науки» описание разных вариантов инженерного процесса и связанного с ним разделения труда — SoTA и не очень, в том числе объясняет разницу: почему одни методы лучше (SoTA, state-of-the-art, «лучшие из известных на текущий момент времени»), а другие хуже.

Если мы теперь говорим, что «результат инженерной науки надо брать всерьёз и строить метод инженерии как описанный этой наукой SoTA метод», то это будет уже не «объяснения того, как бывает», а «предписание того, как надо делать» — и тогда мы говорим, что методология как «инженерная наука» является нормативной наукой²⁴.

Ненаучность инженерии. Эвристики

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

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

Эволюция работает независимо от того, разработана ли теория эволюции. Концептуальные (какие функции какими физическими объектами воплощаются) и архитектурные (какие принципы объединения физических объектов в модули и способы взаимодействия модулей) идеи воплощаются в создаваемых системах непосредственно, но эти системы сами по себе не вносят изменений в конструкцию и выбранный тип её модульности следующих систем. Это делают создатели, чаще всего изменяя конструкции систем непрерывными пробами (мутации, желательно smart, и их должно быть много — эволюционное разнообразие) и ошибками (эволюционный отбор), простым запоминанием и повторением «того, что работает» (наследование в эволюции) — часто даже без поиска объяснений. И это неостановимый процесс, ибо что было SoTA сегодня, перестаёт быть SoTA завтра, учитываем динамичность ландшафта приспособленности. Жизнь меняется, следовательно — SoTA меняется.

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

В книге Discussion of the Method²⁶ (2003) исследователь классической инженерии Billy Koen приводил пример: если бы в средние века к инженеру пришли с просьбой построить мост через небольшую (или даже большую) речку, а он бы отказался на основании того, что сопромат изобретут только через 200 лет — что можно сказать о таком инженере? Или если бы современный инженер при просьбе построить ракету, летящую на Луну или Марс, отказался бы от проекта на основании того, что достаточно подробной «теории Луны» или «теории Марса» ещё не создано? Или при необходимости создать робота инженер вдруг говорит, что «теории о том, что делать, чтобы создавать робота пока нет — поэтому я не знаю, что в каком порядке делать, поэтому подождём до тех пор, пока у учёных не появится соответствующего раздела в их объяснениях из инженерной теории». Или в ещё будущих США вдруг их отцы-основатели говорят, что «непонятно ещё, как делать процветающее общество, не будем писать Конституцию и учреждать новое государство, потому как ещё политологи не создали теории, которая позволяет это сделать надёжно, понятно и просто». Отказы на таких основаниях не свойственны инженерам, их не останавливает отсутствие научного формального знания в том, чем они занимаются.

Инженерия кроме научных/объяснительных теорий активно использует эвристики (heuristics) — это догадки о замеченных удачных паттернах/закономерностях/шаблонах, которые вовсе необязательно «научны» в традиционном смысле этого слова. Это просто замечания, что «что-то работает». В принципе, эвристики вполне можно считать и суевериями — они возникают так же. Вы заметили, что все те три раза, когда вам в голову пришла хорошая мысль, вы были в голубой одежде — всё, нейросеть в вашем мозгу отлично распознаёт повторения, паттерны! Дальше критика выключается, проверки экспериментом выключаются — и эта идея принимается всерьёз! Такая эвристика/суеверие — это не «фальсифицируемая теория» по Попперу и тем более с поправками Дойча про объяснения и замечаниями, что это должна быть «объяснительная теория, сформулированная контрфактуально», и поправками Фристона, что это должна быть «порождающая/generative модель/теория, позволяющая предсказать будущую ситуацию»: инженер с самого начала знает, что эвристики вполне могут быть в его случае ошибочны и неприменимы, оказаться суеверием. Плюс обратите внимание, что инженерные эвристики определяются отличным образом от философской «эвристики», найдите соответствующую литературу сами. Вот примеры инженерных эвристик из справочника по инженерии химического производства²⁷, :

• Используй вертикальный резервуар на опорах, когда его объем меньше 3.8м³

• Используй горизонтальный резервуар на бетонных опорах, когда его объем между 3.8 и 38м³

• Используй вертикальный резервуар на бетонных опорах, когда его объем больше 38м³

На эту тему есть хороший анекдот:

Физику, математику и инженеру дали задание найти объём красного резинового мячика.

Физик погрузил мяч в стакан с водой и измерил объём вытесненной жидкости.

Математик измерил диаметр мяча и рассчитал тройной интеграл.

Инженер достал из стола свою «Таблицу объёмов красных резиновых мячей» и нашёл нужное значение.

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

• Внешних проектных ролей (и их исполнителей) всегда на единицу больше, чем вы знаете; известные вам внешние проектные роли всегда имеют потребность (need) на одну больше, чем вам известно (это шестая из основных инженерных эвристик Tom Gilb²⁸).

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

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

Несмотря на то, что наука в инженерии не обязательна, эвристики в более простых системах по возможности заменяются научными объяснительными SoTA теориями, в том числе в виде компьютерных моделей (разница: правильно применённая теория даёт надёжный ответ, а эвристика, возможно, врёт при малейшем изменении условий её применения), тем самым место для метода проб и ошибок смещается в сторону систем, которые плохо описываются наличными научными теориями. Это могут быть и системы уровня вещества (например, трёхмерная структура белков плохо описывается теорией, но совсем недавно нейронная сеть AlphaFold²⁹ реализовала эвристики, которые позволяют неплохо предсказать эту структуру — и это именно эвристики, а не объяснительная теория).

Важно при этом понимать, что переход от эвристик к нормальной науке важен для того, чтобы получать 100% надёжный результат. Когда заметили, что цитрусовые избавляют от цинги, эти цитрусовые стали брать в дальние плавания наряду с сушёным мясом. Но в этот момент это была эвристика, объяснений не было. Поэтому в какой-то момент один из капитанов взял в плавание запас цитрусовых не того сорта: с малым содержанием витамина C. И все заболели цингой — и вера в эвристику «цитрусовые спасают от цинги» исчезла. А потом открыли витамин C, его влияние на предотвращение цинги — и разобрались, почему одним морякам цитрусовые (одних сортов! С большим содержанием витамина С!) помогали от цинги, а другим морякам цитрусовые (других сортов! С малым содержанием витамина С!) не помогали. Большинство эвристик нуждаются вот в такого сорта объяснениях — но инженеры (с переменным успехом) могут использовать их в работе и до получения объяснений.

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

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

В связи с этим любые достижения в инженерии по предложению Billy Koen нужно оценивать не по абсолютной шкале, а на конкретный момент времени, в соответствии с накопленным на этот момент объёмом научного и эвристического инженерного знания — и это «текущее состояние инженерии» Billy Koen предложил называть SoTA (state-of-the-art). Инженерный проект плох, ежели он не использует научное и эвристическое знание, накопленное на конкретный момент времени (он может быть успешен, но плох!). Не отвечающий SoTA инженерии проект плох (скажем, если в каком-то обществе смена правления идёт через силовой захват власти, а не выборы, то с инженерией этого общества непорядок, это не SoTA. Смена власти на сегодня вполне обеспечивается несиловыми способами, если применена современная системная инженерия уровня общества). Со временем объем знаний растёт, и инженерные проекты становятся более и более сложными, достигая невозможных для предыдущего времени характеристик. Так, сегодня вполне возможен полёт вертолёта на Марсе: инженерия киберфизических систем такого уровня вполне реальна³⁰. Инженерия искусственных бактерий тоже вполне реальна³¹.

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

Существует мнение (его в своих книгах пропагандирует Nassim Taleb, например, в книге «Антихрупкость»³²), что наука/исследования для практической деятельности бесполезна, настоящие новации полностью ненаучны. По этому мнению инженеры-практики добиваются успеха не на основе научных знаний, а исключительно на основе «возни» (tinkering, ср. «He is tinkering with a car» — «он возится с автомобилем»). Taleb сравнивает учёных/исследователей с теми, кто приходит к птицам и пытается научить их летать, давая знания по аэродинамике. Типичное высказывание в его книге на эту тему: «Никто не опасается, что ребёнок, понятия не имеющий о разных теоремах из области аэродинамики и не способный решить уравнение движения, не сможет ездить на велосипеде». Талеб защищает метод проб и ошибок, защищает эвристики. Он абсолютно прав. И он прав, когда пишет о создании реактивных двигателей: сначала было много проб и ошибок, потом только появилась стабильно работающая теория, а не наоборот. Проблемы с ракетами: сначала таки появилась физика, потом понимание, что физическое тело может при достижении некоторой скорости вращаться вокруг Земли — и только после этого реактивные двигатели позволили создать ракету, которая вывела на орбиту первый спутник Земли. И ещё с атомной бомбой та же история — получить атомный взрыв простой вознёй с ураном не получится, надо таки знать, с чем перспективно возиться, а с чем — нет, и сколько минимально урана надо, чтобы произошёл атомный взрыв. Талеб говорит правду, но не всю правду.

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

Метод проб и ошибок всем хорош и в мышлении, и в инженерии, но это «эволюция вручную» — очень дорого и чрезвычайно долго. Если есть способ что-то физическое коротко описать в части самого важного (модель! Она учитывает только важное, а неважное игнорирует!), а потом работать с этим описанием-моделью, а не с самим физическим объектом, то так и нужно делать. Если вы учите ребёнка ездить на велосипеде, то вам особой науки (SoTA объяснительной теории) не нужно. А если вы учите компьютер быть автопилотом на реактивном самолёте, то незамутнённым объяснительной теорией и компьютерным моделированием методом проб и ошибок вы загубите слишком много реактивных самолётов. Нужно губить виртуальные самолёты, для этого иметь модель самолёта, то есть знания, алгоритм, описание самолёта. И когда виртуальный самолёт покажет, что он летает — можно строить реальный самолёт.

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

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

Ещё один аргумент в пользу использования объяснительных теорий в инженерии появляется, когда вы замечаете, что в книжках Талеба ничего не говорится о коллективной работе. Рассуждения Талеба хорошо работают, когда речь идёт о рынке, где никто друг друга не знает, почти ничего не известно о товаре и ситуации его использования, но происходят крупные одиночные сделки между незнакомыми людьми (сам Талеб как раз профессионализировался на торговле ценными бумагами, он был трейдером на фондовом рынке). Если мы хотим хорошее инженерное мышление передать другим инженерам, но не понимаем, из чего это мышление состоит, что передавать, то есть у нас нет инженерной науки/engineering science, нет методологической проработки инженерии (например, нет руководства по системной инженерии типа того, который вы сейчас проходите), то всё сведётся к малопродуктивной охоте и собирательству относительно талантливых «стихийных инженеров». Охота и собирательство талантливых людей хороши, но переход к «осёдлому земледелию», то есть обучение инженеров хорошим объяснительным теориям того, что они должны делать, даёт скачок в производительности труда — выращивать таланты оказывается много дешевле, чем их выискивать и затем пытаться перекупить (обычно к тому времени, как становится понятным, что это талант, он уже достаточно дорого стоит).

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

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

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

В инженерии можно, конечно, говорить на уровне формальности «я чувствую, что я держу равновесие и я чувствую, что на большой скорости надо бы пригнуться», но обычно всё-таки требуются более формальные описания, более точные, по которым можно точнее воспроизвести описываемые явления. Компактные и универсальные объяснительные теории нужны в инженерии, чтобы люди могли иметь одинаковое описание того, что они делают, чтобы они договорились между собой. Все участники инженерного проекта, если они описывают один и тот же объект, будут использовать одно и то же SoTA компактное описание важных объектов в инженерном проекте, и эти важные объекты описываются задействованными объяснительными теориями. А поскольку теории хорошо прокритикованы (это же SoTA теории, которые выдержали критику логикой и экспериментами), то огромная вероятность того, что описание сработает и даст ожидаемый результат. Так, было очевидно, что если хорошо подумать о системе «на верхнем уровне», то результат проекта будет лучше. Поэтому самые опытные разработчики занимались «системной архитектурой» как важнейшими принципами, на которых организована система, что бы это ни было. Развитие инженерной науки показало, что у этих «опытных разработчиков» было две самых больших экспертизы — функциональный синтез (а не функциональная декомпозиция!) и модульная декомпозиция (хотя говорилось как раз о модульном синтезе!). А с приходом эволюционной архитектуры стало понятно, что изменение функций плохо реализуется в ситуациях, когда проделана плохая модульная декомпозиция, модули слишком сильно зависят друг от друга. Это привело к углублению разделения труда: сначала роль «архитектора как опытного разработчика» была уточнена как новая роль архитектора, который занимается не функциональностью и расчётами принципиальных схем верхнего уровня, но архитектора, который занят оптимизацией межмодульных зависимостей и нарезки/разбиения на модули такого, при котором сохраняются важнейшие характеристики работы системы в целом (прежде всего — evolvability/развиваемость), а потом выделилась и новая роль — методолога, который занимается главным образом функциональными описаниями системы, абстрагированными от разбиения системы на модули. SoTA инженерного процесса (какими делами/«методами работы над какими предметами методов» надо заниматься в инженерных проектах каким инженерным ролям) поменялась, а нормативный характер системной инженерии говорит, что «надо» трактуется как обязательность к применению. Если у вас архитектура в проекте что-то другое, то ваш проект идёт не как «надо», это не SoTA, это менее оптимально. Ну, или вы работаете на фронтире, проверяете новую догадку, работаете над умной мутацией инженерного процесса. Предметом «инженерной науки» ведь является инженерный процесс, он же процесс разработки — все методы работы, которые задействуются в ходе создания и развития успешных систем. Это обсуждалось в руководстве по методологии, но там не говорилось, какой именно инженерный процесс и какие роли его исполнителей являются на сегодня SoTA.

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

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

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

Инженер может плохо работать с описаниями. И даже неинженер может плохо работать с описаниями! Если взять художественную литературу как описание вымышленных миров (неинженерная деятельность, если автор не ставит задачей как-то изменить личность читателя): графоманам никогда не получить Букеровскую премию, хотя они умеют писать, и иногда даже «красиво писать», то есть писать беллетристику, то есть умеют записывать свои идеи по поводу мира на материальном носителе в форме, доступной для прочтения другими людьми. В целом «умения читать-писать» и как-то (а не профессионально) излагать какие-то (а не предписываемые профессией) мысли для инженерии недостаточно. Это относится и к людям, и к AI — интеллект у них может быть очень разный, но болтливый и красноречивый создатель, не придерживающийся достижений инженерной науки, не знающий методов системной инженерии и предлагаемого этими методами разделения труда, может быть крайне неэффективным, а часто и вредным: будет забирать время, которое можно было бы потратить на что-то полезное другим людям. Если у вас, конечно, инженерный проект, а не концерт — на концерте болтливым людям дают микрофон, они могут хорошо шутить-развлекать, но не более того.

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

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

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

• совмещать «яблоки из жизни» и «яблоки из задачи» (разбиралось в «Системном мышлении»),

• наработать необходимую скорость в выученных операциях.

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

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

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

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

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

В больших и сложных (а для начинашек и тот проект, который для опытных инженеров «маленький и простой» будет «большим и сложным») проектах нужно осознанно действовать «по науке», использовать знание SoTA инженерного процесса, SoTA разделения труда в инженерии. Системная инженерия — нормативная наука, она требует работы по указанному методу. Так, в больших проектах обязательно нужно делать в системе-создателе «тёмную холодную фабрику»/«автоматизированный конвейер»/pipeline/«internal development platform» и в порядке разделения труда иметь роль инженера этой платформы (иногда по-старинке используют название DevOps, и там уже разные варианты, вплоть до NoOps³⁵, намекающие на отсутствие людей, нужных для работы платформы). А для того, чтобы такой «конвейер» работал, надо принимать жёсткие архитектурные решения по конструкции системы. Когда вы работаете в инженерном проекте, надо знать, почему делают так или иначе (например, почему нехорошо считать, что в вашем проекте «водопад» в управлении жизненным циклом), почему это работает или не работает, что будет, если этого не делать. Каждый инженер поэтому должен быть методологом, чтобы уметь мыслить о методах не только своей личной работы, но и методах работы в коллективном проекте, в котором он участвует.

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

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

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

Но хорошего знания системной инженерии, дополняемого хорошим знанием прикладных предметных областей тоже недостаточно для успеха инженерного проекта. Многие ваши действия «по учебнику» будут приводить к результатам, которые не совпадают с ожидаемыми «по учебнику». Это неизбежно, и в этом случае нужно включать фундаментальное мышление и разбираться с ситуацией при помощи силы интеллекта, а не известных вам предписаний прикладного метода и его нормативной науки. И, конечно, тут вполне возможно опираться на эвристики, пока нет точной объяснительной науки. А сила мышления — это задействование интеллект-стека фундаментальных/трансдисциплинарных методов мышления, найдите время ознакомиться с их содержанием в руководстве по интеллект-стеку. Так, все знают, что инженерам нужно знать математику и физику — зачем знать, и что из этих знаний нужно иметь, если всю математику и всю физику берут на себя AI-агенты, вы как раз и узнаете из руководства по интеллект-стеку.

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

Чтобы построить ракету, которая принесёт на Марс очередной вертолёт, надо организовать инженерный проект. В качестве основного способа инженерии для такого проекта метода проб и ошибок явно недостаточно. Надо обсуждать и то, как заняться методологией полёта на винтокрылых аппаратах, и то, как принимать архитектурные решения и какие архитектурные характеристики важны в данном проекте, надо знать об обратном манёвре Конвея, надо обязательно проводить инженерные обоснования. Обо всём этом будет в нашем руководстве (хотя честно признаемся, что само это руководство больше аннотированный сборник литературы — детальные знания по всем этим темам будут не столько в наставлениях руководства, сколько в рекомендованной литературе). Тем не менее, инженеры в таком сложном проекте будут использовать также и метод проб и ошибок, и будут использовать эвристики/суеверия, но культурные инженеры ещё и будут уметь об этом говорить и будут уметь избегать новичковых ошибок в работе.

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

Инженерная наука

Инженерная наука (engineering science), ищущая компактное описание для SoTA инженерии, должна рассказать об инженерии как культуре инженерного сообщества. Она отвечает на вопрос о том, что делает создатель в роли инженера (или в одной из составляющих архироли инженера) в ходе инженерного проекта.

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

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

• Вы знакомитесь с тем, как работают люди (finetuning), как они мыслят в типовых ситуациях и как рассуждают про связь «яблок из учебника» (их же там считают!) с «яблоками из жизни» (их же едят! Причём тут подсчёт!). Это в обучении AI обычно называют RLHF (обучение с обратной связью от учителя), и тут засада: вы будете повторять типовые ходы уровня ваших учителей в таких проектах, которые видели ваши учителя. Но вы вряд ли сможете превзойти ваших учителей. Это как насмотреться на задачи, для которых есть пошаговые способы решения с ответами. Если вы увидите примерно такую задачу, вы её решите. Если увидите другую задачу — не решите, ибо не знаете, как решать. Собственно, именно тут знание учебника становится жизненным, а не абстрактным знанием. Поздравляю, вы хороший подмастерье, но сами ещё не способны работать мастером.

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

Конечно, вы можете всю эту умственную работу отдать AI или (если вы начальник) любому вашему сотруднику, но это тогда можно будет отдать AI или другому сотруднику и без вас, посредники не нужны. Вы должны понимать, что оставить из мышления себе, а что отдать — и как потом собрать сделанную работу, чтобы проект с приложением ваших мозгов был более успешен, чем без вас.

Без «науки» тем самым трудно решать практические задачи, ибо предлагаемые решения будут вести к неэффективности, переделкам из-за ошибок, неудачам, но сама наука обычно ничего не говорит о том, как породить идею решения. Инженерия тут ничем не отличается от любой другой деятельности, где идеи рождаются «из шума». Конечно, какие-то закономерности в эволюции уже можно обсуждать, поэтому мутации вблизи какого-то локального оптимума динамического ландшафта приспособленности, но вам-то надо выдать догадку, которая ведёт потенциально не к текущему локальному оптимуму, а к глобальному оптимуму — и часто на то место в этом ландшафте, которое только-только должно появиться! Когда-то Bill Gates сказал, что компьютер будет на каждом рабочем столе, и на нём поэтому будет операционная система, которую разрабатывает Microsoft. Это как с Уэйном Гретцки³⁶, которого спросили, как он всё время оказывается там, где шайба? Он ответил, что оказываться там, где шайба — невозможно. Но можно оказываться там, куда шайба вот-вот придёт. Вот инженеры в проекте заняты именно этим: они делают догадки даже не по текущей ситуации, а догадки о той ситуации, которая будет. Недаром теория стратегирования дана сейчас в конце руководства по методологии.

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

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

Методология рассказывает о том, какие есть в мире объекты, их характеристики и отношения друг с другом, что можно с этими объектами делать. Что с этими объектами делать для решения конкретных задач — неведомо, надо высказывать догадки и проверять их. Никакое знание физики не позволяет само по себе решать даже олимпиадные задачки по той же физике, что уж говорить о решении реальных проблем. Но без знания физики и олимпиадные задачки, и инженерные проблемы решать труднее, вы будете считать потенциально верными догадки, которые заведомо неверны, будете тратить на эти догадки драгоценные ресурсы, терять время и нервы.

Наука/исследования аналитичны, они посвящены критике догадок, их опровержению — при помощи теории, которая сама когда-то была хорошо прокритикованной догадкой, но выстояла перед критикой и экспериментами.

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

К сожалению, сведение всей инженерии только к науке («нет теоретического обоснования — не инженерия») и «аналитике/критике» без сопутствующих догадок по синтезу в ущерб практической деятельности по решению проблем, в том числе с помощью «ненаучных» по своей природе догадок-эвристик-гипотез-суеверий отражено и в учебных курсах по инженерии систем самых разных уровней, и в профессиональных руководствах и стандартах. Так, по отношению к киберфизическим системам руководитель NASA Michael Griffin в речи 2007 г. (и с тех пор в образовании по околовоенной и государственной системной инженерии киберфизических «железных» систем мало что изменилось, наше руководство тут сильно отличается, как и современные руководства по программной/software инженерии) «System Engineering and the Two Cultures of Engineering»³⁷ даёт критику расхожего инженерного образования, которое учит «аналитике/критике/объяснениям», а не инженерии:

I have always loved the view of the engineering profession captured by the great Theodore von Karman when he said, "Scientists study the world as it is; engineers create the world that has never been." Less eloquently, engineers are designers; they synthesize knowledge to produce new artifacts. Von Karman speaks to what most of us, and certainly most laymen, would consider the essence of engineering: engineers create things to solve problems.

But all of us who are engineers know that the engineering profession also has a rich scientific side, the analysis of these artifacts and the prediction of their behavior under various environmental and operational conditions. Adapting von Karman's observations, it may be said that engineering science is the study of that part of the world which has been created by man.

Sadly, many students have been led to believe that engineering science is engineering! In a curriculum of 120 or more credits leading to a bachelor's degree in a branch of engineering, the typical student is required to take one, or maybe two, courses in design. Everything else, aside from general-education requirements, focuses on the analysis, rather than the creation, of engineered objects. Graduate education often has no design orientation at all. So, engineering as taught really deals with only a part of engineering as it is practiced.

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

Вы думаете, что это верно только по отношению к системной инженерии? Нет, то же самое верно по отношению к инженерии предприятия, то есть менеджменту. По идее, учебные программы MBA (магистры бизнес-администрирования) были задуманы как выпускающие менеджеров, способных развивать свои предприятия — стратегов, бизнесменов, оргпроектировщиков. Но нет. Исследователь менеджмента Henry Minzberg написал целую книгу «Managers not MBAs»³⁸ об этом: в программах MBA учат аналитике — после окончания этих программ у людей отличные карьеры начальников аналитических отделов (которые готовят аналитические отчёты, но которые не принимают никаких решений и не вырабатывают никаких решений), начальники финансовых служб (которые не принимают никаких управленческих решений, но зато отлично следуют правилам налогообложения). А менеджмент? Minzberg говорит ровно то же — это синтетика, не аналитика. Менеджмент как инженерия предприятия — это прежде всего творчество, умение делать догадки, решающие проблемы, снимающие противоречия — и эти догадки даже не по поводу теории, не «исследовательские», а по поводу ситуации в будущем. Менеджмент, как инженерия предприятия — он в этом, в творчестве, в синтезе, а анализ носит вспомогательную роль, он обязателен, но это только критика. Да, его можно вынести в «отдельную аппаратуру» (помним, что мы буквально пару подразделов назад обсуждали работу³⁹, что общее умение думать не зависит по качеству результата — отдали ли мы критику «спецаппаратуре» или критикуем сами, сразу после высказывания догадки. Но без догадок критиковать нечего!). Совсем недаром программы MBA сегодня не любят детально рассказывать о том, чему же они учат — ибо очевидно, что на выходе такой программы не будет кого-то типа Bill Gates, Jensen Huang, Elon Musk. Как ни странно, все эти великие менеджеры вышли из инженерных вузов, и это не случайно. А на что заманивают в программы MBA? Посмотрите: там заманивают на то, что у вас будет хорошая компания, статусные одногруппники, вам дадут пообщаться с разными успешными людьми. Это не похоже на обучение какой-то науке!

В какой-то мере этот тезис примата творчества/синтеза над аналитикой/критикой подтверждается опытом мастерской инженеров-менеджеров: на стажировку по системному менеджменту в мастерскую приходят выпускники программ MBA, и от многих из них после выпуска независимо поступают отзывы, что «только сейчас стало понятно, чему учили на MBA и как это использовать». Конечно, аналитика важна — если знать её место в инженерии «железной», программной, предприятия (в случае MBA), личности и мастерства в составе личности!

И то же самое можно говорить о создании и развитии систем самых разных масштабов и видов, включая общественные: инженерия всех них подразумевает создание нового, высказывание труднокритикуемых догадок, которые выживут всю рациональную критику (включая и логику, и эксперименты). Критика тут крайне важна, но вспомогательна. Критика тут играет роль естественного отбора в эволюции, она как куратор галереи. Но главный в галерее не куратор, а артист! Куратор важен только для того, чтобы отобрать достойного артиста. Эта метафора взята из биологии развития⁴⁰, но она вполне подходит не только к эволюции-инженеру, но и к людям-инженерам, AI-инженерам.

Основное, что должен уметь делать системный инженер, как создатель — это создавать успешные системы, менять мир к лучшему, придумывать, как это сделать, а анализировать/критиковать/объяснять эти системы и свои методы работы — это важная, экономящая ресурсы, время и нервы, но подчинённая синтезу задача. Упор на квазиоптимальный синтез и непрерывные попытки его улучшить и вписать результат в непрерывно меняющееся окружение, а не упор на «строго научный анализ и безупречное обоснование» характеризует инженера. Обоснование важно, но оно уместно только тогда, когда есть что обосновывать!

Так что в учебных программах нужно учить в том числе и создавать (а хоть и опираясь на генетические/эволюционные алгоритмы), а не только объяснять и критиковать!

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

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

• Инженерная наука сегодняшнего дня (эти строки пишутся в 2025), опирающаяся на современную системную методологию третьего поколения (выходящую на масштаб времени техноэволюции, а не только жизненного цикла одной версии системы), абсолютно другая, нежели даже пять лет назад, когда стало очевидно, что революция continuous delivery и в программной инженерии победила массово, и в «железной» инженерии. Чтобы заниматься инженерией прошлых дней, надо было читать учебники прошлых дней, а затем как-то продвигаться вперёд, заниматься мутацией её методов. Это видно по стилю работы SpaceX сначала над Falcon 9, затем над Starlink, затем над Starship. Инженеры SpaceX имели большой опыт работы в NASA, а затем они преодолели тамошние недостатки. NASA с тамошними технологиями и воззрениями выглядит сегодня по части творчества уже отстающей организацией, там не соблюдается баланс высказывания гениальных догадок и последующей их критики. Поэтому бесполезно не читать учебников вообще, но полезно читать современные учебники, куда вошли SoTA инженерные методы, SoTA инженерная наука. В современные учебники, конечно, вошёл опыт SpaceX и многих других передовых инженерных компаний — в том числе и то замечание, что опыт передовых «железных» компаний является по факту опытом компаний программной инженерии, причём осваиваемый с большой задержкой (лаг 5-10 лет). Современные учебники/регламенты/стандарты/руководства пытаются сократить этот лаг, как это делает и наше руководство.

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

• Сама инженерия стала сложнее, и просто «пробовать работать» уже не получится: слишком низка вероятность хорошего результата. Нужна теория, даже если она и не закрывает 100% встречающихся проблем. Никакая теория не закрывает 100% проблем и всегда нужно подключать фундаментальное мышление, а также всегда нужно подключать меметические алгоритмы и делать на их основе какие-то догадки, а не «всё выводить из теории». Но если не опираться на теорию, а основываться исключительно на «смекалке и натиске», то всё в проекте будет медленно и ресурснозатратно, со скоростью естественной, а не «умной» эволюции: успешной системы вы или не создадите, или успех будет очень кратким. Мутации должны быть «умными», и желательно поэтому не просто «догадываться» о них, но и проверять критикой на основе теории. Если вы догадались, что ответом на 2*2 может быть 5 — используйте теорию, чтобы это проверить, не берите до этого вашу догадку всерьёз!

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

Наше руководство по (безмасштабной и эволюционной/непрерывной, а также неантпропоцентричной) системной инженерии решает вопрос о балансе методов, описанных в инженерной науке и не описанных в этой науке методов инженерной «возни»/tinkering так:

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

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

• Знание принципов освобождает от знания множества фактов. Инженерам нужно сразу знать (а не догадываться по ходу проекта), каковы основные объекты, с которыми работают инженеры в их многочисленных ролях, как бы они ни назывались в разных предметных областях. Это «нужно» — нормативный аспект теории, например, «вы как архитектор должны принимать архитектурные решения в вашем проекте, понимая приоритеты в реализации архитектурных интересов», и т.д. Это основной материал руководства, он изложен в следующих разделах. И если «нужно» и «вы должны» (деонтическая модальность), значит — нужно, и должны. Это значит — мало читать и знать, ещё надо реально делать в проектной работе. У нас в руководстве наставления на работу, их нужно выполнять, брать всерьёз!

• Руководство содержит отсылки к конкретизациям методов и ролей системной инженерии главным образом для «железной» и программной системной инженерии. Есть отсылки и к конкретизациям методов системной инженерии систем другой природы, но их не очень много. Само изложение в руководстве кругозорно, его явно не будет хватать для работы инженером. Подробное (не кругозорное) знакомство с конкретными/прикладными инженерными методами для отдельных видов систем крайне важно, но оно предполагается потом и предполагает прохождение дополнительных прикладных курсов (по программной инженерии, инженерии киберфизических систем, системному менеджменту как инженерии предприятия, и т.д.). Нужно отчётливо понимать, что мастерство во владении отдельными методами набирается достаточно долго (единицы лет), причём по каждому прикладному методу работы и даже их составляющим методам есть курсы/руководства/учебники/регламенты/стандарты даже более объёмные, чем наше. Вспомните объемы вузовских учебников по много более узким дисциплинам, например двухтомные А4 учебники, отдельно двухтомники по органической и неорганической химии! Или знаменитый «ландавшиц», там формат A5, зато сразу 10 томов⁴¹.

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

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

Для профессиональной работы системным инженером (помним, что эта работа отнюдь не всегда называется «системной инженерией», а роль «системным инженером», помним о «коуче», «политике», «агрономе» и т.д.) дополнительное прикладное обучение обязательно! Кругозорного обучения хватает обычно только для любительской работы, в крайнем случае — для помощи в постановке задачи прикладному профессионалу, который с вами беседует, чтобы хотя бы примерно понимать, что он будет делать и почему, и какие его вопросы будут интересовать, и о чём с ним вообще можно говорить, а о чём нужно говорить с другими прикладными ролями.

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

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

Моделирование: мои инженерные проекты

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

Задания

Поставьте отметки о выполнении следующих дел.

1. Опубликован пост с вашими мыслями о системной безмасштабной непрерывной инженерии по материалу текущего раздела и итогам выполнения всех заданий.

2. Вы откомментировали не менее трёх постов на тему системной инженерии, написанных другими инженерами-менеджерами.