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