Про роли мы начинаем говорить, начиная с курса "Моделирование и собранность", и продолжаем дальше разговаривать практически в каждом курсе -- и в курсе системного мышления, и в курсе методологии, и в курсе системной инженерии, и в курсе системного менеджмента. В курсе системного менеджмента особый упор делается на то, что кроме собственно роли обязательно надо рассматривать ещё и практику, выполняемую ролью. Но даже и просто материал по ролям даже и без выхода на версии практик этих ролей даётся более-менее развёрнуто по сравнению со многими другими курсами. Я уже приводил выдержки из курса "Системный менеджмент", раскрывающие материал по ролям -- "Менеджмент, предпринимательство и начальничество" (https://ailev.livejournal.com/1686424.html), "Роли в системном менеджменте, понимаемом как системная инженерия организации" (https://ailev.livejournal.com/1686259.html). и ещё я затрагивал обсуждение ролей на предмет особенностей их исполнения нейронной сеткой на прошлой неделе в материале "Коннективистские концепции агентов, коннективистские архитектуры агентов" (https://ailev.livejournal.com/1684911.html). Сегодня добавим к этой серии ещё один подраздел из "Системного менеджмента", с более практическим рассмотрением: продолжим различать роли, должности, организационные статусы. В частности, именно тут мы рекомендуем назвать всех аналитиков по должности инженерами, это сильно оздоровливает отношения в коллективе.
Главное, что нужно помнить, когда разбираетесь с устройством какой-то организации — не надо честно верить всем произносимым разными людьми словам, всем табличкам на дверях. Помним высказывание Козьмы Пруткова: «Если на клетке слона прочтешь надпись: «буйвол», — не верь глазам своим». Люди вроде бы называются «на слух» понятно и можно вроде ожидать от них выполнения каких-то понятных из их названия работ, но это не так:
-- Работа может выполняться не человеком-начальником, а его подчинённым («я это выполню» может означать «мой сотрудник Петя это сделает»), поэтому разговаривать о деталях дела надо не с начальником, а с подчинённым. С начальником надо договариваться о координационных актах (поручения, обещания, информирование о моменте выполнения обещания, подтверждение приёмки работы как выполнения вашего обещания её сделать, и т.д.). Мы называем «начальником» человека с ролевым аспектом распоряжения трудом и ресурсами.
-- Должности часто называются по ведущей роли, но это не обязательно. Есть штатное расписание, и там будет какой-нибудь «специалист второй категории» как должность (организационное место), на этой должности может находиться человек с самым разным мастерством, выполняющий самые разные роли. И даже начальник, который распоряжается его трудом, у него может оказаться не тот, который записан в штатном расписании. Это «схема»: штатное расписание нужно только для того, чтобы «официально» выписывать человеку зарплату, а реальное положение дел закреплено устными договорённостями.
-- Ведущая роль обозвана неправильно. Когда вам представляют какого-нибудь «аналитика», то это может быть или и впрямь аналитик (который ничего не решает сам, а только «понимает», о чём пишет аналитические отчёты), но может быть и вполне инженер (который решает всё сам, ибо это входит в признаваемые остальными членами команды полномочия). А как же он может принимать решения на такой должности? Очень просто: он «серый кардинал», его полномочия нигде не прописаны, но он имеет большое влияние. В его вроде как «пониманиях» будут «рекомендации», представляющие собой инженерные решения. Вокруг таких «аналитиков» постоянные конфузы, это «скользкая должность»: кто-то обращает внимание на должность и общается не как с полномочным инженером, а как с аналитиком, который не полномочен ничего решать (а он полномочен, но неформально), а кто-то обращается как с полномочным, но неожиданно в критический момент такой «аналитик» говорит, что он всего-навсего аналитик, и пусть кто-то другой из начальства принимает решение, а он тут просто «дал рекомендации». Инженеры принимают решения, а не дают рекомендации по этим решениям. И несут ответственность за решения. Ответственность аналитиков обычно даже не обсуждается. Поэтому мы рекомендуем (если вы начальник и можете это сделать) назвать всех аналитиков по должности инженерами. Это сильно оздоравливает отношения в коллективе. Не все аналитики хотят брать на себя ответственность, но им при переименовании придётся это сделать. Не все сотрудники хотят тратить время на беседы с аналитиками, ибо это пустая трата времени с непонятным результатом. Но беседы с инженерами — это совсем другое дело, результат тут понятен, «принятие решения» (а не «я передам начальству, они примут решение — поиграю в испорченный телефон на одно звено»).
-- Традиции могут врать. Например, ГИП (главный инженер проекта) в некоторых отраслях означает главного разработчика (принимает технические решения), а в некоторых отраслях — главного менеджера проекта (организует команду проекта и становится операционным менеджером, а технические решения в проекте выполняют какие-нибудь «начальники отделов», которые как раз не принимают операционных решений по ресурсам, но зато принимают технические решения, часто даже сами, а не перепоручая принятие таких решений своим сотрудникам в отделе). Вы общаетесь с ГИПом тем самым то по важнейшим инженерным вопросам (какие-нибудь архитектурные решения по поводу целевой системы), и не встречаете почему-то интереса, то наоборот, по менеджерским (выдача зарплаты вовремя, выплаты по контракту вовремя) — и тоже не встречаете интереса. Просто «главный инженер проекта» — это должность, и традиционное распределение ролей и связанных с ними ролевых предметов интереса в разных отраслях (а иногда и в разных организациях одной и той же отрасли) разное. Уточняйте всегда не должности, а роли, чтобы понять, чем занимается (практика) тот или иной сотрудник незнакомой вам организации, какие у него предметы интереса и предпочтения в значениях важных для него характеристик важных для него систем!
-- Если вы ищете какую-то менеджерскую практику (которая обязана быть согласно мета-модели из нашего учебника), то она может оказаться в самом неожиданном месте. Так, составление плана-графика работ по модели «водопада» (ибо про более современные варианты не слышали, не думали) регулярно попадает к главному разработчику, или архитектору. И вместо дополнительного рассмотрения ещё одного варианта концепции системы или архитектурного решения время этих сотрудников расходуется на планирование (которое потом никем не используется в качестве плана, зато какие-то агенты в основной роли менеджеров ставят на контроль дедлайны, прописанные этими агентами, у которых основная роль инженеров, и используют их не как предварительные инженерные оценки длительности работ, а как обещания — и дальше «никто тебя за язык не тянул», типичный бандитский разворот с превращением оценки в обещание. Дальше инженеры делают «схему»: формальные рапорты о выполнении работ вовремя живут собственной жизнью, а содержательно выполнение работ оказывается никак не связанным с планом-графиком. Контрольные вопросы тут про мастерство: какие методы работы используют все помянутые участники в своих ролях, из каких учебников инженерии и менеджмента? Но если вы ищете операционного менеджера в проекте, то часто им будет даже не менеджер по должности, а кто-то из инженеров: он и пишет планы, и выполняет их, а менеджер-по-должности будет только «аналитик», который не принимает никаких решений, но внимательно слушает инженеров, оформляет услышанное красиво и идёт докладывать «наверх» об услышанном. Просто ступенька в «испорченном телефоне». Так что интересуемся, что люди делают, а не как они называются. Интересуемся вплоть до указания практики, ибо «чистить зубы» может оказаться и съесть утром яблоко вместо использования зубной пасты и щётки («в книжке какой-то читал, что этого достаточно, если утром. Но на ночь лучше щёткой» — это и есть, где взял практику), и сходить к зубному врачу на чистку зубов специальным аппаратом. Внимательней будьте не только к ролям, но и к вариантам практики, которые эти роли используют. Они могут быть неожиданными!
-- Главный инженер предприятия, CTO и CIO могут оказаться кем угодно в части основной выполняемой роли агентов на этих должностях. Обычное соглашение в том, что они занимаются «внутренней производственной платформой/инфраструктурой» (разработкой, архитектурой, поддержанием эксплуатации), то есть заведуют практикой DevOps/platform engineering как инженеры платформы создания целевой системы. Метафорически (а в производстве «железа» и буквально) они ответственны за «станочный парк» (компьютеры — это тоже «станочный парк», только современный) для инженеров, а также заказ сервисов, которые выполняются «нашими людьми на чужих станках». Но это «обычное» соглашение выполняется отнюдь не везде. Во многих местах на этих должностях люди много времени тратят на работу в ролях организаторов разработчиков (включая и организацию разработчиков внутренней разработческой/производственной платформы, но и организацию разработчиков целевой системы), организаторов архитектурной работы архитекторов предприятия, то есть это инженеры предприятия. Но не менее часто люди на этих должностях занимаются «курированием» (что превращается в перехват деятельности) разработчиков и архитекторов целевой системы, принимая важнейшие решения по концепции использования, концепции системы, архитектурные решения. Всё, что у людей вызывает ассоциации с «техникой» или людьми, прикасающимися к «технике» — всё вдруг начинает отдаваться CTO, CIO, главному инженеру без различения тех систем и служб, по поводу которых принимаются «технические решения». В результате перегруза часть вопросов неизбежно попадает к каким-то другим людям, сидящим на совсем других должностях, и нужно всегда интересоваться, каково же реально распределение ролей у топ-менеджеров. Ибо CIO может быть и «ответственным» (то есть если что не так, вопросы будут к нему, при этом полномочий на решение вопросов у него может и не быть — слово «ответственный» в менеджменте всегда этим подозрительно) за DevOps и в инженерии целевой системы, и в менеджменте/инженерии предприятия (администраторы), и вдруг заниматься архитектурой организации (а заодно и архитектурой софта и аппаратуры для софта, ибо от CIO именно этого ожидают в качестве подразумеваемой целевой системы его проектов, а что развивать нужно не только софт, но и использующую его организацию, так это уже «так получилось, когда давно создавали должность CIO, этого не учли, кто ж знал, само выросло»). Может быть и наоборот: CFO становится «главным администратором» и тем самым начальником CIO, который делает IT-часть административного конвейера (после этого не ждите, что компьютеры для инженеров целевой системы будут стоить больше, чем компьютеры для подсчёта денег, которые зарабатывают инженеры на дешёвых компьютерах. CTO редко выигрывает у CFO в схватке за IT-ресурсы, если только сама фирма не производит какие-то IT-сервисы — а что IT тут поддерживает абсолютно разные конвейеры, так это в голову не приходит. Но это разные конвейеры: административный для организации и DevOps для целевой системы! Поэтому и информационные системы разные! И должно быть два CIO, по большому счёту!). Уточняйте всегда, кто какие решения на какой должности обычно принимает и какими практиками пользуется, какая у него система в цепочке создания, в какой он сам системе в цепочке создания, думайте в терминах ролей, а не должностей.
-- Должность «системный инженер» осталась с тех пор, когда выделялись отдельно «системноинженерные специальности» в прошлом поколении системной инженерии: роли, занимающиеся инженерией требований (концепция использования и переформулирование её в требования), системной архитектурой (в старом понимании: концепция системы плюс принятие архитектурных решений), проведением испытаний, управлением конфигурацией и инженерной документацией, и прочим «для всей системы». Сегодня разделение труда в инженерии изменилось, вся инженерия (а не только системная инженерия как особая практика) уже опирается на понятие системы (подробности были в курсе «Системная инженерия»). Так что можно только гадать, чем именно занимается «системный инженер» по должности (какую практику инженерии выполняет), какие решения он принимает, тем самым какая у него роль и какие ролевые интересы. Если встретите «системного инженера», всегда интересуйтесь его практиками. В том числе у «системного инженера», «главного системного инженера», «старшего системного инженера» могут оказаться какие-то частные инженерные практики очень древних времён, без опоры на понятие системы, а слово «системный» поставлено какими-нибудь аналитиками в штатное расписание для красоты и значимости, и утверждено какими-нибудь менеджерами с образованием юриста или финансиста без понимания того, что это означает. И совсем не удивляйтесь, если на этой должности обнаружите человека, который 100% времени выполняет практики менеджмента. Общаться же с людьми надо по ролевому принципу, а не по принципу должности с надеждой на то, что роли и должности как-то совпадают.
-- Должность «менеджер проекта» может скрывать самые разные роли, ибо в центре этой должности вроде бы операционный менеджер, работающий по нормам практики проектного управления (версия этой нормы немного отличается для вариантов разных ассоциаций проектного управления), но в реальности всё может быть по-другому. Во-первых, «проект» сегодня совсем необязательно выполняется именно по практикам классического проектного управления (об этом будет в нашем курсе позже). Во-вторых, в маленьких коллективах разработчиков «менеджер проекта» на своей должности будет не только операционным менеджером, но и организатором, а дальше — сюрприз! — можно легко обнаружить, что он исполняет роли стратега/визионера, а ещё и архитектора, и даже принимает принципиальные для разработчика решения по концепции системы, а потом делит работу согласно этим принятым решениям по разработчикам. Но это же инженерные роли, а не менеджерские! Да, на должности «менеджер проекта» часто работает инженер. Это так же часто, как «ведущий инженер» может выполнять главным образом менеджерские роли, а инженерией целевой системы заниматься только маленькую часть времени. Всегда уточняйте, чем занимается на своей должности человек: какая практика, какая роль, какие ролевые интересы и какая у него система в цепочке создания и в какой он сам системе в цепочке создания.
-- Продакт-менеджер/product manager и собственник продукта/product owner. На этих должностях существенная часть деятельности, существенное время выполнения практики — это стратегирование/визионерство по отношению к продукту как целевой системе, или целевой услуге. Но вот дальше там будет «букет» из как менеджерских ролей, так и ролей инженерии целевой системы. При этом ни в одной организации вы не встретите одинакового набора ролей и одинакового распределения времени на выполнение практик этих ролей, а если в организации будут одновременно и product manager и product owner, то вы услышите в каждой из этих организаций пространные объяснения, как между этими должностями разлеглись разные роли, но вот только эти объяснения в разных организациях будут разными (при полной уверенности, что «везде одинаково, и у нас так же»).
-- Наставник как организационный статус — это непонятно что. Должность — это не единственное понятие, с которым путаница, бывают и её эквиваленты — организационные статусы как оргместа для размещения туда людей, просто «должность» обычно входит в штатное расписание, а «организационный статус» не входит. Оргзвено становится таким, когда агента размещают на оргместе (должности или организационном статусе). В оргзвеньях не-подразделениях это может быть секретарь комиссии, председатель научно-технического совета и т.д. Под «наставником» обычно понимается какой-то опытный сотрудник, передающий свой опыт менее опытному. Но за этими словами непонятно какая именно практика (что делают эти люди, а не какой им почёт, уважение, признание заслуг и опыта), поэтому непонятно, какая там роль — непонятно, что на этой роли делать, как к этому относиться другим ролям. Как сказал один начальник отдела, которого пытались сделать «наставником»: «если я этому инженеру наставник, то я должен быть уверен, что он выполняет мои советы. То есть должен стать его начальником, и он никуда не денется, буду передавать ему опыт. А если я его начальник, то зачем мне этот титул наставника? Я ж и так по должности озабочен растить-развивать своих сотрудников! А если я не начальник, то что я буду ему советы давать, когда у него для этого свой начальник есть? И зачем я буду тратить время на то, чтобы уговаривать его эти советы выполнять, если я могу не тратить этого времени, когда я начальник? Пустое это: начальник и наставник это одно и то же». Тут будет сразу множество возражений и разъяснений, но над этой организацией нужно очень хорошо подумать: что там с практиками, ролями и распределениями их по статусам. Потом попробовать табуировать слово «наставник» (и похожие слова типа agile coach и дальше оргстатусы приглашённых консультантов по отдельным практикам) и подумать о том, что происходит в жизни там, где вроде как должна существовать практика наставничества. Потом попробовать вспомнить, где практика наставничества реально существует и даёт результаты, и как она там организована (автор в своей менеджерской практике нигде такого не видел: наставничество «пожилыми молодых» как таковое жило только на бумаге, а реальное всегда было организовано в рамках какой-то организации труда с обычным распределением обычных полномочий обычных сотрудников, а не «как в наставничестве» каким-то особым порядком. С «консультантами» и «учителями/тренерами» обычно понятно, а вот с «наставниками» — нет. Вот и переходите от названий ролей к подробному описанию практик и не забывайте оценить реалистичность выполнения этих практик).
-- На должность может быть назначено целое предприятие, даже на должность директора. Например, как поменять CEO мимо решения акционеров? Назначаем ООО «Директор» единоличным исполнительным органом АО «Марионетка» решением собрания акционеров. Затем директор ООО «Директор» назначает Васю исполняющим роль директора АО «Марионетка» от имени ООО «Директор». И если затем нужно по-быстрому сменить Васю на Дашу, то это пять минут на оформление приказа по ООО «Директор», а не внеочередной созыв собрания акционеров. Такая схема (помним, что у нас это термин: когда официальное/юридически признаваемое оформление организационных статусов по-одному, а реализация в жизни — совсем по-другому) используется повсеместно. Например, при реорганизации РАО «ЕЭС России» было именно так: директора региональных энергокомпаний могли быть переназначены за минуты, никаких месячных ожиданий на созыв собраний акционеров, договорённости с местными властями и прочие реверансы. Второй пример: стаффинговые компании , которые одалживают людей для работы в других фирмах, но формально эти люди работают у них в штате (случай директоров РАО «ЕЭС России» на это очень похож, «одалживают директора», хотя не по просьбе одалживающей фирмы, но принудительно). Консалтинговые фирмы занимаются примерно тем же: могут одолжить тебе целый отдел консультантов (скажем, аудиторов), но формально люди работают у них в штате. Должности как организационные статусы этих людей обычно отсутствуют, но могут существовать невнятные организационные статусы в самой организации, по этим статусам вообще невозможно понять ролей. Скажем, консультантов по новым технологиям так и представляют: «это наш консультант» (организационный статус) и часто даже не добавляют, по чему именно (какой практике) консультант: потому как приходится консультировать и по какой-то прикладной инженерии чего-то в целевой системе, и по организовыванию на эту инженерию какой-то службы, и по многому ещё, что понадобится. За словом «консультант» точно так же может скрываться огромное число ролей, и надо разбираться специально, о чём в каждый момент времени идёт с ним разговор).
Общие замечания: разбирайтесь не по названиям оргстатусов, но по практикам и ролям с их интересами, интересуйтесь системой в цепочке создания, для изменений которой применяются эти практики, интересуйтесь уровнем квалификации в практике оргзвена, выполняющего эту практику (помним, что практику выполняет необязательно один человек. Практика разработки, например, может выполняться командой, и «квалификация команды» эмерджентна, не равна сумме квалификаций её членов — например, они могут внутри себя не договориться, как выполнять разработку, хотя каждый из них может быть более чем умел в разработке, поэтому не могут быть коллективным разработчиком, не могут выполнять эту роль как оргзвено).
Должности (и подразделения как аналоги должностей уровня выше личности) и другие оргстатусы — это чаще всего просто элемент «схемы для найма на работу и выплаты зарплаты», возможность как-то платить зарплату (в случае подразделения то же самое, плюс может речь идти о делёжке бюджета, квотам на разные бонусы) разных размеров разным нужным для выполнения каких-то практик (играющих какие-то нужные роли) людям, возможность понятным образом назначить «формального начальника». Это нельзя путать с ролями. Когда говорят «исполнение должности», то это «исполнение большого количества ролей, на которые назначена эта должность».
При этом первым же шагом в реальности, а не формальной модели из «схемы» после назначения на должность может быть передача сотрудника (или даже целого подразделения) в какой-то проект и назначение премии за успехи в этом проекте — и сумма премии и выполнение задач этого проекта после чего будет в разы и разы больше, чем сумма зарплаты и выполнение задач по линии основной должности. Поэтому задавайте вопросы и уточняйте роль, выполняемую ролью практику и ролевые интересы. Иначе договориться будет невозможно.
Если встретились «скользкие типы», с которыми невозможно понять, чем же они занимаются (роль и её практику), задействуйте лидерство: совместите человека с какой-то важной ролью и отследите, чтобы всё его окружение заставляло этого «скользкого типа» заниматься именно этой ролью, а не увиливать от работы. В явном виде называйте роль и практику, требуйте их исполнения и расскажите всем окружающим об этом: у них ведь наверняка такие же проблемы с этим «скользким типом». Может быть, это не скользкий тип, а просто запутавшийся в своих делах человек. Сосредоточение на какой-то роли (поначалу с мягким внешним понуканием к её занятию) осмыслит его существование на предприятии, он будет благодарен. Если нет — расставайтесь под любым предлогом, люди без глубокой ролевой специализации, но ласковые общительные и поэтому часто с полномочиями (кто из начальников не даст какой-то организационный статус своей ласковой мимими-кошечке в лице приятного человека! Ему ж нетрудно!) не нужны.
Автору курса пришлось как-то уволить системного администратора, который был ласков, общителен и работоспособен, но не владел практикой системного администрирования: коллектив его очень любил, но по своей роли он работать не мог, ни одна задача системного администрирования не решалась вовремя (и вообще не решалась, приходилось эти задачи решать другим людям). Коллективу было жалко расставаться с приятным сотрудником, но после увольнения все облегчённо вздохнули: сильно уменьшилось количество проблем по линии системного администрирования. Это тоже рассказ про агентов с их ролями и выполнением практик, должностями/оргместами/организационными статусами, психологическими особенностями и квалификацией в выполнении практики выполняемой роли. Обсуждать такие случаи нужно ровно так: это и есть набор важных объектов при работе с оргзвеньями (включая internal team частей личности уровня ниже уровня личности, а также крупные подразделения больших компаний уровня много выше уровня личности).
Роли и выполнение практик — главное, приучайтесь обращать внимание на них в первую очередь, на реальные (не по штатному расписанию и должностям, а по линии «кто на кого влияет, кто с кем дружит») полномочия во вторую очередь, на психологические особенности — в третью.
Тем не менее, если вы имеете возможность влиять на штатное расписание, то старайтесь давать должностям наименование согласно культурно-обусловленным ролям, это существенно повышает возможности сотрудникам понимать: о чём с кем договариваться. Сотрудники будут, конечно, обращаться друг ко другу как к «должностям» (у них ведь нет тренинга в системном мышлении, да и роли для всех должностей им обычно неоткуда знать, если они не очень давно в организации, а организация большая). Но поскольку вы позаботились, что названия должностей и основных ролей по возможности совпадают, то коммуникация будет более качественной, как-то связанной с ролями и ролевыми интересами, а не произвольной, поскольку роли и интересы неясны, и нужно тратить время, чтобы их выяснить для каждой ситуации встречи с «должностью». Помним про «аналитика» из примеров разбирательства с должностями выше, попробуйте сделать так же и с другими должностями по аналогии с «аналитиком».