Привет, Хабр!

Сегодня поговорим про матрицы компетенций, и как мы их внедряли в «Рексофт». Мы уже рассказывали про матрицу Android-программиста, и как мы вводили кросс-интервью при повышении грейда, а сегодня я расскажу, о том, как все начиналось, и куда мы пришли. Итак, поехали!

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

• внутренняя – сотрудники компании (готов ли человек к повышению грейда, готов ли он выполнять, например, роль Senior’а в том или ином проекте;

• внешняя – потенциальные сотрудники (когда мы берем человека «с рынка», нам тоже важно определить его грейд, чтобы понять, как он соотносится с людьми, которые уже на борту; как он будет вписываться по технологическому стеку, набору софт скиллов.

Как раньше давали грейд?

Грейд определялся успехами на проекте и личными достижениями, но ключевую роль играло мнение человека, который грейд «раздает»: руководитель практики, департамента. Конечно, это достаточно субъективная модель, но вполне рабочая, когда в компании или отделе примерно 15-20 человек: все друг друга знают, все хорошо представляют уровень подготовки и способности членов команды.

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

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

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

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

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

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

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

Как мы дошли до жизни такой?

Бывали случаи, когда на одной и той же должности, с идентичным графиком и уровнем загруженности были разные люди с ощутимой разницей в зарплате - один просто давно работает в компании и получил грейд по выслуге лет, а второй только-только пришел с рынка, при этом знает не меньше, а даже больше и более прогрессивные вещи. А в 2020 году, когда все ушли на «удаленку» из-за пандемии, люди начали хаотично менять работу, приходить, уходить и возвращаться обратно, появилась необходимость внести в этот хаос немного порядка, чтобы все объективно понимали, кто есть кто и почему. Стали нужны новые инструменты, т.к. встретиться в офисе, как раньше, и что-то обсудить мы уже не могли. Не было формального понимания и оценивания способностей сотрудников.

Как мы создавали нашу матрицу компетенций?

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

Что было дальше?

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

• зеленый – знает;

• синий – в процессе изучения;

• желтый – не знает.

Единственное, чего не хватало такой матрице, это учета софт-скиллов: например, у Senior в арсенале должно быть менторство, помощь «джунам», у тимлида – общение с командой, мотивация, стрессоустойчивость и т.д. Поэтому мы добавили в таблицу еще 3 направления, посвященных именно софт-скиллам:

• командная работа;

• умение работать с задачами (например, Scrum-техники);

• личные софт скиллы (например, креативность, стрессоустойчивость).

После того, как все сотрудники ее впервые заполнили, мы поняли: чем выше грейд, тем меньшее количество направлений сотрудник может поддерживать на этом уровне. Например, если мы говорим про Junior-разработчика, то он должен знать на базовом уровне каждое из направлений: писать на Java, знать основы веб-разработки и т.д. Но если у сотрудника уровень Senior, у него уже сформирована одна определенная направленность, т.к. держать высокий уровень во всех сферах практически невозможно. Обычно человек развивается в одном направлении, достигает больших высот, а все остальное находится на высоком уровне, но никак не идентичном основному.

Так у нас родилось понимание, как на самом деле должна заполняться матрица: на каждом новом грейде количество зеленых ячеек должно быть меньше, чем на предыдущем. Например, на уровне Junior все ячейки зеленые, на Middle –только 70 %, на Senior – из 10 направлений сотрудник должен иметь компетенции только в 4, например. Таким образом у нас появились эксперты по своим направлениям, и начала вырисовываться целая классификация:

• Т-образная матрица – верхний уровень полностью зеленый, максимально развито 1 направление (большинство рядовых сотрудников).

• П-образная матрица – верхний уровень полностью зеленый, максимально развиты 2 направления (будущие тимлиды и эксперты).

• М-образная матрица – верхний уровень полностью зеленый, максимально развиты 2 направления и 1 направление по середине изучено на среднем уровне (специалисты по архитектуре и экспертизе).

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

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

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

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

Матрицу всем!

Изначально мы делали матрицу для технарей и инженеров, но в итоге получился продукт, который необходим для любого отдела или департамента, так как везде есть свои направления, для которых характерны определенные инструменты, навыки и требования. При этом могут быть совпадения, например, по софт склиллам (например, что для Frontend-, что для Backend-разработчика). Но если выйти за рамки производства и перейти, например, в HR, естественно, набор скиллов там будет совсем другой, как и набор грейдов.

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

Что получили мы?

С внедрением матрицы компетенций в «Рексофт» у нас появилось множество новых возможностей – новые процессы, которые протекают уже не в рамках этого инструмента, а с его непосредственным использованием. Например, возьмем те же собеседования: теперь интервью проходит не просто по каким-то абстрактным задачкам и какому-то субъективному мнению об интервьюере, а по пунктам, которые прописаны в самой матрице в зависимости от грейда и направления. Так мы определяем, дотягивает ли кандидат до нашего понимания, например, джуна или Senior’а, или нет: HR выставляет баллы за ответы на вопросы, в результате по формуле мы получаем среднее значение, которое соответствует тому или иному грейду.

Второй процесс – когда сотрудник сам проявляет инициативу и хочет повысить свой грейд. В таком случае мы проводим внутреннее техническое собеседование (раньше такого не было), где в качестве интервьюера – сотрудник, который ранее не работал с кандидатом (из другого проекта, желательно, из другого города). Он задает вопросы и подтверждает в матрице кандидата те или иные пункты, или наоборот, если интервьюер видит, что кандидат не справляется. Таким образом, у нас никто не получает грейд по знакомству или «популярности» в компании. Все формально.

Третий процесс – индивидуальный план развития сотрудника. При его составлении мы вновь обращаемся к матрице, смотрим, какие у сотрудника сильные и слабые стороны, чего ему не хватает. При этом матрица как инструмент дает четкое описание того, что мы хотим: мы не пишем «подтянуть Java», а указываем конкретный фреймворк или другой сопутствующий инструмент. Здесь прозрачность матрицы компетенций работает в полном объеме: план развития строится так, чтобы он работал в рамках нашей компании, и чтобы сотрудник развивался четко по тем пунктам, которых ему действительно недостает.

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

Что дальше?

Технологически мы постоянно совершенствуем инструмент, прописываем новые правила и процессы. Например, мы отошли от модели закрашивать ячейки целиком. Каждая компетенция имеет свою стоимость в баллах (определяется сложностью и важностью), как и ячейка в целом. Если раньше ячейка закрашивалась, когда сотрудник знал 6 из 7 требуемых компетенций на пересечении, то сейчас достаточно знать только 3. Сам грейд определяется по сумме баллов: набрал нужное количество поинтов внутри строчки – получаешь Level Up!

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

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