Привет, Хабр!

В IT‑компаниях зарплаты часто формируются по нескольким принципам сразу:

• «как договорились на собеседовании»;

• «как просил кандидат»;

• «как считает справедливым тимлид»;

• «как ставили в прошлый раз похожему специалисту».

Через пару лет такого подхода в команде из 50 человек обнаруживается, что Senior‑разработчик с тремя годами стажа получает на 30% меньше Middle‑разработчика, который пришёл год назад с агрессивным оффером. Это вскрывается, когда один из них узнаёт зарплату другого, идёт к HR, и начинается серия неприятных разговоров с руководством и потенциальным оттоком из‑за ощущения несправедливости.

Salary banding — это система зарплатных вилок, привязанных к ролям и грейдам, которая снимает большую часть этих проблем. К 2026 году salary banding есть в подавляющем большинстве крупных IT‑компаний и постепенно проникает в средние и небольшие.

Что такое salary banding и почему оно отдельно от грейдинга

Грейдинг — это система иерархии ролей внутри компании: какие позиции существуют, на каких уровнях, как друг с другом соотносятся (например, Senior Backend Engineer выше Middle Backend Engineer, но не сравним напрямую с Senior Frontend Engineer). Грейды отвечают на вопрос «какая роль и какой уровень».

Salary banding — это диапазоны зарплат, привязанные к грейдам. Внутри одного грейда есть минимум, максимум и середина. Конкретная зарплата сотрудника попадает в этот диапазон в зависимости от его производительности, стажа в компании, ключевых компетенций. Salary banding отвечает на вопрос «сколько платить за роль и уровень».

Грейдинг можно построить без зарплат, опираясь только на ответственности и компетенции. Salary banding без грейдинга невозможен: вилки привязаны к чему‑то, и это что‑то — грейды. На практике эти системы строятся параллельно, и HRBP часто оперирует ими как одной.

Польза от banding для компании несколько:

1. Прозрачность: сотрудник понимает, на каком грейде он сейчас и что нужно для перехода на следующий.

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

3. Защита от перекосов: если новый кандидат просит зарплату выше потолка грейда, это сигнал либо для пересмотра грейда (если рынок изменился), либо для отказа кандидату (если запрос неадекватный).

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

Шаг 1: определить роли и уровни

Первый шаг — составить список ролей и уровней, которые есть в компании. Не «должности из штатного расписания», а реальные роли, как они есть на практике. В IT‑компании среднего размера обычно получается 15–30 ролей, на каждую от 3 до 6 уровней.

Типичный набор ролей в IT:

Engineering:
  - Backend Engineer (Junior, Middle, Senior, Lead, Principal)
  - Frontend Engineer (те же уровни)
  - Mobile Engineer (Junior, Middle, Senior, Lead)
  - DevOps / SRE (Middle, Senior, Lead, Principal)
  - Data Engineer (Junior, Middle, Senior, Lead)
  - ML Engineer (Middle, Senior, Lead, Principal)
  - QA / Automation (Junior, Middle, Senior, Lead)

Product & Design:
  - Product Manager (Junior, Middle, Senior, Lead, Director)
  - UX Designer (Junior, Middle, Senior, Lead)
  - Product Analyst (Junior, Middle, Senior, Lead)

Engineering Management:
  - Engineering Manager (parallel to Lead/Principal)
  - Director of Engineering
  - VP Engineering

Operations:
  - HRBP, Recruiter, Office Manager, etc.

Каждая роль имеет описание: ответственности, ожидания, требуемые компетенции. Каждый уровень внутри роли описывает дельту от предыдущего: что нового делает Senior по сравнению с Middle, что Lead делает дополнительно к Senior.

Распространённая ошибка на этом шаге — попытка скопировать структуру другой компании. У Google, Yandex, Сбера, Авито свои особенности, и их структура не обязательно подходит под маленький стартап или компанию среднего размера. Лучше начинать со своей реальности и постепенно усложнять, чем сразу строить 20 уровней, как у big tech.

Описания уровней пишутся в формате «competency matrix» с конкретными формулировками. Не «Senior должен быть опытным», а «Senior самостоятельно проектирует архитектуру модулей до 10 тысяч строк, делает code review для команды до 5 человек, является техническим экспертом в 2–3 областях».

Шаг 2: собрать рыночные данные

Зарплатные вилки строятся на основе того, что платит рынок. Источники данных в 2026 году:

• Отраслевые обзоры. В России это «Хабр Карьера salary survey», «Habr Salary Reports», исследования от «Хантфлоу». Они дают агрегированные данные по ролям и регионам, но опросные методологии часто несовершенны (small sample size, перекос в сторону высокооплачиваемых).

• Платные исследования. У больших компаний есть подписки на Mercer, Aon, Korn Ferry — это глобальные провайдеры зарплатных бенчмарков. Для средней IT‑компании цена не оправдана.

• Внутренние данные о найме. Что компания предлагала кандидатам, что просили кандидаты, какие были accepted offers. Если найм идёт активный, через 6–12 месяцев накапливается достаточный датасет.

• Нетворкинг с коллегами из других компаний. HRBP‑чаты, Slack‑сообщества типа People Ops, профильные конференции. Анонимные обмены данными очень полезны для калибровки.

Практический подход: использовать минимум 3 источника, сравнивать цифры. Если данные сходятся в пределах 15–20%, можно использовать как opportunity. Если расходятся сильнее, нужно копать глубже: возможно, ваша роль определена иначе, чем в источнике, или ваш регион имеет существенный perfaktor.

Для каждой роли и уровня собираются 25-й, 50-й (медиана) и 75-й перцентили рыночных зарплат. Это будут якоря для построения вилок.

Шаг 3: построить вилки

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

Минимум вилки (band minimum) — для тех, кто только что получил этот уровень,
                                 имеет минимальный опыт в роли.
                                 = 75-80% от рыночной медианы
                                 
Средина вилки (band midpoint) = рыночная медиана для этого уровня.
                                 Сюда попадают сотрудники с типичной производительностью
                                 и опытом в роли 1-3 года.
                                 
Максимум вилки (band maximum) — для высокопроизводительных сотрудников или 
                                 для удержания. = 115-125% от рыночной медианы.

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

Между уровнями должна быть существенная разница в midpoint, обычно 20–35%. Если midpoint Senior на 10% выше midpoint Middle, мотивации переходить на Senior мало: проще просить повышения внутри Middle до потолка вилки.

Пример вилок для Backend Engineer в IT‑компании в Москве на середину 2026 года (цифры условные, для иллюстрации):

Junior Backend Engineer:
  Min: 150 000  Mid: 200 000  Max: 250 000  

Middle Backend Engineer:
  Min: 230 000  Mid: 300 000  Max: 370 000

Senior Backend Engineer:
  Min: 350 000  Mid: 450 000  Max: 550 000

Lead Backend Engineer:
  Min: 500 000  Mid: 620 000  Max: 750 000

Principal Backend Engineer:
  Min: 700 000  Mid: 850 000  Max: 1 050 000

Перекрытие между вилками соседних уровней допустимо в пределах 10–15%: топ Middle получает столько же, сколько начинающий Senior. Это нормально, потому что момент перехода между уровнями нечёткий, и переход не должен означать огромный скачок зарплаты.

Дополнительно к base salary в вилку часто включают другие компоненты: годовой бонус (15–25% от base для Senior+, 10% для Middle, 0–5% для Junior), stock options или phantom shares (если есть), доплаты за on-call. Total compensation иногда оказывается на 30–40% выше base, что нужно учитывать при сравнении с рынком, особенно с компаниями, у которых иная структура комп‑пакета.

Шаг 4: применить новую систему к существующим сотрудникам

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

• Сотрудники ниже минимума (below band). Это «underpaid» сотрудники, которые исторически получают меньше рынка. Правильная реакция — поднять их зарплату до минимума вилки в ближайшем регулярном цикле пересмотра. Если разница большая (больше 20–25%), можно поднимать поэтапно: половину сразу, остальное через 6 месяцев. Не оставлять надолго в below band, это создаёт постоянный риск ухода.

• Сотрудники выше максимума (above band). Исторически переплачиваемые относительно их грейда. Самый болезненный случай для HRBP. Снижать зарплату нельзя по ТК и крайне нежелательно по моральным соображениям. Варианты: заморозить зарплату до момента, когда вилка вырастет и догонит её (обычно через 1–2 пересмотра рынка); повысить грейд до соответствующего реальной зарплате (если сотрудник реально работает на этом уровне); продумать переход на другую роль с более широкой вилкой.

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

За один цикл нельзя поднять зарплаты всем above-the-band и below-the-band сразу, бюджет не выдержит. Реалистичный план — растянуть alignment на 12–18 месяцев, в первый цикл закрыть самые острые случаи (extreme below-band), дальше планомерно работать с остальными.

Шаг 5: коммуникация с командой

Самый трудный шаг. Внедрение salary banding часто провоцирует разговоры на уровне «значит, у нас раньше было несправедливо?», «значит, я недоплачен/переплачен?», «значит, теперь мою зарплату вы будете контролировать строже?».

Несколько принципов хорошей коммуникации.

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

2. Объяснение причин. Зачем компания внедряет систему: для справедливости, для предсказуемости, для устранения исторических перекосов. Не для контроля и не для понижения зарплат.

3. Roadmap для каждого сотрудника. На индивидуальном one‑to‑one HRBP вместе с тимлидом объясняет конкретному сотруднику, какой у него грейд, какая вилка, где он внутри вилки, что нужно для следующего грейда. Конкретный план развития.

4. Связь с производительностью. Перемещение внутри вилки и переход между грейдами должны быть привязаны к performance review, а не происходить раз в год автоматически. Это требует наличия performance review process; если его нет, нужно вводить параллельно с salary banding.

5. Регулярные обновления. Раз в полгода‑год вилки пересматриваются под изменения рынка. Об этом тоже коммуницируется команде. Постоянство процесса важнее, чем разовое идеальное внедрение.

Поддержание системы во времени

Salary banding далеко не разовый проект, а постоянный процесс. Несколько ритмов, которые имеет смысл выстроить.

• Раз в полгода: market check. Сбор свежих данных по рынку, сравнение с текущими вилками. Если рынок ушёл больше чем на 10–15%, вилки сдвигаются. В IT в 2024–2026 годах рынок двигался достаточно динамично, такие проверки реально нужны раз в шесть месяцев.

• Раз в год: performance review + salary adjustments. Каждому сотруднику смотрят performance, его место в вилке, обсуждают повышение. Это не автоматическое «всем по 10%», а калиброванное решение.

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

• При каждом найме: проверка соответствия оффера вилке. Если предлагаемая зарплата выходит за вилку грейда, это сигнал: либо рынок ушёл (нужно пересмотреть вилку), либо грейд кандидата выше (нужно нанять на более высокий), либо кандидат запрашивает завышенную цену (отказать или торговаться). Систематические exceptions, не отражённые в обновлении вилок, постепенно делают систему фиктивной.

Что часто упускают при первом внедрении

Несколько вещей, на которых HRBP, внедряющие banding впервые, регулярно спотыкаются.

1. Не учитывают региональный фактор. У компании, работающей в Москве, Санкт‑Петербурге и удалённо из регионов, не может быть одной вилки на всех. Зарплаты в Москве и Тюмени могут отличаться на 25–40% за ту же роль. Решения: либо единая вилка с региональным коэффициентом, либо отдельные вилки на регион. Единая вилка часто выгоднее для рекрутинга в регионах (платите больше рынка), но дороже для бизнеса.

2. Не учитывают компенсационный пакет целиком. В двух компаниях зарплата может быть формально одинаковая, но total comp кардинально разный из‑за ДМС, отпуска, бонусов, stock. При сборе рыночных данных важно собирать total comp, не только base salary.

3. Жёсткие вилки без учёта exception cases. Бывают сотрудники, которые объективно стоят дороже своего грейда: уникальные эксперты в редкой технологии, носители критичного для бизнеса знания, инженеры с известным именем в комьюнити. Им нужны исключения, и система должна предусматривать механизм exception approval (обычно через VP или CEO).

4. Игнорирование gender pay gap. После внедрения вилок важно проверить, нет ли систематического перекоса по гендеру, возрасту, национальности внутри вилок. Если женщины‑сотрудники стабильно сидят в нижней половине вилки, а мужчины в верхней, это сигнал о скрытой дискриминации, который выявляется только при системном анализе.

5. Слишком детальная система с самого начала. Попытка сразу построить 8 уровней с подуровнями каждый и 30 разных ролей приводит к параличу. Лучше начать с 4–5 уровней и 10–15 ролей, добавлять детали по мере необходимости.

6. Отсутствие документации. Вилки и грейды должны быть с описанием логики, источников данных, методологии калибровки. Через год HRBP может уволиться, и без документации новый человек не сможет поддерживать систему. Документ обновляется при каждом пересмотре вилок.

Чек‑лист на ближайший квартал

Минимальный план запуска salary banding в IT‑компании среднего размера:

1. Собрать список ролей и уровней (одна‑две недели работы HRBP + tech leads).

2. Описать competency matrix для каждой роли и уровня (двух‑трёхнедельная итеративная работа).

3. Собрать рыночные данные из 3 источников (одна‑две недели).

4. Построить вилки, согласовать с CEO и CFO (бюджетные импликации обязательно обсуждаются).

5. Провести анализ существующих сотрудников: кто в band, кто below, кто above (одна неделя).

6. Спланировать alignment на ближайшие 12–18 месяцев с приоритетами (одна неделя планирования + одна на согласование).

7. Объявить систему команде через all‑hands встречу с FAQ‑сессией.

8. Провести индивидуальные one‑to‑one с каждым сотрудником в течение месяца.

9. Зафиксировать методологию в Confluence/Notion.

10. Установить регулярные ритмы: market check раз в полгода, performance review раз в год, grade review раз в год.

Полный запуск занимает 3–4 месяца от старта до первого alignment‑цикла. Дальше система работает в фоне, обновляется регулярно и экономит часы.

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

9 июля в 20:00 пройдёт урок «HR на языке цифр: от кадров к стратегии». На нём разберем бизнес‑концепции и инструменты, которые помогают HR эффективнее работать в IT‑компании.

Больше открытых уроков июля смотрите в дайджесте.

Что почитать по теме:

• «Есть ли шанс правильно оценить трудозатраты?» — о планировании, неопределённости и том, почему управленческие решения в IT редко укладываются в идеальную схему.

• «Когда сотрудник тормозит команду: как говорить с ним прямо, но без давления» — про сложные разговоры с сотрудниками, обратную связь и управленческую коммуникацию.