Анатолий Левенчук – Системный менеджмент – 2023 (страница 14)

Принципиально, что организатор включает в себя подроли операционного менеджера/управляющего работами и менеджера по развитию, а не только менеджера по развитию. Это подробно разбирается в случае традиционных инженерных систем как один из важнейших принципов DevOps/SRE/internal development platform engineering, который формулируется как ответственность за эксплуатацию теми же людьми, которые создавали систему: you built it, you run it! (ты это построил, ты это и эксплуатируй!). В курсе «Системная инженерия» дано достаточно литературы по DevOps, где обсуждается этот принцип. Как раз DevOps (в менеджменте администраторы) были отделены для того, чтобы разработчики (в менеджменте организаторы) могли и проектировать, и воплощать организацию и далее быть её эксплуатационными операторами. Главное тут в том, что убирается вечная война между создателями системы и её операторами: одна и та же роль (можно обсуждать, как она дальше делится между оргзвеньями) и проектирует, и создаёт, и проводит эксплуатацию системы, а DevOps обеспечивают для этого «внутреннюю инфраструктуру разработки, internal development platform».

Роли, должности, организационные статусы

Главное, что нужно помнить, когда разбираетесь с устройством какой-то организации – не надо честно верить всем произносимым разными людьми словам, всем табличкам на дверях. Помним высказывание Козьмы Пруткова: «Если на клетке слона прочтешь надпись: „буйвол“, – не верь глазам своим». Люди вроде бы называются «на слух» понятно и можно вроде ожидать от них выполнения каких-то понятных из их названия работ, но это не так:

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

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

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

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

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

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