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

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

Предыдущая статья:

Коля пришел к вам после трех лет работы.

Что вы ответите?

Если вы выбрали В — вы молодец. Но одного разговора мало.

Нужна система, которая делает рост понятным, прозрачным и достижимым.

Без системы:

— Люди не понимают, как расти;

— Лидеры принимают решения «по ощущениям»;

— Возникают обиды и несправедливость;

— Лучшие уходят туда, где есть понятная траектория.

С системой:

— Человек видит свой следующий шаг;

— Лидер может опереться на объективные критерии;

— Рост перестает быть лотереей.

Сегодня разберем, как построить такую систему. Без перегибов в бюрократию, без 50 страниц никому не нужных критериев.

Вспомним стадии по Адизису.

Давайте договоримся о терминах.

Грейд — это не:

— Просто уровень зарплаты;

— Награда за выслугу лет;

— Способ удержать человека;

— Бюрократическая галочка.

Грейд — это:

— Описание ожиданий от человека на определенном уровне;

— Понятный следующий шаг;

— Инструмент диалога о росте;

— Способ синхронизировать ожидания компании и человека.

Хорошая система грейдов отвечает на три вопроса:

1. Где я сейчас? (что от меня ждут на моем уровне);

2. Куда я могу вырасти? (что будет на следующем);

3. Как туда попасть? (что для этого нужно сделать)

Если система не отвечает на эти вопросы — это не система, а фикция.

Прежде чем строить, посмотрим на то, что чаще всего ломает систему.

50 страниц критериев, 10 уровней, матрицы компетенций в Excel на 20 вкладок.

Никто это не читает. Никто это не использует. Люди просто приходят и говорят «хочу следующий грейд», а вы лезете в эти 50 страниц и ничего не понимаете.

Лечение: минимум уровней, максимум понятности.

Это не система. Это те же самые «ощущения», только с названиями.

Лечение: каждый уровень должен быть описан через конкретные ожидания.

Оцениваем только то, как человек пишет код. А как он коммуницирует, как помогает другим, как влияет на процессы — неважно.

В результате вырастают «технические звери», с которыми никто не хочет работать.

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

Человек получает новый грейд — ему автоматически поднимают зарплату. Вроде логично.

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

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

Можно быть сеньором и получать ниже рынка, если компания не тянет. Это нормально, если прозрачно.

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

А если он вырос за три месяца? А если он застрял и ему нужна коррекция?

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

В описание грейда написано «должен знать паттерны проектирования». Человек их выучил — всё, он сеньор?

Нет. Знать и применять в реальных задачах — разные вещи.

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

Внедрили грейды, отчитались перед руководством, поставили галочку. Дальше они лежат мертвым грузом.

Лечение: система должна жить. Обсуждаться на 1-на-1, влиять на задачи, помогать в росте.

Не надо 10 уровней. Для большинства IT-команд достаточно 4-5:

1. Стажер / Джун-1 — только учится, нужен плотный контроль;

2. Джун-2 / Младший разработчик — делает простые задачи самостоятельно, но нуждается в ревью;

3. Мидл — делает сложные задачи самостоятельно, помогает джунам;

4. Сеньор — проектирует архитектуру, влияет на команду, решает критичные проблемы;

5. Лид / Архитектор — отвечает за направление, растит людей, определяет стратегию.

Для маленьких команд можно сократить до 3.

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

Для каждого уровня нужно описать, что ожидается в трех срезах:

А. Технические навыки (харды)

— Какие технологии должен знать;

— Какой сложности задачи решать;

— Как проектировать решения.

Б. Командные навыки (софты)

— Как коммуницировать;

— Как давать обратную связь;

— Как работать в конфликтах.

В. Влияние на продукт и процессы

— Участие в планировании;

— Влияние на требования;

— Улучшение процессов.

Пример для мидла:

Не издавайте грейды приказом и не кладите в стол.

Это должен быть живой документ, который:

— Лежит в открытом доступе (Handbook);

— Обсуждается на встречах;

— Меняется, если жизнь меняется;

— Понятен каждому.

Каждая регулярная встреча с человеком должна включать сверку с грейдами:

— «Посмотрим, где ты сейчас по этим критериям»;

— «Что из этого ты уже делаешь?»;

— «Что еще не делаешь?»;

— «Что хочешь прокачать в ближайшее время?».

Грейды — это не раз в год событие.

Это постоянный фон разговоров о росте.

Как человек понимает, что он готов к следующему уровню?

Варианты:

— Самооценка (человек сам приходит и говорит «я готов»);

— Оценка лидера (вы видите и предлагаете);

— Комитет (несколько лидеров обсуждают кандидата);

— 360 градусов (сбор обратной связи от коллег).

Лучше всего — комбинация. Человек инициирует, лидер собирает данные, комитет принимает решение.

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

Вернемся к Коле из начала статьи.

Коля пришел с вопросом про повышение. Без системы вы бы начали гадать:

С системой вы открываете описание мидла и смотрите вместе:

Техника:

— Задачи делает — ок;

— Код-ревью проводит — ок;

— Предлагает улучшения? — Стоп. Коля, а когда ты в последний раз предлагал улучшения в своем модуле?

Команда:

— Помогает джунам?

— Участвует в обсуждениях?

Влияние:

— Предлагает идеи? — Нет;

— Замечает проблемы в процессах? — Молчит.

Коля сам видит разрыв.

Дальше вы не говорите «ты не дорос».

Вы говорите:

Коля уходит не с обидой, а с планом.

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

Вот как этого избежать:

4-5 уровней достаточно. Не надо 12.

3-5 пунктов на уровень. Не надо 20.

Лучше 3 важных, чем 20 формальных.

Пишите так, как говорите. Не надо канцелярита.

❌ «Осуществляет проактивное взаимодействие с кросс-функциональными командами с целью синхронизации ожиданий».

✅ «Умеет договариваться с аналитиками и тестировщиками, чтобы задача не застревала на стыках».

Не надо оценивать «знание паттернов» ради знания. Оценивайте, использует ли он их в реальных задачах.

Раз в полгода-год садитесь и смотрите: работает ли система? Не устарела ли? Не появилось ли новых важных компетенций?

Система грейдов — это мостик между всеми темами, которые мы разобрали:

Вернемся к Адизису.

Он говорит, что организация стареет, когда в ней перестают расти люди.

Не когда падает выручка. Не когда уходят клиенты. А когда ключевые сотрудники перестают развиваться.

Грейды — это прививка от старения.

Они заставляют:

— Людей — смотреть вперед;

— Лидеров — замечать потенциальный застой;

— Компанию — обновляться.

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

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

Когда Петя понимает, что после бунта его ждет понятный путь — он перестает ломать и начинает строить.

Грейды — это не про оценку. Грейды — это про движение.

Помните Колю из начала статьи?

Через полгода после внедрения системы он пришел на 1-на-1 сам.

Коля не просил повышения. Коля просил роста.

И это главный результат правильной системы грейдов.

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

Ссылка на оригинальную статью: