При росте команды тимлид и вышестоящее руководство начинают задумываться об оценке компетенций сотрудников. В рамках этой статьи я хочу рассказать о первых шагах по внедрению оценки сотрудников и какие бонусы вы можете получить.
Хорошим инструментом является матрица компетенций в связке с диаграммами компетенций.
Начнем с терминологии.
Термины
Матрица компетенций — это таблица с данными о наборе компетенций сотрудников. В ячейках таблицы стоит цифра, обозначающая степень владения компетенцией.
Диаграмма компетенций — это лепестковая диаграмма, которая визуализирует численные показатели компетенций сотрудников.
Классический подход
Матрица компетенций содержит перечень навыков, которые должен применять сотрудник в своей работе. При разработке первой матрицы компетенций у меня получилось около 200 компетенций, которые нужно оценить. Собирать данные о таком количестве данных довольно трудоемко. Поддерживать их в актуальном состоянии еще сложнее. У не смог себя заставить пользоваться таким инструментом.
При этом матрицы компетенций широко применяют во многих отраслях — от торговли, до промышленности. И применяют их очень успешно. Оказалось, что количество навыков в матрице компетенций в других сферах около 20 или даже меньше. Почему бы не уменьшить число компетенций и в нашей сферы.
Начало внедрения
Начать стоит с малого. И даже точностью на первых шагах мы можем пожертвовать.
План:
- Выберите до 20 оцениваемых компетенций. Например: языки программирования, отдельные виды БД, автотестирование, 1. паттерны и т.д.
- Соберите данные с сотрудников. Сотрудник самостоятельно определяет степень владения технологией по шкале от 1 до 5.
- Нормализуйте данные. Это делает оценивающий сотрудник. Нормализация будет субъективной, но погрешности допустимы на этапе внедрения.
- Полученные данные занесите в единую матрицу компетенций.
- Собранные с сотрудников данные обязательно сохраните. Очень интересно наблюдать изменение самооценки сотрудников с течением времени.
Сбор данных
Оценку компетенций можно и нужно производить при собеседовании и найме сотрудников. Дополнительные оценки необходимо проводить и в процессе работы не реже одного раза в полгода. Это позволит отслеживать динамику развития.
Стоит добавить в матрицу цифру, которая отражает интерес сотрудника к развитию компетенции. Тогда вы сможете подбирать правильный проект для сотрудника и динамику интереса к различным технологиям у своих сотрудников.
По матрице компетенций отдельных сотрудников легко построить матрицу компетенций компании или отдельной команды.
Очень полезно строить матрицу компетенций проекта.
Анализ
Итак вы собрали данные. Пришло время получить хоть какую-то пользу.
Полученные матрицы дают такие возможности:
- Увидеть bus-фактор.
- Определить уровень сотрудника и точки роста.
- Помогают подбирать команду.
- Помогают подбирать проект и команду друг к другу.
Bus-фактор
Предположим, что у вас 5 сотрудников и у вас получилась такая матрица:
Эта матрица дает возможность определить bus-фактор.
На данной матрице можно увидеть, что Golang применять в компании пока вряд ли стоит. Никто не хочет быть зависимым от одного единственного сотрудника.
Давайте взглянем на получившуюся диаграмму компетенций. Bus-фактор виден и здесь. Этот же сотрудник явный лидер в знаниях PHP. И казалось бы это хорошо. Ведь он может написать любой код. И это и правда так. Он даже сумел разобраться в асинхронном PHP. Но кто этот код потом сможет поддерживать?
Стоит его ограничить в применении нестандартных подходов или поставить ему задачу на обучение таким техникам других сотрудников. Но в асинхронный PHP ходить не стоит.
Определение уровня сотрудника и точек роста
Приходит к вам сотрудник dev2 требовать повышения зарплаты. Вам нужно определиться с объективностью его требований. Нужно добавить к матрице абстрактных сотрудников с компетенциями junior, middle frontend и middle backend.
На матрице сразу видно, что уровень джуна сотрудник прошел. Но до любого из мидлов он явно не дотягивает.
На диаграмме хорошо видно, что сотруднику логичнее развиваться в сторону фронтенда и понятны направления в которых необходимо развиваться сотруднику, чтобы получить повышение.
Подбор команды
Активный обмен знаниями происходит только в команде. Для адекватного общения в команде интересы сотрудников в команде должны значительно пересекаться. Сложно представить активный обмен знаниями чистого бэкендера и чистого фронтендера или мобильного разработчика и сисадмина.
Задача:
В наличии 5 разработчиков. Нужно подобрать команду из 4 человек на проект. При этом необходимо обеспечить активный обмен знаниями внутри команды.
Разработчики:
В матрице явно видно сильного бэкендера, 3-х фуллстеков и сильного фронтендера.
Сложно представить активный обмен знаниями между dev1 и остальной командой. У него слабо пересекаются знания и интересы с остальной командой. В областях пересечения знаний dev1 намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде.
У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.
Прямо таки явные перекосы в интересах. Хотя и есть совпадающие, но их явно меньше чем различающихся.
Однако я бы отдал предпочтение такой команде:
Точки роста для каждого из сотрудников тут тоже очевидны.
Подобным образом можно подбирать проект и команду друг к другу.
И это только самые простые применения матрицы и диаграммы компетенций.
Итак оценка компетенций начала приносить пользу компании. Но встал вопрос в повышении точности? Только в этот момент стоит усложнять матрицы. И даже при этом большая матрица должна свестись к маленькой матрице, а визуализации делать уже с маленькой матрицы.
Для удобного использования матриц, будет мало гуглодока. Если вы знаете подобного рода инструмент напишите об этом в комментариях. А то так и чешутся руки навелосипедить.
P.S. Это сильно упрощенная модель. Тимлид должен знать свою команду. Матрица и диаграмма компетенций это лишь один из множества инструментов тимлида.
Комментарии (26)
CorneliusAgrippa
10.03.2019 17:39+3"намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде."
Профессор намного превышает студентов по уровню знаний. Следуя этой логике, ему будет сложно передавать им знания.
aak74 Автор
10.03.2019 17:45Не совсем так. Профессор нацелен на обучение. Программист в среднем на обучение не нацелен. Этот вывод из моих личных наблюдений. Чтобы это выяснить наверняка нужно провести исследование.
Ну и конечно тимлид должен знать сильно больше чем записано в матрице.
RPG18
11.03.2019 11:09Программист в среднем на обучение не нацелен.
А платить за обучение пробовали?
AEP
11.03.2019 12:03-1См. комментарий ниже (про доцента). Если продолжать аналогию, то надо сравнивать программиста, нацеленного обучать других, с профессором, а программиста того же ранга, но не нацеленного обучать других, с ведущим научным сотрудником.
Профессор тратит свое время не только на научную деятельность, но и на разработку методики преподавания и в том числе на создание учебных материалов. И ему платят в том числе за эту невидимую для студентов работу.RPG18
11.03.2019 12:25Вы это ближе к реальности. В реальности система мотивации привязана к достижению каких то целей к точке во времени. Т.е. если тратить время на обучение, то количество сделанных задач будет меньше.
aak74 Автор
11.03.2019 12:54И именно поэтому возлагать задачи обучения на сеньора… Далеко не всегда самое правильное решение.
Моей задачей было наладить гармоничный обмен знаниями внутри команды. А для этого уровень знаний должен быть сопоставим. Как и области знаний. Это мое личное мнение.
Это конечно не касается политики и футбола. Там все профессионалы одинаково высокого уровня.
AEP
10.03.2019 17:47Как ни странно, это верно. Доценты часто объясняют понятнее, чем профессора. Доценты помнят, что им самим давалось тяжело, и стараются разъяснить именно этот материал подробнее. Т.е. профессора считают неочевидное очевидным, и оставляют пробелы в понимании у студентов.
То же самое явление имеет место и в спортивных тренировках.aak74 Автор
10.03.2019 17:50Доценты помнят, что им самим давалось тяжело, и стараются разъяснить именно этот материал подробнее. Т.е. профессора считают неочевидное очевидным, и оставляют пробелы в понимании у студентов.
Спасибо за коммент. Именно эту мысль я и пытался донести.
Geminix
10.03.2019 18:14Зарплаты будут выравнивать с компетенциями? Насколько компания заинтересована в нахождении несоответствия зп и компетенции в обе стороны (плюс и минус)?
aak74 Автор
10.03.2019 18:19-1Уменьшать зарплату не стоит. Особенно если пользоваться столь несовершенным инструментом.
Воспользоваться матрицей как сигналом к увеличению можно и даже нужно.
Компания должна быть заинтересована в этом. Если это не так, то бегите.
sshikov
10.03.2019 18:27+3Еще где-то со времен Ф. Брукса известно, что хорошие программисты отличаются от плохих обычно не на проценты, а на порядки. Т.е. скажем в 10 раз, или даже в 100. Поэтому шкала оценки компетенций от 1 до 5 сразу вызывает вопросы.
>Сотрудник самостоятельно определяет степень владения технологией по шкале от 1 до 5.
Самоуверенный джуниор напишет, что владеет в совершенстве, а скромный синьор — оценит себя на балл ниже, потому что знает — совершенства вообще не бывает в природе. Да еще и циферки эти ничего не значат, потому что правила расстановки оценок не сформулированы. Ну еще и шкала вероятно логарифмическая (см. выше).
UnclShura
11.03.2019 00:48Стоит его ограничить в применении нестандартных подходов или поставить ему задачу на обучение таким техникам других сотрудников.
Вы только что потеряли хорошего сотрудника и свою репутацию. Работать с таким «начальником”? Да никогда!aak74 Автор
11.03.2019 07:15На месте специалиста, которому не дают развернуться нахожусь я.
Только я сам сознательно ограничиваю применение техник, которые известны только мне. Потому что интересы команды должны быть выше личных. Или может быть наоборот я эгоист и не хочу сопровождать всю жизнь свой код.
Если же программист сознательно пишет свой код непонятно для большинства своих коллег, то он не такой уж хороший специалист.
sairus777
11.03.2019 03:01Можно ли привести ссылки на первоисточники по «Классическому подходу» с матрицами и диаграммами компетенций?
oqqA
11.03.2019 07:05Приходит к вам сотрудник dev2 требовать повышения зарплаты. Вам нужно определиться с объективностью его требований.
При этом давая субъективные оценки компетенциям от 1 до 5…
Почему не от 1 до 10? И где грань между 4 и 5?
Lofer
Как же всегда было интересно видеть, когда принимают решения за других людей.
Откуда такие однобокие предположения?
aak74 Автор
За каких других людей?
Тимлиды принимают решения о формировании команды.
И Вы выделили целый абзац. С чем именно Вы не согласны?
Lofer
На чем базируется утверждение «У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.»? Почему не рассматривается сценарий, когда dev1 и dev5 работают в кооперации и скажут, что ни одна из БД не подходит?
На чем базируется такое утверждение? Формально, принято решение 'изолировать' dev1 от остальной команды.
Почему не предполагается сценарий, что dev1 будет перенимать знания у прочей команды?
Почему-то рассматриваются только конфликтные сценарии?
Почему не сценарии дополнения отсутсвующий знаний?
aak74 Автор
MongoDB vs MySQL
NoSQL vs SQL
Вечные холивары. Зачем это создавать?
А разве где-то сказано, что в компании только 5 разработчиков и для девелопера №1 нет другого проекта и другой команды?
Сценариев может быть много и я показываю только один из возможных.
Lofer
Это работа не программиста, а специально обученного человека. Выбирается не на «ринге», а по набору объективных критериев. Если у вас не умеют так делать, значит, наверное, надо учиться.
Вообще-то утверждение «Сложно представить активный обмен знаниями между dev1 и остальной командой.» — именно об том и говорит.
Почему-то кто-то «представляет», проецируя свою логику и поведение на Того Парня, не допуская что оно напрочь ошибочное и не укладывается в мотивацию dev1?
aak74 Автор
Почему-то кто-то считает, что прочитал мысли автора статьи. Но это не так.
У меня десяток команд на разных проектах. Я формирую новую. Такого не бывает?
AEP
Предположения взялись из анализа предпосылок для передачи/получения каждого из навыков. Например, предположения однозначно оправданы, если задача для dev1 стоит как «обучи dev2 основам unit-тестирования». Для этого надо, как минимум, иметь общий язык, и (для обучающего) знать «правильный» фреймворк для Unit-тестирования на этом языке.
Еще в матрицу компетенций неплохо бы добавить преподавательские способности.
aak74 Автор
Именно так.
Все остальное стоит воспринимать как сильно упрощенную модель.