Как повышать зарплату разработчику

В IT принято принимать решения быстро: нашел классного разработчика — увеличил зарплату. Кажется, что это единственно верная стратегия. Но так ли это? Разбираемся в статье.

Как работает денежная мотивация в IT

Уровень дохода для разработчика по-прежнему на первом месте, но это не единственный фактор мотивации. По результатам ежегодного опроса Stack Overflow, гибкость процессов (65%) и обучение (56%) важны для них не меньше денег (59%). Также разработчики смотрят на масштаб самого проекта и остальные плюшки. Это значит, что повышение зарплаты должно идти в комплексе с другими материальными и нематериальными бонусами. Причем это касается и новых сотрудников: из неинтересного проекта без возможности развития разработчик быстро уйдет. 

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

Как не стоит повышать зарплату разработчикам

Индексация

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

Стихийное повышение

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

KPI

Показатели эффективности — хороший инструмент, но в IT работает спорно. Главный ориентир в KPI — количество выполненных задач. Хороший разработчик просто не может жертвовать качеством ради достижения заветных баллов. Какой получится в итоге продукт? Догадаться несложно. Кроме того, при такой системе риск выгорания увеличивается в несколько раз. Потому что задач становится много, но получаются они однотипными и не развивают скилы.

Квартальное повышение

Бонусную премию один раз в квартал используют многие компании. Но почему она может быть неэффективной? Разработка продукта — ненормированный процесс: на веб-приложение может уйти 3 месяца, а на новый облачный сервис — полгода и больше. Как тут привязать зарплату к кварталу? Еще такая система может привести к противоположному эффекту: в начале квартала команда будет работать вполсилы, а перед подведением результатов — активно нагонять упущенное время. На качестве это тоже скажется. 

Когда повышать зарплату 

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

Низкая вовлеченность

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

Прибавление в команде более дорогих специалистов

Разработчики не всегда прямо обсуждают заработную плату друг друга. Но это не значит, что тому, кто работает в проекте уже не первый год, можно платить в два раза меньше. Да и не каждый разработчик сообщит о том, что его не устраивают условия, вместо этого — покажет оффер с суммой в два раза больше. На этом этапе многие HR-ы и руководители уверены, что могут легко эту сумму перебить. Но не факт, что разработчик согласится: он уже понял, что в другой компании его вклад ценят выше и доверия к вам будет меньше.

Высокие результаты разработки продукта

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

Общая тенденция на рынке

Здесь нужно действовать быстро: опережать лавину повышения зарплат. Раз в два месяца мониторьте рынок, изучайте предложения конкурентов и ожидания кандидатов. Лучше заранее подготовиться, чем пытаться удержать разработчика с готовым оффером на руках, да и разработчику будет приятно получить бонус. Так что это хорошая тактика для удержания.

Как повышать зарплату эффективно 

Выделим три работающих метода в IT:

• карта развития компетенций, 
• грейды,
• Performance Review.
  

Карта развития компетенций

Этот метод поможет расти всей команде, потому что карта показывает картинку в целом: какие скилы на хорошем уровне, а над чем еще стоит поработать. Особенно он подойдет молодым компаниям, которым важен быстрый рост. Для составления карты выберите soft и hard скилы, которые используют в работе разработчики. Затем составьте таблицу, впишите в столбцы ФИО сотрудников, а слева — навыки. На пересечении ячеек проставляйте баллы владения навыком для каждого сотрудника. Скилы могут оценивать несколько человек. Например, HR, тимлид, Project Manager и руководитель — так картинка будет более полной. 

Грейды

Наиболее популярная система оценки в IT, которую можно подстраивать индивидуально. Например, разбить классические грейды джуна, мидла, сеньора на подгрейды. В итоге получится несколько уровней, благодаря которым повышение зарплаты для каждого станет объективным. Главное, в каждом грейде подробно обозначить:

• зону ответственности;
• необходимые знания и скилы;
• подробное описание компетенций;
• зарплатную вилку.

Performance Review

Итоговые встречи, которые проводятся HR-ом, руководителем и ментором раз в полгода или квартал. В обсуждение нужно включить:

• результаты прошедших месяцев, 
• оценку работы руководителями и самим разработчиком;
• ожидания разработчика от проекта/руководителя/задач;
• цели на следующий период.

При этом не стоит воспринимать Performance Review как неформальную встречу. Форма такой может быть, но результаты и планирование — четким и понятным всем участникам. Например, не просто подтянуть Angular, а какие конкретно функции должен знать программист и применять их для следующего уровня. Думайте наперед: какие инструменты требуются команде для развития проекта? Делайте упор на пользу для бизнеса.  

Дополнительно можно проводить Salary Review — раз в полгода/год. Это поможет проанализировать материальную мотивацию отдельно. Здесь вы оцениваете вклад разработчика в материальном ключе: как он реализовал задачи проекта и какую пользу принес? Обсудите зарплатные ожидания разработчика и возможности компании.