Как мы разрабатывали систему грейдов

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

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

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

Решено было вводить грейды.

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

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

У нас большей части аутсорс/аутстаф проекты, а значит нам важно, чтобы процедура оценки была максимально простой, не отнимала много времени, не отвлекала специалиста от задач клиента. Но при этом важно было, чтобы грейды помогали сотрудникам развиваться. У нас в компании не так много должностей, по сути только Java-разработчики, тестировщики и DevOps-инженеры. И нам необходимо было упорядочить их по категориям, по опыту и знаниям.

Поэтому мы решили, что сделаем свою систему грейдирования, исходя из особенностей нашего бизнеса.

Мы собрали команду — HR и руководителей направлений — и принялись за работу.

Для начала определили сами грейды — Junior+, Middle, Middle+ и Senior.

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

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

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

• коммуникативность,
• адаптируемость,
• инициативность,
• дисциплина,
• самостоятельность.

На разработку софт-скиллов — выбор и составление методики оценки у нас ушло примерно две недели. Еще три недели тимлиды каждого направления описывали хард-скиллы.

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

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

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

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

Мы стараемся проводить две встречи — на одной, с HR, оцениваются софт-скиллы, а на вторую подключается руководитель для оценки хард-скиллов.

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

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

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

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

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