Комментарии 10
По факту никто реально не будет использовать эти инструменты чтобы поднять ОКЛАД сотруднику. Будут исходить от наличия денег и некоторых других факторов (вероятность ухода, сложность поиска замены, рыночная з/п по аналогичной позиции, время простоя и т.д.)
А вот практика сделать 40% оклад, остальное - премия, очень даже часто используется. И если в одних компаниях начисление премии - практически формальность (пара-тройка параметров, которые ставит руководитель и в среднем всем всегда одинаково, ибо даже небольшое отклонение приводит к заметному увеличению или уменьшению премии); то вот в других могут сделать этих параметров довольно много, и все будут отслеживаться автоматически в какой-нибудь системе по (с виду) объективным критериям - количество заявок отработанных, жалобы/благодарности, время реакции на заявку, и так далее. При таких автоматических расчётах сотрудник чувствует, что он не зависит от субъективной оценки руководителем, но как правило, компания оставляет за собой право на пересмотр формул для расчёта премии, и меняет периодически всякие коэффициенты. И если, например, раньше выполнение 100 заявок почти гарантировало максимум премии, то после изменений оказывается, что за них же получаешь 70%, или вообще 20, или даже ступенчатые градации делают. Работодатель может "закручивать гайки", так что каждый раз вроде бы становится хуже (для работника), нужно больше выкручиваться (а иной раз могут сделать так, что никаким способом не получить максимальные показатели). При этом работники будут конечно недовольны, но не настолько, чтобы увольняться. И так гайки крутить можно долго. При этом периодически возвращая для видимости улучшений разные параметры к исходным.
Читаю статью, думаю, какое интересное развернутое вступление к мыслям автора, сейчас начнет выкладывать... а потом упираюсь в "что в итоге".
Кажется, что текст обещал быть более развернутым, но не стал(
Всю статью ждал, какую автор предложит замену. Видимо, несмотря на недостатки грейдовой системы, ничего лучше не придумали?
Если использовать для оценки качественные характеристики, а не количественные, то все будет более хорошо.
Например, такой характеристикой может служить отношение принятых пулреквестов к отклоненным (в результате ошибки слияния, падения тестов или код-ревью).
Перевод абсолютных количественных оценок в относительные с правильным выбором основания также повысит их полезность (вопрос только что считать "правильным" основанием для нормализации оценок).
Проблема грейдовой системы в оценочных функциях, в статье это отмечено. Именно эти методы и определяют эффективность и качество конкретной системы построенной по определенному подходу. В руках идиотов любой инструмент может стать разрушительным.
К сожалению, глобально такое не работает, а не одна компания не будет делать разные стратегии для разных команд. Дело в том, что вы не избавляетесь от человеческого фактора в вашей системе. Если работник слабый, то ему могут давать легкие задания (тупую черную работу) - будет много комитов и все с апрувом и без багов. И наоборот, опытный работник получит сложную исследовательскую задачу и будет её долго пилить с высокими шансами на ошибки и переделки. Я такое видел.
Пытались избежать такое и давали возможность людям самим брать такси - если оценивают количество, то все берут лёгкие и самые нужные и критичные становятся висяками в бэклоге. Тогда решили, что каждый таск/стори будет иметь бал сложности или полезности. Но если их задавала команда на груминге, то они специально завышали оценки - так как конкуренция за бюджет есть и между командами. А когда давали выставлять оценку менеджменту или продактам, то они не могут оценить сложность. По их мнению "тут надо только кнопочку добавить" и оценят на ноль с хвостиком, хотя там может быть 2 спринта работы. Или изменение в инфраструктуре безопасности "это же не так важно как кнопочки, которые видят" - получи опять низкий бал на задание.
Так ваша оценка сложности не являлась качественной, потому что нарушала принцип надежности: "информация является надежной, когда в ней нет существенных ошибок и искажений".
Вообще сама оценка сложности состоит из множества аспектов: оценки рисков, создаваемого технического долга, сложности реализуемого бизнеспроцесса, шаблонности (схожести с ранее решенными задачами), тестируемости, сборки и доставки, желания угодить руководству по срокам и т.п.
Хотите большей объективности, точности и правдивости, оценивайте по большему списку параметров отдельно и выводите общий балл.
Вы забыли главное - оценки по хоть по 3 хоть по 20 параметрам будут ставить люди. И они всегда не объективны, не профессиональны, не ещё чего то там.
Я в свое время слышал, что лучшей метрикой является количество строк кода в продукте на момент его смерти. То есть когда уже больше ничего не измениться, можно ретроактивно проверить кто проделал больше полезной работы. Но такая метрика обычно уже никому не нужна...
Вот так пишешь с телефона, потом перечитываешь с компа вечером, а ошибки уже исправить нельзя...
В большинстве стран законодательно нельзя ухудшать условия труда. Это будет либо нарушением трудового кодекса, либо личного контракта, либо коллективного соглашения.
Поднятие зарплаты для рядовых сотрудников в западных корпорациях решается обычно не по оценкам. На команду дают определённый бюджет - деньгами, поинтами, услугами и тд. И ваше начальство просто раскидывает его по команде. Если кого то нужно удержать и похвалить - им дадут на основании личных интересов, а не KPI. KPI и беседу подведут под нужные цифры. Так что если на 4х дали 1000$ и кому-то отдают 500, то надо сильно постараться получить 0. Обычно будет что то 500, 200, 200, 100. Просто потому что.
Насчёт удержать - тут вот грейд играет. Обычно есть сетка зарплат по рынку согласно внутреннему грейду. И если вам подняли ранг или просто вы ниже рынка - вам добавят. Так как потеря сотрудника дороже и плохо скажется на KPI начальства.
Грейдовая система — плохо?