Как оценить грейд менеджера разработки

Сейчас в управлении разработки Контура 1400+ сотрудников. Это системные аналитики, проектировщики интерфейсов, бэкенд- и фронтенд-разработчики, тестировщики, девопсы, юзабилисты, продакты. И менеджеры разработки в количестве 100+ человек. Раз в полгода руководитель каждого из них обновляет цели по развитию, пересматривает грейд и зарплату.

Для прозрачности этих процессов у большинства ролей есть матрицы компетенций и модели развития. Матрица — набор навыков и их проявлений для каждого грейда, а модель — обобщенные портреты для каждого грейда и прочие артефакты, упрощающие оценку. Например, вот один из навыков из матрицы аналитиков — «Принятие решений»:

Менеджеры разработки как непосредственные руководители ребят используют эти модели для полугодовой оценки сотрудников или чтобы обозначить новичкам траектории развития.

Весной 2020-го менеджеры разработки сами задались вопросом: «А куда нам расти и чем менеджер джун отличается от менеджера сеньора?». Так началась история про модель развития менеджеров разработки.

Как оценивали МР до появления модели развития

В Контуре раньше было так: заместитель руководителя разработки встречался с МР и задавал вопросы про работу, команду и т. д. Например, «Как провел полгода?» Менеджер что-то отвечал, зам как-то узнавал, как дела у продукта, команды, и делал финальный вывод: молодец МР или нет. В конце встречи вместе фиксировали цели на следующие полгода для менеджера.

Работало это неидеально: никто не мог гарантировать, что у равных по скиллам МР будет сравнимая зарплата, так как не было отправной точки «чего ждать от МР такого-то уровня». Цели также могли сильно разниться (и это нормально, если мы говорим о специфике продуктов). Конфликт начинается, когда руководитель одного считает справедливым требовать прокачки тех или иных компетенций, а второму другой руководитель говорит: «Ты и так молодец, можно было бы еще прокачать вот это, но, наверное, это не к твоей роли запрос».

Отсутствие синхронизированных требований к менеджеру каждого грейда порождало ощущение несправедливости и иногда непонимание того, можно ли расти куда-то дальше.

Так четверо МР из разных команд объединили свои силы и собрались в рабочую группу для создания модели развития. Как адепты продуктового пути, мы начали с выявления потребностей у вовлеченных в процесс: самих менеджеров разработки и тех, кто их оценивает.

Шли с двух сторон.

Сначала спросили у самих менеджеров, каковы их ожидания от модели развития. Самыми частыми ответами стали:

• понимать свой уровень развития как МР;
• видеть пути дальнейшего развития;
• обеспечить прозрачность оценки МР;
• наглядно показать потенциальному менеджеру, чем предстоит заниматься и что от него могут ожидать.

А затем обратились к замам, оценивающим менеджеров. Узнали, какие проблемы они видят в текущем процессе:

• нет объективности — нет способа бесспорно объяснить, почему руководитель оценивает какой-то пункт именно так;
• нет согласованной картинки зон ответственности. А она бы показала МР, что «это тоже его задача», когда какая-то проблема не решается;
• не всегда МР сами умеют поставить себе адекватные цели с конкретными критериями достижения. Заму бывает трудно сделать это за МР, потому что не хватает контекста;
• нет четкой схемы ответа на вопросы типа: «А что нужно делать, чтобы получать столько-то денег?» Неясно, достижение каких целей будет соответствовать такой сумме;
• сложно смаппить зарплаты МР с разным набором скиллов и историй успеха.

Проблематика стала понятна: оценка, во-первых, должна быть прозрачной и объективной для любого менеджера, во-вторых, помогать отвечать на вопрос: «А куда мне дальше?»

Время прорабатывать решение!

У самурая есть только путь… Версия 1.0

На дворе 2020 год. У менеджеров нет матрицы, но есть составленная мапка зон ответственности:

Скачайте для лучшего просмотра

Рабочая группа скрупулезно прочесывает ее и перерабатывает в набор навыков для оценки. На выходе получаем 8 навыков с прописанными примерами проявлений для всех грейдов:

• делегирование;
• самостоятельность;
• работа с рисками;
• работа с изменениями: мониторинг, анализ, внедрение;
• работа с неопределенностью: неизвестная проблема, неизвестно количество влияющих факторов, неизвестен результат;
• горизонт работы и точность планирования;
• рефлексия (как собственного опыта, так и командного);
• воспроизведение опыта (повторяемость).

Пример одного из навыков:

21 июля 2020 рабочая группа презентует первую версию модели на широкий круг менеджеров и набирает 10 добровольцев, чтобы они обкатали ее на себе в ближайший летний пересмотр. Спустя месяц мы собираем с них фидбэк и видим, что все прошло не так гладко, как хотелось бы…

Основные проблемы:

• неоднозначные формулировки;
• слишком много индикаторов для оценки;
• в модели к навыкам не прописаны примеры проявления в реальной жизни, а значит, трудно отнести свой опыт к какому-то конкретному грейду.

«Пу-пу-пуууу», — делает рабочая группа и расходится п̶л̶а̶к̶а̶т̶ь̶ проводить пересмотры в своих командах, чтобы после вернуться к модели с новыми силами….

Давай по новой! Версия 2.0

В октябре 2020-го начался второй подход к задаче. По мотивам обратной связи решили облегчить модель, сделать ее более понятной.

Критерий успеха: минимум 51 % менеджеров захотят использовать модель в дальнейшем, даже если она не будет обязательной.

Так, за следующие полгода модель претерпела следующие изменения:

1. Выпилили из всех индикаторов грейды мидл– и сеньор+, чтобы упростить выбор при оценке навыка.
2. Сократили до 4 навыков + 2 бонусов (необязательные навыки, так как они больше про работу вне команды, но тоже почетные и влияющие на грейд и зарплату):

• управление процессами разработки,
• ответственность за людей,
• управление рисками,
• управление ресурсами,

+

• передача управленческого опыта за пределы команды,
• управление проектами за пределами команды — внепроектные активности.

3. К каждому навыку добавили примеры проявлений и способы валидации.

4. Добавили портреты МР: краткое описание менеджера — представителя конкретного грейда

Интерн. Под постоянным руководством наставника выполняет отдельные управленческие задачи. Есть задачи и зоны ответственности, которые ему пока не доверяют (приоритизация продуктовых задач, зарплатные вопросы и т. д.)

Джун. С ситуативной помощью наставника управляет формализованными процессами в своей команде, получает первый опыт оценки людей, изучает факторы мотивации, учится подбирать задачи, нарабатывает опыт управленческих кейсов (риски, ресурсы, конфликты и т. д.)

Мидл. Самостоятельно справляется с управленческими задачами, характерными для своей команды. Осознанно точит процессы (понимает цель, видит результат, рефлексирует: успех/нет/почему). Идентифицирует риски внутри команды разработки, оценивает, выбирает способы реакции, анализирует случившиеся риски. В бизнес сильно не лезет, но контролирует вход задач в разработку. Оценивает участников команды и ставит им цели согласно стратегии продукта. Подбирает людей в команду с учетом факторов мотивации, совместимости, компетенций. Решает проблемы нехватки ресурсов не только добавлением единиц ресурса, но и за счет более эффективных процессов в команде.

Мидл+. Имеет успешный кейс управления процессами в команде с изменившейся конфигурацией (численность, структура, предметная область, роли), в том числе управления несколькими командами. Идентифицирует и оценивает риски в смежных с разработкой областях. Если есть запрос, то применяет свой опыт для прокачки смежных с разработкой процессов. Мыслит шире рамок своей команды, например, делится своими ресурсами с другими командами ради достижения более важной цели и более эффективного применения ресурсов. Выращивает управленческие навыки в людях, в том числе растит МР «на экспорт». Активно делится своим опытом внутри компании.

Сеньор. Есть многократный опыт управления командами в разных конфигурациях, подбирает оптимальные по ситуации процессы. Имеет разнообразный опыт и обширный кругозор. Находит правильных людей под любой проект в рамках направления/управления разработки, вдохновляет и заряжает на успех. Идентифицирует риски разработки на уровне продуктов, направлений, компании, формулирует стратегии и успешные планы реагирования на них. Способствует пиару Контура во внешнем мире как крутой IT-компании.

5. Появился гайд по заполнению модели. В нем есть краевые сценарии и ответы на самые частые вопросы из обратной связи по первой версии модели.

Наступает февраль 2021-го, время новой полугодовой оценки, и уже 40+ менеджеров пробуют себя оценить.

Ниже топ сценариев, в которых модель помогла менеджерам:

• синхронизироваться с руководителем, отталкиваясь от единой модели (55 % ответивших);
• понять, что ожидается от следующего грейда (55 %);
• удобно собрать ОС и отрефлексировать (45 %);
• оценить, какие навыки надо прокачать, чтобы помогать своей команде работать эффективнее (40 %);
• найти неожиданные точки роста (33 %).

Может, на этом и стоило бы остановиться, так как мы сделали уже достаточно полезный инструмент. Но оценивать себя по модели добровольно все еще хотела только треть менеджеров, а не желаемая нами половина! Значит, продолжаем.

Ah shit, here we go again… Версия 3.0

Весна 2021-го. Снова обработка обратной связи, снова куча личных встреч с авторами обратной связи, отработка точечных возражений…

По итогу топовые запросы на доработку такие:

1. К индикаторам про риски и процессы добавить списки типичных рисков и процессов, за которыми должен бдить менеджер. Сделать эти списки доступными любому менеджеру.
2. Согласовать модель со всеми руководителями направлений, чтобы у менеджера было больше уверенности в общепризнанности инструмента.

Если первый пункт это про «сесть и сделать», чем мы и занялись, то вот второй потребовал обсуждений с каждым замом, общую презентацию для них и последующий опрос.

Результаты нас порадовали, так как ⅔ руководителей направлений готовы были пользоваться портретами и индикаторами сходу. Остальных мы отрабатывали точечно. В итоге мы получили модель одобренную «сверху», но обрекать всех 100+ менеджеров на обязательное подробное заполнение замы были не готовы.

К летнему пересмотру 2021-го мы пришли к следующему состоянию.

Модель обязательна для менеджеров разработки и их замов, подробное заполнение поощряется, НО:

1. При желании можно использовать только краткие портреты.
2. Грейд по модели пока не становится обязательным условием для попадания в конкретную зарплатную вилку.

Пережили пересмотр с такими выводами:

1. Краткие портреты МР отражают действительность у большинства менеджеров в Контуре.
2. Формулировки стали лучше. Но все еще спорные и неоднозначные. Надо точить дальше.
3. Подробных расшифровок индикаторов не хватает, чтобы применить к своим менеджерским кейсам. Нужно больше примеров или возможность сравнить себя с другими МР через открытую оценку (калибровка/промодоки/что-то еще).
4. Грейд и зарплатные вилки пока не маппятся, но как-то должны мы в эту сторону прийти.

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

Последняя (но это не точно)

Модель развития менеджеров разработки в Контуре случилась! И имеет высокий процент адептов в комьюнити. Надо ли на этом останавливаться? Конечно, нет!

Что планируем дальше:

1. Облегчить порог вхождения для первой оценки и добавить примеров для уже бывалых — сделать публичными оценки нескольких менеджеров разных грейдов с примерами из их жизни.
2. Добиться того, чтобы грейд по модели трактовал зарплатную вилку (а то чего у нас не как у остальных ролей!).
3. Научиться прикладывать модель к ребятам, которые совмещают роль менеджера с другой (разработчика или аналитика, например).
4. Не сгореть по пути :)

Вот такой путь мы прошли за 1,5 года. Хотелось ли бросить по пути, потому что «ну жили же как-то раньше»? Да. Почему не бросили? Потому что верим в пользу проекта и топим за прозрачность оценки во всем управлении разработки. Получилось ли из этого что-то хорошее? Да, и отзывы это подтверждают.

Если вы в своей компании внедряли модели оценки менеджеров, поделитесь опытом, как это было и что получилось на выходе. Нам безумно интересно, как другие компании решали эту задачу.