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

Уровень сложности
Простой

Время на прочтение
6 мин

Количество просмотров 4.7K

Меня зовут Иван Ярославцев, я руководитель 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.

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

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

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

Рассказывает Verno, центр экспертизы red_mad_robot

Представим, что вопрос, зачем строить матрицу, перед вами уже не стоит. Компания (или подразделение) уже достаточно зрелая, чтобы осознать такие потребности:

Представим также, что матриц компетенции в компании нет и никогда не было — начинать нужно с нуля. Как это сделать?

Перечисляем работы

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

Для сотрудников производства удобнее расписывать дела в привязке к производственным этапам: от инициации проекта до выпуска готовои продукции. Для сотрудников сервисных подразделении — в привязке к этапам взаимодеиствия с их «клиентами». Так, работы HR-службы удобнее визуализировать на карте движения сотрудника (Employee Journey Map), которая захватывает путь от наима до выхода из компании. Можно также сверяться с регламентами и описаниями процессов, должностными инструкциями, паттернами поведения образцовых специалистов.

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

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

Проверяем

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

Распределяем по шкале

Теперь переносим дела из карты в матрицу. Технически матрица — это таблица, в которой списку профессиональных (хард скиллов) и гибких, социальных (софт скиллов) навыков соответствует некоторая оценка. Степень детализации оценки может отличаться. Самый простой способ оценки — двоичная система «владеет / не владеет». Для гибких навыков такая система вполне подойдёт, особенно на первое время: умеет ли сотрудник работать в команде, организовывать рабочее время, имеет ли лидерские задатки и т. п. Можно однозначно ответить, если понаблюдать за ним какое-то время.

Но двоичным способом трудно объективно оценить профессиональные компетенции: насколько хорошо разработчик пишет код, а тестировщик тестирует сборки. Поэтому имеет смысл усложнить систему оценки до нескольких ступеней: начальная (или базовая), средняя, продвинутая и (опционально) экспертная. Чтобы модель получилась валидной, для каждого уровня нужно прописать понятные и измеримые индикаторы. Лучше, если их будет 2–4. Удобнее всего описать их на примере реальных рабочих задач, а затем также проверить на фокус-группе. В результате получится следующее:

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

Также учитываем, что индикаторы компетенций не должны повторяться и пересекаться между собой. Если такое случилось, значит, вы слишком усложнили перечень компетенций — нужно его сократить, объединив близкие. Индикаторы — это «умеет», «может», «делает». «Знает» и «понимает» могут быть дополнительными индикаторами для начального уровня, но не основными. И тем более они не являются значимыми для среднего и продвинутого уровня, где ценится опыт решения разных задач.

Задаём систему соответствия

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

Для этого собираем желаемые профили позиций. Учитываем также, что в разных проектах (направлениях, подразделениях) одной компании требования к квалификации, скажем, продуктового дизайнера могу отличаться. Ориентируемся на имеющийся опыт управления командами, стратегию компании и рыночные показатели.

Дальше с помощью матрицы мы оценим квалификацию сотрудников и сравним с желаемыми профилями. Будет видно, насколько реальное состояние соответствует желаемому и каких компетенций объективно не хватает, будем искать способы устранить этот разрыв.

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

Стоит ли ориентироваться на готовые матрицы или правильнее собрать свои

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

А если сотрудник выполняет непрофильные задачи

Допустим, рекрутер организовывает корпоративные праздники или ведёт социальные сети компании. Вносить эти дела в матрицу компетенций рекрутера, разумеется, не стоит. Странно всерьёз грейдировать непрофильные навыки сотрудника, если он помогает закрывать задачи, где ещё не накопилось работы для отдельного специалиста. Но как дополнительная нагрузка это достаточный повод для поощрения.

Другое дело, если рекрутер всерьёз рассматривает развитие в области коммуникации и у компании есть такая потребность. Если лучшим вариантом кажется перепрофилировать имеющегося сотрудника, а не нанять отдельного, тогда полезно составить представление о компетенциях SMM-специалиста или ивент-менеджера. Нужно будет постепенно сокращать рекрутерские задачи, увеличивая объём коммуникативных. И дальше также собирать список дел и ожидаемых результатов, постепенно прорабатывая матрицу.

Подытожим.

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

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

Чтобы получить пробную консультацию по прокачке ваших ИТ-команд, пишите Паше Бунтману из Verno.

Авторы текста: Анастасия Зальцман, Артур Сахаров. Редактор: Татьяна Павлова. Автор иллюстраций: Дарья Щеголютина.

Вам будет интересно

Перейти на главную блога

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

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

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

Контекст: Продакт-оунер в Управлении разработки в Контуре отвечает за создание программного продукта (или его части) и максимизацию ценности продукта для конечного пользователя. Обычно в его обязанности не выходит клиентский опыт (в B2B-сервисах Контура разделяют пользователя и клиента), поиск новых рынков и маркетинг — эти задачи закрывают другие сотрудники. При этом выделенная роль продакт-оунера есть не в каждой команде — в основном только в крупных, технически сложных продуктах с множеством сценариев и разными целевыми аудиториями.

Примечание: продакт-оунер в Контуре — не роль из Scrum, а название должности, синоним менеджера продуктов.

Почему не подошли готовые модели

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

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

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

Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.

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

Модель компетенций можно формировать «сверху вниз» — командой топ-менеджеров и HR-ов, привлекая самих оцениваемых сотрудников в качестве экспертов. В Управлении разработки Контура используется обратный подход — матрица создается внутри отдела, для оценки которого предназначена, а стейкхолдеры сверху транслируют свои ожидания от роли продакт-оунера и самого инструмента (матрицы). 

Мы считаем путь «снизу вверх» более эффективным. И вот почему:

1. он позволяет создать более точный инструмент оценки; 
2. готовый инструмент проще внедрять, потому что сотрудники причастны к его созданию и настроены более лояльно.

Однако этот путь может показаться сложнее: нужно организовать командную работу экономно (с сотрудников не снимаются прямые задачи), а на выходе получить качественный инструмент, который не будет сделан небрежно или впопыхах.

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

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

Этапы создания матрицы компетенций

Этап 1. Кому и зачем нужна матрица

Мы начали с определения потребностей целевой аудитории — поштормили и составили список вопросов:

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

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

Кому и зачем нужна матрица компетенций (карта навыков):

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

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

Время на этап: 2 встречи рабочей группы по 1 часу + 10 интервью.

Этап 2. Что делает продакт-оунер

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

Помогают вопросы: 

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

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

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

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

Время на этап: 1-2 встречи каждой малой группы по 1 часу (у нас было 4 группы).

Этап 3. Что самое важное в работе продакт-оунера

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

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

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

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

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

Время на этап: 1 встреча малой группы на 1 час.

Этап 4. Как собрать и визуализировать матрицу

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

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

Время на этап: 1 встреча рабочей группы на 2 часа

Этап 5. Как описать каждую компетенцию

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

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

Теория. Существует несколько базовых способов оценки компетенций:

— вопросы в ходе оценочной беседы (проверяем знания);

— тестовый кейс (проверяем владением навыком);

— рабочие артефакты — расчеты экономики, результаты исследования и т.п. (более комплексная оценка поведения, а не локального навыка);

— обратная связь от руководителей и стейкхолдеров;

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

— оценка экспертом, ассессмент-центр.

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

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

Время на этап: индивидуальное «домашнее задание» + 1-2 встречи рабочей группы на 1 час.

Этап 6. Как протестировать модель и исправить недостатки

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

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

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

Получившийся список разделили на два TODO-листа: 

1. формулировки, которые необходимо исправить уже к ближайшей оценке — в этом списке оставили однозначные и недвусмысленные комментарии; 
2. формулировки, за практическим использование которых необходимо понаблюдать — для более сложных идей и замечаний.

Время на этап: 10 тестов по 1 часу + 1 встреча группы для обсуждения итогов и TODO-листа (1 час).

Этап 7. Как создать процесс постоянного обновления и улучшения матрицы

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

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

В первый год использования матрицы мы в основном уточняли формулировки — например, выявили и убрали пару компетенций с пересекающимися индикаторами. А в этом году мы уже созрели до того, чтобы увеличить количество уровней — трех классических (junior, middle, senior) нам оказалось недостаточно для описания всех ступеней развития продакт-оунера внутри компании.

Матрица компетенций — живая сущность, она должна меняться вместе с рынком, компанией и ожиданиями от роли продакт-оунера, поэтому еще в момент создания инструмента важно договориться о процессе рефакторинга: как и когда снимается обратная связь, как вносятся изменения.

Время на этап: 1 час работы группы после каждого периода оценки.

Что получилось: матрица компетенций продакт-оунера

В матрице 4 группы компетенций: работа над продуктом, исследования, управление и лидерство, софт-скиллы.

В блоке «Работа над продуктом» компетенции условно расположены в порядке работы над фичей/продуктом — от расчета экономической эффективности до оценки результата с помощью метрик.

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

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

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

Прямо сейчас у нас выделено 3 уровня развития компетенции:

Джун — знает теорию и применяет знания на уровне фичи, набора сценариев, подпродукта. Работает с наставником.

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

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

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

Компетенция: учитывает экономику продукта

Junior

• Знает бизнес-модель продукта. 
• Знает экономическую эффективность фич, над которыми работает.

Как проверить: 

• Может раскрыть эти вопросы применительно к своему продукту в ходе оценочной беседы.

Middle

Все индикаторы уровня «Junior», а также:

• Знает экономическую эффективность части продукта или целого продукта.
• Рассчитывает экономическую эффективность фич.
• Понимает точки роста и развития продукта.

Как проверить:

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

Senior

Все индикаторы уровня «Middle», а также:

• Понимает бизнес-модель направления или нескольких продуктов.
• Может рассчитать эффективность нескольких продуктов, межпродуктовых проектов.
• Может рассчитать эффективность новых проектов в продуктах.
• Способен определить точки роста и развития для целого бизнес-направления или большого сложного продукта.

Как проверить:

• Может раскрыть эти вопросы применительно к своему направлению.
• Обратная связь от руководителя направления.

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

Junior

• Знает разницу между качественными и количественными методами исследований. Умеет выбирать подходящий метод для определенного этапа работы над продуктом или задачей. Знает и пробует применять фреймворки (JTBD, CJM и т.п.). Для выбора метода прибегает к помощи наставника или специалиста по юзабилити.
• Знает, как сформировать выборку. Консультируется с наставником или специалистом по юзабилити.
• Фиксирует результаты исследования, используя рекомендации или наработки юзабилиста или советуется по поводу формы фиксации результатов с наставником.

Как проверить:

• Обсуждение рабочего или тестового кейсов.
• Уже имеет несколько завершенных исследований (5−10). Во время оценки можно обсудить артефакты исследований — материалы, выводы. Оценка артефактов исследования экспертом.

Middle

Индикаторы уровня «Junior», а также:

• Формулирует и фиксирует план исследования без наставника с адекватными сроками и последовательностью этапов. Умеет составлять многоэтапные исследования, способен наметить комплексно, верхнеуровнево цепочку исследований для решения задачи.
• Понимает, какими ресурсами можно провести исследование. Договаривается о ресурсах, распределяет работу.
• Сочетает качественные и количественные методы; использует в работе фреймворки. Может самостоятельно выбрать метод и аргументировать, почему именно этот метод подходит для конкретного исследования.
• Может сам выделить критерии для формирования целевой выборки, понимает и принимает решение, сколько респондентов нужно для проведения исследования.
• Собирает информацию о пользователях и их сценариях из разных источников. Сам выбирает форму фиксации результатов исследований, обеспечивает доступ команды к результатам.

Как проверить:

• Обсуждение рабочего или тестового кейса.
• Имеет 7−10 самостоятельно проведенных завершенных исследований с использованием не менее трех разных методов, участвовал минимум в 20 исследованиях. Оценка артефактов исследования экспертом.
• Обратная связь от команды.

Senior

Индикаторы уровня «Middle», а также:

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

Как проверить:

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

Что в итоге

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

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

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

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

Полезные материалы

Вдохновение: матрицы компетенций менеджеров продуктов от разных авторов

• Навыки менеджера продуктов от ProductSense
• Матрица компетенций как инструмент развития продуктовой команды (доклад Елизаветы Кондрашовой на ProductSense, доступен в подписке)
• Product Manager Skill Map, Сергей Тихомиров
• Компетенции продакт-менеджеров от Егора Руди (Profi.ru)
• Таблица оценки навыков и компетенций продакт-менеджера, Владимир Миролюбов
• Матрица продуктовых компетенций акселератора ФРИИ
• Таблица навыков продакта, Product Star
• Какие навыки нужны продакт-менеджеру, Валерия Розова
• Профстандарт «Менеджер продукта в области информационных технологий»: редакции 2014, 2021
• Organa. The PM Competency Framework
• Intercom: career path for product managers
• A competency-based model for the success of an entrepreneurial start-up
• Core Competency Deficits in Failed Startup Teams: Towards a Startup-specific Behavioral Competency Model

Теория: книги и статьи об оценке компетенций

• Лайл М. Спенсер, Сайн М. Спенсер. Компетенции на работе
• Understanding Competencies and Competency Modeling
• Doing Competencies Well. Personnel Psychology
• Экопси. Data Enabled Employee Profile
• Экопси. Центры оценки: теоретические основы и технологии работы.
• Экопси. Разработка профессиональных компетенций на основе анализа данных, вебинар
• ФРИИ. Диагностика продуктовых компетенций, вебинар
• E-executive. Изготовление стула и понимание компетенций — что общего?
• Телеграм-канал «Экопси» о профессиональном развитии
• Телеграм-канал Анны Донской об оценке персонала

Меня зовут Иван Ярославцев, я руководитель 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.

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

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

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