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