Меня зовут Иван Ярославцев, я руководитель Alto. Мы разрабатываем сайты, интернет‑магазины, веб‑сервисы на заказ. В статье собрал всю необходимую информацию — от создания матрицы до ее внедрения. Здесь есть пошаговые инструкции, понятные объяснения и полезные советы. На примере нашей компании покажу, что матрица‑компетенций — это простой инструмент. Начать работать с ним можно прямо сейчас, для этого не нужно 100+ часов.

Матрица-компетенций — это важно

Осознание, что нужна матрица компетенций пришло не сразу. Я столкнулся с этим, когда разработчиков стало пятеро. Началось все с вопросов: «Куда расти дальше?», «Как вырасти в грейде и зарплате?». Без матрицы‑компетенций приходилось каждый раз составлять план развития, прописывать навыки для каждого члена команды. Через несколько месяцев появлялись новые вопросы: «Какие навыки обсуждали?», «Какие освоены?», «Как это проверить?».

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

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

Создаем матрицу компетенций

Шаг 1. Соберите информацию

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

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

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

Шаг 2. Сгруппируйте компетенции

Развитие компетенций становится более конкретным и легким, когда они визуализированы. На первом этапе подойдут google‑таблицы. Быстрее инструмента для структурирования информации вы не найдете. На каждом отдельном листе сделайте специализацию: frontend, backend и т. д. если у вас в одной должности несколько направлений, то выделить общую часть «JS+HTML» и отдельно «React» и «Vue».

Теперь на каждом листе выделите разделы и компетенции. Например, разделами могут быть — «ООП», «Особенности языка», «Работа сервера».

Напротив каждого пункта, отметьте грейд: Junior. Middle, Senior. Набор грейдов зависит от команды и бонусов, которые он дает.

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

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

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

В итоге вот, что мы оставили у себя:

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

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

• Также оставляем возможность пересмотр зарплаты, если есть хорошая обратная связь от менеджеров и QA‑специалистов.

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

Внедряем матрицу-компетенций

Шаг 3. Проведите оценку

Теперь вам предстоит оценить ваших сотрудников, по полученному списку компетенций. Например, в Alto мы используем следующую систему оценки:

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

• Задать общие вопросы. Проверить сможет ли рассказать теорию.

• Попросить рассказать решение какого‑нибудь кейса.

• Задайте уточняющие вопросы, если кажется, что где‑то есть пробелы.

• Попросить подкрепить примером с проекта — это снимет большинство вопросов.

Всю информацию стараемся выписывать сразу в матрицу. Так легче проверять. Это ощутимо снижает когнитивную нагрузку с проверяющего.

Шаг 4. Проверьте новые компетенции

Если погрузится в теорию обучения, то есть несколько способов проверки знаний:

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

• Рассказать теорию ответить на вопросы. Например, рассказать что такое принципы ООП и почему его поддержание на проекте важно.

• Артефакты из практики. Например, просим рассказать на каком из проектов применяли SOLID и как решили.

• Сдача онлайн‑тестов. У коллег есть необычное решение с телеграм‑ботом.

Все, что можно сдать без участия тимлида — нужно сдавать асинхронно. Помечайте их с детализацией, что нужно подготовить. Например, для Junior‑тестировщиков это может быть: «Подготовить скриншоты, где будут показано, что они умеют делать запросы с JOIN и GROUP BY».

Шаг 5. Проверьте компетенции на практике

Пожалуй, самый сложный этап. Одно дело, когда речь про тестирование навыков базовых запросов SQL. Совсем другое, когда нужно убедиться, что специалист правда умеет использовать RabbitMQ. А еще бывает, что нужна компетенция или технология, которую еще не используем, но она будет нужна клиентам.

Как мы это решили у себя. Прежде всего компетенции подбираем с учетом планов по проекту на котором специалист работает. Если же проекта нет, то разворачиваем демо‑проект, где специалист решает типовые задачи. После чего делаем пометку: «знает теорию и базовую практику». Это значит, что теперь ему можно доверить проект под присмотром опытного программиста.

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

Например, в прошлом году так было с Flutter. Когда один из PHP‑разработчиков захотел перейти на флаттер. Сначала собрали один проект для себя. Проверили знания на практике. Только после этого предложили одному из наших клиентов разработку мобильного приложения на Flutter.

Шаг 6. Поддерживайте актуальность

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

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

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

В итоге

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

• PHP с ветвлением на Laravel и Битрикс.

• Frontend‑React.

• Project‑Manager.

• QA‑Manual.

• Тимлиды разработки.

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

У вас уже есть опыт создания матрицы‑компетенций? Расскажите, с какими трудностями вы сталкивались. Поделитесь своей историей и мнением в комментариях или напишите мне в телеграм, организуем интервью.