Вторник. Возвращаюсь с лонгридом в рубрике #дневниктрансформации И сегодня расскажу, что стало причиной моего содержательного отсутствия в течение более чем недели.

В предыдущих сериях:

Первые шаги в HR-менеджменте Системный найм Про управленку Современный и комфортабельный офис Долгосрочное планирование Регламенты Ресурсный учет

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

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

Итак. Унифицированная модель оплаты труда. Начали с самого сложного и массового - система грейдирования разработчиков. Классические подходы к системе грейдирования, когда выделяется какой-то набор уровней-разрядов и происходит оценка по ним, мне не нравилась. Она не соответствовала ожидаемому и реализуемому тренду на универсальность специалистов. Сейчас технологии меняются очень быстро и "специалисты в левом ухе" будут все менее востребованы. С другой стороны, для компании все более ценными становятся специалисты, способные, например, писать backend, понимающие, как организован frontend и способные выполнять базовый функционал devops.

Наша модель предполагает наличие до четырех разных компетенций у каждого разработчика и по каждой из этих компетенций определяется уровень - тут без сюрпризов - джун, мидл, сеньор. Далее мы разработали математическую модель оплаты труда, в которой заложили максимальную гибкость к изменениям внешних технологических факторов (популярность и развитие стеков, спрос на технологии со стороны заказчиков и т.д) и привязали все к фиксированной точке отсчета - федеральному минимальному размеру оплаты труда. Как следствие, в компании появилась понятная схема индексирования заработной платы вслед за регулярным индексированием МРОТ. Настройка адекватности модели заняло порядка двух месяцев.

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

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

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

Продолжение далее...