Системный инженер
как технический лидер

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

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

Понятие технического лидерства (technical leadership, отличается от организационного лидерства, organizational leadership) означает помощь в организации коллективной мыслительной работы по отношению к той или иной технической идее: все участники проекта должны делать одну и ту же систему, а не разные. Отличия технических лидеров от «технических евангелистов»: евангелисты – это проповедники чужих идей на предмет их воплощения в самых разных проектах инженерной компании или даже отрасли, а системные инженеры как технические лидеры – сами себе «технические иисусы христы» в отдельных конкретных проектах, они сами поставщики тех технических решений, в которых потом они должны уметь убедить других людей в их конкретном проекте. Системные инженеры не просто берут идеи от одних инженеров, а потом убеждают других инженеров их принять.

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

Организационные лидеры занимаются тем, что помогают людям занять свои роли в организации, они катализируют сотрудничество, делают организацию целой. Технические лидеры делают целевую систему целостной. Какую целевую систему? Разных уровней. Политические лидеры как технические лидеры уровня общества должны делать общество целостным, чтобы оно функционировало без каких-то существенных коллизий.

В давней (это статья 2009 года. Помним, что первый iPhone появился в 2007 году. В инженерии 2009 год – это очень давно! Всё в инженерии происходит быстро, и не только в железной инженерии) статье «Наука и искусство системной инженерии»³⁵, отражающей опыт космической системной инженерии NASA, приводится сравнение системного инженера со специально обученным и талантливым дирижёром симфонического оркестра, который творит Симфонию. Системный инженер, как дирижёр, налаживает работу «симфонического оркестра» из многих инженеров-разработчиков, и даже часто не отдельных людей-разработчиков, а целых команд разработчиков. Это одновременно и правда, и неправда. Правда в том, что системные инженеры – это технические лидеры. Неправда в том, что системный инженер – это один человек, «рулящий» огромными коллективами других инженеров.

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

Вспомните ситуацию начала времён WWW, когда появилась и начала бурно развиваться профессия веб-мастера в середине 90х прошлого века. Трудно уже вспомнить, но всего двадцать лет назад был один человек, который занимался для вебсайтов всем: программировал движок, разрабатывал арт-дизайн, пришивал его к движку, наполнял вебсайт материалом, продвигал его в Сети и т. д. Один человек, который совмещал в себе всё разнообразие прикладной инженерии для сайтостроения. Сейчас «вебмастера» уже нет, а есть отдельно программисты CMS (content management system) или программисты бэк-энда, дизайнеры, верстальщики (которых уже так не называют, это программисты фронт-энда), тимлиды и DevOps, редакторы (в вариантах editor и content manager, причём второго уже и редактором не называют, а раньше называли), администраторы, модераторы, специалисты по пользовательским интерфейсам и по пользовательскому опыту (раньше их не различали, теперь даже пишут UI/UX), SEO (search engine optimization) и после этого появившиеся спецы по SMM (social media marketing), и это еще не полный список (вы заметили, что в этом списке не хватает архитектора? Он обязательно должен быть!).

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

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

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

• Дисциплина всё записывать/учитывать: договорились и делаем – записать, о чём договорились, что делаем, что сделали, чем обосновывали. Не записали – это не договорились, так что – не делаем! Памяти не верим, верим записям. Современная инженерия без компьютеров не делается! Внимание людей к деталям проекта и целокупности проекта поддерживается компьютерами! И личная собранность и организационная/командная/коллективная собранность сегодня держится не на биологической памяти, а на компьютерной памяти! Голыми руками и голым мозгом не работаем! То, что «все ходы записаны» и легко разобраться в ситуации, за это отвечают девопсы (управление версионированием и конфигурацией у них).

Есть ли «системный инженер» в сайтостроительстве как отдельная должность? Может быть (хотя называться он может как-нибудь по-другому, например тимлид или «архитектор проекта», а иногда и «ведущий аналитик», у которого и права принимать решения нет, только «право давать рекомендации начальникам»), а может и не быть. Есть ли «системная инженерия» в сайтостроительстве? Безусловно, есть: это и обсуждение сайта как целого (создание концепции использования), и практики создания сайтовой архитектуры, и практики технического и организационного лидерства как поддержки совместного технического творчества инженеров как в технической части, так и в организации труда этих инженеров (это практика DevOps).

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

• в симфонической музыке за счёт компьютерной поддержки композитора оказались выкинутыми и дирижёр, и его оркестр, а «симфонические» фонограммы к современным фильмам и играм готовятся самим композитором буквально в одиночку – но на компьютере. Компьютер настолько увеличивает возможности одного человека, у которого есть в голове полный замысел, что других людей можно смело выкинуть из процесса. Музыка оказалась несложной, умещается в одной голове, если ей помогает компьютер. Симфонический оркестр с нотной записью партитуры для каждого музыканта и дирижёром по факту оказался не нужен.

• в музыкальной мейнстримной живой культуре сегодня преобладает джаз, подразумевающий совсем другие принципы коллективного творчества: импровизация плюс взаимоподстраивание (рок – это развитие того же джаза, ибо в рок-группах никакого «дирижёра», а вместо «нот» используется звукозапись);

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

Если посмотреть на то, что происходит в инженерии (в том числе и программной, и «железной», и инженерии организации, и врачевании, и социальной инженерии как политике, и любых других видов инженерии), то тренд к «джазовой» организации деятельности несомненен. Все движение agile – это движение именно в эту сторону «джазовости» как импровизационности и согласованию деятельности «на лету». Это и понимается как «гибкость», непредзаданность последовательности шагов, уменьшение размера планируемой заранее работы по принципу small batch size³⁷, введение не всей системы с тысячей функций одним шагом (и этот шаг с подписанием акта приёмки-сдачи будет последним шагом проекта), а инкрементами, функция за функцией. Как ни странно, такой «постепенный» подход заодно улучшает скоростные характеристики разработки за счёт того, что раньше получается отклик от задействования целевой системы в её окружении и поэтому раньше исправляются ошибки, меньше тратится времени на проработку заведомо неудачных идей.

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

Это соответствует и идеям, о которых говорит John Doyle в его работах по системам управления³⁸