Матрица компетенций что это
Применение матрицы и диаграммы компетенций
При росте команды тимлид и вышестоящее руководство начинают задумываться об оценке компетенций сотрудников. В рамках этой статьи я хочу рассказать о первых шагах по внедрению оценки сотрудников и какие бонусы вы можете получить.
Хорошим инструментом является матрица компетенций в связке с диаграммами компетенций.
Начнем с терминологии.
Термины
Матрица компетенций — это таблица с данными о наборе компетенций сотрудников. В ячейках таблицы стоит цифра, обозначающая степень владения компетенцией.
Диаграмма компетенций — это лепестковая диаграмма, которая визуализирует численные показатели компетенций сотрудников.
Классический подход
Матрица компетенций содержит перечень навыков, которые должен применять сотрудник в своей работе. При разработке первой матрицы компетенций у меня получилось около 200 компетенций, которые нужно оценить. Собирать данные о таком количестве данных довольно трудоемко. Поддерживать их в актуальном состоянии еще сложнее. У не смог себя заставить пользоваться таким инструментом.
При этом матрицы компетенций широко применяют во многих отраслях — от торговли, до промышленности. И применяют их очень успешно. Оказалось, что количество навыков в матрице компетенций в других сферах около 20 или даже меньше. Почему бы не уменьшить число компетенций и в нашей сферы.
Начало внедрения
Начать стоит с малого. И даже точностью на первых шагах мы можем пожертвовать.
Сбор данных
Оценку компетенций можно и нужно производить при собеседовании и найме сотрудников. Дополнительные оценки необходимо проводить и в процессе работы не реже одного раза в полгода. Это позволит отслеживать динамику развития.
Стоит добавить в матрицу цифру, которая отражает интерес сотрудника к развитию компетенции. Тогда вы сможете подбирать правильный проект для сотрудника и динамику интереса к различным технологиям у своих сотрудников.
По матрице компетенций отдельных сотрудников легко построить матрицу компетенций компании или отдельной команды.
Очень полезно строить матрицу компетенций проекта.
Анализ
Итак вы собрали данные. Пришло время получить хоть какую-то пользу.
Полученные матрицы дают такие возможности:
Bus-фактор
Предположим, что у вас 5 сотрудников и у вас получилась такая матрица:
Эта матрица дает возможность определить bus-фактор.
На данной матрице можно увидеть, что Golang применять в компании пока вряд ли стоит. Никто не хочет быть зависимым от одного единственного сотрудника.
Давайте взглянем на получившуюся диаграмму компетенций. Bus-фактор виден и здесь. Этот же сотрудник явный лидер в знаниях PHP. И казалось бы это хорошо. Ведь он может написать любой код. И это и правда так. Он даже сумел разобраться в асинхронном PHP. Но кто этот код потом сможет поддерживать?
Стоит его ограничить в применении нестандартных подходов или поставить ему задачу на обучение таким техникам других сотрудников. Но в асинхронный PHP ходить не стоит.
Определение уровня сотрудника и точек роста
Приходит к вам сотрудник dev2 требовать повышения зарплаты. Вам нужно определиться с объективностью его требований. Нужно добавить к матрице абстрактных сотрудников с компетенциями junior, middle frontend и middle backend.
На матрице сразу видно, что уровень джуна сотрудник прошел. Но до любого из мидлов он явно не дотягивает.
На диаграмме хорошо видно, что сотруднику логичнее развиваться в сторону фронтенда и понятны направления в которых необходимо развиваться сотруднику, чтобы получить повышение.
Подбор команды
Активный обмен знаниями происходит только в команде. Для адекватного общения в команде интересы сотрудников в команде должны значительно пересекаться. Сложно представить активный обмен знаниями чистого бэкендера и чистого фронтендера или мобильного разработчика и сисадмина.
В наличии 5 разработчиков. Нужно подобрать команду из 4 человек на проект. При этом необходимо обеспечить активный обмен знаниями внутри команды.
В матрице явно видно сильного бэкендера, 3-х фуллстеков и сильного фронтендера.
Сложно представить активный обмен знаниями между dev1 и остальной командой. У него слабо пересекаются знания и интересы с остальной командой. В областях пересечения знаний dev1 намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде.
У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.
Прямо таки явные перекосы в интересах. Хотя и есть совпадающие, но их явно меньше чем различающихся.
Однако я бы отдал предпочтение такой команде:
Точки роста для каждого из сотрудников тут тоже очевидны.
Подобным образом можно подбирать проект и команду друг к другу.
И это только самые простые применения матрицы и диаграммы компетенций.
Итак оценка компетенций начала приносить пользу компании. Но встал вопрос в повышении точности? Только в этот момент стоит усложнять матрицы. И даже при этом большая матрица должна свестись к маленькой матрице, а визуализации делать уже с маленькой матрицы.
Для удобного использования матриц, будет мало гуглодока. Если вы знаете подобного рода инструмент напишите об этом в комментариях. А то так и чешутся руки навелосипедить.
Как создать матрицу компетенций персонала
Результат работы сотрудников зависит от их профессиональных навыков и личных качеств. Но от каких именно? Чтобы определить ключевые компетенции работников, а затем оценить их, используют матрицу компетенций.
Что такое матрица компетенций
Матрица компетенций персонала — это таблица с данными об уровне компетентности сотрудников. Она описывает требования к поведению персонала на рабочем месте для всех должностей компании. Кроме матрица, существуют и другие методы оценки персонала.
Матрица разрабатывается на основе моделей компетенций. Модель состоит из набора компетенций для одной должности или группы смежных должностей. Ко всем сотрудникам предъявляются разные требования, поэтому в одной компании должно быть несколько моделей с различным набором характеристик. Например, руководители должны проявлять лидерские качества, а для линейных сотрудников важнее исполнительность.
Пример заполнения простой матрицы:
Виды профессиональных компетенций
Компетенциями называют способность сотрудника выполнять профессиональные задачи на определенном уровне. То есть это не знания или умения, а их проявление на рабочем месте. Компетенции бывают следующих видов:
В модель для управленческих должностей важно включать компетенции из всех четырех групп. А для линейных должностей только из трех — всех, кроме управленческих. Таким образом, матрица компетенций состоит из моделей, а каждая модель включает 3-4 вида компетенций.
Зачем нужна матрица компетенций
Заполненная матрица компетенций показывает, какие навыки нужны сотрудникам для работы, какие у них уже развиты, а какие нужно развить. Эта информация полезна как для руководства, так и для самих сотрудников. Она помогает решать ряд управленческих задач на всех этапах взаимодействия с персоналом — от найма до увольнения.
Адекватная самооценка и желание развиваться
Матрица компетенций дает сотруднику понимание, какое поведение он должен проявлять для успешной работы в команде. Также она показывает его сильные и слабые стороны. Это отличная стартовая точка для мотивированного обучения и развития.
Оценка соискателей и адаптация
Отбирая новых сотрудников на должность компании, HR оценивает их опыт, личные и профессиональные качества. С матрицей компетенций HR-у не нужно каждый раз прописывать профиль компетенций должности, требования и обязательные навыки.
Развитие сотрудников и перестановки кадров
На основе матрицы можно составлять индивидуальные планы развития сотрудников, а также переводить работников на более подходящие должности, чтобы увеличить их продуктивность. Иногда, опираясь на матрицу, принимают решение о повышении или увольнении сотрудника.
Методы разработки матрицы компетенций
Выделяют 3 основных способа разработки матрицы компетенций.
Заимствование готовой матрицы
В свободном доступе есть большое количество готовых матриц и моделей компетенций. Вы можете выбрать подходящие и адаптировать под свою компанию. Это быстрый и бюджетный способ. Его недостаток в том, что выбранные матрицы могут не соответствовать реальности бизнеса в полной мере. Анализ матриц компетенций других компаний в большей степени полезен в качестве справочной информации перед разработкой собственной модели.
Готовые решения под бизнес
Многие консалтинговые компании оказывают услуги по разработке матриц и моделей компетенций. Эксперт-консультант погружается в бизнес-процессы компании, и создает персональные модели для линейных и управленческих должностей. Это наиболее затратный метод, однако он позволяет сэкономить время и создать эффективный инструмент для оценки сотрудников.
Самостоятельная разработка
Разработкой матрицы компетенций внутри компании должен заниматься руководитель отдела или компании. Он выделяет лучших специалистов на каждой должности, и анализирует их работу. На основе этого наблюдения и своего опыта, он описывает подробный образ сотрудника и выделяет ключевые качества, которые важны для его эффективной работы. Этот метод занимает больше времени руководителя, однако при правильном подходе, можно не сомневаться в объективности готовых моделей.
Совет. Формированием подробного образа сотрудника должен заниматься именно руководитель отдела или компании, а не HR. HR меньше взаимодействует с сотрудниками и не так хорошо осведомлен об их работе — из каких этапов она состоит, каким образом каждый сотрудник выполняет свои функции и какие качества при этом проявляет.
Как создать матрицу компетенций
В бизнес-процессах каждой компании есть свои особенности, поэтому для каждой должности создаются уникальные наборы компетенций — модели. После чего все модели объединяются в единую матрицу. Это происходит за 8 шагов.
1 — Выделите должности для разработки матрицы
Обозначьте список должностей, для которых будете создавать модели компетенций. Часто делают ошибку, выделяя виды деятельности, а не должности. Например, создают модель для сотрудников отдела продаж или маркетинга. Важно определить именно должности.
Например, если в организации есть три вида менеджеров (для холодных продаж, для работы с текущими клиентами и для приема входящих звонков), то и моделей должно быть три. Их составление поможет понять, для какой должности лучше подходит тот или иной сотрудник.
2 — Опишите функции каждой должности
Выберите первую должность для проработки. Подробно опишите каждую функцию, которую выполняет сотрудник на этой должности. Если раньше на предприятии или на производстве были прописаны основные бизнес-процессы, это упростит задачу. Чтобы собрать информацию о функциях сотрудника, нужно провести опросы или интервью с руководителем и с самим сотрудником, установить наблюдение за его работой.
Когда вы описали функции, важно определить критерии их успешного выполнения. Например, для менеджера по продажам это может быть определенный объем продаж или количество заключенных договоров за месяц. На основе этих показателей определите самых результативных сотрудников.
3 — Подберите компетенции для каждой функции
На основе анализа работы успешных сотрудников определите стандарты поведения, которые обеспечат максимальную эффективность выполнения функции на рабочем месте. Например, задача маркетолога — выполнить анализ конкурентов. Необходимые способности — понимание и применение принципов анализа рынка, внимательность, умение работать в Excel таблицах, способность делать выводы на основе полученных данных.
Для выполнения разных функций могут требоваться одни и те же компетенции, поэтому компетенции в списке могут повторяться.
4 — Выделите важные компетенции
Изначально у вас получится длинный список компетенций для выбранной должности. Опираясь на частоту упоминаний, составьте их рейтинг. Затем разделите компетенции на группы — корпоративные, личной эффективности, профессионально-технические и управленческие.
Опираясь на рейтинг, сократите список до 6-10 штук, чтобы акцентировать внимание на самых важных. Именно они будут включены в модель компетенций. Чем больше пунктов вы оставите, тем сложнее будет их внедрить.
5 — Составьте шкалу оценки каждой компетенций и опишите ее уровни
Когда готов итоговый список компетенций для должности, составьте шкалу их оценки. Выделите 4-5 уровней. Для этого можно использовать пятибалльную, десятибалльную или процентную шкалу оценки. Например:
На основе готовой шкалы пропишите в отдельной таблице индикаторы поведения для каждого уровня. Должна прослеживаться очевидная разница между каждым уровнем. Кроме позитивных индикаторов, важно описать и негативные, которые демонстрируют отсутствие нужного качества.
Например, индикаторы для компетенции “Убедительность в общении” могут выглядеть следующим образом:
Аналогичным образом опишите каждую компетенцию. Обратите внимание, что требования к уровню компетенций на той или иной должности должны различаться. Поведение, которое считается базовым уровнем для руководителя, может быть продвинутым уровнем для линейного сотрудника.
6 — Заполните матрицу
Опираясь на готовые модели компетенций, сведите информацию обо всех должностях в единую таблицу. Формат таблицы произвольный, он зависит от целей оценки и количества информации, которую вы добавляете.
Например, для оценки соискателей достаточно использовать простую таблицу, в которой перечислены основные компетенции для каждой должности. А для управления развитием персонала подойдет более сложная матрица, в которой описана модель поведения для каждого сотрудника. Можно разбить компетенции на группы и добавить дополнительные сведения, например, о повышении квалификации или прохождении аттестации. Образец сложной матрицы:
7 — Оцените уровень компетенций сотрудников
Когда эталонная матрица готова, можно приступать к оценке персонала на ее основе. Продумайте, каким образом вы будете оценивать уровень компетенций сотрудников. Например, можно провести тестирование оцениваемого сотрудника или опрос его коллег и руководителей. Для проведения опроса рекомендуем использовать опросник 360 градусов.
Результаты оценки внесите в матрицу компетенций. Для наглядности можно подсветить ячейки другим цветом, чтобы показать степень соответствия эталонным критериям. Например:
Проводите регулярную оценку компетенций, чтобы в матрице всегда были актуальные данные об уровне развития сотрудников.
Совет. Для визуализации моделей используется диаграмма или карта компетенций. Она показывает, как отличается реальный уровень сотрудников от эталонных оценок.
8 — Примите управленческие решения
Используйте матрицу компетенций для принятия управленческих решений: прием на работу, кадровые перестановки или назначение обучения. Случается, что модели компетенций отличаются от реальных профилей компании, поэтому они не принимаются в расчет в момент принятия управленческих решений. Например, в матрице указано, что одна из основных компетенций для программиста — работа в команде. А получает повышение самый необщительный сотрудник, который более результативен благодаря высокой самоорганизации.
Вывод. Матрица компетенций показывает актуальный уровень развития сотрудников и помогает принимать важные управленческие решения. Однако со временем даже эффективные модели устаревают. Компания развивается, роли и функции перераспределяются, поэтому меняются и требования к должностям. Рекомендуем раз в год пересматривать модели компетенций, и при необходимости вносить в них изменения.
Тут живут драконы: матрица компетенций как инструмент тимлида
Не исключено, что вы скажете: «Матрица компетенций? Серьезно?». Скорее всего вы что-то уже слышали про этот инструмент, и даже сделали какие-нибудь выводы, почему не хотите его использовать. Может быть, просто было не до того, или как убийственный аргумент «так сложилось исторически. ».
На самом деле это вполне логичный и не новый инструмент, который может быть очень полезен. И внедрять его можно совершенно по-разному, что мы и попробуем вам доказать на практических кейсах двух разных команд — техподдержки и разработки. На их основе вы сами сможете оценить трудозатраты (они могут быть ну очень разные) и прикинуть более подходящий для вас путь в этом направлении.
А при чем тут драконы, объясним под катом.
Эта статья основана на нашем с Константином Кафтаном на 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 апреля.
Обсуждать планируем самые разные проблемы, от прикладных (онбординг новичков, организация базы знаний, внутренний университет, обучение на практике, фиксация инцидентов и ведение базы постмортемов) до фундаментальных (современные подходы к обучению и системному мышлению).
Мы с программным комитетом уже начали работу и получили первую двадцатку тем. Подавайте заявки, если дорожите знаниями внутри компании, и знаете, как с ними следует обращаться. А мы поможем довести материал до классного доклада.