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

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

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

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

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

9

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

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