Зачем нужна система грейдов разработчиков ПО?
- Рано или поздно, полезным разработчикам повышают зарплату. Самые сложные вопросы: когда и на сколько повышать? Система грейдов должна отвечать на эти вопросы. Это, с точки зрения компании или руководителей
- А с точки зрения самих разработчиков, необходимы понятные критерии повышения уровня компетентности и вознаграждений
- Качественная система грейдов способствует скорейшему прогрессу программистов. Так же как и мотивации, заинтересованности в развитии компании
Какие грейды могут быть у разработчиков?
Все слышали о такой градации:
- Джуниор
- Мидл
- Сеньор
Но три уровня, это мало для полноценной системы грейдов. Поэтому прибегают к внутренним грейдам или под-уровням. Например:
- Джуниор
- Джуниор+
- Джуниор++
- Мидл
- …
- Сеньор+
- Сеньор++
Как часто можно повышать грейды?
Это один из самых интересующих разработчика вопросов. Тут нужно выбрать баланс для компании и разработчиков. Неплохим вариантом будет: пол-года. Пол-года — это время, за которое разработчик, действительно, может «подрасти». Можно сделать промежуток времени «плавающим», например, первые грейды — через пол-года, последние — через год.
Кандидат может провалить защиту на следующий грейд. Нужно предусмотреть сколько минимум время нужно закладывать на очередную защиту по грейду. Могу предложить — 3 месяца
Испытательный срок, если он есть, обычно не входит в рассветы времени до следующего грейда.
На сколько будeт расти зарплаты?
Можно отталкиваться от минимальной зарплаты (на уровне Джуниора) и максимальной (Сеньор++). А далее равномерно распределить увеличение между уровнями.
Финансовый рост при переходе по «внутренним» грейдам (Мидл, Мидл+) может быть менее значителен, чем на новый основной грейд (Мидл, Сеньор). А еще, рост внутри уровней Сеньора может быть больше, чем Мидла. А внутри Мидла — больше чем внутри Джуниора.
Какие основные критерии для перехода на новый уровень?
- Конечно же скилы (hard skills).
Другими словами, знания в технологиях, применяемых в компании или планируемых к применению в ближайшем будущем
Конкретная градация скиллов сильно зависит от используемого стека технологий.
Каждый новый грейд включает в себя скиллы предыдущих. Т.е. необходима экспертиза по технологиям из всех нижестоящих грейдов
Рассмотрим подробнее в следующих статьях
- Повышающаяся продуктивность (полезность компании)
Если используются гибкие методологии, это может быть повышающийся уровень выполнения спринтов или же неизменно хороший уровень
- Здоровые отношения в коллективе (это можно узнать у кадровика или самостоятельно наблюдать за кандидатом) и положительное влияние на атмосферу в коллективе (не приносит ли он больше вреда, чем пользы, не конфликтный ли)
- Прочитанные книги
Чем больше в кандидате теории, тем вариативнее будут принимаемые им решения.
Это могут быть книги как по разработки, так и по личностному росту или же процессам (опять таки, гибкие методологии или другие методологии разработки)
Книги лучше распределять по грейдам начиная от простых (и более подходящих для начальных грейдов) и заканчивая более сложными (и более соответствующими высоким грейдам).
Подробнее рассмотрим в следующих статьях
Кто и как принимает решение о защите грейдов?
Ниже привожу один из вариантов «целостной картины»:
- На защите, решение принимает, коллегиально: директор по разработке (тех дир), директор продукта (главный менеджер) и HR-директор (кадровик) и непосредственный руководитель.
- Подтверждение скилов исходит от непосредственного руководителя (тем лид). Он может привести примеры проектов или фич, подтверждающие хорошее качество и необходимые знания
- Кандидат на новый грейд информирует непосредственного руководителя о заинтересованности по переходу на новый грейд. Помогает руководителю сформировать базу кода, подтверждающую скиллы
- Кандидат на новый грейд проявляет инициативу, чтобы получать задачи для подтверждения скиллов нового грейда
- Грейды проходят последовательно, без пропусков. Исключение — когда взяли на работу на определенный грейд