Применение матрицы и диаграммы компетенций

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


    Хорошим инструментом является матрица компетенций в связке с диаграммами компетенций.


    Начнем с терминологии.


    Термины


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


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


    Диаграмма компетенций — это лепестковая диаграмма, которая визуализирует численные показатели компетенций сотрудников.


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


    Классический подход


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


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


    Начало внедрения


    Начать стоит с малого. И даже точностью на первых шагах мы можем пожертвовать.


    План:


    1. Выберите до 20 оцениваемых компетенций. Например: языки программирования, отдельные виды БД, автотестирование, 1. паттерны и т.д.
    2. Соберите данные с сотрудников. Сотрудник самостоятельно определяет степень владения технологией по шкале от 1 до 5.
    3. Нормализуйте данные. Это делает оценивающий сотрудник. Нормализация будет субъективной, но погрешности допустимы на этапе внедрения.
    4. Полученные данные занесите в единую матрицу компетенций.
    5. Собранные с сотрудников данные обязательно сохраните. Очень интересно наблюдать изменение самооценки сотрудников с течением времени.

    Сбор данных


    Оценку компетенций можно и нужно производить при собеседовании и найме сотрудников. Дополнительные оценки необходимо проводить и в процессе работы не реже одного раза в полгода. Это позволит отслеживать динамику развития.


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


    По матрице компетенций отдельных сотрудников легко построить матрицу компетенций компании или отдельной команды.


    Очень полезно строить матрицу компетенций проекта.


    Анализ


    Итак вы собрали данные. Пришло время получить хоть какую-то пользу.


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


    1. Увидеть bus-фактор.
    2. Определить уровень сотрудника и точки роста.
    3. Помогают подбирать команду.
    4. Помогают подбирать проект и команду друг к другу.

    Bus-фактор


    Предположим, что у вас 5 сотрудников и у вас получилась такая матрица:


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


    Эта матрица дает возможность определить bus-фактор.


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


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


    Давайте взглянем на получившуюся диаграмму компетенций. Bus-фактор виден и здесь. Этот же сотрудник явный лидер в знаниях PHP. И казалось бы это хорошо. Ведь он может написать любой код. И это и правда так. Он даже сумел разобраться в асинхронном PHP. Но кто этот код потом сможет поддерживать?


    Стоит его ограничить в применении нестандартных подходов или поставить ему задачу на обучение таким техникам других сотрудников. Но в асинхронный PHP ходить не стоит.


    Определение уровня сотрудника и точек роста


    Приходит к вам сотрудник dev2 требовать повышения зарплаты. Вам нужно определиться с объективностью его требований. Нужно добавить к матрице абстрактных сотрудников с компетенциями junior, middle frontend и middle backend.


    Матрица компетенций с уровнями


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


    Диаграмма компетенций с уровнями


    На диаграмме хорошо видно, что сотруднику логичнее развиваться в сторону фронтенда и понятны направления в которых необходимо развиваться сотруднику, чтобы получить повышение.


    Подбор команды


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


    Задача:


    В наличии 5 разработчиков. Нужно подобрать команду из 4 человек на проект. При этом необходимо обеспечить активный обмен знаниями внутри команды.


    Разработчики:


    Матрица компетенций. Подбор команды.


    В матрице явно видно сильного бэкендера, 3-х фуллстеков и сильного фронтендера.


    Сложно представить активный обмен знаниями между dev1 и остальной командой. У него слабо пересекаются знания и интересы с остальной командой. В областях пересечения знаний dev1 намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде.


    Диаграмма компетенций. Подбор команды.


    У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.


    Диаграмма компетенций. Конфликт


    Прямо таки явные перекосы в интересах. Хотя и есть совпадающие, но их явно меньше чем различающихся.


    Однако я бы отдал предпочтение такой команде:


    Диаграмма компетенций. Хорошая команда.


    Точки роста для каждого из сотрудников тут тоже очевидны.


    Подобным образом можно подбирать проект и команду друг к другу.


    И это только самые простые применения матрицы и диаграммы компетенций.


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


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

    P.S. Это сильно упрощенная модель. Тимлид должен знать свою команду. Матрица и диаграмма компетенций это лишь один из множества инструментов тимлида.

    Поделиться публикацией

    Комментарии 28

      +3
      У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.

      Сложно представить активный обмен знаниями между dev1 и остальной командой. У него слабо пересекаются знания и интересы с остальной командой. В областях пересечения знаний dev1 намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде.

      Как же всегда было интересно видеть, когда принимают решения за других людей.
      Откуда такие однобокие предположения?
        –2
        Как же всегда было интересно видеть, когда принимают решения за других людей.

        За каких других людей?
        Тимлиды принимают решения о формировании команды.

        И Вы выделили целый абзац. С чем именно Вы не согласны?
          +2
          За каких других людей?

          На чем базируется утверждение «У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.»? Почему не рассматривается сценарий, когда dev1 и dev5 работают в кооперации и скажут, что ни одна из БД не подходит?
          Сложно представить активный обмен знаниями между dev1 и остальной командой.

          На чем базируется такое утверждение? Формально, принято решение 'изолировать' dev1 от остальной команды.
          Почему не предполагается сценарий, что dev1 будет перенимать знания у прочей команды?
          Почему-то рассматриваются только конфликтные сценарии?
          Почему не сценарии дополнения отсутсвующий знаний?
            –1
            На чем базируется утверждение «У dev1 с dev5 будут вечные разногласия на предмет самой правильной БД.»?

            MongoDB vs MySQL
            NoSQL vs SQL
            Вечные холивары. Зачем это создавать?

            Формально, принято решение 'изолировать' dev1 от остальной команды.

            А разве где-то сказано, что в компании только 5 разработчиков и для девелопера №1 нет другого проекта и другой команды?

            Сценариев может быть много и я показываю только один из возможных.
              +1
              Вечные холивары. Зачем это создавать?

              Это работа не программиста, а специально обученного человека. Выбирается не на «ринге», а по набору объективных критериев. Если у вас не умеют так делать, значит, наверное, надо учиться.
              А разве где-то сказано, что в компании только 5 разработчиков и для девелопера №1 нет другого проекта и другой команды?

              Вообще-то утверждение «Сложно представить активный обмен знаниями между dev1 и остальной командой.» — именно об том и говорит.
              Почему-то кто-то «представляет», проецируя свою логику и поведение на Того Парня, не допуская что оно напрочь ошибочное и не укладывается в мотивацию dev1?
                –1
                Почему-то кто-то «представляет», проецируя свою логику и поведение на Того Парня, не допуская что оно напрочь ошибочное и не укладывается в мотивацию dev1?

                Почему-то кто-то считает, что прочитал мысли автора статьи. Но это не так.

                У меня десяток команд на разных проектах. Я формирую новую. Такого не бывает?
          0
          Предположения взялись из анализа предпосылок для передачи/получения каждого из навыков. Например, предположения однозначно оправданы, если задача для dev1 стоит как «обучи dev2 основам unit-тестирования». Для этого надо, как минимум, иметь общий язык, и (для обучающего) знать «правильный» фреймворк для Unit-тестирования на этом языке.

          Еще в матрицу компетенций неплохо бы добавить преподавательские способности.
            0
            Еще в матрицу компетенций неплохо бы добавить преподавательские способности.

            Именно так.

            Все остальное стоит воспринимать как сильно упрощенную модель.
          +3

          "намного превышает остальных по уровню знаний. И ему будет сложно передавать знания остальной команде."


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

            –1
            Не совсем так. Профессор нацелен на обучение. Программист в среднем на обучение не нацелен. Этот вывод из моих личных наблюдений. Чтобы это выяснить наверняка нужно провести исследование.
            Ну и конечно тимлид должен знать сильно больше чем записано в матрице.
              0
              Программист в среднем на обучение не нацелен.

              А платить за обучение пробовали?

                0
                Пробовали.
                Хороший программист не факт, что хороший преподаватель.
                  0
                  Так и обучать же не с нуля.
                  –1
                  См. комментарий ниже (про доцента). Если продолжать аналогию, то надо сравнивать программиста, нацеленного обучать других, с профессором, а программиста того же ранга, но не нацеленного обучать других, с ведущим научным сотрудником.

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

                      Моей задачей было наладить гармоничный обмен знаниями внутри команды. А для этого уровень знаний должен быть сопоставим. Как и области знаний. Это мое личное мнение.

                      Это конечно не касается политики и футбола. Там все профессионалы одинаково высокого уровня.
                0
                Как ни странно, это верно. Доценты часто объясняют понятнее, чем профессора. Доценты помнят, что им самим давалось тяжело, и стараются разъяснить именно этот материал подробнее. Т.е. профессора считают неочевидное очевидным, и оставляют пробелы в понимании у студентов.

                То же самое явление имеет место и в спортивных тренировках.
                  0
                  Доценты помнят, что им самим давалось тяжело, и стараются разъяснить именно этот материал подробнее. Т.е. профессора считают неочевидное очевидным, и оставляют пробелы в понимании у студентов.

                  Спасибо за коммент. Именно эту мысль я и пытался донести.
                0

                Зарплаты будут выравнивать с компетенциями? Насколько компания заинтересована в нахождении несоответствия зп и компетенции в обе стороны (плюс и минус)?

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

                  Компания должна быть заинтересована в этом. Если это не так, то бегите.
                  +4
                  Еще где-то со времен Ф. Брукса известно, что хорошие программисты отличаются от плохих обычно не на проценты, а на порядки. Т.е. скажем в 10 раз, или даже в 100. Поэтому шкала оценки компетенций от 1 до 5 сразу вызывает вопросы.

                  >Сотрудник самостоятельно определяет степень владения технологией по шкале от 1 до 5.
                  Самоуверенный джуниор напишет, что владеет в совершенстве, а скромный синьор — оценит себя на балл ниже, потому что знает — совершенства вообще не бывает в природе. Да еще и циферки эти ничего не значат, потому что правила расстановки оценок не сформулированы. Ну еще и шкала вероятно логарифмическая (см. выше).
                    +1
                    Стоит его ограничить в применении нестандартных подходов или поставить ему задачу на обучение таким техникам других сотрудников.


                    Вы только что потеряли хорошего сотрудника и свою репутацию. Работать с таким «начальником”? Да никогда!
                      0
                      На месте специалиста, которому не дают развернуться нахожусь я.
                      Только я сам сознательно ограничиваю применение техник, которые известны только мне. Потому что интересы команды должны быть выше личных. Или может быть наоборот я эгоист и не хочу сопровождать всю жизнь свой код.

                      Если же программист сознательно пишет свой код непонятно для большинства своих коллег, то он не такой уж хороший специалист.
                      0
                      Можно ли привести ссылки на первоисточники по «Классическому подходу» с матрицами и диаграммами компетенций?
                        0
                        Приходит к вам сотрудник dev2 требовать повышения зарплаты. Вам нужно определиться с объективностью его требований.


                        При этом давая субъективные оценки компетенциям от 1 до 5…
                        Почему не от 1 до 10? И где грань между 4 и 5?
                          –1
                          да хоть от одного до ста
                          это сути не меняет вообще
                            0
                            Соглашусь, что лучше использовать шкалу оценки 0-10. Это позволит сделать более точек оценку. Причём перед тем как оценивать, необходимо зафиксировать что в идеале означает каждая цифра. Как минимум нужно описать 0,10 и ещё несколько реперных значений.
                            0
                            Стоит добавить в матрицу цифру, которая отражает интерес сотрудника к развитию компетенции. Тогда вы сможете подбирать правильный проект для сотрудника и динамику интереса к различным технологиям у своих сотрудников.

                            Если вы работаете в крупной компании, и основным «поставщиком» проектов для вас законодательство, то вы не сможете учитывать интересы сотрудника к технологиям/проектам, только если вы не R&D. Либо вы будите его «продавать команде», найти что-то что их заинтересует и на чем они смогут прокачать свою экспертизу. Но тут есть обратная сторона, что будет если они не купят?

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

                            Самое читаемое