Офтоп Nik Vashenko
7 101

Своевременное повышение зарплаты как инструмент эффективного управления командой

Директор веб-студии Lodoss team — о том, как и за что нужно повышать зарплату сотрудникам, чтобы это приносило пользу компании.

В закладки

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

Разработкой ПО занимаются высококвалифицированные специалисты с приличными зарплатами. Для веб-студии затраты на оплату труда — это одна из основных статей расходов.

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

В дверь постучали

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

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

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

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

Нужен системный подход

Без прозрачной системы метрик каждое решение будет лишь субъективным мнением. Сотрудники не будут понимать, что именно нужно сделать, чтобы заслужить повышение. Со временем это приведёт к снижению эффективности труда.

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

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

За что повышать

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

Может быть, стоит повысить, когда работник показал отличные результаты? Опять нет, за это полагается премия, только нужно чётко определить и объяснить команде, что есть норма, а что — её перевыполнение.

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

Например, на работу был принят младший разработчик. Он четыре месяца сидел на коммерческом проекте и выполнял задачи, которые ему ставил тимлид.

Сначала это были совсем маленькие задачи, затем крупнее, и наконец он смог в оговорённые сроки самостоятельно создавать довольно крупные модули. Теперь у него есть полезное для компании умение, которое отличает его от других младших разработчиков.

Когда повышать

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

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

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

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

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

Дать младшему руководящему составу полномочия решать вопрос об уровне зарплаты их подчинённых

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

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

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

Проверка уровня компетенции раз в год или другой достаточно продолжительный промежуток времени

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

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

Дать работникам возможность проходить испытания на повышение уровня по их запросу

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

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

От себя дам две основных рекомендации:

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

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

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

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Nik Vashenko", "author_type": "self", "tags": [], "comments": 21, "likes": 33, "favorites": 1, "is_advertisement": false, "subsite_label": "flood", "id": 34625, "is_wide": false, "is_ugc": true, "date": "Wed, 14 Mar 2018 11:51:49 +0300" }
{ "id": 34625, "author_id": 147939, "diff_limit": 1000, "urls": {"diff":"\/comments\/34625\/get","add":"\/comments\/34625\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/34625"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199791, "possessions": [] }

21 комментарий 21 комм.

Популярные

По порядку

Написать комментарий...

–3

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

Ответить

0

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

Ответить

0

Проекты за редким исключением везде +/- одни и те же. А если уж стены и лица коллег надоели, то тут уже мало чем можно помочь. Но такое редко происходит за год-два, это больше похоже на 3-5.

Ответить
3

В веб-студиях проекты и одинаковые и более того - довольно скучные - в сотый раз натянуть верстку, сделать двухсотую форму отправки сообщения и т.п. Но в мире программирования проекты абсолютно разные, требуют соверешенн разныз скилов. И когда один скил прокачивается (например, построение сложной бизнес-логики но не особо требовательной к скорости) можно уйти в другую компанию и прокачивать другой (жесткий хайлоад).

Лично мне проект приедается за 2.5-3 года. И надо двигаться. Либо вертикально, либо горизонтально, либо в другую компанию.

Ответить

0

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

Ответить
0

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

Ответить
0

Разница в большей личной ответственности и некоторых обязательных пунктах в допниках.

Ответить
0

Я понимаю, о чём вы говорите, просто к слову, вот эти вот «миддл» и «сениор» — это всё же больше про размер зарплаты, чем про реальные навыки специалиста, потому что никакого золотого стандарта этих обозначений не существует, и всё очень по личным ощущениям, а часто совсем мимо. Хочу сказать, сеньор одной компании не сможет стать сеньором другой, и так далее.

Ответить
0

Строго говоря, так же и с зарплатой, сеньор одной компании может получать меньше мида другой ))

Ответить

6

Главная проблема третьего подхода - это "Извините, ваш уровень не повысился, попробуйте в следующем году". Таким образом аутсорс-конторы на одной и той же пайке держат программистов по несколько лет.

Ответить
2

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

Ответить
3

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

Ответить
1

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

Ответить
2

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

Если у вас десятки сотрудников, почему нет промежуточного звена руководителей?

Ответить
0

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

Ответить
1

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

Ответить
1

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

Ответить
0

большое спасибо, Nik. успехов вам! :)

Ответить

1

Вся суть статьи хорошо изложена в этих трех абзацах 👍

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

Может быть, стоит повысить, когда работник показал отличные результаты? Опять нет, за это полагается премия, только нужно чётко определить и объяснить команде, что есть норма, а что — её перевыполнение.

Я уверен, что *повышать стоит только тогда, когда сотрудник перешёл на качественно новый уровень. Если теперь он делает то, что не мог месяц назад*, что прямо или косвенно приносит компании большую прибыль, что не могут делать коллеги с той же должностью и зарплатой.

Ответить
1

Интересно

Ответить
0

Хотя бы чем-то поделились, уж очень общие слова в статье.

Ответить

0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Хакеры смогли обойти двухфакторную
авторизацию с помощью уговоров
Подписаться на push-уведомления
{ "page_type": "default" }