Как матрица компетенций позволяет нам не страдать от кадрового голода

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

Всем привет! Я — Елизавета Соловьёва, HR BP.
Мало найти подходящего специалиста в IT-компанию. Важно удержать его, показать перспективу развития как в профессии, так и в карьере.

Для этого нужны какие-то метрики, которые покажут, что hard skills и soft skills сотрудника соответствуют очередному грейду в линейке junior-middle-senior-teamlead-CTO, что можно брать на себя руководство проектной командной или всей технической составляющей бизнес-юнита. Поэтому мы внедрили в работу матрицу компетенций.

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

Компания QSOFT делает собственный продукт TEAMLY — платформу для совместной работы и управления знаниями. И одновременно занимается заказной разработкой и работает над множеством проектов.

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

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

Тимлид поддерживает и внешние коммуникации команды — взаимодействует с техлидом и даже CTO (chief technical officer или, по-русски, технический директор) по производственным вопросам, часто имеет выход на внешнего заказчика.

Итак, в хорошей проектной команде соблюдаются следующие основные тезисы:

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

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

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

Например, Марго из нашего проекта TEAMLY поделилась своим прошлым опытом: Как матрица компетенций помогла мне не перепутать собственных сотрудников. Такой подход имеет право на существование, но нам он неудобен по некоторым причинам — например, у нас существенно больше сотрудников. Зато в статье просто прекрасная пошаговая инструкция.

Поэтому мы вышли на чуть более высокий уровень абстракции и вывели для себя следующую базовую структуру матрицы компетенций (МК).

Начнём сверху — с заголовка.

Матрица компетенций составляется на каждую должность. Разработчиков на разных языках у нас несколько: PHP, Python, C#, JavaScript и т.д. Столько же МК разработчиков. Многие строки в них совпадают, но есть и специфичные для каждого языка позиции — синтаксис языка и владение его фишками, фреймворки, другие специфичные штуки.

Переходим к таблице.

У неё довольно простая структура — в столбцах грейды специалиста, в строках — навыки и уровень их прокачки на каждый грейд. Но строки неоднородны. На верхнем уровне фигурирует объединяющий навык. Во вложенных строках расписаны конкретные технологии. Если для позиции неважно, какой именно технологией должен владеть сотрудник, то заполнение уровней во вложенных строках избыточно — как, например, для навыка «Авторизация».

Навык «Базы данных» сложнее. Во вложенных строках не просто разные продукты, как в «Авторизации», но и отдельно выделен навык «Репликация DB», владение которым не зависит от конкретной среды. То есть, сеньору нужно до тонкостей знать MySQL, владеть на начальном уровне Постгри или Монго, но нужно уметь делать репликацию.

Логично, что QSOFT ведет базу знаний на платформе собственной разработки — TEAMLY. И что матрицы компетенций доступны всем заинтересованным лицам в корпоративной БЗ.

Чтобы сделать МК на платформе TEAMLY, нужно создать новую умную таблицу в одном из Пространств. Пространство — это аналог папки.

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

Есть ещё:

Каждый строка в Умной таблице — это самостоятельная страница, которая открывается по клику на Заголовок. Для её просмотра, дополнения и редактирования не нужно куда-то переходить — вся работа проходит в одном окне.

Здесь можно писать полноценные статьи, прикреплять материалы и фиксировать параметры компетенций. Для примера взят текст из Вики.

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

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

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

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

Итак, МК начинает работать с этапа вакансии. Да, мы не вставляем её полностью в объявление на hh — её использует рекрутёр при беседе с кандидатом. Но мы можем перечислить основные скилы, показать МК или её часть претенденту.

Во-первых, ему важно сразу понятно, чего от него ждут. Во-вторых, он может оценить себя — может быть он будет сразу на мидла претендовать, минуя джуна. Ну а мидлы и сеньоры при трудоустройстве понимают, какие навыки им нужно подтянуть, чтобы быть в привычном грейде и, главное, иметь чёткий профессиональный трек. Конкретные сроки, в которые будут достигнуты новые уровни и получен новый грейд, каждый новичок обсуждает с тимлидом one-to-one уже после онбординга. В результате получается индивидуальный план развития (ИПР) сотрудника.

Что этот документ даёт сотруднику?

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

Чем ещё поможет сотруднику индивидуальный план развития:

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

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

Опросы, которые мы проводим среди сотрудников каждые полгода, показали рост индекса удовлетворённости сотрудников (eNPS — Employee Net Promoter Score) по мере внедрения МК и составления ИПР.

Сотрудник с МК доволен. А что же эйчар?

Не растекаясь мыслью по древу приведу список того, чем лично мне помогает МК

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

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

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

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

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