Заходят тимлид, менеджер и инженер в бар, а там матрица компетенций…
Посадить дерево… в таблицу
Рано или поздно в большинстве компаний с расширением штата все приходят к необходимости собрать компетенции сотрудников в одном месте. Так совпало, что когда я пришла к идее осуществить это на практике, у команды DevOps-инженеров в GlowByte появился новый тимлид Гриша Шутов, который озаботился фактически таким же вопросом в отношении своих коллег с целью узнать их получше. И мы решили развивать матрицу вместе.
Технические нюансы и ситуации, с которыми столкнулся Гриша:
Работа в консалтинге подразумевает участие в проектах с различным стеком технологий. Раздувать команду или воспитывать универсальных «бойцов» невыгодно, а бизнес ждать не будет, работать нужно сейчас.
Требуются DevOps-инженеры не только с базой, но и со специфическими знаниями ML.
Если в команду пришёл джун/мидл, надо чётко понимать, что и как в него вложить, чтобы не перегреть и одновременно эффективно использовать его знания, решить, чем именно заинтересовать.
Big data, машинное обучение, Hadoop, нейронные сети… Разные проекты, на которых коллеги формируют и повышают уникальную компетенцию, часто она уходит вместе с ними, если они покидают команду. Возникает вопрос: как передавать этот опыт, как его фиксировать?
Нередкие случаи: «для проекта нужен инженер — 10 лет опыта администрирования хадуп, 5 лет промышленного кубера, писать на питоне и джаве и работать за МРОТ».
Ну и последнее. Стартует проект, а менеджер приходит с невнятным описанием того, кто, когда и зачем нужен, «давайте смотреть всех, кто есть».
Какие проблемы увидела я как менеджер проектов:
Аналогичные трудности с подбором специалиста под определённые проекты, даже если есть чёткое ТЗ.
Постоянное расширение команд, а это зачастую отсутствие контроля роста и понимания (в том числе у руководителей направлений), кто есть в командах. Уверена, многие из вас сталкивались с этим.
Прозрачность в карьерном росте сотрудников. Сотрудник должен понимать, куда ему расти, что ему необходимо проработать. Круто, если у него есть карта роста, ещё круче, если она визуализирована.
Защита вакансий перед руководством. Должно быть понимание, чем подкрепить потребность в открывшихся вакансиях.
Перебрав разные имеющиеся инструменты, выбор пал на матрицу компетенций. Да, он не нов, но дальше опишу, как мы его применили, как развиваем, с какими проблемами столкнулись и как их попытались решить.
Итак, началось всё с дерева компетенций. Его создал Гриша на старте своей работы. Он аккумулировал всё, даже самые специфические навыки: что коллегам интересно изучать и что для них важно. Получилось дерево с толстыми ветками из направлений и тонкими ветвями по конкретным инструментам. Вышло красиво, но неудобно, особенно в разрезе нескольких сотрудников.
Рисунок 1. Дерево компетенций
Первое, что я сделала, перевела дерево в табличный вид. Получилась следующая картина:
Рисунок 2. Матрица компетенций по инструментам
Рисунок 3. Матрица компетенций по направлениям
Далее приступили к проработке софт-скилов. Софт-скилы — важная составляющая не только касательно команды, но и проекта в целом, поэтому мы их включили в нашу матрицу.
Сначала составили скелет общей матрицы, а именно:
Выделили ключевые скилы, которые так или иначе используются в жизни проекта и команды. Они трансформировались в бизнес-группы: бизнес-отрасли и кейсы (в консалтинге важная часть касательно проектов: могут быть финансовые проекты, в сфере банковской инфраструктуры, в ритейле, телекоме и т. д.), коммуникабельность, менеджмент и кураторство, личный тайм-менеджмент, социализация.
Подключили других менеджеров проектов, лидеров команд. По итогу собрали 21 навык, который так или иначе влияет на работу, объединили в группы. В число таких навыков попали «температура горения» (показывает, как сотрудник себя чувствует, и не нужна ли ему смена проекта/обстановки), уровень токсичности для выстраивания разговора в правильном русле, уровень лояльности и мотивации, помогающий оценить заинтересованность в текущей работе.
Определили легенду. Она достаточно простая: 1 — нет навыков, а 5 — экспертный уровень. Подобрали соответствующие цвета, которые подкрашиваются автоматически при выставлении оценок (очень наглядно и удобно).
Выделили грейды и проставили им оценки исходя из нашего опыта и понимания, кто в чём должен быть экспертом, и общей картины, которая сложилась после опроса команды. Например, у тимлида должно отлично получаться курировать команду, распределять задачи и т. д.
Ориентируясь на матрицу, появилась возможность проработать гибкие навыки, нужные для роста. Это полезно и для команды, и для проекта, упрощает процесс выстраивания диалога с заказчиком и сотрудником.
Рисунок 4. Матрица компетенций по софт-скилам
Следующим шагом была проработка таблицы с хард-скилами:
В первую очередь распределили все скилы по направлениям: Базы данных, Cloud, CI/CD и т. д. Внутри этих групп разместили инструменты, совсем специфичные выделили в отдельную подгруппу, которая не участвует в общей оценке.
Добавили легенду, чтобы ребята не путались с оценкой.
В ходе тестирования матрицы командой возникла потребность в нулевой оценке — жёсткий отказ от изучения, сотруднику не интересно заниматься тем или иным направлением.
Рисунок 5. Матрица компетенций по хард-скилам
Кстати, был случай отказа одним коллегой от методологии, такие истории мы воспринимаем нормально. Изначально ведь хочется заинтересовать сотрудника, если же он не видит потребности в прохождении матрицы, мы не настаиваем. Ещё был кейс, когда один из ребят захотел перейти из команды аналитиков в DevOps-инженеры. После заполнения матрицы и понимания, сколько всего необходимо изучить, желание расти именно в эту сторону пропало.
Принцип выставления оценок и подсчёта показателей
По каждому инженеру выставляется две оценки: личная, когда сотрудник оценивает сам себя, и оценка тимлида. В первоначальном варианте была только личная оценка, но мы столкнулись с проблемой, когда человек недооценивает себя, реже — переоценивает. Так появился коррелирующий балл в лице тимлида.
Далее высчитывается среднее значение по каждому техническому инструменту и наибольшее — внутри направления. Изначально мы пытались также брать среднее по инструментам внутри направления, но универсальных «бойцов» с высокой компетентностью по всем технологиям не бывает, а значит правильнее было ориентироваться на наибольший балл из инструментов и выставлять его по направлению.
Рисунок 6. Пример расчёта
Визуализация
Мне захотелось получить из всех этих цифр что-нибудь визуально понятное и красивое. Исходя из этих соображений, я построила лепестковую диаграмму, показывающую уровень компетентности по хард-скилам. Что нам это дало:
Наглядность. Видно, по каким направлениям мы просели, а значит мы либо отправим кого-то обучаться, либо откроем вакансию.
Информативность. По части направлений у нас оказался один компетентный сотрудник, следовательно, нужно расширять знания внутри команды.
Возможность определить эксперта по направлению участникам команды для выбора куратора или просто консультации. Так как матрицу видит только руководство и тимлид, раскрыть график показалось нам хорошей идеей.
Рисунок 7. Лепестковая диаграмма по хард-скиллам
Важные моменты по матрице
Матрица обновляется на каждом performance review с сотрудником посредством персональных опросников. Благодаря ей можно наглядно представить историчность данных, оценить динамику роста специалиста, помочь в выборе для развития нужных навыков.
Её могут просматривать только тимлид команды и руководство. Для сотрудников открыта лепестковая диаграмма по техническому стеку и персонализированная матрица.
Прохождение опросника к матрице и в целом её составление по специалисту — история необязательная, но желательная.
Рисунок 8. Историчность данных
Зачем нужна матрица, или Как это работает на практике
Стартует проект. Команда собирает требования и составляет технический стек проекта, рисует лепестковую диаграмму на основе результатов первичного анализа. Далее по графику определяет, какие технологии необходимо «покрыть» и на каком уровне.
Рисунок 9. Технический стек проекта
С этими результатами команда обращается к тимлиду за подбором команды на проект. Определяются специалисты, основываясь в том числе на матрицу компетенций. Далее отрисовывается диаграмма по техническому стеку команды.
Рисунок 10. Технический стек команды
Рисунок 11. Софт-скилы командыЛегенда
А — Понимание процессов в одной из базовых отраслей (Ритейл, Банки, Телеком)
Б — Способность предлагать новые задачи/решения
В — Способность оказывать консультации по бизнес области
Г — Митапы, подготовка презентаций, публикация статей
Д — Способность находить компромисс между бизнесовыми и техническими ограничениями
Е — Умение описывать бизнес-контекст технической работы
Ж — Способность работать в условиях неопределенности
З — Общение с заказчиком
И — Презентация своих задач
К — Способность налаживать отношения со специалистами на новых аккаунтах
Л — Самостоятельность в управлении своими задачами, приоритизация
М — Курирование членов команды
Н — Управление своими задачами и задачами подчиненных
О — Замещение Lead-а в случае необходимости
П — Подбор людей в команду
Р — Создание позитивной атмосферы в команде
С — Самостоятельность в управлении своими задачами, приоритизация
Т — Работа с несколькими задачами одновременно, переключение между ними с мин. потерями времени
У — Умение делегировать задачи с целью повышения продуктивности, и развития младших коллег
Ф — Способность реально оценивать задачи
Наложив полученные данные на команду, делается предварительный вывод, какие трудности могут возникнуть в ходе проекта, какие риски нужно заложить и как выстраивать диалог между заказчиком и командой.
Бонус
Матрицу компетенций можно использовать и для составления портрета заказчика по софт-скилам. Вообще делиться такого рода информацией полезно: благодаря этому уже на пресейле можно понимать, с кем предстоит работать и как выстраивать взаимодействие.
Можно, например, выделить следующие показатели оценки заказчика:
Вовлечённость. Заказчик может быть не заинтересован в проекте, занимать нейтральную позицию, поддерживать или, наоборот, мешать.
Коммуникация. Какой уровень общения необходим заказчику. Он может не идти на контакт, и всё нужно будет тянуть из него клещами, или же, наоборот, быть общительным и ценящим внимание.
Контроль. Требуется каждую неделю присылать отчёт о проделанной работе, презентации с графиками и т. д. А может оказаться и другим: ТЗ отдал и забыл.
Степень лояльности. Лояльный — нет никаких особых проблем, давно с ним работаем и сюрпризов не ожидаем. Средней лояльности — также особых проблем нет, но и большой любви не ожидаем. Проблемный — долго отвечает на вопросы, что влечёт за собой срыв сроков, не принимает реализацию и т. д.
Команда со стороны заказчика, с кем нужно будет работать и какие у них компетенции.
Менеджер, зная всё это, оценивает сложившуюся ситуацию, если нужно, просчитывает возможные риски, подробно прорисовывает и описывает прототип и доносит до команды способ общения с заказчиком.
Выводы
Поколение, которое любит «ачивки» из игр, хорошо восприняло описанную инициативу в работе. Одним ребятам матрица помогает выбрать ориентир, другим служит справочником и помогает определиться, к кому обратиться за компетенцией при решении задачи, третьим — оценить прогресс в работе.
По итогу мы сделали матрицу компетенций и частью онбодинга, что значительно упростило задачу вывода сотрудника на проект.
Периодически мы встречаемся с командой для сбора обратной связи и по возможности продолжаем развивать инструмент. Также есть желание применить его и в других командах GlowByte. Кое-какие шаги в этом направлении мы уже сделали. Фидбэк был разный, потому активно пока не «лоббируем» эту тему.
