редакции
Иван Ярославцев
Разработчики растут и тимлид свободен: практика внедрения матрицы компетенций
С чего все началось
Осознание, что нужна матрица компетенций пришло не сразу. Я столкнулся с этим, когда разработчиков стало пятеро. Началось все с вопросов: «Куда расти дальше?», «Как вырасти в грейде и зарплате?». Без матрицы-компетенций приходилось каждый раз составлять план развития, прописывать навыки для каждого члена команды. Через несколько месяцев появлялись новые вопросы: «Какие навыки обсуждали?», «Какие освоены?», «Как это проверить?».
Позже ситуация повторилась у тимлида. Спрашиваешь куда ты потратил пол месяца работы. Оказалось, что составлял планы развития и пытался грейдировать разработчиков.
Были и общие ситуации, когда требовалось легко и быстро определять критические компетенции. Например, при обеспечении непрерывности производства. Как это сделать — не всегда понятно. Совсем плохо, когда уходил человек с ключевыми компетенциями, а замены не было.
Были и другие неприятные ситуации. Все они убедили меня, что необходимо брать компетенции сотрудников под контроль.
Первая попытка
Первое, что я решил — сделать самую простую таблицу навыков. Это таблица с именами сотрудников, их навыками и оценкой.
Вот первая версия, которая у меня получилась. Эту версию я отправил в общий чат. Написал, что это те скиллы, которые будут нужны нам в ближайшем будущем. Через месяц один из разработчиков признался, что активно учится по матрице. Это стало отправной точкой и мощным триггером для разработки матрицы компетенций. Я сразу погрузился в ее методологию — особенности, разные подходы и взгляды. Через неделю работы понял, что для создания, внедрения и поддержании матрицы потребуется 100+ часов. На это не было сил и ресурсов Поэтому пришлось упрощать алгоритм. В итоге методом проб и ошибок пришел к 6 основных шагам, без которых невозможно представить разработку матрицы-компетенций: Теперь расскажу о каждом из них подробнее. Разработка матрицы начинается со списка необходимых навыков. Основная задача на этом этапе — собрать как можно больше информации. Поэтому не группируйте их сразу в категории и подкатегории. Не повторяйте моих ошибок. Проще всего попросить самых опытных членов вашей команды написать список компетенций для разных уровней. Это поможет сэкономить время и выявить те скиллы, которые вы не рассматривали. Еще один способ — провести опрос среди всех сотрудников. Попросите каждого члена команды написать список того, что хочет знать. Только приготовьтесь к тому, что на вопрос «Какие технологии хочешь изучить?», разработчик ответит сообщением из трех букв «PHP». Поэтому сразу запланируйте время на личные встречи, где вместе с сотрудником разберете каждый пункт. В качестве источника используйте дорожные карты, которые структурируют обучение. Посмотреть их можно на сайте roadmap.sh. — это зарубежный проект, где размещены карты, руководства для разработчиков. Развитие компетенций становится более конкретным и легким, когда они визуализированы. На первом этапе подойдут google-таблицы. Быстрее инструмента для структурирования информации вы не найдете. На каждом отдельном листе сделайте специализацию: frontend, backend и т.д. если у вас в одной должности несколько направлений, то выделить общую часть «JS+HTML» и отдельно «React» и «Vue». Теперь на каждом листе выделите разделы и компетенции. Например, разделами могут быть — «ООП», «Особенности языка», «Работа сервера». Напротив каждого пункта, отметьте грейд: Junior. Middle, Senior. Набор грейдов зависит от команды и бонусов, который он дает. Не забудьте соотнести компетенции со стратегией вашей компании и проектами с которыми планируете работать. Например, если у вас в планах в этом году работать с продуктовой командой по несколько человек, то пора переставать делать интернет-магазины на OpenCart. Заказчик редко заказывает целую команду на этом стеке. Также на данном этапе вам придется решить — стоит ли привязывать заработную плату к грейдам. Мы в Alto пришли к тому, что одних знаний и практики недостаточно, чтобы оценить размер оплаты. Коллеги, которые привязали грейды к зарплатной сетке в итоге все равно оставляли за собой право платить каким-то разработчикам больше. Выходит, что привязка весьма условная. В целом опыт показывает, что несправедливо оценивать только по уровню знаний. Так как производительность у каждого программиста может различаться в несколько раз. В итоге вот, что мы оставили у себя: Когда окончательная структура будет готова, приступайте к внедрению вашей матрицы-компетенций. Теперь вам предстоит оценить ваших сотрудников, по полученному списку компетенций. Например, в Alto мы используем следующую систему оценки: Сначала просим отметить навыки, которые специалист знает. После тимлид приступает к проверке. Как правило, он самостоятельно принимает всех на работу. Поэтому он уже в курсе их навыков и знаний. Ему будет достаточно следующих вопросов: Всю информацию стараемся выписывать сразу в матрицу. Так легче проверять. Это ощутимо снижает когнитивную нагрузку с проверяющего. Если погрузится в теорию обучения, то есть несколько способов проверки знаний: Все, что можно сдать без участия тимлида — нужно сдавать асинхронно. Помечайте их с детализацией, что нужно подготовить. Например, для Junior-тестировщиков это может быть: «Подготовить скриншоты, где будут показано, что они умеют делать запросы с JOIN и GROUP BY». Так по тестированию у нас получилось сдать 40% компетенций без участия тимлида. Пожалуй, самый сложный этап. Одно дело, когда речь про тестирование навыков базовых запросов SQL. Совсем другое, когда нужно убедиться, что специалист правда умеет использовать RabbitMQ. А еще бывает, что нужна компетенция или технология, которую еще не используем, но она будет нужна клиентам. Как мы это решили у себя. Прежде всего компетенции подбираем с учетом планов по проекту на котором специалист работает. Если же проекта нет, то разворачиваем демо-проект, где специалист решает типовые задачи. После чего делаем пометку: «знает теорию и базовую практику». Это значит, что теперь ему можно доверить проект под присмотром опытного программиста. После этого договариваемся с клиентами. Объясняем, что есть новая для нас технология. Предупреждаем о текущей компетенции, риске и нашей ответственности. Стараемся либо дать скидку, либо договориться об оплате за результат. Например, в прошлом году так было с Flutter. Когда один из PHP-разработчиков захотел перейти на флаттер. Сначала собрали один проект для себя. Проверили знания на практике. Только после этого предложили одному из наших клиентов разработку мобильного приложения на Flutter. Все, что теперь вам осталось — чтобы матрица не обросла мхом и не получился документ ради документа. Постоянные согласования утомят всех. Поэтому дайте тимлиду полную свободу редактирования матрицы. Это позволит без лишних согласований адаптировать матрицу компетенций под его требования. Например, у нас тимлид значимо видоизменил матрицу. Сделал свою формулу подсчета для грейдов и многое другого. В итоге и сотрудникам нравится и тимлид постоянно работает с ней. Также договоритесь о еженедельных встречах с руководителями На них можно обсудить, что необходимо добавить или отредактировать в матрице. Со временем вы заметите, что на встречах будут появляться вопросы, которых раньше не замечали. В итоге у меня получился документ, который делает рост компетенций прозрачнее и предсказуемей. Сейчас у нас есть отдельные матрицы для: Все эти матрицы мы планируем в ближайшее время выложить и опубликовать в телеграм-канале. После чего планируем опубликовать отдельную статью с опытом других компаний и подборкой матриц-компетенций по разным стэкам. У вас уже есть опыт создания матрицы-компетенций? Расскажите, с какими трудностями вы сталкивались. Поделитесь своей историей и мнением в комментариях или напишите мне в телеграм, организуем интервью для публикации следующей статьи.
Шаг 1. Сбор информации
Шаг 2. Группировка компетенций
Шаг 3. Оценка компетенций
Шаг 4. Проверка компетенций в теории
Шаг 5. Проверка компетенции на практике
Шаг 6. Поддержка актуальности
В итоге