Привет! На связи снова стрим Люди+. И мы продолжаем рассказывать про то, как составлять матрицы компетенций. В первой части мы рассказали, что такое матрица компетенций и зачем она нужна, а также про наш меню-подход и почему мы к нему пришли.

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

Этапы разработки матрицы компетенций

Итак, вы решились делать матрицы компетенций. Обосновали и согласовали проект со всеми стейкхолдорами. С чего же начать?

0 этап. Рабочая группа

Рабочую группу лучше разбить на 3 категории:

• эксперты, которые будут составлять матрицу;

• эксперты-оценщики, которые посмотрят и почелленджат готовый вариант;

• пилотная группа.

Эксперты — это синьоры и выше. 3-4 человека. Так вы сможете разделить объем работы и коллегиально решить спорные вопросы. Если вы составляете матрицу для специальности, которая есть в нескольких департаментах/командах, то лучше брать экспертов из разных команд. Это позволит вам создать оптимальную матрицу с учетом различий в подходах разных команд. Не собирайте всех-всех, оставьте кого-то для ревью.

Эксперты-оценщики — уже более разнородная группа, в которую могут входить:

• эксперты, которые не участвовали в написании матрицы, чтобы оценить технические аспекты работы. Они обеспечивают техническую глубину и точность при оценке хардовых компетенций;

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

• HR специалисты, которые обладают информацией о текущих и потенциальных сотрудниках, их карьерных планах и обучении. Они помогают собрать данные о существующих сотрудниках и потребностях компании в новых навыках.

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

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

Если у вас в компании есть владелец профессии, поздравляем! Идите смело к нему и просите помочь. Если owner — вы, то тоже поздравляем! Вас ждет увлекательный квест, но не делайте все в одиночку, привлекайте коллег.

I этап. Выделить необходимые навыки

Для начала дадим определения, чтобы быть в одном поле.

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

Компетенция — это набор навыков, которые нужны для выполнения задачи/цели. Компетенция уже содержит в себе навыки. Сотрудник себя оценивает исключительно по навыкам, не компетенциям.

Домен — это верхнеуровневое объединение группы компетенций.

Посмотрите на пример ниже. В нем отображены все виды, которые были описаны:

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

Выделять можно по нескольким критериям:

• по технологиям (например, фреймворки, базы данных);

• по подходам (например, паттерны проектирования);

• по ролям в команде (например, Frontend, Backend, тестирование);

• по классам решаемых задач (SQL для питониста).

Разделите навыки на общие (например, общие навыки разработки, используемые в разных языках программирования) и узконаправленные (например, навыки Kotlin). Если в организации матрицы уже есть или создаются параллельно, то не дублируйте общие навыки, а постарайтесь их переиспользовать.

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

Мы не рекомендуем сильно углубляться в уровни компетенций и разбивать навыки на совсем мелкие знания. Будет сложно описывать в дальнейшем. Сами стараемся придерживаться правила - не более 4х уровней (домен, родительская компетенция, дочерняя компетенция, навык). На этом этапе может хотеться много разного описать. Запишите пока в комментарии, включите в описания навыков на следующем этапе.

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

II этап. Описать выбранные навыки

Перед тем, как описывать навыки вам необходимо определить уровни владения компетенциями. У нас их пять:

• Не владеет — пока не приходилось сталкиваться с этим навыком в реальных задачах или в теории;

• Начинающий — начинает изучать тему/область/инструмент, но еще не было возможности применить на практике или применялось очень мало/точечно, нужна консультация/помощь коллег. Возможно применял в pet-проекте;

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

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

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

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

Пример таблицы для составления матрицы:

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

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

• Делать описания через поведенческие паттерны (знает, умеет, применяет и проч.) и задачи, которые сотрудник выполняет;

• Делать описания максимально конкретными и не использовать стандартные описания, как те, что приведены выше. Все, что может быть понято двояко, вызовет вопросы и недопонимания во время оценки.

Пример хорошего описания навыка (для удобства чтения представим таблицу в виде списка):

Пример плохого описания навыка:

Это самая трудозатратная часть проекта. Держитесь!

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

III этап. Оценка матрицы

Итак, вы сделали все описания. Самое время подключить к работе ревьюеров и отправить им готовую матрицу.

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

Что важно обсудить в ходе ревью:

1. Логика разделения на навыки и компетенции;

2. Достаточность навыков в матрице (нужно ли что-то дополнить, убрать и схлопнуть);

3. Описания навыков и разбивку по уровням;

4. Рекомендованные уровни владения навыками;

5. Ключевые навыки, если вы используете меню-подход.

IV этап. Протестировать матрицу на пилотной группе

К этому этапу есть два подхода.

Селф-ревью. Сотрудник оценивает свои компетенции по выбранной специальности. Специальность состоит из скоупа навыков, которые мы прописывали в матрице компетенций. Помимо самого сотрудника, в селф-ревью также участвует его руководитель, который на финальном этапе верифицирует ответы. Это сделано для того, чтобы руководитель смог приблизить оценку к объективной, так как сотрудники часто имеют склонность к занижению оценки своих навыков (О да, наш опыт показывает, что чаще люди недооценивают себя, чем переоценивают!).

Ревью. Другими словами, оценка 360 или 180. Каждый, кто взаимодействует с сотрудником, делится мнением о том, насколько хорошо тот владеет навыками из списка. Приглашать можно как коллег из своей команды или проектной команды, так и коллег из профильного сообщества. В этом виде ревью сотрудник не проходит самооценку.

Пилотная группа должна состоять как минимум из 3-5 человек разного уровня владения специальностью. Так вы сможете собрать достаточную обратную связь.

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

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

1. Сколько времени заняла оценка? Было ли это сложно и/или непонятно?

2. Описание каких навыков вызвало затруднение или недопонимание?

3. Есть ли навыки, которые можно схлопнуть в один или сократить для более эффективной оценки?

4. Каких навыков/компетенций не хватило для более полной оценки?

5. Понятна ли логика разделения на компетенции и навыки? Все ли навыки сидят в нужных компетенциях?

6. Какие еще комментарии может дать сотрудник по процессу оценки?

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

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

V этап. Отредактировать матрицу и добавить в общую библиотеку

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

Теперь вы можете проводить оценку. А вашей матрицей смогут пользоваться смежные команды с похожей специальностью.

Можете себя похвалить ? Вы сделали неоценимый вклад в развитие компетенций ваших коллег!

Когда нужно актуализировать матрицу компетенций?

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

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

• расширяется команда проекта;

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

• вы запускаете новый продукт;

• у вас появляется еще одна команда;

• появились обновления в технологии, которые вы планируете внедрять.

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

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

Заключение

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

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

Автор: Ксения Казакова, HR project manager.