Написать нам
Меню

Назад к главному

Как построить матрицу компетенций с нуля

Рассказывает Verno, центр экспертизы red_mad_robot

Представим, что вопрос, зачем строить матрицу, перед вами уже не стоит. Компания (или подразделение) уже достаточно зрелая, чтобы осознать такие потребности:

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

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

  • сформировать чёткие результаты для онбординга сотрудников;

  • построить понятные вилки зарплат;

  • стандартизировать оценку (ассессмент) сотрудников, скажем, раз в год;

  • видеть, каких специалистов и отдельных компетенций в коллективе не хватает прямо сейчас, и иметь возможность предсказывать нехватку в будущем;

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

Представим также, что матриц компетенций в компании нет и никогда не было — начинать нужно с нуля. Как это сделать?

Перечисляем работы

Первым делом выберем функциональную роль, с которой будем работать, и систему грейдов внутри неё. Например, продуктовый дизайнер: от стажёра до старшего специалиста. И визуализируем блоки работ, которыми занимаются дизайнеры в компании.

Для сотрудников производства удобнее расписывать дела в привязке к производственным этапам: от инициации проекта до выпуска готовой продукции. Для сотрудников сервисных подразделений — в привязке к этапам взаимодействия с их «клиентами». Так, работы HR-службы удобнее визуализировать на карте движения сотрудника (Employee Journey Map), которая захватывает путь от найма до выхода из компании. Можно также сверяться с регламентами и описаниями процессов, должностными инструкциями, паттернами поведения образцовых специалистов.

Фрагмент карты работ бизнес-аналитика. Блоки взяты из описания производственного процесса. Для визуализации использован шаблон диаграммы Mind Map в Miro<br>
Фрагмент карты работ бизнес-аналитика. Блоки взяты из описания производственного процесса. Для визуализации использован шаблон диаграммы Mind Map в Miro

Следом добавим задачи развития подразделения: например, онбординг новичков и наставничество коллег, технологизацию команды и развитие базы знаний, технический PR и другие, если есть. Это непрофильные работы, но если они ведутся системно, в них постоянно задействована часть команды. Со временем заинтересованные сотрудники нарабатывают компетенции менторов, преподавателей и спикеров, авторов статей, которые можно оценить и продолжать развивать, выстраивая индивидуальные траектории.

Расписывая дела, вы найдёте подходящий уровень детализации. Углубляться до небольших задач — явно избыточно, но и не стоит останавливаться на крупных блоках работ. Иначе в дальнейшем будет сложно определить достаточные индикаторы того, что работа выполнена как надо.

Проверяем

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

Распределяем по шкале

Теперь переносим дела из карты в матрицу. Технически матрица — это таблица, в которой списку профессиональных (хард скиллов) и гибких, социальных (софт скиллов) навыков соответствует некоторая оценка. Степень детализации оценки может отличаться. Самый простой способ оценки — двоичная система «владеет / не владеет». Для гибких навыков такая система вполне подойдёт, особенно на первое время: умеет ли сотрудник работать в команде, организовывать рабочее время, имеет ли лидерские задатки и т. п. Можно однозначно ответить, если понаблюдать за ним какое-то время.

Но двоичным способом трудно объективно оценить профессиональные компетенции: насколько хорошо разработчик пишет код, а тестировщик тестирует сборки. Поэтому имеет смысл усложнить систему оценки до нескольких ступеней: начальная (или базовая), средняя, продвинутая и (опционально) экспертная. Чтобы модель получилась валидной, для каждого уровня нужно прописать понятные и измеримые индикаторы. Лучше, если их будет 2–4. Удобнее всего описать их на примере реальных рабочих задач, а затем также проверить на фокус-группе. В результате получится следующее:

Фрагмент матрицы компетенций QA-инженера<br>
Фрагмент матрицы компетенций QA-инженера

Общий принцип подбора индикаторов такой: на базовом уровне человек умеет решать простые задачи с учётом ограничения на ошибки. На среднем уровне — справляется с задачами разной сложности. На продвинутом — уверенно решает сложные и нетривиальные задачи, может адаптировать свои умения к незнакомым ситуациям. Индикаторы экспертного уровня указывают на способность человека решать кризисные задачи, развивать рабочие процессы и обучать других.

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

Задаём систему соответствия

Компетенции описаны и распределены по уровням владения. Но как понять, какой набор должен быть у начинающего специалиста, какой — у среднего, а какой — у старшего?

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

Фрагмент таблицы референсных значений для оценки компетенций iOS-разработчиков<br>
Фрагмент таблицы референсных значений для оценки компетенций iOS-разработчиков

Дальше с помощью матрицы мы оценим квалификацию сотрудников и сравним с желаемыми профилями. Будет видно, насколько реальное состояние соответствует желаемому и каких компетенций объективно не хватает, будем искать способы устранить этот разрыв.

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

Стоит ли ориентироваться на готовые матрицы или правильнее собрать свои

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

А если сотрудник выполняет непрофильные задачи

Допустим, рекрутер организовывает корпоративные праздники или ведёт социальные сети компании. Вносить эти дела в матрицу компетенций рекрутера, разумеется, не стоит. Странно всерьёз грейдировать непрофильные навыки сотрудника, если он помогает закрывать задачи, где ещё не накопилось работы для отдельного специалиста. Но как дополнительная нагрузка это достаточный повод для поощрения.

Другое дело, если рекрутер всерьёз рассматривает развитие в области коммуникации и у компании есть такая потребность. Если лучшим вариантом кажется перепрофилировать имеющегося сотрудника, а не нанять отдельного, тогда полезно составить представление о компетенциях SMM-специалиста или ивент-менеджера. Нужно будет постепенно сокращать рекрутерские задачи, увеличивая объём коммуникативных. И дальше также собирать список дел и ожидаемых результатов, постепенно прорабатывая матрицу.

Подытожим.

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

Чем больше развита практика, скажем, мобильной разработки — с проектами разной величины и сложности, с большим штатом сотрудников разной квалификации, — тем с более сложной матрицей она работает. И наоборот, если направление появилось недавно, требования к нему складываются постепенно, и постепенно же, через наблюдение, рефлексию и обратную связь собирается и усложняется матрица.

Будьте готовы к тому, что пройти описанные выше шаги непросто и небыстро. Здесь достаточно места для трудностей и спорных моментов. Вряд ли получится делегировать эту работу экспертам со стороны и в конце получить удобный инструмент. А пригласить специалистов по составлению матриц, которые проведут руководителей и HR-специалистов по процессу от начала до конца и закроют имеющиеся вопросы — вполне рабочая идея.

Больше о том, как организовать работу команд, в телеграм-канале «Не мешайте людям работать».

Чтобы получить пробную консультацию по прокачке ваших ИТ-команд, пишите Паше Бунтману из Verno.

Авторы текста: Анастасия Зальцман, Артур Сахаров. Редактор: Татьяна Павлова. Автор иллюстраций: Дарья Щеголютина.

Наша рассылка
В ней только самое важное: новости, кейсы, немного аналитики. Присылаем два раза в месяц.
Политика обработки персональных данных
По вопросам работы с персональными данными и подписками пишите на [email protected]
© red_mad_robot, 2008— 
Сделано роботами для людей
Разработка —