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

Как устроена матрица: роли, навыки, уровни

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

Уровни чаще всего называют привычно: Junior, Middle, Senior, Lead. Под ними удобно держать модель братьев Дрейфус 1980 года, где пять ступеней — от новичка, который действует по инструкции, до эксперта, который видит ситуацию целиком.

Хорошая ячейка описывает поведение, а не знание. «Знает SQL» проверить нельзя. «Пишет запросы с JOIN и индексами, читает EXPLAIN» — можно.

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

Пример строк для PHP-бэкендера

Чтобы было понятно, о какой детализации речь, вот несколько строк, которые встречаются почти в любой матрице бэкенд-разработчика.

• PHP 8: типизация, исключения, пространства имён.
• Фреймворк: Laravel или Symfony, жизненный цикл запроса.
• Базы данных: SQL, индексы, транзакции, миграции.
• Тестирование: PHPUnit, моки, покрытие критичных сценариев.
• Инфраструктура: Git, Docker, понимание CI.
• Работа в команде: код-ревью, оценка задач, общение с QA.

Строки для QA и проджектов

У тестировщика в матрицу обычно входят техники тест-дизайна, например классы эквивалентности и граничные значения, работа с Postman и API, автотесты на Playwright или Selenium, умение завести понятный баг-репорт.

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

Матрица, грейды и ИПР: в чём разница

Эти три инструмента часто путают, хотя отвечают они на разные вопросы. Я свёл их в таблицу.

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

Почему рост начался без грейдов

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

Как проводить оценку по матрице

Оценку удобно делать в два шага. Сначала сотрудник сам отмечает свой уровень по каждой строке, потом техлид делает то же независимо. На встрече обсуждают только расхождения, а их обычно 3–5, а не 40.

К каждой отметке «умеет» полезно приложить пример: задачу, пул-реквест, инцидент. Тогда разговор о повышении идёт по фактам, и мне как руководителю проще объяснить решение и тем, кого повысили, и тем, кого пока нет.

Как часто пересматривать уровни

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

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

Начинать стоит с одной роли, где больше всего людей. Пошагово это выглядит так.

• Собрать 2–3 сильных специалистов роли и техлида.
• Выписать задачи, которые команда реально делает за полгода.
• Сгруппировать их в 8–15 навыков, не больше.
• Для каждого навыка описать 3–4 уровня через наблюдаемое поведение.
• Проверить таблицу на двух-трёх сотрудниках разного уровня.
• Пересматривать раз в полгода, когда меняется стек.

Где взять образцы компетенций

Известный открытый образец — Programmer Competency Matrix Сиджина Джозефа. Она устарела по стеку, но хорошо показывает принцип описания уровней. Ещё полезно посмотреть на требования в вакансиях hh.ru для своей роли: они показывают, что рынок ждёт от миддла и сеньора.

Типичные ошибки при внедрении

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

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

Отдельная проблема — оценка по матрице без обратной связи. Если сотрудник узнаёт итог в письме от HR, а не на разговоре с техлидом, таблица воспринимается как экзамен. Тогда люди начинают прятать слабые места вместо того, чтобы их закрывать.

Что я хочу узнать у читателей

Мы готовим серию материалов и собираемся опубликовать наши матрицы для PHP, React, QA и проджектов. Мне интересно, какие проблемы вы встречали при составлении, что останавливает от внедрения и как выглядят ваши таблицы. Тех, кто пришлёт свои, я отмечу ссылкой в будущей статье.