Так или иначе мне пришлось познакомиться с Engineer ladders системой грейдов для девелоперов https://www.engineeringladders.com/Developer.html .

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

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

Во-первых, верхние уровни двух осей избыточны. Они просто давят низкими оценками.

Во-вторых, целый лвл D-7 добавлен абсолютно искусственно.

В-третьих, при этом почему-то не предусмотрено уровней для стажеров, интернов и других начинающих специалистов.

Главное: абсолютно непонятный выбор шкал для оценки разработчика.

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

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

Сколько значений в этой таблице из 25 полей (3 из которых вообще не используются) про качество и количество зарелизенного кода? Т.е. того, за что в основном разработчику должны бы платить? Примерно 4, первые 2 значения в шкалах system и technology. Начиная с 3 деления даже эти 2 шкалы становятся уже не про код, а про его презентацию.

Может быть, эта система описывает потенциал разработчика? Тоже нет, здесь вообще ничего об этом не говорит.

Я не хочу сказать, что все оставшиеся 21 поле абсолютно бесполезны. Нет! Всегда лучше, когда человек что-то умеет, чем не умеет, особенно, если это связано с работой. Но стоит ли расставлять приоритеты именно так? Целых 3 оси + по половине каждой из двух оставшихся - исключительно навыки презентации и управления. Мне кажется, что акценты окончательно ушли не туда.

Вся система выстроена как будто бы из предположения, что разработчик растет в руководители и только туда. Что написание кода - удел джунов, которые еще просто не доросли до управления и презентаций.

Что бы сделал я?

Использовал бы ту же матрицу, но сменил примерно все оси координат.

Допустим, что нам нельзя перерисовывать дизайн, и поэтому осей непременно должно быть 5.

Ось \ баллы	0	1	2	3	4	5
Теория/Опыт	0, лет	0,5	1	3	5	7+
Деливери	0	1	2	3	4	5
Софт скиллы	не ревьювит	слабо ревью	хорошо ревьювит	+ презентует	+ общается с заказчиком	+ регулярно менторит
Креативность/Вовлеченность	выгорел	слабо	средне	пытается	горит	зажигает
Продукт	0, лет	1/2	1	2	4	4+

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

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

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

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

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

В таком разрезе, все еще проще с оцениванием. Суммируем баллы по 5 шкалам, и:

<=6 - интерн

7-13 - джун

14-17 - миддл

18-21 - сениор

>=22 - лид.

[естественно, здесь мое личное понимание пороговых значений и это не догма]

Некоторым ос��м можно присвоить поправочные коэффициенты, если вы не согласны в их равноправии и тп.

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

Почему мне кажется, что эта система координат лучше?

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

Деньги!

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

Ниже раскладка по годовой ЗП и график сопоставления баллов и денег для одной неназванной европейской столицы. Как читать таблицу. Даны пороговые и средние значения баллов для каждой позиции (например, для джуна - 7 - минимум баллов, чтобы называться джуном, 13.5 - порог до миддла, 10.25 - среднее между границами). Для среднего числа баллов дана не менее средняя ЗП по glassdoor. Графа estimation - простейшая линейная интерполяция с округлением.

	points	salary	estimation
	7		36,000
jun	10.25	43,000	43,000
	13.5		50,000
mid	15.5	53,000	54,500
	17.5		59,000
sen	19.5	65,000	63,500
	21.5		68,000
lead	23.25	72,000	71,500
	25		75,500

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

Для самого сотрудника подробная прозрачность имеет огромные плюсы.

Человек видит свое текущее положение. Видит, какие шкалы западают и где ему проще всего добрать баллов, чтобы получить прибавку. Как мне кажется, мотивация много выше, чем “вырасти-ка до System owner”.

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

Бонус 2.

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

Бонус 3.

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

Инженерная лестница