Как составить матрицу знаний

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

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

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

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

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

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

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

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

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

Посмотрите мгновенный отчет о резюме на Indeed

Получите рекомендации для своего резюме за считанные минуты

Что такое матрица навыков?

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

Преимущества использования матрицы навыков

Существует несколько ключевых преимуществ использования матрицы навыков:

Позволяет членам команды узнать о своих навыках

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

Определяет ожидания

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

Легко указывает, где требуются новые сотрудники

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

Выделяет области в организации, которые необходимо развивать

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

Как составить матрицу навыков

Ниже описаны шаги, которые вы можете предпринять для создания матрицы навыков для вашей команды:

1. Определение навыков, необходимых для выполнения проекта

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

2. Оцените текущий уровень навыков каждого члена команды

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

• Отсутствие компетентности Опыт

• Общий уровень компетентности и опыта

• Промежуточный уровень компетенции-опыт

• Продвинутый уровень компетенцииопыт

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

3. Оцените уровень заинтересованности каждого члена команды в том или ином навыке

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

4. Используйте информацию из матрицы навыков для определения недостающих навыков

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

Пример матрицы навыков

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

Уровень компетентности:

1. Нет опыта компетентности

2. Общий уровень компетентности опыт

3. Промежуточный уровень компетентностиОпыт

4. Продвинутый уровень компетенцииОпыт

Уровни заинтересованности:

1. Не заинтересован

2. Заинтересованные

Член команды Анализ данных Управление проектами Маркетинг Обслуживание клиентов Компьютерные системы Иоланда 42 21 32 32 21 Шарон 22 32 11 32 42 Анвар 21 32 22 21 32 Крис 21 32 32 21 42 Томаш 32 21 21 21 32 31

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

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

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

Контекст: Продакт-оунер в Управлении разработки в Контуре отвечает за создание программного продукта (или его части) и максимизацию ценности продукта для конечного пользователя. Обычно в его обязанности не выходит клиентский опыт (в 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. Изготовление стула и понимание компетенций — что общего?
• Телеграм-канал «Экопси» о профессиональном развитии
• Телеграм-канал Анны Донской об оценке персонала

Всем привет!

Меня зовут Иван Антипин, я заместитель технического директора AGIMA. На рынке сложилась тяжелая ситуация: многие компании закрываются, а сработанные и крепкие команды распадаются под давлением обстоятельств. В этой статье расскажу об инструменте управления рисками — о матрице компетенций. Этот подход помогает распределять задачи с учетом балансировки нагрузки, избегать выгорания и неожиданной потери ключевых компетенций в команде. Текст написан на основе нашего с GeekBrains курса для тимлидов, по материалам лекции Ивана Михеева.

Управлять компетенциями важно

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

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

Все эти ситуации неприятные, но есть хорошая новость. Справится с ними простой инструмент — матрица компетенций.

Что такое матрица компетенций

Это таблица с ролями и навыками, важными для командной цели. Примерно такая:

Цифры в таблице показывают, насколько хорошо у сотрудников развиты нужные компетенции. Это могут быть как Hard Skills, так и Soft Skills. Выглядеть таблица может как угодно. Иногда ее оформляют в виде диаграммы, чтобы увидеть, какая компетенция выделяется в команде, а какую нужно подтянуть. Выглядит это вот так:

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

Как оценивать навыки

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

На нем мы видим 4 сектора. Каждый обозначает отдельный этап познания:

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

Эта модель поможет оценить знания и навыки сотрудников. Самый простой подход — взять числа от 0 до 3 и присвоить каждой стадии. Тогда получится, что неосознанное незнание — это 0, а неосознанное знание — 3. Но можно использовать и другие диапазоны: например, от 0 до 10 — незнание, от 10 до 20 — знание и т. п. Главное, чтобы шкала подчинялась одной логике и правилам для всех.

Как составить матрицу

Работа над матрицей состоит из 3 этапов. На каждом свои особенности и нюансы.

I этап. Выделить необходимые навыки.

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

• по технологиям (фреймворки, базы данных и т. п.);
• по подходам (паттерны проектирования и т. п.);
• по ролям в команде (Frontend, Backend, тестирование и т. п.);
• по классам решаемых задач (SQL для питониста).

Важно, чтобы каждый навык был не просто задекларирован, но и детально описан. Что он в себя включает? Какие критерии вы учитываете? Как будете оценивать? Ответы на эти вопросы нужно зафиксировать.

II этап. Оценить каждого сотрудника.

К этому процессу есть несколько подходов.

• Оценка 360. Каждый, кто взаимодействует с сотрудником, делится мнением о том, насколько хорошо тот владеет навыками из списка. Опрос можно проводить письменно и устно. Удобно делать это через Google-форму. Чем больше людей опросите, тем более объективной будет оценка. Но учитывайте, что очень профессионального, но грубого человека оценят почти наверняка ниже, чем он заслуживает. Поэтому лучше использовать этот инструмент для оценки Soft Skills.
• Тестирование. Вы составляете вопросы и предлагаете человеку ответить. Вопросы должны быть корректными и правильными — отражать потребности проекта. Ваша задача — объективно оценить именно навыки, нужные для конкретных задач, а не познания в PHP.
• Самооценка. Вы предлагаете сотрудникам самим поставить себе баллы по важным компетенциям. Шкалу можно определить самостоятельно — главное, чтобы для всех она была одинаковой. Здесь нужно учесть нюансы: есть люди, которые завышают себе оценки, а есть те, кто не может побороть синдром самозванца и оценки занижает. Поэтому разумно попросить наставников или более опытных коллег эти оценки проверить. Это может стать отдельным способом оценить команду.
• Оценка наставников. Кураторы и наставники оценивают менее опытных членов команды по шкале, которую вы для них зададите. Из их мнения складывается матрица.

III этап. Актуализировать матрицу.

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

• у вас открывается новое направление;
• у вас расширяется команда;
• вы начинаете использовать новый стек;
• вы запускаете новый продукт;
• у вас появляется еще одна команда.

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

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

Как применять матрицу

Матрица компетенций в первую очередь помогает принимать управленческие решения. Рассмотрим на примере. У нас матрица на троих человек и четыре навыка. Кто из них самый эффективный?

Ответ можем получить просто просуммировав баллы. Тогда выходит, что Михаил эффективнее всех. Но на самом деле суммирование не имеет смысла. Важнее понимать, на каком участке сотрудник должен быть эффективным.

Если мы разделим навыки на классы задач, которые решает сотрудник, то выясним, что Иван более эффективен во Frontend-задачах, а Михал — в Backend-задачах. А общая сумма не важна. Больше значения имеет, насколько они хороши в задачах, которые решают каждый день.

Чтобы сотрудники понимали свой уровень, можно положить матрицу в основу грейдирования. Если по классу задач минимальная оценка сотрудника — двойка, то он Middle-разработчик. Если тройка — то Senior. Тогда матрица приобретет привычный вид. А еще будет проще понять, кто и в каком стеке у вас Senior, кто Middle, а кому нужно освоить какие-то технологии, которые пригодятся ему в будущем.

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

Как с помощью матрицы распределять ресурсы

Ситуация: ваш бизнес-заказчик открывает новое направление. Теперь вам нужно быстро подготовить инфраструктуру и нанять 2 новых сотрудников. Это проблема: поставить новичков в изолированную команду на изолированный модуль нельзя. Они не знают правила работы, не знакомы с инфраструктурой и не понимают ваш код-стайл. Скорее всего, придется выделить одного разработчика из действующей команды. Как это сделать, не навредив налаженному процессу?

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

Тогда вы увидите, что забирать сотрудника из команды № 4 нельзя — по ним это ударит сильнее всего. А вот забрать из команды № 3 можно — это несильно повлияет на средний уровень навыка, команда не так сильно потеряет в качестве и скорости.

Матрица поможет и с Bus-фактором. Часто в команде главные компетенции сосредоточены в руках одного-двух человек. Эти люди знают, как все устроено на проекте и где что лежит. Если они уйдут, то утащат весь багаж знаний с собой. Восстановить баланс будет сложно. Чтобы этого не произошло, с помощью матрицы можно обнаружить и устранить узкие места.

Допустим, для проекта важны 3 навыка: Angular, React и Vue. У вас 4 разработчика, которые разбираются в этих темах на разном уровне. Матрица показывает, что Angular — ваше узкое место.

Это значит, что вам не очень выгодно вести разработку на Angular. Но если у вас уже есть код и компоненты, которые на нем разработаны, то стоит задуматься, как расширить эту экспертизу и кому передать знания. Матрица показывает, что ближе всего к этому разработчик № 4 — его и стоит обучить.

Как сбалансировать навыки в команде

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

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

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

Чем полезна матрица компетенций

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

1. Контролировать уровень знаний в команде.
2. Распределять ресурсы эффективно и безболезненно для остальных команд.
3. Мотивировать сотрудников и планировать их развитие (составлять индивидуальные планы развития, планировать KPI).
4. Распределять ресурсы эффективно и безболезненно для остальных команд.
5. Снижать риски потери знаний, если они сосредоточены у одного человека.
6. Заложить основу для разработки грейдов или валидировать их объективность и актуальность.

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

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

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