СА
грейды и вот эта вся схема с KPI вообще склонны к вырождению в механизмы работы на ревью, а не на результат.
Просто ревью должно отражать результат, тогда всё будет ок)
Size: a a a
2020 August 04
RK
грейды и вот эта вся схема с KPI вообще склонны к вырождению в механизмы работы на ревью, а не на результат.
все так, но этот как раз повод основательно подойти к Competency matrix и тому как проходит ревью
RK
не чтобы их не "хакали" а чтобы "хакали" так как надо для компании
O
еще есть мнение что это убивают любую иниативу
RK
эмм ну перф зависит от импакта
RK
как и промо
O
Просто ревью должно отражать результат, тогда всё будет ок)
Тут есть сложные и неочевидные зависимости. Я знаю одного человека, который не так давно работал в одной очень известной российской компании и там, не смотря на то, что kpi к результату привязан, массово занимались натуральными махинациями с ревью и нагрузкой на команду, чтобы на цифрах все выглядело максимально добротно.
O
Со всеми этими грейдами надо понимать, что они же построены не для того, чтобы все работали и прям росли, а для того, чтобы усложнить рост и удержать зарплаты, иначе отделы начнут резко состоять из лидов, а их столько просто не нужно.
O
Да, в эту тему я пока не погружался, текущая команда - гиперлокальная, даже на удалёнке имитируем работу в одном офисе. GitLab вроде сделал систему коэффициентов для географии.
Ага, и эта система коэфициентов хоть и интересная, но по сути позволяет нанимать "средних по рынку". По крайней мере в тех локациях, что я смотрел, по Европе.
O
еще есть мнение что это убивают любую иниативу
Все так. Лично видел, много слышал. Нет смысла херачить перманентно, надо нахерачить на хорошее ревью.
E
Все так. Лично видел, много слышал. Нет смысла херачить перманентно, надо нахерачить на хорошее ревью.
А разве это плохо?
Не нужно херачить перманентно, но лучше добиться от человека в нужное время его пик перформанса
Не нужно херачить перманентно, но лучше добиться от человека в нужное время его пик перформанса
АА
Со всеми этими грейдами надо понимать, что они же построены не для того, чтобы все работали и прям росли, а для того, чтобы усложнить рост и удержать зарплаты, иначе отделы начнут резко состоять из лидов, а их столько просто не нужно.
кмк, не совсем так.
например имею пример компании которая резко увеличила количество работников.
уровней/грейдов/статусов как бы нет и есть.
как понять в условиях найма/ухода работников кто есть кто и как кого биллить пока не очень ясно.
например имею пример компании которая резко увеличила количество работников.
уровней/грейдов/статусов как бы нет и есть.
как понять в условиях найма/ухода работников кто есть кто и как кого биллить пока не очень ясно.
АА
А разве это плохо?
Не нужно херачить перманентно, но лучше добиться от человека в нужное время его пик перформанса
Не нужно херачить перманентно, но лучше добиться от человека в нужное время его пик перформанса
а вот здесь нюанс, что оно может не совпадать с перформанс ревью :)
E
Ну так даже выгодно компании)
O
А разве это плохо?
Не нужно херачить перманентно, но лучше добиться от человека в нужное время его пик перформанса
Не нужно херачить перманентно, но лучше добиться от человека в нужное время его пик перформанса
Не, несколько не так это выглядит. Условно ,человек может сделать 3 хороших фичи. Для ревью хватит одной, промоушен на следующий грейд далеко, два раза подряд точно не поднимут. Он делает одну и потом просто пинает болт до следующего цикла, где делает вторую и т.д.
O
кмк, не совсем так.
например имею пример компании которая резко увеличила количество работников.
уровней/грейдов/статусов как бы нет и есть.
как понять в условиях найма/ухода работников кто есть кто и как кого биллить пока не очень ясно.
например имею пример компании которая резко увеличила количество работников.
уровней/грейдов/статусов как бы нет и есть.
как понять в условиях найма/ухода работников кто есть кто и как кого биллить пока не очень ясно.
Не, понимание того, кто есть кто и понимание того, кому как денег досыпать и по ролям двигать - это несколько параллельные вещи
O
или просто у него чтобы пройти ревью хорошо - надо сделать 3 крутых фичи, человек будет только их делать ,а то что у проекта есть баги и он лично глазами и видит и мог бы править, не будет.
Я это все конечно утрирую, но такое бывает
Я это все конечно утрирую, но такое бывает
O
Не, несколько не так это выглядит. Условно ,человек может сделать 3 хороших фичи. Для ревью хватит одной, промоушен на следующий грейд далеко, два раза подряд точно не поднимут. Он делает одну и потом просто пинает болт до следующего цикла, где делает вторую и т.д.
а если для ревью надо 2 или 3, то он просто сгорит, потому что тогда ему надо будет показать совершенно нереальную производительность для шифта.
O
Блин, вся эта схема с ревью и KPI пройдена миллионами людей на заводах, где есть план и есть зп + премия. Сценарии проблем с этим уже исписаны кругом-везде.
Тем более что в нашем случае даже премии по сути нет, надо просто делать "в среднем как все".
Тем более что в нашем случае даже премии по сути нет, надо просто делать "в среднем как все".
O
или просто у него чтобы пройти ревью хорошо - надо сделать 3 крутых фичи, человек будет только их делать ,а то что у проекта есть баги и он лично глазами и видит и мог бы править, не будет.
Я это все конечно утрирую, но такое бывает
Я это все конечно утрирую, но такое бывает
Да и еще раз да. Багфиксы, рефакторинг и прочее занимают кучу времени, но очень плохо выглядят на ревью. Потому что Вася половину имплемента сидел и чинил всякое говно, а Петя за это время выкатил очень модную фичу. Молодец чаще всего будет Петя, а Вася получит максимум "все ок, копай дальше".