Меня зовут Иван Антипин, я заместитель технического директора AGIMA. На рынке сложилась тяжелая ситуация: многие компании закрываются, а сработанные и крепкие команды распадаются под давлением обстоятельств. В этой статье расскажу об инструменте управления рисками — о матрице компетенций. Этот подход помогает распределять задачи с учетом балансировки нагрузки, избегать выгорания и неожиданной потери ключевых компетенций в команде. Текст написан на основе нашего с GeekBrains курса для тимлидов, по материалам лекции Ивана Михеева.

Хабр

Управлять компетенциями важно

Каждый тимлид однажды сталкивается с неожиданными проблемами. Еще вчера все было под контролем, а сегодня Senior-разработчик говорит, что уходит из команды, потому что не видит развития. В то же время приходит перспективный Junior и заявляет примерно то же самое: не понимает, как расти дальше и что делать — и уже начал терять интерес и мотивацию.

Бывают и более общие ситуации. Например, бизнес-заказчик просит перераспределить команду между двумя проектами, а как это сделать — непонятно. Тут уберешь разработчика — первый проект упадет, а этого переставишь — там всё сломается. Еще хуже, когда из команды уходит человек с уникальными навыками и заменить его пока некем — так называемый Bus-фактор. Совсем плохо, если это происходит неожиданно и времени передать дела не так много.

Все эти ситуации неприятные, но есть хорошая новость. Справится с ними простой инструмент — матрица компетенций.

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

Это таблица с ролями и навыками, важными для командной цели. Примерно такая:

Цифры в таблице показывают, насколько хорошо у сотрудников развиты нужные компетенции. Это могут быть как Hard Skills, так и Soft Skills. Выглядеть таблица может как угодно. Иногда ее оформляют в виде диаграммы, чтобы увидеть, какая компетенция выделяется в команде, а какую нужно подтянуть. Выглядит это вот так:

Оценить каждую компетенцию можно в любой шкале: цифры, знаки, буквы. Главное — чтобы они были синхронны для каждого сотрудника и каждого навыка. Например, единичка в навыке 1 и единичка в навыке 3 должны указывать на одинаковый уровень владения ими. Без этого не получится адекватная аналитика.

Как оценивать навыки

Правильно оценить любую компетенцию будет проще, если знать, как люди учатся. Посмотрим на график:

На нем мы видим 4 сектора. Каждый обозначает отдельный этап познания:

  • Неосознанное незнание: человек не знает, нужен ему какой-то навык или нет, либо вообще не знает о существовании этого навыка.
  • Осознанное незнание: человек уже понял, что ему нужно получше разобраться в вопросе и освоить что-то новое, но пока этого не сделал.
  • Осознанное знание: человек получил новый навык, но пока не довел его до автоматизма, он знает, как делать, но ему нужно прикладывать усилия.
  • Неосознанное знание: человек довел умение до автоматизма и перестал отдавать себе отчет, как он решает задачу — решает и всё.

Эта модель поможет оценить знания и навыки сотрудников. Самый простой подход — взять числа от 0 до 3 и присвоить каждой стадии. Тогда получится, что неосознанное незнание — это 0, а неосознанное знание — 3. Но можно использовать и другие диапазоны: например, от 0 до 10 — незнание, от 10 до 20 — знание и т. п. Главное, чтобы шкала подчинялась одной логике и правилам для всех.

Как составить матрицу

Работа над матрицей состоит из 3 этапов. На каждом свои особенности и нюансы.

I этап. Выделить необходимые навыки.

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

  • по технологиям (фреймворки, базы данных и т. п.);
  • по подходам (паттерны проектирования и т. п.);
  • по ролям в команде (Frontend, Backend, тестирование и т. п.);
  • по классам решаемых задач (SQL для питониста).

Важно, чтобы каждый навык был не просто задекларирован, но и детально описан. Что он в себя включает? Какие критерии вы учитываете? Как будете оценивать? Ответы на эти вопросы нужно зафиксировать.

II этап. Оценить каждого сотрудника.

К этому процессу есть несколько подходов.

  • Оценка 360. Каждый, кто взаимодействует с сотрудником, делится мнением о том, насколько хорошо тот владеет навыками из списка. Опрос можно проводить письменно и устно. Удобно делать это через Google-форму. Чем больше людей опросите, тем более объективной будет оценка. Но учитывайте, что очень профессионального, но грубого человека оценят почти наверняка ниже, чем он заслуживает. Поэтому лучше использовать этот инструмент для оценки Soft Skills.
  • Тестирование. Вы составляете вопросы и предлагаете человеку ответить. Вопросы должны быть корректными и правильными — отражать потребности проекта. Ваша задача — объективно оценить именно навыки, нужные для конкретных задач, а не познания в PHP.
  • Самооценка. Вы предлагаете сотрудникам самим поставить себе баллы по важным компетенциям. Шкалу можно определить самостоятельно — главное, чтобы для всех она была одинаковой. Здесь нужно учесть нюансы: есть люди, которые завышают себе оценки, а есть те, кто не может побороть синдром самозванца и оценки занижает. Поэтому разумно попросить наставников или более опытных коллег эти оценки проверить. Это может стать отдельным способом оценить команду.
  • Оценка наставников. Кураторы и наставники оценивают менее опытных членов команды по шкале, которую вы для них зададите. Из их мнения складывается матрица.

III этап. Актуализировать матрицу.

Делать это нужно регулярно. Вот только несколько ситуаций, в которых она может понадобиться:

  • у вас открывается новое направление;
  • у вас расширяется команда;
  • вы начинаете использовать новый стек;
  • вы запускаете новый продукт;
  • у вас появляется еще одна команда.

Как только в матрице появляются новые незаполненные столбцы и строки, анализировать ее становится сложнее. Поэтому важно следить за ее актуальностью. Частота опросов зависит от динамики изменения бизнеса. Если команда 10 лет работает над одним проектом, то необходимые навыки не меняются — обновлять матрицу можно раз в год или реже. Если же команда работает на стартапе, который постоянно развивается, то и навыки нужны все время разные, и сотрудники растут быстрее. Тогда матрицу приходится обновлять чаще — например, раз в полгода.

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

Как применять матрицу

Матрица компетенций в первую очередь помогает принимать управленческие решения. Рассмотрим на примере. У нас матрица на троих человек и четыре навыка. Кто из них самый эффективный?

Ответ можем получить просто просуммировав баллы. Тогда выходит, что Михаил эффективнее всех. Но на самом деле суммирование не имеет смысла. Важнее понимать, на каком участке сотрудник должен быть эффективным.

Если мы разделим навыки на классы задач, которые решает сотрудник, то выясним, что Иван более эффективен во Frontend-задачах, а Михал — в Backend-задачах. А общая сумма не важна. Больше значения имеет, насколько они хороши в задачах, которые решают каждый день.

Чтобы сотрудники понимали свой уровень, можно положить матрицу в основу грейдирования. Если по классу задач минимальная оценка сотрудника — двойка, то он Middle-разработчик. Если тройка — то Senior. Тогда матрица приобретет привычный вид. А еще будет проще понять, кто и в каком стеке у вас Senior, кто Middle, а кому нужно освоить какие-то технологии, которые пригодятся ему в будущем.

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

Как с помощью матрицы распределять ресурсы

Ситуация: ваш бизнес-заказчик открывает новое направление. Теперь вам нужно быстро подготовить инфраструктуру и нанять 2 новых сотрудников. Это проблема: поставить новичков в изолированную команду на изолированный модуль нельзя. Они не знают правила работы, не знакомы с инфраструктурой и не понимают ваш код-стайл. Скорее всего, придется выделить одного разработчика из действующей команды. Как это сделать, не навредив налаженному процессу?

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

Тогда вы увидите, что забирать сотрудника из команды №4 нельзя — по ним это ударит сильнее всего. А вот забрать из команды №3 можно — это несильно повлияет на средний уровень навыка, команда не так сильно потеряет в качестве и скорости.

Матрица поможет и с Bus-фактором. Часто в команде главные компетенции сосредоточены в руках одного-двух человек. Эти люди знают, как все устроено на проекте и где что лежит. Если они уйдут, то утащат весь багаж знаний с собой. Восстановить баланс будет сложно. Чтобы этого не произошло, с помощью матрицы можно обнаружить и устранить узкие места.

Допустим, для проекта важны 3 навыка: Angular, React и Vue. У вас 4 разработчика, которые разбираются в этих темах на разном уровне. Матрица показывает, что Angular — ваше узкое место.

Это значит, что вам не очень выгодно вести разработку на Angular. Но если у вас уже есть код и компоненты, которые на нем разработаны, то стоит задуматься, как расширить эту экспертизу и кому передать знания. Матрица показывает, что ближе всего к этому разработчик №4 — его и стоит обучить.

Как сбалансировать навыки в команде

Иногда важно разобраться, насколько команда квалифицирована в отдельных вопросах. Здесь матрица тоже поможет. Для этого нужно построить среднее распределение навыков внутри команды и посмотреть, какой экспертизы не хватает.

На диаграмме выше видно, что в команде плохо знают Angular. Если вы переходите с него на Vue, то это нестрашно. Но если на Angular разработан ваш core-функционал, то вам явно пора увеличивать компетенции в этой теме внутри команды.

Еще важно следить за балансом по грейдам. Если у вас много Junior-специалистов и всего один Senior, то последнему скоро станет скучно. Но когда наоборот — много Senior-разработчиков и всего один Junior — тоже плохо. Более опытные не смогут делегировать простые задачи и будут решить их сами. Перекосы по технологиям тоже мешают команде. Если один сотрудник хорошо знает MySQL, а другой — PostgreSQL, то это почва для конфликта. Оба сотрудника будут считать, что их инструмент наиболее эффективен.

Чем полезна матрица компетенций

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

  1. Контролировать уровень знаний в команде.
  2. Распределять ресурсы эффективно и безболезненно для остальных команд.
  3. Мотивировать сотрудников и планировать их развитие (составлять индивидуальные планы развития, планировать KPI).
  4. Снижать риски потери знаний, если они сосредоточены у одного человека.
  5. Заложить основу для разработки грейдов или валидировать их объективность и актуальность.

Всего один простой инструмент может снять с тимлида огромное количество вопросов. Рекомендуем попробовать.

P. S. А если вы знаете подобные инструменты, которыми пользовались и которые тоже показали эффективность, расскажите о них в комментариях.