в симфонической музыке за счёт компьютерной поддержки композитора оказались выкинутыми и дирижёр, и его оркестр, а «симфонические» фонограммы к современным фильмам и играм готовятся самим композитором буквально в одиночку но на компьютере. Компьютер настолько увеличивает возможности одного человека, у которого есть в голове полный замысел, что других людей можно смело выкинуть из процесса. Музыка оказалась несложной, умещается в одной голове, если ей помогает компьютер. Симфонический оркестр с нотной записью партитуры для каждого музыканта и дирижёром по факту оказался не нужен.
в музыкальной мейнстримной живой культуре сегодня преобладает джаз, подразумевающий совсем другие принципы коллективного творчества: импровизация плюс взаимоподстраивание (рок это развитие того же джаза, ибо в рок-группах никакого «дирижёра», а вместо «нот» используется звукозапись);
симфонические оркестры остались как очень дорогое средство антикварного хранения традиции, и от них никакого развития музыки не ожидается. Эпоха великих композиторов и великих дирижёров окончилась. Развитие музыки и музицирования идёт, при этом идёт достаточно бурно, но в совершенно других формах. Например, дети массово заканчивают сегодня не столько музыкальную школу, сколько школу диджеинга и там игра идёт не отдельными нотами, а более крупными блоками (сэмплами, треками), и на выходе не только «треки», но и отдельные «сеты» (аналоги альбомов звукозаписи или концертных программ в живой музыке).
Если посмотреть на то, что происходит в инженерии (в том числе и программной, и «железной», и инженерии организации, и врачевании, и социальной инженерии как политике, и любых других видов инженерии), то тренд к «джазовой» организации деятельности несомненен. Все движение agile это движение именно в эту сторону «джазовости» как импровизационности и согласованию деятельности «на лету». Это и понимается как «гибкость», непредзаданность последовательности шагов, уменьшение размера планируемой заранее работы по принципу small batch size37, введение не всей системы с тысячей функций одним шагом (и этот шаг с подписанием акта приёмки-сдачи будет последним шагом проекта), а инкрементами, функция за функцией. Как ни странно, такой «постепенный» подход заодно улучшает скоростные характеристики разработки за счёт того, что раньше получается отклик от задействования целевой системы в её окружении и поэтому раньше исправляются ошибки, меньше тратится времени на проработку заведомо неудачных идей.
Все остальные примеры новинок в организационных дисциплинах (например, переход от акцента на administration/management к leadership, предложение блокчейна в финансовой инженерии) тоже идут именно в эту сторону отсутствия «единоличного лица, принимающего все ответственные решения». Ситуация, при которой все главные решения принимаются одним лицом, которое всеми «дирижирует», опасна. «Дирижёр всего» потенциально создаёт угрозу появления в проекте «бутылочного горлышка», существенно замедляющего принятие инженерных решений (ибо решений много, дирижёр один, все решения он не то что скоординировать он просто познакомиться с ними не успеет толком)! Но главное тут даже не в замедлении работы: одному человеку иметь образование и опыт во всех дисциплинах, в которых принимаются важнейшие решения по проекту невозможно: гений в одних вопросах вполне закономерно может быть полным идиотом в других вопросах. Метафора «великого вождя» в системной инженерии не соответствует духу времени.
Это соответствует и идеям, о которых говорит John Doyle в его работах по системам управления38: для устойчивого (не срывающегося в широком разнообразии режимов) скоростного и точного управления нужно иметь большое разнообразие датчиков, актуаторов, обработчиков информации, которые организованы многоуровнево, системно. В этой структуре при этом множество самых разных обратных связей, сложно устроенных (и просто устроенных прямых связей, команды «просто исполняются», а вот информация от датчиков обрабатывается сложно). Крупные быстрые элементы дают скорость, мелкие медленные точность, и компромисс между скоростью-точностью будет только при сочетании достаточного числа вот этих разных масштабов, появлении множества мест принятия решений. По большому счёту именно такое и происходит в «джазовом» проекте, в котором непрерывно меняется как будущее окружение (его оценки! Его же ещё нет, системы ещё нет!), так и в ответ на это структура целевой системы (которая только-только проектируется и изготавливается, её тоже зачастую ещё нет), так и в ответ на это цепочка создания (по мере изменений целевой системы требуется изменять и практики её создания, то есть менять создателей).
Системные инженеры как люди, занимающие позицию в проекте в профессиональной роли отвечающего за какую-то целокупность всей системы (помним, что мы говорим о системе самых разных уровней это может быть бактерия для генного системного инженера, или городской квартал в «умном городе» для инженера-строительного девелопера, или общество какой-то страны для политика) специализируются тем самым до лидеров инженерной разработки/development (самый верхний уровень, концепция использования и самые верхние уровни концепции системы), и часто на этом самом верхнем уровне это неотличимо от работы инженеров-разработчиков, инженеров-архитекторов и DevOps (разработчиков инфраструктуры непрерывного введения в эксплуатацию, аналог «управления жизненным циклом» в ситуации множественности этих жизненных циклов). Системные инженеры не руководят («руками водят», то есть дают поручения на выполнение работ по развитию системы) прикладными разработчиками, но принимают решения по принципам их работы и структуре развиваемой/evolving разработчиками системы, а также создают условия (в том числе инфраструктуру) для работы всех разработчиков. Это не руководство или управление/management, это governance.
Команды системных инженеров не столько руководят специализированными на работе в каких-то прикладных инженерных областях (domains) людьми, выполняющими ещё более узкие инженерные практики, сколько организуют их взаимодействие по поводу разделения их труда, выполняя свой кусок инженерной работы в части целевой системы и технологий, используемых в проекте создания (прежде всего технологии непрерывного ввода в эксплуатацию).
Вместо «дирижёрской» поэтому лучше использовать «джазовую» метафору описания деятельности, это подробней будет изучаться в курсе системного менеджмента/инженерии предприятия. Так, звукорежиссёр из записанных в студии разными музыкантами в разное время отдельных треков делает окончательную запись. Но он не предписывает, какую музыку играть музыкантам. Звукорежиссёр тут DevOps. Или руководитель джазового ансамбля, который выбирает, какую мелодию будут играть но он не командует кому, когда и что играть, и не выдаёт точные ноты мелодии, не указывает точную гармонию или ритмический паттерн. Это разработчик концепции использования. Или художественный руководитель, который определяет, кто вообще будет играть в ансамбле и устраивающий разнос музыкантам по поводу плохого качества их игры. Это архитектор. Люди, исполняющие роли системных инженеров в команде тоже имеют различающиеся функции, в самых разных их сочетаниях. Но как музыкантов из ансамбля называют «музыкант» (исполнителей ролей музыкантов, отождествляя их с ролями), так и мы системных инженеров из команды/коллектива проекта будем называть «системный инженер» для краткости. Курсы «Онтологика и коммуникация», «Практическое системное мышление», «Методология» помогут вам тут разобраться с различиями ролей, должностей, исполнителей ролей (как отдельных людей, так и организованных в плане распоряжения своим и чужим трудом, инструментами и материалами групп людей). В курсе системного менеджмента как инженерии организации вы получите дополнительный опыт того, как строить системы из людей так, чтобы в их состав входили все нужные виды инженеров (входили люди, исполняющие все необходимые для создания целевой системы практики, исполняя все нужные инженерные роли, включая роли в системах цепочек создания).