Skip to main content
Improvado
Международный агрегатор рекламных кампаний
60 млн $
капитализация
22 млн $
инвестиции в серии А
Создаем стартапы на блокчейне Cardano с использованием платформы Plutus, написанной на Haskell
Узнать больше

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

salary increase

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

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

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

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

Индексация

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

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

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

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

Субъективное повышение

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

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

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

KPI

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

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

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

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

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

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

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

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

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

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

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

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

Минусы строгой привязки заработной платы к грейдам сотрудников

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

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

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

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

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

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

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

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

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

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

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

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

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

sharding
новое
ton
bottle_wine
выбор редакции
Зачем вину блокчейн: как токенизируют премиальный алкоголь

Елизавета Черная

Редактор Бренд-медиа

Статьи

web3
nft
business
launchpad
twa
Тренды блокчейна и криптоиндустрии 2024: Telegram Mini Apps (TMA)

Елизавета Черная

Редактор Бренд-медиа

Статьи

web3
buildings
anonymus
выбор редакции
Zero-knowledge proof: один из трендов 2024 в блокчейне

Евгений Биктимиров

Венчурный аналитик

Статьи

ethereum
web3
dApps
cpay
выбор редакции
AA zksync
zero knowledge proofs
выбор редакции
stock market chart
выбор редакции
planets
fundraising
выбор редакции
cto
wallet
tokens
выбор редакции
rocket computer
выбор редакции
Как создать дизайн для MVP стартапа за 7 дней

Юлия Черепанова

Head of Design Office

Статьи

startup
MVP
design
nft
AI
crypto wallets
выбор редакции
Account Abstraction: что это такое и зачем нужно криптомиру

Павел Найданов

Solidity разработчик

Статьи

ethereum
web3
business
red space
выбор редакции
speed up development
myths
выбор редакции
Мифы о разработке блокчейн продуктов

Николай Бордуненко

Project manager at MetaLamp

Статьи

web3
dApps
startup
launching
выбор редакции
Кого нужно нанимать в команду для запуска MVP?

Алексей Сухарев

Head of Sales Department

Статьи

business
startup
MVP
galaxy
magazine
spaceman
выбор редакции
coffee
investors
nft
Первый NFT marketplace на Cardano

Станислав Жданович

Haskell разработчик

Статьи

cardano
web3
nft
stair
выбор редакции
bridge
rocket
abstraction
Как мы нанимаем Plutus инженеров через собственную программу обучения

Светлана Дульцева

Супервизор программы обучения

Статьи

education
cardano
web3
mountains
blockchain
salary
salary increase
app
developer with books
keyboard
abstract