Без хаоса и разочарований: внедрение грейдовой системы вместо интуитивного начисления зарплат

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

Здесь рассказываю о своем опыте, команде, принципах, результатах и факапах.

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

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

До грейдов

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

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

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

Разнобой зарплат на одинаковых должностях. Один инженер у нас мог получать на 10-20% больше другого, работающего на аналогичной позиции. Каждые полгода мы пытались «выравнивать» этот хаос, но без четких критериев шансы на успех были минимальны.

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

Как все начиналось и во что вылилось

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

1. Создали список всех необходимых компетенций. 

Хард-скилы разбили по направлениям, специфичным для каждой специализации, как то:

• знание законов и норм;

• владение специализированным софтом;

• работа с подрядчиками, экспертами;

• точные расчеты и умение применять их на практике;

• проектирование.

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

Организованность

• Управление временем, планирование и приоритизация

• Самостоятельность в работе

• Проведение совещаний

• Презентация результатов своей работы

Коммуникация

• Работа в команде

• Переговоры

• Стрессоустойчивость

• Обратная связь

• Вовлеченность

Лидерство

• Ответственность

• Делегирование

• Принятие решений

• Наставничество

• Стратегическое мышление

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

  3. Ввели уровни компетенций для оценки прогресса. Каждый сотрудник попадает на один из четырех уровней: от минимального владения (пользуется Google и иногда советуется с коллегами) до топ-эксперта, способного объяснить все на пальцах. Мы прописали требования так, чтобы сотрудник сам мог ориентироваться, до какого уровня ему нужно дойти для повышения.

Наши уровни:

• 25% — изучал в университете или самостоятельно знает, как найти нужную информацию в базе нормативных документов.

• 50% — ориентируется в документах с помощью Google, а в практических задачах иногда консультируется с коллегами.

• 75% — уверенно ориентируется в нормативных документах, знает, какие применять в работе, подсказывает коллегам при необходимости.

• 100% — сам разрабатывает нормативные документы, может найти слабые места и знает, как обойти их.

Живой пример:

Инженер Петя, придя в компанию, соответствовал своей должности на 100%. За полгода он улучшил навыки в Autocad и снизил ошибки в чертежах, увеличив свою компетентность на 20%, что позволило повысить ему зарплату на 20%.

Для перехода на следующий грейд Пете нужно было развить навыки переговоров до 50–75%. За полгода он освоил переговоры с поставщиками и строителями, достигнув необходимого уровня. Теперь Петя — ведущий инженер и может продолжать рост до главного инженера.

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