---
title: "Как установить справедливую систему повышения зарплат"
date: 2023-10-31
description: "Если вы руководите коллективом, в котором больше трех человек, то наверняка знаете эту боль — зарплату сотрудникам повышать надо, но непонятно, как сделать это "
author: "Роман Штых"
intro_image: "https://metalamp.ru/images/yfdfkn2.png"
fulltext_image: "https://metalamp.ru/images/yfdfkn2.png"
categories:
  - name: "Magazine"
    url: "https://metalamp.ru/magazine.md"
tags:
  - name: "business"
    url: "https://metalamp.ru/tags/business.md"
---

# Как установить справедливую систему повышения зарплат

![Как установить справедливую систему повышения зарплат](https://metalamp.ru/images/yfdfkn2.png)

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

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

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

 Я, Роман Штых, CEO в MetaLamp, расскажу в этой статье, как всё устроено. Надеюсь, материал пригодится, и вы сможете использовать подобную практику у себя в командах.

 
## Почему мы решили пересмотреть работающую систему повышения зарплат

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

 Смотрите доклад сооснователя MetaLamp Сергея Черепанова.

 Условный пример — если ты разработчик уровня джуниор-3, то ты можешь зарабатывать 450-600 рублей в час. Конкретная цифра зависит от опыта: перешел человек на нужный грейд, получает минимальную ставку из вилки. Поработал какое-то время, взял на себя дополнительные обязанности — увеличиваем ставку, но в пределах вилки грейда.

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

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

 Подробнее мы рассказывали об этом статье [Как мотивировать разработчиков развиваться с помощью прозрачной системы повышения зарплат](https://metalamp.ru/magazine/article/kak-motivirovat-razrabotcikov-razvivat-sa-s-pomos-u-prozracnoj-sistemy-povysenia-zarplat)

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

 **Разрыв между уровнем по карте и реальным опытом.** Мы регулярно наблюдали сотрудников, которые по карте были условным джуниором-3, а на деле опыта у них было намного больше. Платить им ставку джуниора было несправедливо, а сдавать на новый грейд они не могли: например, банально не хватало времени подготовиться.

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

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

 **Невозможно планировать бюджет компании.** Люди сами решают, когда им пробовать переходить на следующий уровень, когда у них будет расти зарплата. Для руководства это тяжело с точки зрения финансового планирования — например, трудно рассчитать клиентскую ставку для заказчика, т.к. она уже может стать неактуальной после перехода на следующий грейд. 

 **Нет системного сбора фидбека.** Конечно, мы ввели инструменты, которые помогают понимать мотивацию сотрудника, его моральное состояние — например, у нас есть практика встреч one-on-one, но это скорее история про личное отношение. Но мы же работаем в команде, в бизнесе — значит, на повышение зарплаты должна влиять и обратной связи от коллег и заказчиков о сотруднике.

 В итоге мы решили пересмотреть существующую систему повышения зарплат и поменять ее на новую. Для разработки решения вдохновлялись инструментом Performance review. Но при этом постарались сохранить прозрачность и системность для всей команды.

 ![](https://metalamp.ru/images/Group 2 3.png)

 
## На какие критерии стоит опираться при оценке сотрудника

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

 У нас две группы критериев: измеримые и неизмеримые. Проще всего работать с измеримыми:

 
- **Технические компетенции** — будем использовать карту развития или индивидуальный план развития, в зависимости от специалиста. Тут всё как и было.
- **Срок работы в компании**. Это показатель не только опыта, но и лояльности, понимания процессов. Человек у нас давно, мы этому рады — значит, это должно сказываться на заработной плате.**‍**
- **Уровень английского языка.** Мы сформировали такой критерий: сотрудник может читать, писать, говорить и понимать. Условно говоря, способен ли человек эффективно работать с англоязычной командой.

 Эти критерии просто измерить, но строить систему только на них будет несправедливо. Поэтому добавляем неизмеримые критерии, они же субъективные.

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

 
- **Софт-скиллы.**Это умении давать и принимать фидбэк, дружелюбная и прозрачная коммуникация, когда ты на связи и не пропадаешь.
- **Опыт работы с разными технологиями, технический кругозор.**Здесь подразумевается не просто срок работы или количество технологий, которые успел пощупать разработчик на проектах. А скорее насколько сильно разработчик перерос свой грейд технических компетенций, заметен ли качественный рост скиллов, изменилось ли сложность задач.**‍**
- **Скорость работы.**Насколько быстро разработчик сдает те или иные таски. Сначала этот параметр хотели отнести к измеримым — кажется, что можно попробовать измерять скорость выполнения задач и смотреть на соответствие оценки по срокам и реальному времени выполнения. Но чтобы это сделать, нужен некий эталон задачи, а они ведь часто разные. Нужно создать условную стандартизацию скорости выполнения тасок и инфраструктуру треккинга. Но даже если это и получится, всё равно будут ситуацию, когда задача закрывалась долго не по вине разработчика. А раз этот параметр в итоге всё равно оказывается субъективным, то его проще использовать как неизмеримую метрику.
- **Качество.**Много ли багов в задачах разработчика, как часто приходится переделывать задачи, насколько сотрудник внимателен к требованиям и насколько грамотно их реализует.
- **Инициативность.** Видит ли сотрудник проблемы на своем проекте и предлагает ли решения. Нет ли практики замалчивания.
- **Взятие ответственности за проект.** Готов ли специалист отвечать за проблемы, которые есть на проекте. Этот критерий появился из практики — ребята часто берут на себя роль тимлида, хотя ими не являются, помогают коллегам с меньшим опытом, распределяют задачи. Это классно, мы хотим мотивировать такое отношение к задачам.

 
## Как устроена система повышения зарплат

 Новую систему повышения зарплат назвали Performance Review, хотя это модифицированная версия этого метода. Скелет системы выглядит так.

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

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

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

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

 **Обсуждение потенциала роста.**После сбора фидбека менеджер встречается с сотрудником. Они обсуждают точки роста на следующие полгода на основе фидбека. Тут важно уточнить — не менеджер заставляет расти в таком-то направлении, а сотрудник изучает фидбек и определяет, на каких точках роста он хочет сосредоточиться.

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

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

 
## На какую сумму поднимать зарплату

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

 **Разным критериям соответствуют разные суммы.** Например, фидбеку за софт-скиллы может соответствовать сумма в 2,000 рублей, росту в технических компетенциях 15,000. Измеримые приносят больше дохода — так система становится объективнее, потому что неизмеримые хоть и тоже влияют на команду, но их оценка в первую очередь субъективна. Для нас же было важно сделать систему прозрачную и приближенную к объективной, поэтому мы отдали переходу на новый грейд по карте развития, опыту в разных технологиях и знанию английского самые большие суммы.

 **У каждого критерия есть коэффициент.**Он зависит от той оценки, которую сотрудник получил во время фидбека. Например, если оценка софт-скиллов от коллег будет на уровне “нормально” - коэффициент будет 60%, значит вместо 2,000 рублей, человек получит повышение на 1,200. На «хорошо» — значит, в сумму повышения записываем 100% от цены критерия (в данном примере - 2,000).

 Существуют коэффициент, который всегда равен 100% — это срок работы, лояльность компании. Даже если точек роста нет совсем, сотрудник точно получит повышение на конкретную сумму.

 **Плохой фидбек влияет на все коэффициенты**. Если коллеги, руководство и заказчики оценивают софт-скиллы, скорость работы и качество задач у сотрудника на «плохо», мы считаем это проблемой, сильной просадкой. Это пагубно сказывается на работе всей команды.

 Если такая ситуация возникает, то мы сокращаем все коэффициенты до 50%. Например, по измеримым коэффициентам набрал человек повышения зарплаты на 20 тысяч рублей, но получил «плохо» за качество работы. Значит, мы повысим ему зарплату только на 10 тысяч рублей.

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

 
## Как сотрудники отреагировали на новую систему повышения зарплат

 Систему вводили не массово и не очень быстро. Сначала попробовали ее на фокус-группе из 10 человек, собрали отзывы. Затем рассказали о системе на общей планерке, ответили на вопросы. Далее пришлось даже переработать какие-то условия системы, т.к. вскрылись недостатки, которые мы не видели в первой версии, но команда помогла нам их разглядеть. 

 Мы решили поделить всех разработчиков на 4 волны. Каждую волну мы пересматривали в сентябре, октябре, ноябре и декабре 2021 года соответственно. В первую очередь пригласили на встречи сотрудников, которые получали повышение зарплаты довольно давно.

 Чтобы оценить, как система мотивирует людей развиваться, нет ли в ней подводных камней, решает ли она проблемы с прозрачностью, нужен хотя бы год. Пока это управленческий эксперимент. Мы хотели сделать объективную систему, которая бы учитывала как можно больше факторов, но при этом она была бы прозрачной и работала на всех сотрудников одинаково. Нам кажется что пока нам это удается. Отзывы о системе от сотрудников хорошие, конфликтных ситуаций не было, несмотря на то, что у нас в коллективе 80 человек. Мы пока что тоже довольны. Сейчас система работает для разработчиков, но мы планируем ее транслировать на все направления компании.

 Расскажите, как у вас устроен процесс повышения зарплаты? Как вам эта система? Было бы комфортно работать с такими условиями?

 ‍

 ![article-logo](https://metalamp.ru/images/article/logo.svg) 
## Больше статей по этой теме


## Custom Fields

**reading time:** 10

**Article type:** articles

**Article description:** Если вы руководите коллективом, в котором больше трех человек, то наверняка знаете эту боль — зарплату сотрудникам повышать надо, но непонятно, как сделать это прозрачно и справедливо. 

**Author (copy):** Роман Штых