Специализация/конкретизация практик системной инженерии

Понимание системной инженерии можно разбить на три основных уровня прикладности/специализации/конкретизации (не путать с системными уровнями), каждый из которых можно далее разбивать на подуровни.

1. Уровень специализации безмасштабной системной инженерии

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

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

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

Ещё эту диаграмму лучше бы считать

• или диаграммой общего жизненного цикла, надолго застревающей на состоянии воплощения системы «80% сделано» (и каждый день там будет что-то доделываться новое и что-то удаляться из уже не нужного, а ещё рекомендуемый норматив времени на работу с так называемым «техническим долгом»²⁹ – 20%, так что в любой момент времени оказывается, что готово только 80%, а ещё 20% нужно «отдать должок»). В жизни часто всё ещё менее однократно: представьте себе, что вы готовите круглосуточный шведский стол в курортном пансионате (не только подачу в этом стиле³⁰, но вместе с работой кухни, «под ключ». Ни в один момент времени вы не можете сказать, что закончили работу: что-то подъели, и нужно приготовить дополнительную порцию, что-то наоборот, испортилось несъеденное, и нужно убрать. А ещё нужно планировать сезонную смену меню, отвечать на жалобы тех, у кого болит живот (ни у кого не болит, а вот у этого одного заболел!) и кто нашёл жучка в тарелке (никто не нашёл, а вот этот один нашёл!) и следить, чтобы не уносили слишком много еды с собой. Это явно не описывается движением кейса «шведский стол» к приёмке-сдаче системы. Закрытие кейса – это будет как раз неуспех! Трудно представить, но операционная система Windows это примерно такой же «шведский стол». И к этой модели стремится огромное число других систем. Даже если вы делаете революцию в обществе, это тоже будет только «открыть двери накрытого шведского стола», а потом этот кейс нельзя будет считать закрытым, закрыть после этого двери – это неуспех проекта, аварийная ситуация.

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

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

2. Уровень специализации инженерии систем одного системного уровня.

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

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

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

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

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

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

Опять же, схема должна рассматриваться двумя путями:

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

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