Что такое матрица компетенций
Применение матрицы и диаграммы компетенций
При росте команды тимлид и вышестоящее руководство начинают задумываться об оценке компетенций сотрудников. В рамках этой статьи я хочу рассказать о первых шагах по внедрению оценки сотрудников и какие бонусы вы можете получить.
Хорошим инструментом является матрица компетенций в связке с диаграммами компетенций.
Начнем с терминологии.
Термины
Матрица компетенций — это таблица с данными о наборе компетенций сотрудников. В ячейках таблицы стоит цифра, обозначающая степень владения компетенцией.
Диаграмма компетенций — это лепестковая диаграмма, которая визуализирует численные показатели компетенций сотрудников.
Классический подход
Матрица компетенций содержит перечень навыков, которые должен применять сотрудник в своей работе. При разработке первой матрицы компетенций у меня получилось около 200 компетенций, которые нужно оценить. Собирать данные о таком количестве данных довольно трудоемко. Поддерживать их в актуальном состоянии еще сложнее. У не смог себя заставить пользоваться таким инструментом.
При этом матрицы компетенций широко применяют во многих отраслях — от торговли, до промышленности. И применяют их очень успешно. Оказалось, что количество навыков в матрице компетенций в других сферах около 20 или даже меньше. Почему бы не уменьшить число компетенций и в нашей сферы.
Начало внедрения
Начать стоит с малого. И даже точностью на первых шагах мы можем пожертвовать.
Сбор данных
Оценку компетенций можно и нужно производить при собеседовании и найме сотрудников. Дополнительные оценки необходимо проводить и в процессе работы не реже одного раза в полгода. Это позволит отслеживать динамику развития.
Стоит добавить в матрицу цифру, которая отражает интерес сотрудника к развитию компетенции. Тогда вы сможете подбирать правильный проект для сотрудника и динамику интереса к различным технологиям у своих сотрудников.
По матрице компетенций отдельных сотрудников легко построить матрицу компетенций компании или отдельной команды.
Очень полезно строить матрицу компетенций проекта.
Анализ
Итак вы собрали данные. Пришло время получить хоть какую-то пользу.
Полученные матрицы дают такие возможности:
Bus-фактор
Предположим, что у вас 5 сотрудников и у вас получилась такая матрица:
Эта матрица дает возможность определить bus-фактор.
На данной матрице можно увидеть, что Golang применять в компании пока вряд ли стоит. Никто не хочет быть зависимым от одного единственного сотрудника.
Давайте взглянем на получившуюся диаграмму компетенций. Bus-фактор виден и здесь. Этот же сотрудник явный лидер в знаниях PHP. И казалось бы это хорошо. Ведь он может написать любой код. И это и правда так. Он даже сумел разобраться в асинхронном PHP. Но кто этот код потом сможет поддерживать?
Стоит его ограничить в применении нестандартных подходов или поставить ему задачу на обучение таким техникам других сотрудников. Но в асинхронный PHP ходить не стоит.
Определение уровня сотрудника и точек роста
Приходит к вам сотрудник dev2 требовать повышения зарплаты. Вам нужно определиться с объективностью его требований. Нужно добавить к матрице абстрактных сотрудников с компетенциями junior, middle frontend и middle backend.
На матрице сразу видно, что уровень джуна сотрудник прошел. Но до любого из мидлов он явно не дотягивает.
На диаграмме хорошо видно, что сотруднику логичнее развиваться в сторону фронтенда и понятны направления в которых необходимо развиваться сотруднику, чтобы получить повышение.
Подбор команды
Активный обмен знаниями происходит только в команде. Для адекватного общения в команде интересы сотрудников в команде должны значительно пересекаться. Сложно представить активный обмен знаниями чистого бэкендера и чистого фронтендера или мобильного разработчика и сисадмина.
В наличии 5 разработчиков. Нужно подобрать команду из 4 человек на проект. При этом необходимо обеспечить активный обмен знаниями внутри команды.
В матрице явно видно сильного бэкендера, 3-х фуллстеков и сильного фронтендера.
Сложно представить активный обмен знаниями между dev1 и остальной командой. У него слабо пересекаются знания и интересы с остальной командой. В областях пересечения знаний dev1 намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде.
У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.
Прямо таки явные перекосы в интересах. Хотя и есть совпадающие, но их явно меньше чем различающихся.
Однако я бы отдал предпочтение такой команде:
Точки роста для каждого из сотрудников тут тоже очевидны.
Подобным образом можно подбирать проект и команду друг к другу.
И это только самые простые применения матрицы и диаграммы компетенций.
Итак оценка компетенций начала приносить пользу компании. Но встал вопрос в повышении точности? Только в этот момент стоит усложнять матрицы. И даже при этом большая матрица должна свестись к маленькой матрице, а визуализации делать уже с маленькой матрицы.
Для удобного использования матриц, будет мало гуглодока. Если вы знаете подобного рода инструмент напишите об этом в комментариях. А то так и чешутся руки навелосипедить.
Как создать матрицу компетенций для успеха работы команды
Интернет-ресурс «Analytics in HR», февраль 2018 г.
Ерик Ван Вульпен, перевод В. Чемекова («Лучшие кадры»)
Представляем вашему вниманию перевод статьи о формировании команды на принципах компетентностного подхода. В его основе — Матрица компетенций (навыков), в основе которой два основных параметра: квалификация (в оригинале — proficiency) и заинтересованность ее применять — «интерес». Сама квалификация — функция двух составляющих: уровня навыков или знаний и уровня ответственности.
Статья может считаться примером применения компетентностного подхода при формировании команды для реализации проекта «на входе» в процесс в отличие от оценки команды «на выходе» из него, когда целесообразно оценивать и результаты, чтобы понимать, за счет каких компетенций успех был достигнут.
Представьте, что вы собираетесь реализовать свой первый проект HR-аналитики. Конечно вы хотите, чтобы проект был успешным. Но как вы убедитесь, что у вас есть правильные люди и правильные навыки, чтобы быстро начать и успешно закончить работу? И здесь Матрица компетенций или Матрица компетенций — ваш партнер.
Что такое Матрица компетенций (навыков)?
Матрица компетенций или Матрица компетенций, является инструментом для отображения требуемых навыков для команды или проекта. Она визуализирует необходимые и наличествующие навыки и компетенции в команде, что делает ее важным инструментом для любого кадрового специалиста, управляющего данными.
Заполненная Матрица компетенций визуализирует необходимые навыки, навыки, имеющиеся в команде, и навыки, которые в команде отсутствуют — разрыв в навыках.
Квалификация выражается парой чисел, где:
Х — Уровень навыков или знаний
Y — Уровень ответственности в применении навыков или знаний
Для чего используется Матрица компетенций (навыков)?
Перейдем к практическим аспектам. Для чего используется Матрица компетенций? Есть две главные цели.
Во-первых, Матрица компетенций помогает оценить необходимые команде навыки для реализации проекта или команды. Чтобы эффективно использовать Матрицу компетенций, необходимо рассмотреть навыки, необходимые для успешного выполнения задачи или проекта. Это поможет увидеть ключевые действия команды и определить соответствующие навыки или компетенции, необходимые для выполнения этих действий.
Во-вторых, Матрица компетенций дает представление о имеющихся у членов команды навыках. После выявления навыков, необходимых для проекта, следует оценить навыки членов команды.
Например, если проект HR-аналитики требует предприимчивости, IT-навыков, анализа данных и составления отчетности, то необходимо проверить, кто из членов команды их имеет.
Если необходимый навык отсутствует, вы можете нанять сотрудника с соответствующими навыками для добавления в команду. Если это сделать перед началом проекта, то это поможет обеспечить лучший результат. Если же вы делаете анализ навыков ретроспективно, значит, вы получите неудачный проект!
Преимущества Матрицы компетенций (навыков)
Матрица компетенций помогает управлять производительностью несколькими способами. Это выгодно не только команде, но и отдельным сотрудникам, организации, а возможно, и внутренним и внешним клиентам!
Команда: Матрица компетенций — это, прежде всего, инструмент, помогающий команде в целом. Коллектив получает представление как об имеющихся, так и об отсутствующих навыках. Недостающие навыки можно получить, нанимая людей с соответствующими компетенциями.
Кроме того, команда получает информацию о своих слабых сторонах и может позаботиться о том, чтобы отсутствующие навыки не мешали работе.
Индивид: Матрица компетенций помогает отдельным сотрудникам двумя путями.
Во-первых, она дает им понимание их компетентности, того, какой вклад они могут внести, и чего им не хватает. Это отличная отправная точка для их обучения и развития.
Во-вторых, сотрудник получает сведения о навыках, необходимых для успешной работы в команде. Это также показывает области, в которых он может преуспеть.
Организация: в более широком масштабе обзор имеющихся компетенций и зон развития получает организация. Это те области, в которые организация может инвестировать свой бюджет в обучение и развитие, чтобы лучше функционировать. Кроме того, Матрицы компетенций могут помочь перераспределить внутренние таланты на те позиции, где они наиболее востребованы.
Клиенты: конечные акционеры, заинтересованные стороны и потребители получают лучшее обслуживание. Неважно, будут ли это внутренние или внешние клиенты. Команды повысили осознанность о недостающих навыках, что помогает обойти подводные камни.
Преимущества Матрицы компетенций (навыков)
Этапы создания Матрицы компетенций (навыков)
Следующие шаги представляют собой путь создания Матрицы компетенций.
Определить необходимые навыки для проекта
Начнем с самого главного: определим требуемые навыки для проекта или команды.
Матрицы компетенций часто создаются менеджером или отделом персонала для повышения производительности команды. Менеджер должен оценить, какие навыки отсутствуют, чтобы команда не пропустила сроки, не допустила внутреннего конфликта или не превысила затраты.
Вот почему мы начинаем с оценки нужных навыков и компетенций, необходимых для завершения проекта. Это также позволит получить нужные данные для оценки компетенций членов команды, а также избежать оценивания длинного списка нерелевантных компетенций!
Оценить актуальный уровень квалификации членов команды
Для второго шага вам нужно оценить актуальные уровни квалификации членов команды. Это можно сделать, просто спросив их. Это также можно сделать более строгим образом. Например, через тестирование компетенций сотрудника или опроса его коллег и руководителя.
Для каждого навыка следует знать его уровень. Их можно сгруппировать по четырем категориям:
Часто используемым инструментом оценки компетентности является инструмент обратной связи «Оценка 180-градусов». Он оценивает навыки сотрудника, опрашивая его коллег и непосредственного руководителя.
Преимущество такого инструмента заключается в том, что люди не всегда точно оценивают свои собственные навыки. Это может быть из-за чрезмерной компетентности, примером чего является эффект Даннинга-Крюгера — когнитивное искажение, в котором люди с низкими способностями впадают в заблуждение иллюзорного превосходства.
Альтернативным и даже лучшим инструментом является инструмент обратной связи «Оценка 360-градусов». В дополнение к предыдущего инструменту, он охватывает оценки других лиц — клиентов, прямых руководителей.
Вы можете, конечно, по-разному измерять квалификацию. Я видел, как организации используют 5-балльную шкалу: 0) Нет опыта или знаний, 1) Недостаточные опыт или знания, 2) Допустимый опыт или знания, 3) Значительный опыт или знания, 4) Экспертный опыт или знания.
Не стесняйтесь менять и использовать эти шкалы так, как вам нравится!
Определить заинтересованность человека в работе над задачами, которые ему были предложены
Дополнение к предыдущему шагу заключается в том, что вам нужно знать еще что-то кроме навыков. Людям также должна нравиться работа, в которой они хороши. Чаще всего это так, но бывает иначе.
Ваша Матрица компетенций может показать, что у вас есть кто-то компетентный для решения задачи, но если человек не хочет выполнять задачу, вы все равно попадете в тупик. Вам следует знать о каждом сотруднике, что они:
Выяснив это, вы можете свести все данные вместе.
Включить всю информацию в Матрицу компетенций и действовать на основе полученной информации
Теперь, когда вы знаете как необходимые, так и наличествующие компетенции, вы можете создать Матрицу компетенций. Она наглядно демонстрирует — какие навыки доступны и какие отсутствуют.
Это приведет к матрице следующего вида.
Пример Матрицы компетенций
Матрица компетенций ниже основана на примере подразделения анализа персонала. Для проекта были определены шесть важнейших навыков: Предприимчивость, Анализ данных, Продвинутая аналитика данных, Визуализация данных, Базовые знания в области HR, IT и хранение информации.
Далее мы оценили возможности и заинтересованность каждого из членов команды. Они сведены в следующей таблице:
Используя Матрицу компетенций, вы можете легко определить сильные и слабые стороны команды. Джонатан и Олден имеют крепкую деловую хватку, Трейси выполнит роль аналитика данных, а Сандра, скорее всего, будет связкой между командой и ИТ-отделом.
С другой стороны, команде не хватает навыков глубокого анализа данных. Большинство опытных аналитических групп не прибегают к расширенной аналитике данных. Зачастую они пытаются создать собственную модель для аналитики и автоматизировать оперативную и стратегическую отчетность.
Однако на более продвинутом этапе аналитические способности станут более востребованными. На этом этапе команде, возможно, придется нанять специалиста по анализу данных с передовыми навыками аналитики. Продвинутый этап аналитики включает также и навык разработки. И если кто-то находится на базовом уровне аналитических навыков, но готов их улучшать, это отличный знак.
Многие команды аналитиков изо всех сил пытаются найти все необходимые навыки. Действительно, очень трудно найти людей, которые понимают как HR-аналитику, так и аналитику данных в бизнесе. Я предвижу увеличение количества компаний, привлекающих людей с желанием учиться, потому что людей, которые имеют все соответствующие навыки, не хватает.
Тут живут драконы: матрица компетенций как инструмент тимлида
Не исключено, что вы скажете: «Матрица компетенций? Серьезно?». Скорее всего вы что-то уже слышали про этот инструмент, и даже сделали какие-нибудь выводы, почему не хотите его использовать. Может быть, просто было не до того, или как убийственный аргумент «так сложилось исторически. ».
На самом деле это вполне логичный и не новый инструмент, который может быть очень полезен. И внедрять его можно совершенно по-разному, что мы и попробуем вам доказать на практических кейсах двух разных команд — техподдержки и разработки. На их основе вы сами сможете оценить трудозатраты (они могут быть ну очень разные) и прикинуть более подходящий для вас путь в этом направлении.
А при чем тут драконы, объясним под катом.
Эта статья основана на нашем с Константином Кафтаном на TeamLead Conf. Константин тимлид отдела технической поддержки IPONWEB, а я технический писатель группы разработки в IPONWEB, занимаюсь управлением знаниями.
Рассказ построен на практических кейсах компании IPONWEB, поэтому сначала немного познакомимся с компанией, чтобы вы могли понять, близок ли вам этот материал.
Наши HR на запрос на классную маркетинговую картинку, которая расскажет про нашу сферу, дали это:
Действительно, IPONWEB разрабатывает платформы для клиентов, которые занимаются онлайн-рекламой. Мы работаем по модели Software as a Service (или точнее Platform as a Service). У нас есть много компонентов: HTTP-сервер, predict-алгоритм, UI, репортинг. Бизнес-логика для порядка 50 проектов, написанная на Lua.
Еще у нас есть флагман BidSwitch, который начинался как spin-off. Нас больше интересует интеграция партнеров (demand-side, supply-side), поэтому у нас очень много логов. Это такой же проект, на таком же стеке, но он достаточно большой, у него есть специфика и выделенная линия техподдержки, которую Константин и возглавляет.
Почему мы выбрали название «Тут живут драконы», что это значит? Так раньше на средневековых картах обозначали места, где неизвестно, что происходит — такие Terra Incognita. По этому поводу есть две истории. Первая — про структуру навыков, скиллов, которые есть у команды, и чем команда больше, тем больше таких Terra Incognita возникает; а про вторую поговорим чуть позже.
Как мы здесь оказались
Так получилось, что мы (Светлана и Константин) не очень часто пересекаемся по работе, и о том, что мы подали заявки по сути одной тематики, узнали только с сайта конференции. Тогда мы решили объединиться — нам показалось, что так будет интереснее для всех.
Профайлы команд
Команда Константина «Technical Support»:
Цели и триггеры
В команде Technical Support:
В Dev Team нужно было:
Performance review
Performance review — это стандарт нашей компании. Раз в N месяцев с каждым сотрудником проводится performance review в присутствии сотрудника, его тимлида, в качестве рефери используется HR или нотариус. На performance review мы обследуем, что сделал сотрудник из тех задач, которые были поставлены, что у него не получилось, если не получилось, почему, чего бы хотелось достичь еще, что мы можем предложить. После этого ставятся новые цели, задачи, устанавливается следующий срок.
В команде поддержки этот срок достаточно короткий, потому что больших, растянутых по времени, проектов нет — это 3, максимум 4 месяца. В команде разработки это полугодовые циклы ревью. Раньше сроки были больше, просто потому, что у разработчиков можно лучше наметить road map. В некоторых других командах разработки, например, фронтенда performance review происходит тоже каждые 3-4 месяца. Возможно, интервал никак не связан с тем, разработкой или поддержкой занимается команда, но так сложилось у нас.
Зачем нужна матрица компетенций
Год назад наша компания проходила период интенсивного роста, стало больше людей, больше инструментов, больше задач — всего больше. В один прекрасный момент стало понятно, что без правильных документов трудно понять, что происходит. И мы нашли решение как систематизировать информацию: о задачах; инструментах и скиллах; сотрудниках.
А зачем это все вам? Вы узнаете о наших практических кейсах, но у вас может возникнуть резонный вопрос — как понять, что мне это нужно?
Если у вас возникли проблемы, похожие на те, что мы обозначили выше, то есть вы не понимаете полный пул задач ваших разработчиков, слишком долго вводите в курс дел новых сотрудников и другие проблемы, которые уже назывались, то это вам, наверное, нужно.
С чего начать
С чего начать расскажем на своем примере.
В команде техподдержки мы: определили задачи, которыми занимаемся; провели декомпозицию задач на отдельные манипуляции; выяснили, какие инструменты сотрудник должен знать для работы в том или ином секторе.
Ниже несколько упрощенный пример.
В команде есть сотрудники Бэтмэн, Джокер, Флэш и Иванов, и стандартные задачи:
Из инструментов у нас есть:
Потом мы выяснили, кто что знает и в каком объеме.
2 — эксперт, который может научить; 1 — значит человек более-менее знает; пустые ячейки вместо, чтобы никого не обижать.
Сводим в одну таблицу:
Серым выделены те инструменты, которые в той или иной задаче не обязательны. Например, для общей диагностики нам не обязательно знание BQ и Grafana. Получилась достаточно интересная картина.
Нежданчики (Support)
Всплыло несколько нежданчиков, которые помогли понять:
Вернемся к таблице.
Формально в общей диагностике занят Бэтмэн. Из таблицы видно, что Джокер в случае необходимости его хорошо подменит, с учетом того, что он еще эксперт в UI — почему нет? То есть Бэтмэн у нас заменяемый.
Джокер вообще молодец — он подкован практически везде, кроме разве что deploy monitoring, но этому можно научить.
Общеизвестно, что Джокер несколько эксцентрично проводит свободное время и в любой момент может выпасть из работы. Что тогда произойдет? Тогда все будет грустно с диагностикой deal трафика.
Мало того, у нас же нет эксперта по BQ! То есть надо срочно кого-то подтянуть, обучить. Например, можно Бэтмэна обучить BQ, а Иванова — Graphite.
Даже с учетом такой упрощенной системы оценки, можно получить некую сумму по каждому из сотрудников, чтобы понять, насколько он компетентен и хорошо подкован. Эти оценки подкинули еще один нежданчик.
Еще две интересные вещи — это общая сумма по команде и ее средний балл. Строго говоря, эти цифры сами по себе не особо интересны — интересна динамика их изменения из месяца в месяц. Если у нас по какой-то причине начал падать total, то, скорее всего кто-то ушел, а пришел слабенький сотрудник — проблема с комплектацией, нужно обратиться к HR. Если вдруг начал падать average, значит, у нас что-то не так с обучением — виноват тимлид и только тимлид.
Важно, что в данном случае это инструмент тимлида, который не показывается сотрудникам, ведь оценки субъективны.
Dev Team
В Dev Team все немного более демократично, или, может быть, мы просто усложнили себе задачу. Список скиллов в команде разработки больше, хоть и однородность задач, возможно, выше.
Мы собрали совет из 4-х опытных разработчиков (в том числе тимлид и специалист по управлению знаниями), провели мозговой штурм, и проанализировали задачи и навыки. Мы просто шли пошагово и на своих личных ощущениях, но нескольких человек, анализировали задачи, раскладывали их на навыки, формировали список.
Сначала это был список, потом его структурировали на более универсальные скиллы, в которые входит кодинг и отдельно бизнес-скиллы, потому что для наших разработчиков это важная часть. А из этого списка навыков уже составили матрицу.
В первую итерацию матрицы у нас не входили так называемые софт-скиллы, то есть то, что нельзя назвать хард-скиллами. Это что-то, связанное с ежедневной работой, и даже входящее в критические навыки, в том числе: планирование; коммуникация с командой; умение управлять процессом разработки в мини-группах или самим собой; умение формулировать требования, например, в ходе код-ревью.
Все эти навыки мы не сразу включили, потому что не понимали, как точно их оценивать.
Во вторую итерацию они вошли в систему оценки:
В разработке мы отказались от самого понятия «софт-скиллы», а назвали это универсальными скиллами. В них не входит, например, знание английского языка или то, что ты не бесишь свою команду — этого нет, потому что это как раз ближе к софт-скиллам, описывает характер человека. Мы оцениваем навыки где-то на грани, и поэтому придумали такое название — универсальные скиллы.
Когда список навыков был готов, мы провели их оценку с помощью сплошного опроса. Мы проводили настоящий экзамен, в котором часть вопросов предполагала однозначный ответ, а часть обсуждало рабочие ситуации: «Как поступить, если кто-то что-то задерживает или не делает?», «Как бы ты реализовал ту или иную функциональность в проекте?». Это нам очень помогло, потому что эта часть вопросов позволила поговорить с большим количеством разработчиков.
Затем мы прогрейдировали разработчиков по шкале от 1 до 3 за каждый навык.
Те навыки, которые мы не смогли оценить с помощью первичного опроса, мы оценили с помощью пиров (peer), то есть попросили оценить коллег. У нас не было на тот момент руководителей каких-то групп, иначе это могли бы сделать они.
Эта матрица выглядит примерно так.
Конечно, все уместить на картинке не получилось, поэтому некоторые вещи, например, корреляции и профиль разработчиков здесь непонятны. Но и так можно примерно оценить, что получается, и посмотреть, насколько это наглядно и что можно измерять.
Цвета соответствуют оценке. Выведены те же самые метрики, что и в команде поддержки — total и различные average по скиллам.
Обратим внимание на Dev8. Из таблицы получается, что это как будто первый кандидат на увольнение. Но, во-первых, у него есть специфичное знание по одной из позиций, поэтому он нам нужен. Но важнее, что эта таблица — не инструмент увольнения. Об этом я тоже расскажу, мы не ради этого все затевали.
Average по навыкам — это работа, по результатам которой должен быть сформирован план, как подтянуть навык. То есть если разработчики чего-то не знают — это не их проблема. Это значит, что мы не дали им достаточно информации, и в целом знаний по какому-то из навыков вообще недостаточно в компании. Нужно либо написать документацию, либо сделать какой-то playground, чтобы они смогли попрактиковаться, либо докупить какой-то внешний курс, чтобы они могли обучиться, провести Knowledge Sharing Session, отправить их друг у друга учиться, работать в паре какое-то время, включить человека в другой проект. Могут быть разные варианты knowledge sharing. Суть в том, что нужно сначала провести мероприятие, и только потом говорить о динамике.
Важно заметить, что поскольку в нашей компании матричная структура, не всем разработчикам нужны некоторые навыки. Они их получат, когда будут выполнять задачу, связанную с этим навыком. Иначе бессмысленно, особенно если навык не входит в список критических. Например, в некоторой части проектов нет uPredict, это не критический навык. В целом этот подход помог нам сформулировать, какие навыки являются ключевыми, а какие нет, и что специалист сможет наверстать, когда у него возникнет такая практическая задача.
Другой важный момент про грейдинг. Мы изначально сделали ошибку, которой спровоцировали большее, чем могло бы быть, сопротивление команды — мы не вербализовали значение оценик 1, 2 и 3. Они были у нас в голове на уровне интуиции, но мы не могли ответить, почему один разработчик получил 1, а второй — 2. Разработчики делились друг с другом результатами греда и это спровоцировало конфликты. В отличие от группы поддержки, мы по запросу сообщали личные оценки, но не чужие.
Нужно четко определить и передать это всем, например, что в знании Lua оценка:
Как внедрить
Когда первичная матрица была готова, в команде разработки мы привязали к ней метрики. В основном это был процент максимальных оценок по скиллам, который позволяет поставить грейд разработчику.
Помимо оценок по отдельным навыкам, нам нужно было прогрейдировать разработчиков. У нас были грейды A, B и C — что-то вроде junior, middle, senior. В IT junior, middle, senior уже слишком наполнено смыслом, в который вкладывается, в том числе, и опыт работы. Нам нужны были обозначения, абсолютно не имеющие никаких коннотаций заранее. A, B и C — это даже не как оценки в американской школе. Метрика «процент максимальных скиллов» нам помогла это сделать.
Остальные метрики — различные проценты по отдельным скиллам и среднее.
Еще мы попытались построить корреляции с другими методами оценки сотрудников, в том числе зарплатой. Привязать к метрикам зарплату мы, разумеется, не хотели, это было просто упражнение, но все достаточно хорошо соотнеслось.
Идея в том, что соотнося оценки по матрице с зарплатой вы проверяете какие-то свои соображения по этому поводу, и можете оценить, сколько платите за каждый конкретный процент максимальных скиллов. Можно примерно разложить, за что и сколько можно доплачивать, где менять зарплату. Или выявить, что вы кому-то серьезно не доплачиваете — оказывается, есть человек, который обладает уникальным знанием или достаточно хорошим набором скиллов, и вы были не правы.
Также мы сюда привязали те метрики, которые мы берем из других систем. У нас есть метрики из системы контроля версий, связанные с роллбэками или прохождением ревью, например. Мы их тоже сопоставили, но у нас нет цели делать жесткие привязки. Мы просто подтверждаем свои гипотезы таким образом.
Впоследствии цели на performance review ставились в терминах этой матрицы. То есть мы могли понятно объяснить, чем отличается 1 от 2, и в каких (только нескольких) позициях разработчику нужно за полгода подтянуться.
Мы выработали внутреннее правило — не давать после performance review больше, чем три цели в терминах матрицы.
Нежданчики (Dev Team)
В разработке тоже встретились нежданчики. В принципе, мы получили многое из того, что хотели. У нас появилось четкое понимание в виде карты, с которой можно работать, где есть белые пятна, где нужно команду дообучить. Мы полностью переписали план подготовки новых сотрудников. В результате процесс адаптации человека в живой проект сократился с 5-6 месяцев до 2-3. То есть теперь за испытательный период мы полностью успеваем внедрить нового сотрудника в проект. Мы полностью переписали онбординг-план, потому что смогли выявить список ключевых навыков, которые нужны новичкам сразу. А под второстепенные навыки (или очень специфичные для отдельных проектов) артефакты знания можно создавать в процессе обучения.
В тот момент у нас были интерны, и мы не планировали брать их всех, а только одного из четырех. Но взяли троих. Напрямую мы не связываем то, что у нас сразу три интерна прижились, с тем, что мы сделали матрицу компетенций. Но мы на них свои многие соображения проверяли, и они первые, кто прошел через новый план подготовки. В частности, мы включили в него много практики, создали playground, чтобы именно по критическими скиллам они могли упражняться на практике.
Помимо того, что мы выявили кто и насколько лоялен компании, а кто хочет быть уникальным и незаменимым. Были критические скиллы, которыми люди хотели делиться, в то же время обнаружились узкие места, в которых люди упивались тем, насколько они уникальны и незаменимы. В этом случае автобусный фактор был результатом сознательного решение. Мы сразу смогли задокументировать эту часть фреймворка и дообучить на это второго человека. Хотя было сопротивление со человека-эксперта, который не хотел делиться знанием и хотел реализовывать это только в своем проекте.
Мы выявили энтузиастов и драйверов команды. Тех, кто сразу хотел что-то контрибьютить: «Давайте еще вот это добавим? А почему мы не оцениваем это?».
Совершенно неожиданно, то, что мы вообще не собирались искать, — мы нашли те вещи, которые можно перенести в серверную часть кода, в библиотеки, чтобы не изобретать велосипед. Это получилось больше благодаря проведению сплошного экзамена и дополнительному общению.
Кейсы
Выше типичный кейс, когда можно часть кода перенести в общую библиотеку. Тут есть какое-то знание, которым недостаточно поделиться, нужно перенести его в кодовую базу.
На этом примере только один разработчик знает, как настраивать CI, потому что это он его настроил. Это узкое место, в котором нужно поделиться знаниями. Кстати, это тот самый Номер 8.
Когда мы знаем, какие навыки не входят в критические, можно применять разные фильтры, чтобы понять, какие навыки с низкой средней оценкой относятся к критическим, а какие просто специфичные для бизнес-юнитов. Мы еще только учимся вычислять профили разработчиков по этой матрице.
Цена внедрения матрицы компетенций
То, что всех интересует — это священные человеко-часы. Всех всегда интересует вопрос трудозатрат.
В случае службы поддержки это заняло:
Dev Team
В команде разработки по сравнению с поддержкой немного пугающая разница в трудозатратах. Но здесь есть важный момент: на первичную оценку скиллов (составление списка) ушли те же 3-4 часа. Основные трудозатраты оказались совершенно в другом, они складываются из следующего:
Детализация
Отдельно остановимся на том, как важно вовремя остановиться.
Матрица компетенций — это инструмент, а не универсальное решение всех задач.
Нужно понять, чего вы все-таки хотите, и сколько вы готовы инвестировать времени. Первый этап, когда мы просто расписываем навыки, распределяем сотрудников, применяем элементарную оценку, не особо трудозатратен. Потом можно усложнить: ввести большее количество метрик, среднее по навыку, провести сплошной опрос и т.д.
Support остановился где-то между easy и medium, а Dev Team — примерно на medium.
Для каждой манипуляции, для каждого инструмента можно еще ввести коэффициент сложности, и уже по этим коэффициентам рассчитывать финальную общую и среднюю оценку. Мы так далеко не пошли, а остановились на средней степени сложности. Суть в том, что можно наращивать уровни абстракции, но вопрос, нужно ли.
Чего не стоит делать
Чем матрица компетенций не является и чего с ней делать не стоит.
Если у вас достаточно разнородная команда, подумайте, нужна ли вам одна матрица или несколько — те самые профайлы. Мы сейчас идем в этом направлении и пока не решили эту проблему.
А если вопрос управления знаниями для вас так же актуален, как для меня, приглашаю участвовать в специальной конференции KnowledgeConf 2019 в Москве 26 апреля.
Обсуждать планируем самые разные проблемы, от прикладных (онбординг новичков, организация базы знаний, внутренний университет, обучение на практике, фиксация инцидентов и ведение базы постмортемов) до фундаментальных (современные подходы к обучению и системному мышлению).
Мы с программным комитетом уже начали работу и получили первую двадцатку тем. Подавайте заявки, если дорожите знаниями внутри компании, и знаете, как с ними следует обращаться. А мы поможем довести материал до классного доклада.