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