Кто Твой Начальник или Три Роли Менеджеров

В современных сложных организационных структурах сотрудники слишком часто путаются к кому из “начальников” с каким вопросом подходить. Человеку кажется, что над ним некое “управленческое облако”. Часто он наугад пытается решить проблему с наиболее доступным руководителем и удивляется, почему его отослали к другому.

Более того, не только сотрудники, но и сами менеджеры не всегда осознают какие роли на себя берут и где проходит граница между ними.

Я выделил три основных роли менеджеров, основываясь на вопросах, которые сотрудник может с ними решить:

1. Линейный руководитель
2. Менджер приоритетов
3. Профессиональный менеджер

Линейный руководитель

У каждого сотрудника компании (кроме CEO), должен быть один единственный линейный менеджер. Такой человек отвечает за сотрудника. Он нанимает его, интегрирует в организацию, увольняет (при необходимости), проводит performance review, помогает сотруднику расти профессионально, решает бытовые вопросы. В случае каких-то конфликтов в рамках проектов - он участвует в решении таких вопросов. Линейный руководитель отвечает за долгосрочные цели и ценности своей команды.

Менеджер приоритетов

В зависимости от организации, эта роль может быть у менеджера проектов (PM) или менеджера продуктов (PM). Обобщенно можно назвать Priority Manager (тоже PM). Это тот человек, которого можно спросить: что мне делать в рамках проекта? Стоит ли мне углубляться в проблему, которая может занять много времени, или сосредоточится на чем-то простом? Какие сроки? Какие баги фиксить?

Профессиональный менеджер

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

Профессиональный менеджер, это человек который отвечает за целостность и грамотность решений в рамках профессии: Java разработчик, QA, художник. Этот человек способен различить хорошее решение от плохого и подсказать, как нужно сделать. Также эта роль включает в себя владение и определение практик и технологических процессов, которые используются на уровне компании. Примеры такого менеджмента: архитектор или арт директор, QA-директор, CTO. При этом, может быть свой архитектор для серверной и для клиентской части. Если такие специалисты не руководят непосредственно людьми, то они выполняют только эту роль в чистом виде. Бывают ситуации, когда эта роль коллегиальна: группа QA из разных команд компании определяет свои практики.

Анализ различных структур

На практике один руководитель может совмещать две или три роли, но может быть и так, что все роли у разных людей, либо какие-то роли берет на себя отдельная структура. Рассмотрим различные варианты.

Классическая матричная структура

Есть набор функциональных департаментов, скажем, front-end разработчиков, back-end, mobile разработчиков, QA, IT. У каждого департамента есть свой менеджер. Возникает проект, который требует по-несколько человек из каждого департамента. PMO (Project Management Office) выделяет проектного менеджера, который будет отвечать за планы, приоритеты и формирование команды. В таком случае, руководители департаментов (или менеджеры под ними) будут и линейными и профессиональными менеджерами людей в команде, а проектный менеджер, соответственно, менеджером приоритетов.

Новичок и Ментор

Если в команде появляется trainee, то, вполне вероятно, в самом начале технический лидер команды будет решать все его вопросы. Т.е. будет выполнять все три роли.

CTO / Главный Архитектор 

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

В таких случаях в компании может быть введена роль CTO (и / или Главного Архитектора), который не будет напрямую руководить людьми или принадлежать конкретным проектам, однако будет отвечать за некоторые ключевые решения по технологиям. При этом, в некоторых случаях такая роль может иметь свою команду, которая будет заниматься исследовательской деятельностью для задач, которые можно "вынести за скобки". 

Такая роль - в чистом виде профессиональный менеджмент определенного аспекта.

Профессиональный форум

Профессиональное руководство может быть представлено форумом лидеров направления из разных групп. К примеру, компании нужно принять решение где все сервисы будут сохранять логи. Из разных проектов может быть собрана группа, которая примет это решение.

Такой форум также может существовать как "рекомендательный", когда представители делятся своими лучшими практиками и готовы более детально поделиться с теми, кто заинтересовался.

Agile-команда

Считается, что Agile-команды само-организованные, поэтому могут достаточно много решений принимать самостоятельно. Как именно - это дело и ответственность команды. В таком случае:

• Линейный руководитель: находится вне пределов команды.
• Менеджер приоритетов: Product owner. В случае небольших задач в середине спринта - решает команда. 
• Профессиональный менеджер: многие вопросы решает команда, однако, она может быть ограничена принятыми в организации или на проекте методиками. Кто их определяет - зависит от организации.

Структура Spotify

Компания Spotify является одним из примеров для Agile-компаний. В этом видео прекрасно разобрана культура и структура компании.

• Линейный руководитель: находится в одной из команд в пределах трайба (tribe). К примеру, разработчики фронт-енда из разных команд (squad) отчитываются фронт-енд разработчику в одной из команд. Фактически он и является их профессиональным менеджером, так как может ответить на все вопросы, как что-то сделать в рамках технологии. При этом он может адекватно оценить их работу, уровень и прогресс. Линейным менеджером такого руководителя является (надо понимать) руководитель трайба.
• Менеджер приоритетов: Так же как и в обычных Agile-командах.
• Профессиональный менеджер: линейный руководитель, так как он работает на той же технологии является профессиональным менеджером. Также гильдии (guilds) способны предлагать свои практики в той или иной области.

Read More

Agile Performance Review или Мера Программиста

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

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

1. Мне очень сложно было давать комплексную оценку успехов каждого сотрудника в течение полугода. Иногда слышишь что-то хорошее, иногда что-то похуже. Можно сформировать мнение о каждом. Но этого недостаточно.
2. Лидеры команд редко знают зарплаты своих подчиненных (по крайней мере - не от компании), и их представление о рынке труда может быть достаточно неточным.
3. Лидеры команд, за редким исключением, очень хвалят своих ребят. Это вполне нормально и даже хорошо. Но мало помогает нам быть объективными.
4. Была необходимость сравнить людей из разных команд для определения Best Performers, приоритета продвижения и т.д.

В нашей компании был формальный метод проведения оценки, но он был слишком сложный, занимал уйму моего времени и времени менеджеров команд. А что самое плохое, результат был уж совсем не объективный. Я собрался мыслями и выписал, с моей точки зрения, самые важные качества сотрудника:

	Характеристика	Описание
R	Ответственность (responsibility)	Уровень ответственности сотрудника можно определять комплексно. Какого плана задачи вы можете ему поручить? Стали бы вы поручать ему организовывать вечеринку? Насколько вы можете на него положиться в вопросе сроков? В некотором смысле это “взрослость” человека.
T	Технический уровень (technical skills)	Тут понятнее - по сути этот тот уровень, который оценивается на собеседованиях. Junior знает что-то об одной технологии. Middle хорошо знает одну технологию и немного о близлежащих, Senior знает глубоко технологию и близлежащие, а также еще кое-чего. И т.д.
C	Общение (communication skills)	Человек, который умеет грамотно общаться и находить общий язык с людьми часто очень позитивно влияет на производительность команды. Здесь учитывается неконфликтность, умение грамотно писать письма, умение обсуждать вопросы. Важно когда человек не стесняется сам инициировать необходимое ему общение и т.д.
P	Производительность (performance)	По сути - это то, насколько человек быстро “схватывает” информацию, быстро умеет попробовать разные варианты и выбрать лучший. Бывает, что умные, общительные и ответственные люди - большие теоретики, и им не хватает именно скорости мышления и действий, динамичности.
G	Потенциал роста (growth potential)	Здесь оценивается базовая подготовка  и заинтересованность в самообразовании, новых технологиях и т.д. Это оценка перспективности. Ходит ли человек на конференции? Читает ли книги? Смотрит ли видео-уроки и т.д.

Численная оценка привязывается к уровням maturity, при этом допускались промежуточные уровни - до десятых.

Оценка	Уровень	Описание
1	Junior	Требует много внимания и ведения за собой
2	Middle	Достаточно самоходен, но иногда теряет фокус, либо требует технической поддержки
3	Senior	Самоходен, технически грамотен, может помочь разобраться другим ребятам в команде
4	Tech / Team Leader	Может решить проблемы для небольшой команды
5	Sr. Tech / Team Leader, Manager	Может решить проблемы для группы

Сессия для каждой команды

Мы собираемся с каждым менеджером команды и, при необходимости, с тим лидерами. Затем проходим по списку членов команды и даем им сравнительную оценку.

По сути, вместо подхода “сверху вниз”, когда менеджер “расхваливает” мне своего подчиненного общими фразами, мы реализуем подход “снизу вверх”, когда мы даем оценки по каждому важному качеству задавая конкретные вопросы. Таким образом, за скобками остается личное отношение. 

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

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

Оценка результатов

После окончания всех сессий со всеми менеджерами можно подбить итоговый результат. Я считаю, что ответственность и технический уровень все же являются самыми весомыми характеристиками, поэтому, в итоговой формуле они получают наибольший вес: Performance = (R + T + (C + P + G) / 3)) / 3

Результат этой формулы, по моей теории, должен коррелировать с зарплатой сотрудника. Я подставлял его в свой зарплатный файл и видел переоплаченных и недооплаченных сотрудников.

Что в итоге

По прошествии пяти лет использования подобного подхода могу сказать, что он все еще меня радует:

1. Его достаточно просто объяснить лидерам команд: как сами критерии, так и способ оценивания.
2. Оценка специалиста происходит достаточно быстро - достаточно несколько минут обсуждения.
3. Часто несколько технических лидеров, которые взаимодействуют с сотрудником принимают участие в обсуждении команды. Нам всем очень быстро удается договориться.
4. Обсуждая оценку сотрудника совершенно нет нужды обсуждать его текущую компенсацию, о которой ребята обычно не знают.
5. Я выступаю модератором и даю лидерам команд базовые ориентиры по оценкам. Соответственно, в последствии я могу получить достаточно объективную полную картину по всему центру или департаменту.
6. Позитивный отклик от сотрудников. Что более важно, отсутствие негативного отклика - редкое недовольство оценкой со стороны сотрудников. Команда ощущает дух справедливости.

Ограничения метода

1. Метод используется для оценки сотрудников уровня от Junior до Senior. Для тим лидеров и менеджеров используются другие подходы.
2. По сути нет возможности использовать этот метод на собеседовании, что могло бы сразу дать понимание в какой оценочный (а значит и зарплатный) диапазон попадает данный сотрудник.
3. Результат данного метода должен коррелировать с уровнем зарплаты. Однако, если есть необходимость получить уровень полугодичного бонуса, то нужно использовать другую практику, сфокусированную на успехах (и неудачах) за период.

Read More