• Главный инженер предприятия, CTO и CIO могут оказаться кем угодно в части основной выполняемой роли агентов на этих должностях. Обычное соглашение в том, что они занимаются «внутренней производственной платформой/инфраструктурой» (разработкой, архитектурой, поддержанием эксплуатации), то есть заведуют практикой DevOps/platform engineering как инженеры платформы создания целевой системы. Метафорически (а в производстве «железа» и буквально) они ответственны за «станочный парк» (компьютеры – это тоже «станочный парк», только современный) для инженеров, а также заказ сервисов, которые выполняются «нашими людьми на чужих станках». Но это «обычное» соглашение выполняется отнюдь не везде. Во многих местах на этих должностях люди много времени тратят на работу в ролях организаторов разработчиков (включая и организацию разработчиков внутренней разработческой/производственной платформы, но и организацию разработчиков целевой системы), организаторов архитектурной работы архитекторов предприятия, то есть это инженеры предприятия. Но не менее часто люди на этих должностях занимаются «курированием» (что превращается в перехват деятельности) разработчиков и архитекторов целевой системы, принимая важнейшие решения по концепции использования, концепции системы, архитектурные решения. Всё, что у людей вызывает ассоциации с «техникой» или людьми, прикасающимися к «технике» – всё вдруг начинает отдаваться CTO, CIO, главному инженеру без различения тех систем и служб, по поводу которых принимаются «технические решения». В результате перегруза часть вопросов неизбежно попадает к каким-то другим людям, сидящим на совсем других должностях, и нужно всегда интересоваться, каково же реально распределение ролей у топ-менеджеров. Ибо CIO может быть и «ответственным» (то есть если что не так, вопросы будут к нему, при этом полномочий на решение вопросов у него может и не быть – слово «ответственный» в менеджменте всегда этим подозрительно) за DevOps и в инженерии целевой системы, и в менеджменте/инженерии предприятия (администраторы), и вдруг заниматься архитектурой организации (а заодно и архитектурой софта и аппаратуры для софта, ибо от CIO именно этого ожидают в качестве подразумеваемой целевой системы его проектов, а что развивать нужно не только софт, но и использующую его организацию, так это уже «так получилось, когда давно создавали должность CIO, этого не учли, кто ж знал, само выросло»). Может быть и наоборот: CFO становится «главным администратором» и тем самым начальником CIO, который делает IT-часть административного конвейера (после этого не ждите, что компьютеры для инженеров целевой системы будут стоить больше, чем компьютеры для подсчёта денег, которые зарабатывают инженеры на дешёвых компьютерах. CTO редко выигрывает у CFO в схватке за IT-ресурсы, если только сама фирма не производит какие-то IT-сервисы – а что IT тут поддерживает абсолютно разные конвейеры, так это в голову не приходит. Но это разные конвейеры: административный для организации и DevOps для целевой системы! Поэтому и информационные системы разные! И должно быть два CIO, по большому счёту!). Уточняйте всегда, кто какие решения на какой должности обычно принимает и какими практиками пользуется, какая у него система в цепочке создания, в какой он сам системе в цепочке создания, думайте в терминах ролей, а не должностей.

• Должность «системный инженер» осталась с тех пор, когда выделялись отдельно «системноинженерные специальности» в прошлом поколении системной инженерии: роли, занимающиеся инженерией требований (концепция использования и переформулирование её в требования), системной архитектурой (в старом понимании: концепция системы плюс принятие архитектурных решений), проведением испытаний, управлением конфигурацией и инженерной документацией, и прочим «для всей системы». Сегодня разделение труда в инженерии изменилось, вся инженерия (а не только системная инженерия как особая практика) уже опирается на понятие системы (подробности были в курсе «Системная инженерия»). Так что можно только гадать, чем именно занимается «системный инженер» по должности (какую практику инженерии выполняет), какие решения он принимает, тем самым какая у него роль и какие ролевые интересы. Если встретите «системного инженера», всегда интересуйтесь его практиками. В том числе у «системного инженера», «главного системного инженера», «старшего системного инженера» могут оказаться какие-то частные инженерные практики очень древних времён, без опоры на понятие системы, а слово «системный» поставлено какими-нибудь аналитиками в штатное расписание для красоты и значимости, и утверждено какими-нибудь менеджерами с образованием юриста или финансиста без понимания того, что это означает. И совсем не удивляйтесь, если на этой должности обнаружите человека, который 100% времени выполняет практики менеджмента. Общаться же с людьми надо по ролевому принципу, а не по принципу должности с надеждой на то, что роли и должности как-то совпадают.