Анатолий Левенчук - Системная инженерия – 2022

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

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

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

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

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

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

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