Разработчики растут и тимлид свободен: практика внедрения матрицы компетенций

Меня зовут Иван Ярославцев, я руководитель Alto. Мы разрабатываем веб-сервисы на заказ. Проще говоря у нас команда программистов. В статье хочу поделиться своим опытом — от создания матрицы до ее внедрения. Здесь есть личный опыт, пошаговые инструкции, понятные объяснения и полезные советы. На примере нашей компании покажу, что матрица-компетенций — это простой инструмент. Начать работать с ним можно прямо сейчас, для этого не нужно 100+ часов.

С чего все началось

Осознание, что нужна матрица компетенций пришло не сразу. Я столкнулся с этим, когда разработчиков стало пятеро. Началось все с вопросов: «Куда расти дальше?», «Как вырасти в грейде и зарплате?». Без матрицы-компетенций приходилось каждый раз составлять план развития, прописывать навыки для каждого члена команды. Через несколько месяцев появлялись новые вопросы: «Какие навыки обсуждали?», «Какие освоены?», «Как это проверить?».

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

Были и общие ситуации, когда требовалось легко и быстро определять критические компетенции. Например, при обеспечении непрерывности производства. Как это сделать — не всегда понятно. Совсем плохо, когда уходил человек с ключевыми компетенциями, а замены не было.

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

Первая попытка

Первое, что я решил — сделать самую простую таблицу навыков. Это таблица с именами сотрудников, их навыками и оценкой.

Вот первая версия, которая у меня получилась.

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

Это стало отправной точкой и мощным триггером для разработки матрицы компетенций. Я сразу погрузился в ее методологию — особенности, разные подходы и взгляды. Через неделю работы понял, что для создания, внедрения и поддержании матрицы потребуется 100+ часов. На это не было сил и ресурсов Поэтому пришлось упрощать алгоритм.

В итоге методом проб и ошибок пришел к 6 основных шагам, без которых невозможно представить разработку матрицы-компетенций:

  • Сбор информации
  • Группировка компетенций
  • Оценка компетенций
  • Проверка компетенций в теории
  • Проверка компетенций на практике
  • Поддержка актуальности

Теперь расскажу о каждом из них подробнее.

Шаг 1. Сбор информации

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

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

Список компетенций до группировки

Еще один способ — провести опрос среди всех сотрудников. Попросите каждого члена команды написать список того, что хочет знать. Только приготовьтесь к тому, что на вопрос «Какие технологии хочешь изучить?», разработчик ответит сообщением из трех букв «PHP». Поэтому сразу запланируйте время на личные встречи, где вместе с сотрудником разберете каждый пункт.

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

Шаг 2. Группировка компетенций

Развитие компетенций становится более конкретным и легким, когда они визуализированы. На первом этапе подойдут google-таблицы. Быстрее инструмента для структурирования информации вы не найдете. На каждом отдельном листе сделайте специализацию: frontend, backend и т.д. если у вас в одной должности несколько направлений, то выделить общую часть «JS+HTML» и отдельно «React» и «Vue».

Теперь на каждом листе выделите разделы и компетенции. Например, разделами могут быть — «ООП», «Особенности языка», «Работа сервера».

Список компетенций с группировкой

Напротив каждого пункта, отметьте грейд: Junior. Middle, Senior. Набор грейдов зависит от команды и бонусов, который он дает.

Таблица PHP с грейдами

Не забудьте соотнести компетенции со стратегией вашей компании и проектами с которыми планируете работать. Например, если у вас в планах в этом году работать с продуктовой командой по несколько человек, то пора переставать делать интернет-магазины на OpenCart. Заказчик редко заказывает целую команду на этом стеке.

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

Мы в Alto пришли к тому, что одних знаний и практики недостаточно, чтобы оценить размер оплаты. Коллеги, которые привязали грейды к зарплатной сетке в итоге все равно оставляли за собой право платить каким-то разработчикам больше. Выходит, что привязка весьма условная.

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

В итоге вот, что мы оставили у себя:

  • Сеньоры и тимлиды живут вне матрицы. У них индивидуальный путь развития, но часть компетенций они берут из матрицы.
  • У каждого разработчика есть возможность получить повышение. При условии если он сдает компетенции, которые обозначил тимлид.
  • Также оставляем возможность пересмотр зарплаты, если есть хорошая обратная связь от менеджеров и QA-специалистов.

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

Шаг 3. Оценка компетенций

Теперь вам предстоит оценить ваших сотрудников, по полученному списку компетенций. Например, в Alto мы используем следующую систему оценки:

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

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

Всю информацию стараемся выписывать сразу в матрицу. Так легче проверять. Это ощутимо снижает когнитивную нагрузку с проверяющего.

Результаты скрининга компетенций

Шаг 4. Проверка компетенций в теории

Если погрузится в теорию обучения, то есть несколько способов проверки знаний:

  • Теоретический кейс с решением задачи. Например, предлагаем кейс, где скрипт с выгрузкой товаров с сайта в XML падает с 502 ошибкой. Просим найти несколько вариантов решения, рассказать о плюсах и минусах каждого.
  • Рассказать теорию ответить на вопросы. Например, рассказать что такое принципы ООП и почему его поддержание на проекте важно
  • Артефакты из практики. Например, просим рассказать на каком из проектов применяли SOLID и как решили.
  • Сдача онлайн-тестов. У коллег есть необычное решение с телеграм-ботом.

Все, что можно сдать без участия тимлида — нужно сдавать асинхронно. Помечайте их с детализацией, что нужно подготовить. Например, для Junior-тестировщиков это может быть: «Подготовить скриншоты, где будут показано, что они умеют делать запросы с JOIN и GROUP BY». Так по тестированию у нас получилось сдать 40% компетенций без участия тимлида.

Шаг 5. Проверка компетенции на практике

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

Как мы это решили у себя. Прежде всего компетенции подбираем с учетом планов по проекту на котором специалист работает. Если же проекта нет, то разворачиваем демо-проект, где специалист решает типовые задачи. После чего делаем пометку: «знает теорию и базовую практику». Это значит, что теперь ему можно доверить проект под присмотром опытного программиста.

Компетенция QA-специалиста

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

Например, в прошлом году так было с Flutter. Когда один из PHP-разработчиков захотел перейти на флаттер. Сначала собрали один проект для себя. Проверили знания на практике. Только после этого предложили одному из наших клиентов разработку мобильного приложения на Flutter.

Шаг 6. Поддержка актуальности

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

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

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

В итоге

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

  • PHP с ветвлением на Laravel и Битрикс
  • Frontend-React
  • Project-Manager
  • QA-Manual
  • Тимлиды разработки

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

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

0
25 комментариев
Написать комментарий...
Shoo

Самую важную часть вы пропустили:
Как вы собираетесь оценивать результаты этой работы?
По каким критериям будете судить, что абстрактная матрица с натягиванием совы на глобус дает больше эффективности, чем ИПР и индивидуальные цели?
А что она вообще какую-то эффективность дает, как будете оценивать?
А что затраты на её создание и сопровождение окупились?

Ну и помимо этого:
Зачем вообще в команде из <50 разработчиков нужны грейды?
Куда в матрице компетенций потерялись софт скиллы?

Ответить
Развернуть ветку
Иван Ярославцев
Автор

1. Не у каждого инструмента надо тратить время на оценку окупаемости, тут простой критерий, если тимлиду стало легче жить — то уже верное направление
2. Оно не противоречит друг-другу, чтобы составить ИПР нужно знать какие компетенции сейчас в компании востребованы(это есть в матрице) и что хочет исполнитель (ему проще опереться на готовый список, чем все доставать из головы).
3. См п.1
4. Окупаемость хрен его знает, но тут не такие вложения, чтобы ее нужно было считать.
5. Нам матрица не столько нужна для грейдов, сколько для списка актуальных востребованных компетенций. Грейды все же нужны для самоидентичности сотрудников. Как правило людям легче, если они видят насколько выросли за последние N месяцев
6. Убрали все то, что сложно проверить на встрече. Оставили только в матрицах проджекта и тимлида, где это более релевантно. Для разработчиков и QA придерживаемся позиции, что нам важно, чтобы специалист был по софт-скилам в норме. Т.е. не было ощутимых проблем с коммуникацией, ответственностью и т.п. Если такая проблема возникает, то ее решаем без матрицы компетенций.

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

Ответить
Развернуть ветку
Shoo

Не, смотрите. Матрица компетенций - хорошая штука, иногда и вправду нужная и полезная.
Проблема в том, что сделать её правильной и полезной - это капей какой ресурсоемкий процесс.
И что как и любой другой инструмент, она требует ответа на вопрос "зачем?" перед тем, как её использовать.
Иначе получаются инструменты ради инструментов.

Т.е. вот есть проблема - тимлиду болненько.
Какой именно источник боли решает матрица компетенций?
Почему именно таким способом её надо решать? Какие ещё были варианты и почему выбрали этот?
Ну, т.е. это же стандартный процесс.
Определить проблему -> Определить критерии решения этой проблемы -> Найти способы решения, которые попадают под эти критерии -> Выбрать оптимальный -> Сделать -> Собрать метрики успешности.

Исходя из статьи у меня сложилось впечатление, что вы из этой цепочки оставили только "Определить проблему -> Сделать".
И это очень распространенная проблема, потому что люди смотрят "а вот в гуголе такое решают через матрицу компетенций" и делают.
А то, что они не гугол, и проблемы их не такие как в гуголе, и вообще всё другое - это из вида упускается.
Собственно, вопросы все эти я задавал в десятках команд, и дай бог единицы были способны на них ответить.

Если тимлид тратит много времени на составление ИПР - возможно лучше вложить деньги и время в обучение тимлида, что бы он лучше умел это делать?
Если команда не знает, каких компетенций и где им не хватает - возможно лучше потратить силы на анализ существующих проблем и RCA, а не на матрицу компетенций?
Если люди в команде не знают, куда они хотят развиваться - то поможет ли им в этом матрица?

История с исключением софтов - тоже стандартная проблема таких инструментов.
Добавляем софты - слишком сложно оценивать. Убираем софты - смысл теряется.
Хард скиллы дешевые и быстро прокачиваются, софты - дорогие и прокачиваются очень сложно.
Матрица компетенций и построенные на ней ИПРы - это направление, куда будут развиваться сотрудники. И вы им как бы говорите "забей на участие в decision making, шаринг знаний, вовлеченность в продукт, научись лучше жсоны в редис складывать".
Ну кмон.

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Классный коммент, правда спасибо и со всем на 100% согласен.

Смысл статьи, как раз в том, чтобы показать, что не всегда матрица. Вернее ее прототип — ресурсоемкий процесс. Потому что при опросе стало понятно, что в крупных компаниях 30 человек задействованно. Есть комитеты. И процедуры по пересмотрению. И если небольшая команда будет видеть только такой опыт, то матрицы как идею зарубит на корню.

Когда мы отказывались от субподряда по QA и запускали свой отдел. У меня первая версия заняла 10 часов. Это анализ требований к последним 10 проектам + рисерч + пару интервью с лидами QA отделов.

В процессе еще часов 10 ушло, чтобы ее довести до состояния «все вопросы очевидны и понятны».

Т.е. тут не тот объем, чтобы прогонять PDCA циклы и принимать решение, тот ли инструмент. При том, что видно. Что это точно экономит время тимлида.

По поводу софтов. Мы их оставили для тимлидов и проджектов, для программистов и QA исключили. При этом, смотрим, чтобы они они были в норме еще на собеседовании. И дальше отслеживаем, чтобы так все и оставалось. Развиваем по запросу.

Буду рад, если укажете, кем и где вы работаете. Чтобы понимать контекст комментариев. Можно в личку t.me/altoivan

Ответить
Развернуть ветку
Shoo

Ну да, программистам и куа софты ж не нужны.
Спасибо, смешно. :)

«Точно видно что экономит» - это, конечно, хорошая метрика успеха, но нет.
Потому что важно не столько время, сколько кпд.

Ответить
Развернуть ветку
Dima

А ты хорош!

Ответить
Развернуть ветку
Студия интерфейсов UXART

Прикольно, спасибо что поделились)

Для дизайнеров сделать такое посложнее конечно)

Ответить
Развернуть ветку
Дмитрий Прозоров

Таких карт для дизайнеров сделано уже много https://vc.ru/56149

Ответить
Развернуть ветку
Вадим Т.

о,уже вторая статья про матрицу компетенций за сегодня

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Нам удивительно везет) видимо добавим в чек-лист проверку всех статей за день

Ответить
Развернуть ветку
Влад Иванов

За дорожные карты спасибо!

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Рады стараться

Ответить
Развернуть ветку
Слава Григорьев

Я похожее использую в качестве шаблона при планировании.

Ответить
Развернуть ветку
Игорь Забродин

а не плохая идея, надо будет тоже так попробовать

Ответить
Развернуть ветку
Иван Ярославцев
Автор

покажете?

Ответить
Развернуть ветку
Петр Любицин

А сколько часов нужно на эту?

Ответить
Развернуть ветку
Иван Ярославцев
Автор

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Иван Ярославцев
Автор

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

Ответить
Развернуть ветку
Антон Мастраков
Ответить
Развернуть ветку
Иван Ярославцев
Автор

И мы того же мнения)

Ответить
Развернуть ветку
Херня Всё

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

Вместо того, чтобы 1) херачить 2) делать охуенно - достаточно проходить обучалки и просить денег..

Ответить
Развернуть ветку
Иван Ярославцев
Автор

так сложилось на рынке, что среднему кандидату важно видеть: 1. Что он растет 2. Получает повышение за рост.

Матрица и ИПР показывают был ли рост на самом деле. И дают аргументацию для зарплаты.

Ответить
Развернуть ветку
Natasha

Простите, а ранее Вы компетенции и грейд на глаз определяли?

Ответить
Развернуть ветку
Иван Ярославцев
Автор

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

Ответить
Развернуть ветку
22 комментария
Раскрывать всегда