Скользкая тема, но я решил, что накинуть в начале зимы самое то, потому как скоро сезон «выравнивания» во многих конторах. Тема грейдов не нова. С разной успешностью её применяют многие годы с тех пор как г-н Смит придумал разделение труда в конце 18 века. Сначала людей поделили по способностям и возможностям, следом стало понятно, в что в рамках такого разделения тесно, потому что два токаря токарят, но один из них может делать сложные детали.  В большинстве «материальных» профессий эта штука продолжает существовать до сих пор, там по прежнему разряд рабочего значит очень много.  Но  ранжирование (грейдирование, присвоение разрядов и пр)  часто атрибут системы, где каждый работает отдельно друг от друга.  Токарь и станок, сотрудник почты и посетитель. В этой схеме ранг сотрудника гарантирует наличие у него определенного набора детерминированных качеств и умений, которые позволят лучше разделять работу между участниками для достижения результатов. Условно, я был инженером 3ей категории, когда меня взяли в НИИ после института, и мне не доверяли толком ничего без пригляда, а когда стал инженером первой категории — получил автономность и кучу интересных задач.  При наличии набора критериев грейды помогают распределять людей по зарплатам, по задачам, по статусу.  

В ИТ с определением границ сложнее. Нет четких критериев достижения того или иного грейда. На деле мы работаем, но кто-то делает свою работу лучше и быстрее, а кто-то чуть хуже и медленнее. Могу я быть синьор-разработчиком и не мочь в какие-то тонкости? — Да. Могу я быть Джуниор-разработчиком и мочь в исключения, сложные sql-запросы? — Да. На заре современного ИТ (начало 2000х) грейды (джун, мидл, синьор) выписывались за фактический опыт работы. В наше время, когда в ИТ набежало много молодых талантов, эта схема перестала работать. Потому что набраться опыта оказалось совершенно недостаточно. Я встречал 20летних, которые пилят сложнейший осознанных код, но также встречал старперов, которые деление на ноль не ловят. Вот тут основное — вариативность решаемых задач на столько велика, что любая попытка измерить скил ит в натуральном виде обречен на провал.  

Но я вижу проблему глубже. 

Помогает ли грейд человеку лучше работать? Помогает ли он достижению результатов команде? Надо ли людей сравнивать друг с другом, разве это  дает людям информацию о том, как они выполняют свою работу? Оправданы ли затраты на все эти бесконечные перформанс-ревью, попытки развивать людей по сценарию, чтобы дотащить до грейда? — хз, скажу, что скорее нет. В моем мире куда лучше работает хорошая (подкрепляющая/развивающая) обратная связь. Если вы сделали что-то великое, вам нужно узнать об этом — раньше, чтобы развить успех. И если вы сделали что-то не очень хорошее, вы тоже должны это знать, чтобы исправить прям сразу, ну или прикинуть направления развития. Мир слишком быстро меняется, чтобы действовать по плану. Через две недели после планирования планов развития влетела новая задача — развиваться под нее или откидывать задачу, потому что нет этих скилов в планах? Накосячил — стоит ждать конца года, чтобы получить на ревью «фи»?  Добавим к этому:

1️⃣Хуманы подвержены эффекту Даннинга-Крюгера (нет. уже опровергли, что это вообще сущесвует), когнитивному искажению, при котором некомпетентные люди переоценивают свои навыки.

2️⃣Некоторые компетентные хуманы страдают от синдрома самозванца, когда они чувствуют себя некомпетентными и страдают от этого.

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

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

А зарплату надо пропорционально наносимой пользе платить, а не грейду. Жалко, что я пока так не могу:)

Вот такое вот пятничное получилось.