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

К оценке прогресса ребят стали привлекать кураторов на местах, но это породило свои сложности. У кураторов разный технический уровень, требования и подходы, это не позволяло добиться объективной и однозначной оценки. К тому же, за это время мы перешли на матричную структуру управления — это значит, что каждый разработчик закрепляется за полностью укомплектованной бизнес-командой и делает задачи только для своего бизнес-направления. Этот подход значительно повышает скорость поставки задач, однако есть риск замыкания экспертизы внутри таких мини-команд. Помимо этого, за прошедшее время у нас расширился технологический стек. Раньше инструментарий для всех задач был одинаков, и разработчики были универсальными и взаимозаменяемыми. Теперь же появилось новые виды задач, которые потребовали освоения новых инструментов. И очень важно замотивировать ребят изучать новые технологии, при этом объективно оценивая их прогресс в каждом из направлений.

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