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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подытожим.

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

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

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

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

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