![](https://habrastorage.org/getpro/habr/upload_files/204/809/6bb/2048096bb42fc1f4a6036f845768b32e.jpeg)
Посадить дерево... в таблицу
Рано или поздно в большинстве компаний с расширением штата все приходят к необходимости собрать компетенции сотрудников в одном месте. Так совпало, что когда я пришла к идее осуществить это на практике, у команды DevOps-инженеров в GlowByte появился новый тимлид Гриша shut0v, который озаботился фактически таким же вопросом в отношении своих коллег с целью узнать их получше. И мы решили развивать матрицу вместе.
Технические нюансы и ситуации, с которыми столкнулся Гриша:
Работа в консалтинге подразумевает участие в проектах с различным стеком технологий. Раздувать команду или воспитывать универсальных “бойцов” невыгодно, а бизнес ждать не будет, работать нужно сейчас.
Требуются DevOps-инженеры не только с базой, но и со специфическими знаниями ML.
Если в команду пришёл джун/мидл, надо чётко понимать, что и как в него вложить, чтобы не перегреть и одновременно эффективно использовать его знания, решить, чем именно заинтересовать.
Big data, машинное обучение, Hadoop, нейронные сети… Разные проекты, на которых коллеги формируют и повышают уникальную компетенцию, часто она уходит вместе с ними, если они покидают команду. Возникает вопрос: как передавать этот опыт, как его фиксировать?
Нередкие случаи: “для проекта нужен инженер – 10 лет опыта администрирования хадуп, 5 лет промышленного кубера, писать на питоне и джаве и работать за МРОТ”.
Ну и последнее. Стартует проект, а менеджер приходит с невнятным описанием того, кто, когда и зачем нужен, “давайте смотреть всех, кто есть”.
Какие проблемы увидела я как менеджер проектов:
Аналогичные трудности с подбором специалиста под определённые проекты, даже если есть чёткое ТЗ.
Постоянное расширение команд, а это зачастую отсутствие контроля роста и понимания (в том числе у руководителей направлений), кто есть в командах. Уверена, многие из вас сталкивались с этим.
Прозрачность в карьерном росте сотрудников. Сотрудник должен понимать, куда ему расти, что ему необходимо проработать. Круто, если у него есть карта роста, ещё круче, если она визуализирована.
Защита вакансий перед руководством. Должно быть понимание, чем подкрепить потребность в открывшихся вакансиях.
Перебрав разные имеющиеся инструменты, выбор пал на матрицу компетенций. Да, он не нов, но дальше опишу, как мы его применили, как развиваем, с какими проблемами столкнулись и как их попытались решить.
Итак, началось всё с дерева компетенций. Его создал Гриша на старте своей работы. Он аккумулировал всё, даже самые специфические навыки: что коллегам интересно изучать и что для них важно. Получилось дерево с толстыми ветками из направлений и тонкими ветвями по конкретным инструментам. Вышло красиво, но неудобно, особенно в разрезе нескольких сотрудников.
![Рисунок 1. Дерево компетенций Рисунок 1. Дерево компетенций](https://habrastorage.org/getpro/habr/upload_files/b0d/01c/aad/b0d01caad99b34fd3a56be20fef703fa.png)
Первое, что я сделала, перевела дерево в табличный вид. Получилась следующая картина:
![Рисунок 2. Матрица компетенций по инструментам Рисунок 2. Матрица компетенций по инструментам](https://habrastorage.org/getpro/habr/upload_files/e25/38e/139/e2538e13959ec1b9399c830a11578bbd.png)
![Рисунок 3. Матрица компетенций по направлениям Рисунок 3. Матрица компетенций по направлениям](https://habrastorage.org/getpro/habr/upload_files/b87/14d/277/b8714d277bbe86356a92cd7fff21969d.png)
Далее приступили к проработке софт-скилов. Софт-скилы – важная составляющая не только касательно команды, но и проекта в целом, поэтому мы их включили в нашу матрицу.
Сначала составили скелет общей матрицы, а именно:
Выделили ключевые скилы, которые так или иначе используются в жизни проекта и команды. Они трансформировались в бизнес-группы: бизнес-отрасли и кейсы (в консалтинге важная часть касательно проектов: могут быть финансовые проекты, в сфере банковской инфраструктуры, в ритейле, телекоме и т. д.), коммуникабельность, менеджмент и кураторство, личный тайм-менеджмент, социализация.
Подключили других менеджеров проектов, лидеров команд. По итогу собрали 21 навык, который так или иначе влияет на работу, объединили в группы. В число таких навыков попали “температура горения” (показывает, как сотрудник себя чувствует, и не нужна ли ему смена проекта/обстановки), уровень токсичности для выстраивания разговора в правильном русле, уровень лояльности и мотивации, помогающий оценить заинтересованность в текущей работе.
Определили легенду. Она достаточно простая: 1 – нет навыков, а 5 – экспертный уровень. Подобрали соответствующие цвета, которые подкрашиваются автоматически при выставлении оценок (очень наглядно и удобно).
Выделили грейды и проставили им оценки исходя из нашего опыта и понимания, кто в чём должен быть экспертом, и общей картины, которая сложилась после опроса команды. Например, у тимлида должно отлично получаться курировать команду, распределять задачи и т. д.
Ориентируясь на матрицу, появилась возможность проработать гибкие навыки, нужные для роста. Это полезно и для команды, и для проекта, упрощает процесс выстраивания диалога с заказчиком и сотрудником.
![Рисунок 4. Матрица компетенций по софт-скилам Рисунок 4. Матрица компетенций по софт-скилам](https://habrastorage.org/getpro/habr/upload_files/452/4cf/643/4524cf64397dc1d8211670ef87f673da.png)
Следующим шагом была проработка таблицы с хард-скилами:
В первую очередь распределили все скилы по направлениям: Базы данных, Cloud, CI/CD и т. д. Внутри этих групп разместили инструменты, совсем специфичные выделили в отдельную подгруппу, которая не участвует в общей оценке.
Добавили легенду, чтобы ребята не путались с оценкой.
В ходе тестирования матрицы командой возникла потребность в нулевой оценке – жёсткий отказ от изучения, сотруднику не интересно заниматься тем или иным направлением.
![Рисунок 5. Матрица компетенций по хард-скилам Рисунок 5. Матрица компетенций по хард-скилам](https://habrastorage.org/getpro/habr/upload_files/9fa/c31/4f6/9fac314f6f30f0728a9f7f7e98a649f4.png)
Кстати, был случай отказа одним коллегой от методологии, такие истории мы воспринимаем нормально. Изначально ведь хочется заинтересовать сотрудника, если же он не видит потребности в прохождении матрицы, мы не настаиваем. Ещё был кейс, когда один из ребят захотел перейти из команды аналитиков в DevOps-инженеры. После заполнения матрицы и понимания, сколько всего необходимо изучить, желание расти именно в эту сторону пропало.
Принцип выставления оценок и подсчёта показателей
По каждому инженеру выставляется две оценки: личная, когда сотрудник оценивает сам себя, и оценка тимлида. В первоначальном варианте была только личная оценка, но мы столкнулись с проблемой, когда человек недооценивает себя, реже – переоценивает. Так появился коррелирующий балл в лице тимлида.
Далее высчитывается среднее значение по каждому техническому инструменту и наибольшее – внутри направления. Изначально мы пытались также брать среднее по инструментам внутри направления, но универсальных “бойцов” с высокой компетентностью по всем технологиям не бывает, а значит правильнее было ориентироваться на наибольший балл из инструментов и выставлять его по направлению.
![Рисунок 6. Пример расчёта Рисунок 6. Пример расчёта](https://habrastorage.org/getpro/habr/upload_files/60d/b93/a4e/60db93a4e1ad426e2ee99a66b739cf91.png)
Визуализация
Мне захотелось получить из всех этих цифр что-нибудь визуально понятное и красивое. Исходя из этих соображений, я построила лепестковую диаграмму, показывающую уровень компетентности по хард-скилам. Что нам это дало:
Наглядность. Видно, по каким направлениям мы просели, а значит мы либо отправим кого-то обучаться, либо откроем вакансию.
Информативность. По части направлений у нас оказался один компетентный сотрудник, следовательно, нужно расширять знания внутри команды.
Возможность определить эксперта по направлению участникам команды для выбора куратора или просто консультации. Так как матрицу видит только руководство и тимлид, раскрыть график показалось нам хорошей идеей.
![Рисунок 7. Лепестковая диаграмма по хард-скиллам Рисунок 7. Лепестковая диаграмма по хард-скиллам](https://habrastorage.org/getpro/habr/upload_files/1d8/80d/9a9/1d880d9a98a731d20526c5180e69aa7d.png)
Важные моменты по матрице
Матрица обновляется на каждом performance review с сотрудником посредством персональных опросников. Благодаря ей можно наглядно представить историчность данных, оценить динамику роста специалиста, помочь в выборе для развития нужных навыков.
Её могут просматривать только тимлид команды и руководство. Для сотрудников открыта лепестковая диаграмма по техническому стеку и персонализированная матрица.
Прохождение опросника к матрице и в целом её составление по специалисту – история необязательная, но желательная.
![Рисунок 8. Историчность данных Рисунок 8. Историчность данных](https://habrastorage.org/getpro/habr/upload_files/7d5/fab/b0d/7d5fabb0d24d37f6cfd23b547e70459d.png)
Зачем нужна матрица, или Как это работает на практике
Стартует проект. Команда собирает требования и составляет технический стек проекта, рисует лепестковую диаграмму на основе результатов первичного анализа. Далее по графику определяет, какие технологии необходимо “покрыть” и на каком уровне.
![Рисунок 9. Технический стек проекта Рисунок 9. Технический стек проекта](https://habrastorage.org/getpro/habr/upload_files/b51/a96/6a9/b51a966a92c09cc45cfeb325e58f5011.png)
С этими результатами команда обращается к тимлиду за подбором команды на проект. Определяются специалисты, основываясь в том числе на матрицу компетенций. Далее отрисовывается диаграмма по техническому стеку команды.
![Рисунок 10. Технический стек команды Рисунок 10. Технический стек команды](https://habrastorage.org/getpro/habr/upload_files/a68/15d/d08/a6815dd08988eea43e59f1ca65d95399.png)
![Рисунок 11. Софт-скилы команды Рисунок 11. Софт-скилы команды](https://habrastorage.org/getpro/habr/upload_files/fd5/da9/733/fd5da9733b435c1907daf95e7e3dfb23.png)
Легенда
А - Понимание процессов в одной из базовых отраслей (Ритейл, Банки, Телеком)
Б - Способность предлагать новые задачи/решения
В - Способность оказывать консультации по бизнес области
Г - Митапы, подготовка презентаций, публикация статей
Д - Способность находить компромисс между бизнесовыми и техническими ограничениями
Е - Умение описывать бизнес-контекст технической работы
Ж - Способность работать в условиях неопределенности
З - Общение с заказчиком
И - Презентация своих задач
К - Способность налаживать отношения со специалистами на новых аккаунтах
Л - Самостоятельность в управлении своими задачами, приоритизация
М - Курирование членов команды
Н - Управление своими задачами и задачами подчиненных
О - Замещение Lead-а в случае необходимости
П - Подбор людей в команду
Р - Создание позитивной атмосферы в команде
С - Самостоятельность в управлении своими задачами, приоритизация
Т - Работа с несколькими задачами одновременно, переключение между ними с мин. потерями времени
У - Умение делегировать задачи с целью повышения продуктивности, и развития младших коллег
Ф - Способность реально оценивать задачи
Наложив полученные данные на команду, делается предварительный вывод, какие трудности могут возникнуть в ходе проекта, какие риски нужно заложить и как выстраивать диалог между заказчиком и командой.
Бонус
Матрицу компетенций можно использовать и для составления портрета заказчика по софт-скилам. Вообще делиться такого рода информацией полезно: благодаря этому уже на пресейле можно понимать, с кем предстоит работать и как выстраивать взаимодействие.
Можно, например, выделить следующие показатели оценки заказчика:
Вовлечённость. Заказчик может быть не заинтересован в проекте, занимать нейтральную позицию, поддерживать или, наоборот, мешать.
Коммуникация. Какой уровень общения необходим заказчику. Он может не идти на контакт, и всё нужно будет тянуть из него клещами, или же, наоборот, быть общительным и ценящим внимание.
Контроль. Требуется каждую неделю присылать отчёт о проделанной работе, презентации с графиками и т. д. А может оказаться и другим: ТЗ отдал и забыл.
Степень лояльности. Лояльный – нет никаких особых проблем, давно с ним работаем и сюрпризов не ожидаем. Средней лояльности – также особых проблем нет, но и большой любви не ожидаем. Проблемный – долго отвечает на вопросы, что влечёт за собой срыв сроков, не принимает реализацию и т. д.
Команда со стороны заказчика, с кем нужно будет работать и какие у них компетенции.
Менеджер, зная всё это, оценивает сложившуюся ситуацию, если нужно, просчитывает возможные риски, подробно прорисовывает и описывает прототип и доносит до команды способ общения с заказчиком.
Выводы
Поколение, которое любит “ачивки” из игр, хорошо восприняло описанную инициативу в работе. Одним ребятам матрица помогает выбрать ориентир, другим служит справочником и помогает определиться, к кому обратиться за компетенцией при решении задачи, третьим – оценить прогресс в работе.
По итогу мы сделали матрицу компетенций и частью онбординга, что значительно упростило задачу вывода сотрудника на проект.
Периодически мы встречаемся с командой для сбора обратной связи и по возможности продолжаем развивать инструмент. Также есть желание применить его и в других командах GlowByte. Кое-какие шаги в этом направлении мы уже сделали. Фидбэк был разный, потому активно пока не “лоббируем” эту тему.
wizard_s
Главный вопрос: Как определяется, что такое для скилла "nginx" (подставьте любой другой) 1, а что такое 4? И есть ли в компании тот, кто знает на 5 (и кто оценил, что он знает на 5?), чтобы адекватно оценить, что кто-то знает на 4?
По идее к такой системе по каждому инструменту должен прилагаться отраслевой или внутренний стандарт, в котором описано, что на 1 надо уметь писать простой proxy_pass, а на 4 с закрытыми глазами делать логику на lua и perl. Где его взять?