Посадить дерево... в таблицу

Рано или поздно в большинстве компаний с расширением штата все приходят к необходимости собрать компетенции сотрудников в одном месте. Так совпало, что когда я пришла к идее осуществить это на практике, у команды DevOps-инженеров в GlowByte появился новый тимлид Гриша shut0v, который озаботился фактически таким же вопросом в отношении своих коллег с целью узнать их получше. И мы решили развивать матрицу вместе.  

Технические нюансы и ситуации, с которыми столкнулся Гриша:

• Работа в консалтинге подразумевает участие в проектах с различным стеком технологий. Раздувать команду или воспитывать универсальных “бойцов” невыгодно, а бизнес ждать не будет, работать нужно сейчас.

• Требуются DevOps-инженеры не только с базой, но и со специфическими знаниями ML.

• Если в команду пришёл джун/мидл, надо чётко понимать, что и как в него вложить, чтобы не перегреть и одновременно эффективно использовать его знания, решить, чем именно заинтересовать.

• Big data, машинное обучение, Hadoop, нейронные сети… Разные проекты, на которых коллеги формируют и повышают уникальную компетенцию, часто она уходит вместе с ними, если они покидают команду. Возникает вопрос: как передавать этот опыт, как его фиксировать?

• Нередкие случаи: “для проекта нужен инженер – 10 лет опыта администрирования хадуп, 5 лет промышленного кубера, писать на питоне и джаве и работать за МРОТ”.

• Ну и последнее. Стартует проект, а менеджер приходит с невнятным описанием того, кто, когда и зачем нужен, “давайте смотреть всех, кто есть”.

Какие проблемы увидела я как менеджер проектов: 

• Аналогичные трудности с подбором специалиста под определённые проекты, даже если есть чёткое ТЗ.

• Постоянное расширение команд, а это зачастую отсутствие контроля роста и понимания (в том числе у руководителей направлений), кто есть в командах. Уверена, многие из вас сталкивались с этим.

• Прозрачность в карьерном росте сотрудников. Сотрудник должен понимать, куда ему расти, что ему необходимо проработать. Круто, если у него есть карта роста, ещё круче, если она визуализирована.

• Защита вакансий перед руководством. Должно быть понимание, чем подкрепить потребность в открывшихся вакансиях.

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

Итак, началось всё с дерева компетенций. Его создал Гриша на старте своей работы. Он аккумулировал всё, даже самые специфические навыки: что коллегам интересно изучать и что для них важно. Получилось дерево с толстыми ветками из направлений и тонкими ветвями по конкретным инструментам. Вышло красиво, но неудобно, особенно в разрезе нескольких сотрудников.

Первое, что я сделала, перевела дерево в табличный вид. Получилась следующая картина:

Далее приступили к проработке софт-скилов. Софт-скилы – важная составляющая не только касательно команды, но и проекта в целом, поэтому мы их включили в нашу матрицу. 

Сначала составили скелет общей матрицы, а именно:

• Выделили ключевые скилы, которые так или иначе используются в жизни проекта и команды. Они трансформировались в бизнес-группы: бизнес-отрасли и кейсы (в консалтинге важная часть касательно проектов: могут быть финансовые проекты, в сфере банковской инфраструктуры, в ритейле, телекоме и т. д.), коммуникабельность, менеджмент и кураторство, личный тайм-менеджмент, социализация. 

• Подключили других менеджеров проектов, лидеров команд. По итогу собрали 21 навык, который так или иначе влияет на работу, объединили  в группы. В число таких навыков попали “температура горения” (показывает, как сотрудник себя чувствует, и не нужна ли ему смена проекта/обстановки), уровень токсичности для выстраивания разговора в правильном русле, уровень лояльности и мотивации, помогающий оценить заинтересованность в текущей работе.

• Определили легенду. Она достаточно простая: 1 – нет навыков, а 5 – экспертный уровень. Подобрали соответствующие цвета, которые подкрашиваются автоматически при выставлении оценок (очень наглядно и удобно).

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

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

Следующим шагом была проработка таблицы с хард-скилами:

• В первую очередь распределили все скилы по направлениям: Базы данных, Cloud, CI/CD и т. д. Внутри этих групп разместили инструменты, совсем специфичные выделили в отдельную подгруппу, которая не участвует в общей оценке. 

• Добавили легенду, чтобы ребята не путались с оценкой.

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

Кстати, был случай отказа одним коллегой от методологии, такие истории мы воспринимаем нормально. Изначально ведь хочется заинтересовать сотрудника, если же он не видит потребности в прохождении матрицы, мы не настаиваем. Ещё был кейс, когда один из ребят захотел перейти из команды аналитиков в DevOps-инженеры. После заполнения матрицы и понимания, сколько всего необходимо изучить, желание расти именно в эту сторону пропало.

Принцип выставления оценок и подсчёта показателей

1. По каждому инженеру выставляется две оценки: личная, когда сотрудник оценивает сам себя, и оценка тимлида. В первоначальном варианте была только личная оценка, но мы столкнулись с проблемой, когда человек недооценивает себя, реже – переоценивает. Так появился коррелирующий балл в лице тимлида.

2. Далее высчитывается среднее значение по каждому техническому инструменту и наибольшее – внутри направления. Изначально мы пытались также брать среднее по инструментам внутри направления, но универсальных “бойцов” с высокой компетентностью по всем технологиям не бывает, а значит правильнее было ориентироваться на наибольший балл из инструментов и выставлять его по направлению.

Визуализация

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

1. Наглядность. Видно, по каким направлениям мы просели, а значит мы либо отправим кого-то обучаться, либо откроем вакансию.

2. Информативность. По части направлений у нас оказался один компетентный сотрудник, следовательно, нужно расширять знания внутри команды.

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

Важные моменты по матрице

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

2. Её могут просматривать только тимлид команды и руководство. Для сотрудников открыта лепестковая диаграмма по техническому стеку и персонализированная матрица.

3. Прохождение опросника к матрице и в целом её составление по специалисту – история необязательная, но желательная.

Зачем нужна матрица, или Как это работает на практике

1. Стартует проект. Команда собирает требования и составляет технический стек проекта, рисует лепестковую диаграмму на основе результатов первичного анализа. Далее по графику определяет, какие технологии необходимо “покрыть” и на каком уровне.

2. С этими результатами команда обращается к тимлиду за подбором команды на проект. Определяются специалисты, основываясь в том числе на матрицу компетенций. Далее отрисовывается диаграмма по техническому стеку команды.

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

Бонус

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

Можно, например, выделить следующие показатели оценки заказчика:

1. Вовлечённость. Заказчик может быть не заинтересован в проекте, занимать нейтральную позицию, поддерживать или, наоборот, мешать.

2. Коммуникация. Какой уровень общения необходим заказчику. Он может не идти на контакт, и всё нужно будет тянуть из него клещами, или же, наоборот, быть общительным и ценящим внимание.

3. Контроль. Требуется каждую неделю присылать отчёт о проделанной работе, презентации с графиками и т. д. А может оказаться и другим: ТЗ отдал и забыл.

4. Степень лояльности. Лояльный – нет никаких особых проблем, давно с ним работаем и сюрпризов не ожидаем. Средней лояльности – также особых проблем нет, но и большой любви не ожидаем. Проблемный – долго отвечает на вопросы, что влечёт за собой срыв сроков, не принимает реализацию и т. д. 

5. Команда со стороны заказчика, с кем нужно будет работать и какие у них компетенции.

Менеджер, зная всё это, оценивает сложившуюся ситуацию, если нужно, просчитывает возможные риски, подробно прорисовывает и описывает прототип и доносит до команды способ общения с заказчиком.

Выводы

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

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

Периодически мы встречаемся с командой для сбора обратной связи и по возможности продолжаем развивать инструмент. Также есть желание применить его и в других командах GlowByte. Кое-какие шаги в этом направлении мы уже сделали. Фидбэк был разный, потому активно пока не “лоббируем” эту тему.