Как стать автором
Обновить

Грейдовая система — хорошо?

Время на прочтение5 мин
Количество просмотров3.9K

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

Думаю стоит сразу отметить, что все нижеизложенное точно не стоит воспринимать как руководство к действию. Это всего лишь мои мысли о существующей системе оценки эффективности труда.

Что вам скажет менеджер

На ежеквартальном общении с руководством компании менеджер скажет, как мы подобрали 26 параметров оценки эффективности, рассчитали коэффициенты и теперь наш график идет вверх. После общения с руководством компании, он выступит на вебинаре, показав эту систему расчета эффективности работы, ему зададут пару вопросов, и все будут довольны. Потом он придет в свой кабинет и будет раз в квартал подставлять значения параметрам в таблицу Exсel, чтобы на графике увидеть, у какого из сотрудников отдела снизился коэффициент полезной работы на секунду времени. Что не так с этой ситуацией, можно сразу и не понять, ведь компания стала больше зарабатывать после введения этой системы, а акционеры вообще очень рады. Давайте заглянем глубже.

Что должен сказать менеджер

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

Что здесь может не сработать? Да почти все, в таком мире живем. Людям очень часто присуще не распространяться о наболевшем, все как-то держать в себе, поэтому на вопросе "Все нравится?" в опроснике от менеджера может быть галочка, а фактически человек будет готов вот-вот уйти в другое место, потому что некрасиво говорить о том, что не нравится.

Что вам скажет Техлид

Техлид до введения этой системы просто указывал в отчете о штатном расписании, что его команда занималась разработкой в определенном направлении, поддерживала определенный продукт, пилила определенные фичи и вообще занималась тем же, чем и в прошлом квартале, только лучше и быстрее. Еще он скажет, что Петя Иванов придумал крутую фичу, а Ваня Петров, уже больше года как-то не очень хорошо работает. А теперь ему нужно трясти свою команду, требуя заполнять раздел my-work в Jira, с указанием сколько дней было потрачено на ту или иную задачу. Будет ли кто-то на самом деле это анализировать?! Скорее нет, чем да, поэтому можно просто писать по-старому (Занимался разработкой, потрачено 40 часов за неделю). Но это нужно менеджеру, что бы он мог подставить в свою таблицу процентное соотношение рабочих часов и часов, потраченных на созвоны и синки.

Что должен сказать Техлид

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

Что здесь может не сработать? Да снова все. Человеческий фактор в оценивании сотрудника может сильно исказить объективную картину. Друг главы команды может смело ничего не делать, и если личное станет выше профессионального, этот человек так и будет ничего не делать, оставаясь на зарплате.

Что вам скажет разработчик

Разработчик спокойно сидел за своим столом в опенспейсе/коворкинге/квартире/кабинете, слушал музыку и писал код. Вдруг ему приходит письмо с текстом: "Не забудь заполнить тайм-трекер, нам нужно для отчета". Он заполняет его вспоминая, что он хотя бы примерно делал на этой неделе. Спустя еще час приходит следующее письмо: "Привет, прошел год с момента как ты устроился к нам на работу, твоя эффективность на 2.6 попугая ниже средней эффективности членов твоей команды, это стоит обсудить". Он открывает hh.ru Он отвечает, что учтет оценку и постарается работать усерднее. Следующие несколько месяцев разработчик открывает тикет на каждый чих, делает пару коммитов и тикет закрывает. В итоге его timesheet забит тикетами: "Рефакторинг функции ReloadPage()", "Оптимизация функции SaveJson()" - по 30 минут каждая. И вот, спустя еще 6 месяцев, ему приходит письмо "Как мы видим, твоя эффективность повысилась, количество закрытых тикетов зашкаливает, поэтому со следующего месяца мы увеличиваем твою зарплату на 20%". И вот разработчик, ни делая ничего сверхъестественного, только увеличив количество отчетов, поднял себе зарплату.

Что должен сказать разработчик

В случае, если его устраивает вышесказанное, ничего. Но если чуть больше времени уделять общению с командой и руководством (хотя бы ближайшими менеджерами), можно неплохо улучшить условия труда и отношение к твоему труду. Нужно заполнять отчеты по времени? Требуйте создать автоматическую систему подсчета на основе учета промежутка между статусом In Progress и Done в задачах, которые поручаются разработчику. Нужно повысить эффективность? Пообщайтесь с менеджером и выясните, почему в его системе учета вы неэффективны, и если вы с ней согласны, станьте эффективнее, если нет, скажите почему не согласны.

Что здесь может не сработать? Если вы скромный человек, вам может быть сложно общаться с руководством. Если вы просто человек, выполняющий свою работу и не более того, у вас может не хватить сил достучаться и что-то изменить в компании. Но в случае, если вам что-то не нравится, и вы не в силах это принять или изменить, лучше сменить место работы на более подходящее. Поговаривают в стартапах с этим полегче:)

И в конце

Я не являюсь экспертом в методологиях управления, я простой разработчик, сделавший выводы на основе общения с другими разработчиками и менеджерами. Я много думал о том, какие системы управления персоналом лучше остальных и понял, что идеальной методологии не существует до сих пор и не может существовать, просто потому что эти методологии применяются людьми. Что я в итоге думаю о грейдовой системе? В своем формальном описании она не идеальна, и чаще всего не будет работать в чистом виде, однако гибридные системы управления с элементами оценки эффективности как по объективным (цифры) так и по субъективным (мнения) показателям имеют право на существование, просто потому, что хороших альтернатив не так много.

Теги:
Хабы:
Всего голосов 10: ↑4 и ↓60
Комментарии4

Публикации

Истории

Ближайшие события