Для чего нужна матрица компетенций
Применение матрицы и диаграммы компетенций
При росте команды тимлид и вышестоящее руководство начинают задумываться об оценке компетенций сотрудников. В рамках этой статьи я хочу рассказать о первых шагах по внедрению оценки сотрудников и какие бонусы вы можете получить.
Хорошим инструментом является матрица компетенций в связке с диаграммами компетенций.
Начнем с терминологии.
Термины
Матрица компетенций — это таблица с данными о наборе компетенций сотрудников. В ячейках таблицы стоит цифра, обозначающая степень владения компетенцией.
Диаграмма компетенций — это лепестковая диаграмма, которая визуализирует численные показатели компетенций сотрудников.
Классический подход
Матрица компетенций содержит перечень навыков, которые должен применять сотрудник в своей работе. При разработке первой матрицы компетенций у меня получилось около 200 компетенций, которые нужно оценить. Собирать данные о таком количестве данных довольно трудоемко. Поддерживать их в актуальном состоянии еще сложнее. У не смог себя заставить пользоваться таким инструментом.
При этом матрицы компетенций широко применяют во многих отраслях — от торговли, до промышленности. И применяют их очень успешно. Оказалось, что количество навыков в матрице компетенций в других сферах около 20 или даже меньше. Почему бы не уменьшить число компетенций и в нашей сферы.
Начало внедрения
Начать стоит с малого. И даже точностью на первых шагах мы можем пожертвовать.
Сбор данных
Оценку компетенций можно и нужно производить при собеседовании и найме сотрудников. Дополнительные оценки необходимо проводить и в процессе работы не реже одного раза в полгода. Это позволит отслеживать динамику развития.
Стоит добавить в матрицу цифру, которая отражает интерес сотрудника к развитию компетенции. Тогда вы сможете подбирать правильный проект для сотрудника и динамику интереса к различным технологиям у своих сотрудников.
По матрице компетенций отдельных сотрудников легко построить матрицу компетенций компании или отдельной команды.
Очень полезно строить матрицу компетенций проекта.
Анализ
Итак вы собрали данные. Пришло время получить хоть какую-то пользу.
Полученные матрицы дают такие возможности:
Bus-фактор
Предположим, что у вас 5 сотрудников и у вас получилась такая матрица:
Эта матрица дает возможность определить bus-фактор.
На данной матрице можно увидеть, что Golang применять в компании пока вряд ли стоит. Никто не хочет быть зависимым от одного единственного сотрудника.
Давайте взглянем на получившуюся диаграмму компетенций. Bus-фактор виден и здесь. Этот же сотрудник явный лидер в знаниях PHP. И казалось бы это хорошо. Ведь он может написать любой код. И это и правда так. Он даже сумел разобраться в асинхронном PHP. Но кто этот код потом сможет поддерживать?
Стоит его ограничить в применении нестандартных подходов или поставить ему задачу на обучение таким техникам других сотрудников. Но в асинхронный PHP ходить не стоит.
Определение уровня сотрудника и точек роста
Приходит к вам сотрудник dev2 требовать повышения зарплаты. Вам нужно определиться с объективностью его требований. Нужно добавить к матрице абстрактных сотрудников с компетенциями junior, middle frontend и middle backend.
На матрице сразу видно, что уровень джуна сотрудник прошел. Но до любого из мидлов он явно не дотягивает.
На диаграмме хорошо видно, что сотруднику логичнее развиваться в сторону фронтенда и понятны направления в которых необходимо развиваться сотруднику, чтобы получить повышение.
Подбор команды
Активный обмен знаниями происходит только в команде. Для адекватного общения в команде интересы сотрудников в команде должны значительно пересекаться. Сложно представить активный обмен знаниями чистого бэкендера и чистого фронтендера или мобильного разработчика и сисадмина.
В наличии 5 разработчиков. Нужно подобрать команду из 4 человек на проект. При этом необходимо обеспечить активный обмен знаниями внутри команды.
В матрице явно видно сильного бэкендера, 3-х фуллстеков и сильного фронтендера.
Сложно представить активный обмен знаниями между dev1 и остальной командой. У него слабо пересекаются знания и интересы с остальной командой. В областях пересечения знаний dev1 намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде.
У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.
Прямо таки явные перекосы в интересах. Хотя и есть совпадающие, но их явно меньше чем различающихся.
Однако я бы отдал предпочтение такой команде:
Точки роста для каждого из сотрудников тут тоже очевидны.
Подобным образом можно подбирать проект и команду друг к другу.
И это только самые простые применения матрицы и диаграммы компетенций.
Итак оценка компетенций начала приносить пользу компании. Но встал вопрос в повышении точности? Только в этот момент стоит усложнять матрицы. И даже при этом большая матрица должна свестись к маленькой матрице, а визуализации делать уже с маленькой матрицы.
Для удобного использования матриц, будет мало гуглодока. Если вы знаете подобного рода инструмент напишите об этом в комментариях. А то так и чешутся руки навелосипедить.
Навыки команды: Как я настраивал матрицу компетенций
Почему в Confluence?
Когда я пришел в команду разработки платформ бизнес-сервисов, мне было сложно разобраться, кто чем занимается, какие продукты разрабатываются и поддерживаются, какие навыки для этого нужны команде, кого и чему нужно научить.
В этой статье я расскажу, как мы строили матрицу навыков (компетенций) команды, как она эволюционировала, и какие вопросы мы теперь с её помощью решаем.
Статья будет полезна руководителям групп, тимлидам, которые хотят быстро внедрить процесс наполнения и актуализации матрицы компетенций.
Первое, что пришло на ум, — это сделать таблицу, где в строчках сотрудники, а в колонках навыки/продукты. Встал вопрос, где вести такую таблицу?
Шаг 1. Обычная таблица
В начале я сделал обычную таблицу, где в строчках — навыки, в колонках —сотрудники. На тот момент в команде было 10 человек и с полсотни навыков, сгруппированных по тринадцати темам.
Начальный список навыков мы c командой придумали во время ретро. Таблица выглядела относительно компактно. И все с удовольствием пошли заполнять. Заполнять необходимо было количеством звездочек. Тут же возник вопрос? А сколько звездочек ставить? Нужны критерии.
После этого все довольно оперативно смогли заполнить информацию по себе.
Итоги после первого шага
Время: От идеи до первичного заполнения прошел один спринт (две недели).
Выхлоп: Стало понятно, где у нас пробелы в знаниях, кого чему нужно учить. Составили график обучения (заказали курсы в нужном объеме).
Шаг 2. Сводная таблица
Шло время, команда росла, добавление новой колонки с новым сотрудником становилось все труднее. Кто работал в Confluence, знает капризы работы с таблицами. К тому же появились новые навыки, захотелось их по-другому сгруппировать. Плюс оказалось, что анализировать 15 человек не так удобно, как десять. Поэтому я решил воспользоваться функционалом свойств страниц.
Для начала создал страницу «Шаблон профиля специалиста».
Все навыки разделены по группам. Для каждой группы навыков добавил по отдельному свойству страницы.
Для примера на картинке выше две группы навыков: Computer languages и Management.
Далее добавил метку (Label) на страницу «Шаблон профиля специалиста». Например, skills.
Отлично — у меня появился шаблон. Я попросил каждого участника команды скопировать страницу и назвать своим именем, заполнить свой уровень по каждому из навыков.
Теперь магия — сводная таблица по свойствам страниц.
Добавил макрос «Вертикальное меню», внутри него макрос «Элемент вертикального меню», внутри него макрос «Отчет по свойствам страницы».
У элемента вертикального списка задал название. Оно может быть любым и может не совпадать с названием свойства страницы.
А вот с макросом «Отчет по свойствам страницы» немного сложнее.
Во-первых, надо указать метку — ту, что навесили на «Шаблон профиля специалиста». Например, skills. Это позволило мне отобрать только нужные страницы.
Во-вторых, стоит ограничить список пространств, в которых будут искаться страницы. Например, текущим.
В-третьих, важно указать «Свойство страницы», ведь, как мы помним [из предыдущего], в шаблоне сотрудника у нас много свойств, каждое из которых соответствует одной группе навыков. В данном случае — «computer language».
Наконец, лучше задать название первой колонке в сводной таблице. Я назвал её «Сотрудник»
Повторил для следующей группы навыков. Добавил «Элемент вертикального меню» и внутри него «Отчет по свойствам страницы».
Теперь давайте посмотрим, что у меня получилось?
Итоги после второго шага
Время: На разработку шаблона и сводной таблицы ушло около недели.
Выхлоп: Стало удобнее анализировать полученные данные.
Шаг 3. Продвинутый шаблон
Предупреждение: Для этого улучшения потребуются права администратора пространства.
Некоторое время мы жили с такой таблицей, было удобно смотреть и добавлять новых сотрудников. В то же время в соседнем подразделении реализовали инициативу по сбору информации о доступных учебных курсах, и на какой уровень этот курс помогает перейти. Навыки соседей частично пересекались с нашими, но вот градации были разными. То есть для каждого навыка было детально определено, что нужно знать и уметь делать.
Мне показалось полезным перенять этот опыт, и мы с командой решили перейти от универсальных звездочек к цифрам. И в этот момент возникает сложность: так как для каждого навыка свои критерии оценки, то при переносе критериев в шаблон он становится очень большим, а при его заполнении нужно много чего удалять.
Для решения этой проблемы я решил использовать «Пользовательский шаблон».
Первое, что мне помогло, — «Подсказка» с расшифровкой, что нужно знать и уметь, чтобы проставить соответствующий уровень навыка.
Второе — tooltip. Этот макрос позволил мне сделать всплывающее описание к навыку и будет полезен для просмотра информации на сводной таблице.
В итоге мой шаблон выглядит вот так:
Теперь таблица с навыками сотрудников смотрится более компактно, есть подсказки, какой уровень что означает.
Ой, я чуть не забыл рассказать про то, как воспользоваться нашим пользовательским шаблоном. Все просто. Добавляем макрос «Создать из шаблона»
В результате появляется кнопка
Возможно, у внимательного читателя возникнет вопрос: зачем нужна еще метка? Все просто. При подготовке сводной таблицы можно еще больше ограничить список отбираемых страниц.
Я использую эту возможность для формирования отдельных сводных отчетов по мини-командам. Как вы помните, когда я пришел, нас было десять, на первой итерации изменений — уже 15, сейчас нас более двадцати, и мы приняли решение делиться на четыре мини-команды.
В нашем случае это команды:
Итоги после третьего шага
Время: На разработку и тестирование нового шаблона у меня ушло две недели. Основное время на уточнение формулировок критериев для каждого навыка.
Выхлоп: Оценка уровня навыка стала более точной. Есть возможность сравнивать с целевым специалистом и планировать обучение.
Заключение
Вот какие задачи решает матрица компетенций у нас:
Тут живут драконы: матрица компетенций как инструмент тимлида
Не исключено, что вы скажете: «Матрица компетенций? Серьезно?». Скорее всего вы что-то уже слышали про этот инструмент, и даже сделали какие-нибудь выводы, почему не хотите его использовать. Может быть, просто было не до того, или как убийственный аргумент «так сложилось исторически. ».
На самом деле это вполне логичный и не новый инструмент, который может быть очень полезен. И внедрять его можно совершенно по-разному, что мы и попробуем вам доказать на практических кейсах двух разных команд — техподдержки и разработки. На их основе вы сами сможете оценить трудозатраты (они могут быть ну очень разные) и прикинуть более подходящий для вас путь в этом направлении.
А при чем тут драконы, объясним под катом.
Эта статья основана на нашем с Константином Кафтаном на 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 апреля.
Обсуждать планируем самые разные проблемы, от прикладных (онбординг новичков, организация базы знаний, внутренний университет, обучение на практике, фиксация инцидентов и ведение базы постмортемов) до фундаментальных (современные подходы к обучению и системному мышлению).
Мы с программным комитетом уже начали работу и получили первую двадцатку тем. Подавайте заявки, если дорожите знаниями внутри компании, и знаете, как с ними следует обращаться. А мы поможем довести материал до классного доклада.