Как мотивировать разработчиков, используя прозрачную систему зарплат

В компаниях чаще всего используется один из трех подходов к повышению зарплат: просто индексация всем, субъективное несистемное повышение отдельным сотрудникам или привязка к KPI. У каждого подхода есть свои проблемы.

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

На мой взгляд, это совсем неэффективный подход:

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

Но у этой системы есть одно важное преимущество - простота и дешевизна реализации. 

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

• Когда системы нет, вы рискуете просто не обратить на кого-то внимание. Хотя человек реально вырос и уже заслуживает повышения.
• Вопрос справедливости остается открытым — у сотрудников начнутся вопросы, почему одному человеку зарплату повысили, другому нет.
• Есть стеснительные люди, которые хорошо работают, но не умеют или стесняются говорить о повышении. Но если не повышать им зарплату, не давать подтверждение их профессионализму, они начнут выгорать — это плохо и для сотрудников, и для бизнеса.

Субъективная система повышения зарплат только вредит в долгосрочной перспективе. Когда нет внятных прозрачных критериев, оценивать сотрудников остается только интуитивно. С таким подходом будут видны только трудовые подвиги. Люди же, предпочитающие спокойно развиваться постепенно брать больше ответственности, могут остаться незамеченными. Хотя именно их подход и приводит к продуктивной и качественной работе без выгораний, а значит, они достойны повышения зарплаты.

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

• Сотрудники берут не качеством, а количеством — зачем развиваться и делать сложные задачи, если можно выполнить десяток простейших тасок?
• Большой риск выгорания. Потому что делать однотипную работу совсем без развития — это деградация и скука.
• Не подходит, если разработчик в проектах сталкивается с новыми, не шаблонными вызовами. Получается, человек решит задачу, а оценку получит плохую — ведь условный объем тасок на день будет не закрыт.

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

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

Студия MetaLamp началась как «кружок» энтузиастов-разработчиков, которые хорошо выполняли работу на фрилансе и которым стали доверять большие коммерческие проекты. Как и во многих подобных проектах, основная проблема такой компании — развитие. Нужно много разработчиков, берем людей разного уровня, и они должны понимать, как, куда и зачем двигаться в профессиональном плане.

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

Условно, есть три больших грейда: джуниор, миддл и сеньор. У нас они разбиты на «подгрейды». Для каждого грейда есть список технических и нетехнических вопросов. У сотрудника всегда есть понимание, что нужно изучить и в чем разобраться, чтобы попасть на уровень вверх.

Конечно, мы пришли к самому простому решению — привязать ставку почасовой оплаты к этим грейдам. Сотрудники любого уровня понимают, что им нужно выучить и к кому прийти, что зарабатывать больше. Это решает сразу несколько проблем:

• Стеснительные коллеги больше не ощущают несправедливости. Если они хотят больше денег — идут учиться на новый грейд.
• Сотрудники могут планировать и влиять на рост доходов. Если хочется повышения быстрее, можно напрячься, много работать и учиться, и быстро пройти до нужного уровня зарплаты. Или спокойно и размеренно узнавать новое и сдать на повышение попозже. В среднем, наш рекорд — 10 месяцев до middle–1 с нуля, и 4 месяца до junior-3.
•  Это мотивирует разработчиков развиваться, «бустит» их профессиональный уровень. Компания получает сотрудников, готовых много учиться, и это отлично.
• Система вводит прозрачные правила игры. Вероятность конфликта и субъективности хоть и не пропадает насовсем, но заметно снижается. Тем более, что сдачу на новый уровень принимают коллеги, которые уже сдали на этот грейд.

Подробнее о том, как всё устроено и как мы организовали прием экзаменов на новый грейд без участия руководителей, рассказывали в статье: «Как карта развития помогает справляться со стихийными повышениями и неосознанной некомпетентностью».

Такая система у нас постепенно формировалась с момента основания компании, а полноценно работала порядка пяти лет. Но чем дольше и активнее мы росли, тем больше “граблей” собирали. В какой-то момент оказалось, что систему пора менять.

Если опираться в повышении зарплат только на карту развития компетенций, появляются проблемы.

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

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

В итоге появилась формальная бюрократия: вроде бы условия прозрачные, но не подходят для всех и начинают ограничивать людей.

Теории много, практики не хватает. Это другая сторона проблемы — начали появляться специалисты, которые очень быстро повышали грейд. Эти люди часто учили теорию дома, по вечерам, сдавали её и становились middle-специалистами. Но у них не было достаточно практического опыта, они участвовали в одном-двух проектах, многие вещи знали в теории, но не пробовали реализовать их в боевых условиях.

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

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

Однако, чтобы нивелировать вышеописанные минусы мы попытались модернизировать систему и внедрили диапазон ставок на каждом уровне. Сделали так: на условном уровне “3-джуниор” человек может получить не 500 рублей в час, а 500-700 рублей в час.

Это добавило субъективности, но позволило нам повышать зарплату, учитывая тот же опыт работы: только перешел на уровень, получаешь 500 рублей, прошло полгода — повысили до 700 рублей, без сдачи на новый грейд.

Еще придумали систему доплат за ответственность. Например, если разработчик начинал «тимлидить» и справлялся с этой задачей, мы доплачивали ему фиксированную сумму в месяц. Хотя это и не заложено в карту компетенций.

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

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

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