Comments 9
Performance review проводится как раз для того, чтобы не повышать зарплату. Оно создает удобные условия, чтобы откладывать решение на неопределенный срок.
До изобретения как было - приходит сотрудник и говорит: я план выполняю и перевыполняю, вот доказательства. А получаю как все. Давай-ка повышай зарплату, или ухожу. Что тут ответить?
После внедрения: по результатам PR проведенного на основании оценок ваших коллег, вам следует подтянуть A, B и С, пройти процедуру ассесмента и тогда все будет. Но это вообще не проблема. Мы сейчас с вами быстро согласуем план вашего развития на год вперёд, и по результатам вернёмся к вопросу. Ну и весь следующий год вы перформите за те же деньги.
Сотрудники результатов PR друг друга не видят, чтобы сравнить. Поэтому теперь вынуждены верить джентльменам на слово. Очень удобно.
У каждой методологии свои плюсы и минусы. В ваших словах есть правда.
Для нас было важно оценить все что делал сотрудник, получить неявные инсайты от них и улучшаться. Просмотрев кучу методологий, мы остановились именно на Performance Overview.
А что бы вы использовали? Что советуете применять?
Ретро отличный инструмент для выявлений зон улучшения процесса, и получения обратной связи от команд разработки. Не представляю как его использовать для грейдинга команды.
А может не надо грейдить команду? Оценить разработчика может только другой более опытный разработчик. И всегда есть тема, которую ты видишь впервые, независимо от уровня. Как выше уже написали, это нужно, чтобы не повышать зп. В итоге мы среднее время работы в компании год и имеем, т.к., вместо повышения, человек в другую компанию уходит
мы не стремимся не повышать зарплату, как раз наоборот. Основная наша цель это объективно оценить вклад, и достойно его вознаградить. Все что вы говорите верно, из за этого мы в своих опросниках смотрим на уровень и объем выполненных задач -> получаем ревью от техлида -> тимлид готовит решение на основе полученных данных.
Пожалуйста,не пишите оставшиеся 2 части.
Как мы внедряли процесс Performance Overview для грейдинга команды разработки. Часть 1