Если опираться в повышении зарплат только на карту развития компетенций, появляются проблемы.
Опыт и компетенции есть, но формально грейд не сдан. Есть опытные разработчики, которые работают давно, попробовали много разных технологий, отлично разбираются в своем профиле, у них очень много практических навыков. Но они не сдают грейды по карте — загрузка по рабочим задачам большая, а по вечерам тратить время и силы еще и на обучение не выходит.
Получается, по компетенциям ребята уже соответствуют новому грейду, но зарплату мы им не повышаем. Конечно, можно было бы решить эту проблему внеочередным повышением зарплаты без сдачи грейда, но тогда это бы подорвало доверие к системе у остальных разработчиков.
В итоге появилась формальная бюрократия: вроде бы условия прозрачные, но не подходят для всех и начинают ограничивать людей.
Теории много, практики не хватает. Это другая сторона проблемы — начали появляться специалисты, которые очень быстро повышали грейд. Эти люди часто учили теорию дома, по вечерам, сдавали её и становились middle-специалистами. Но у них не было достаточно практического опыта, они участвовали в одном-двух проектах, многие вещи знали в теории, но не пробовали реализовать их в боевых условиях.
Не хватало оценки продуктивности. По карте развития оценивались компетенции, но не оценивалась продуктивность — сотрудник мог работать медленно, выполнять меньшее количество задач в проекте, но успевал учиться. По логике карты, ему зарплату повышали. Другой выполнял задач больше, а учиться не успевал — получается, мы не могли ему увеличить ставку.
Учитываются только технические компетенции. Конечно, для инженера это очень важно — мы должны были разбираться в сложных технологиях, чтобы реализовывать разные проекты. Но есть же еще опыт работы, дополнительная ответственность, которую берет на себя человек, знание английского языка, софт-скиллы. Всё это актуально и сильно влияет на работу. Ты можешь быть замечательным инженером, но если у тебя беда с софт-скиллами и английским, то это не только твоя проблема — это проблема для компании и команды.
Однако, чтобы нивелировать вышеописанные минусы мы попытались модернизировать систему и внедрили диапазон ставок на каждом уровне. Сделали так: на условном уровне “3-джуниор” человек может получить не 500 рублей в час, а 500-700 рублей в час.
Это добавило субъективности, но позволило нам повышать зарплату, учитывая тот же опыт работы: только перешел на уровень, получаешь 500 рублей, прошло полгода — повысили до 700 рублей, без сдачи на новый грейд.
Еще придумали систему доплат за ответственность. Например, если разработчик начинал «тимлидить» и справлялся с этой задачей, мы доплачивали ему фиксированную сумму в месяц. Хотя это и не заложено в карту компетенций.
В итоге получается, что такая система не идеальна, пробелы приходилось закрывать “костылями”. Но нам кажется, что её недостатки компенсируются прозрачностью и доверием, которое в неё заложено. Правила игры для всех одни, путь к повышению понятен - эта самая главная задача, которую мы перед собой ставили.
Спустя пять лет, мы решили переизобрести нашу систему повышения зарплат. Сделать так, чтобы система оставалась справедливой и прозрачной для всех, но учитывала, что нас стало больше, и накопившиеся проблемы стали явно мешать. Во многом мы от карты компетенций отошли, но направленность на развитие постарались сохранить. Расскажу об этой системе в следующей статье.
Система повышения зарплат с привязкой к карте развития компетенций будет работать не во всех коллективах. Она пригодится, если у вас бизнес с духом стартапа: команда энтузиастов, которая стремится развиваться и которая принимает повышение зарплат через развитие компетенций. И главное, чтобы бизнес-модель компании поддерживала такой подход, чтобы были задачи, требующие решения сложных задач. По нашему опыту, такая система — отличный способ подтолкнуть развитие людей. Потому что дух саморазвития, атмосфера в коллективе, сложные вызовы и поддержка со стороны руководства— это чудесно, однако мотивировать людей развиваться стоит еще и деньгами.
