Смотрите «Дом Дракона» 22 августа в подписке Плюс Мульти с Амедиатекой на Кинопоиске
«Дом Дракона»
Смотрите в подписке Плюс Мульти с Амедиатекой на Кинопоиске
Доступно на Кинопоиске по Подписке Плюс Мульти с Амедиатекой или при наличии Доп. опции "Амедиатека". Условия: clck.ru/FMQND.
Доступно на Кинопоиске по Подписке Плюс Мульти с Амедиатекой или при наличии Доп. опции "Амедиатека". Условия: clck.ru/FMQND.
18+

А давайте все-таки посчитаем KPI разработчика

За десять лет в программировании я ни разу не встретил расчета KPI разработчика. Бизнес буквально мечтает о введении этого показателя: следит за рынком, вводит грейды, присваивает ярлыки: Junior, Senior, Middle. Этой проблемой со мной поделился хороший товарищ, топ-менеджер международной компании, и у меня появилась следующая идея.

Мой босс, когда речь заходит о подсчете KPI

KPI — сугубо бизнесовый показатель. Применить его к отдельно взятому разработчику нереально. И вправду, как оценить показатель творческой деятельности? Как вообще понять, что один разработчик работает хорошо, а другой плохо с точки зрения бизнеса?

Мое решение — всего лишь теория, которую нужно подтвердить или опровергнуть. Что если оценивать не столько работу разработчика, сколько дополнительную нагрузку на бизнес в результате его работы. А конкретно: сколько ресурсов затрачивает разработчик, если выполняет свою работу недостаточно эффективно. Включая часы тестирования, аналитики, ревью и прочие затраты, которые можно посчитать.

Взгляд изнутри

Мы думаем что фича разрабатывается так:

Набросал в Draw.io из шаблона. Изи

Вот только план несколько утопичен. На деле все несколько сложнее:

Так же упущено много деталей, но уже ближе к реальной жизни

Безусловно, общие время и ресурсы, затрачиваемые при разработке, зависят от каждого члена команды. Если кто-то из членов команды делает свою работу недобросовестно, то это будет видно по затраченному времени его коллег.

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

Идея расчета KPI для разработчика в том, чтобы считать время, которое команда тратит на работу вне минималистичной схемы. А именно повторное ревью, повторное тестирование. То есть все, что выходит за рамки линейного процесса или было отправлено назад на доработку. В отсутствии доработок и экономии на этом и есть прямой интерес бизнеса.

Считаем в деньгах

Для простоты предлагаю посчитать в деньгах. Возьмем ряд переменных:

D — ставка разработчика (500);

Hd — выработка часов;

T — ставка тестировщика (250);

Ht — время повторного тестирования;

A — ставка аналитика (200);

Ha — время на разъяснения;

L — ставка лида (1000);

Hl — овертайм на ревью.

Тогда формула будет выглядеть так:

R = (T*Ht + A*Ha + L*Hl + D*Hd) / D*Hd * 100 – 100

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

Пример. Разработчик потратил на задачу восемь часов. Она вернулась к нему на доработку с багами. Он два часа фиксил ошибки, лид потратил полчаса на ревью, а тестировщик еще час проверял, что все исправлено. Считаем:

(250*2 + 200*0 + 1000*0,5 + 10*500) / (10*500) * 100 – 100 = 20

Получаем процент. Компания потратила на 20% ресурсов больше, чем нужно было. Это немного, но в рамках рисков. Но если бы разработчик набросал свою фичу на коленке за два часа, перепроверять и дорабатывать пришлось бы несколько раз, цифра выросла бы в разы:

(250*6 + 200*0 + 1000*2 + (2 + 4)*500) / ( (2 + 4)*500 ) * 100 – 100 = 117

Если бы разработчик подошел к задаче ответственнее, потратил шесть часов сразу и все перепроверил — результатом формулы могло бы стать 0%. Это и называется «сработать чисто». А при текущей схеме мы потеряли 3500 у.е.

Можно вывести формулу с учетом предварительной оценки задачи, но важно помнить, что релевантность будет зависеть от множества факторов. Добавим переменных:

S — общие затраты (T*Ht + A*Ha + L*Hl + D*Hd);

Et — оценка задачи.

Re = (S / D*Hd + (Et*D – D*Hd) / D*Hd) * 100 – 100

Если добавить к предыдущему примеру оценку задачи в десять часов показатель будет равен 183, а если оценить в четыре часа — 83.

Сам алгоритм в стадии разработки. И к вам я пришел за обратной связью, взглядом со стороны, возможно, в надежде найти единомышленников. В моей компании «ЮзТехе» мне дали картбланш на тестирование теории. Я планирую подключиться к БД редмайна, вытащить оттуда историю статусов задач с трэкингом, наложить сверху вычисления и посмотреть, что получится.

Если вас заинтересовала идея, напишите об этом в комментариях, я постараюсь публиковать здесь промежуточные результаты своих тестов. А если вдруг кто захочет поучаствовать в эксперименте, милости прошу в Telegram, обсудим детали.

0
79 комментариев
Написать комментарий...
Alex C.

Пока батраки-технари несут на своих пальцах, стучащих по клавам, в светлое будущее компанию, написывая мегабайты кода, садя зрение и кривя спину, эффективные менеджеры отогнув мизинчик, попивая кофеёк, расположив свои чресла на удобных кожаных креслах спорят о kpi работников и в особенности о коэффициентах в формуле, быть ли 1е-2 в числителе или в знаменателе. Вопрос сложный, так просто к нему не подойти.

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

Порой бывает кнопку прикрутить нелинейно отражается на времени работы и трудозатратах всей команды в целом.

Как вариант, предлагаю, под названием "А давайте все-таки посчитаем KPI разработчика", написать мелким шрифтом "Проблемы топ-менеджеров международных компании - это Junior, Senior, Middle.".

Согласитесь, от расчета kpi, вашим работникам легче не станет, им станет легче, если вы поможете хотя бы на шаг придвинуться к утопичной идеи баланса между работой и их реальной жизнью.

Ответить
Развернуть ветку
Антон Анискин

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

По вашему - работнику пофиг - переделывалась ли задача три раза по неделе или была сделана сразу в один заход но за 7 рабочих дней например.
Он всё равно ту же самую зарпоату получит.

А для компании есть разница - каждый месяц откручивать несколько лямов на щарплаты налоги. И получать либо в несколько раз меньге либо в несколько раз больше доставленных в прод задач.

Просто за счет того, что кто то взял и взглянул на процесс системно.
Вот за это "эффективные менеджеры" и получают свои деньги.

Ответить
Развернуть ветку
7 комментариев
Олег Брюханов

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

Ответить
Развернуть ветку
Натуральный Кирилл

.

Ответить
Развернуть ветку
Goddard Targarten

Лол. Программисты бедные несчастные работяги? Ну так идите менеджером, это ж не трудно, они все тупые и ничего не делают, только мизинчик отгибают. Или может расскажите про тяжёлые условия труда и уровень зп тем, кто зарабатывает физическим трудом?

Ответить
Развернуть ветку
2 комментария
Andrey Zharkikh

про ненужность менеджера на проекте можно будет всерьёз поговорить тогда, когда разработчики научатся по-русски друг с другом разговаривать и задавать вопросы вовремя... ну хотя бы ЭТО научатся делать. Тогда заместо менеджера можно будет посадить дрессированную эксельку и google translate. Но пока этого нет -- менеджер дополняет отсутствующие компетенции в команде.

А про KPI... да нафиг его не надо считать! просто тогда ответ на вопросы "почему мне нельзя повысить ЗП?" или "почему это меня уволить?" ответ будет "потому!".

Ответить
Развернуть ветку
2 комментария
Nikolay Pasynkov
Автор

Как и ожидалось, коллеги по цеху заклевали =) У человека при виде трех букв рядом K, P и I - сразу в голове всплывает "Ох уж эти проклятые менеджеры, опять хотят порезать мне зарплату и пить смузи!" Я встречал разных менеджеров, большинство из них, кстати, пашет как не в себя.

Вообще KPI не про "резать зарплату", а про эффективное использование ресурсов. Бизнесу проще больше зарабатывать чем резать ФОТ на копейку демотивируя сотрудника, уж тем более в такой высококонкуретной среде как ИТ. Смотрите глубже.

Представьте, у вас достаточно большой отдел разработки. Аналитик А - пишет достаточно подробные постановки, а аналитик B - в основном крупноблочно. Разработчик X - хорошо справляется с достаточно-подробными задачами, а разработчик Y - легко разбирает бизнес-требования и грамотно реализует. C каким кого поставить? А добавьте еще пару архитекторов у которых тоже свои заморочки. Эффективность сотрудников в команде это не про зарплату а про то кому с кем работать комфортнее и в каком эффективность команды будет выше.

Есть очень разные люди. Кому-то комфортнее когда у него мягкий лид, кому-то вообще проще одному, потому что не находит общий язык с командой и так далее. А задача "коварных менеджеров" при этом так их собрать, чтобы всем было комфортно, никто не лез на hh и получал удовольствие от того что у него получается, а не когда его долбит тестировщик, или аналитик опять "написал какую-то херню".

Ответить
Развернуть ветку
Любой инструмент

Проблема в том,что единая команда распадается на отдельные команды со своими kpi. Их главная цель становится выполнение своего локального kpi,а не общего.

Ответить
Развернуть ветку
10 комментариев
Alex C.

Пашете со своим плугом или в офисе выдают?)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Кроко

Бросьте вы лучше эту идею с KPI для программистов. Прежде чем считать, надо понять в деталях всю систему в целом, что её делает эффективной. Зарплату, время, количество фич, строк кода или открытых-закрытых багов в неделю считать просто и приятно. Но что вы будете делать с полученными цифрами?

За десять лет в программировании я ни разу не встретил расчета KPI разработчика.

И за десять лет вместо того, чтобы задать себе вопрос "А почему так?" делаете утверждение, что "бизнес буквально мечтает о введении этого показателя". Плохой бизнес наверное мечтает. Попробуйте оценить в KPI эффективность воспитания ребенка родителем. Будете считать количество кружков и секций или время проведенное в детсаду-школе? Количество медалей-грамот или среднюю оценку в конце четверти?

Ответить
Развернуть ветку
Sergey Gotsulyak

Коллега, представим ситуацию : нашли более-менее работающую формулу, посчитали KPI, поняли, что у нас в компании работают программисты с разбросом показателя от 34% до 146%. Дальше что?

Уволить всех разработчиков с KPI менее 50% ? Снизить оклады разработчикам с KPI менее 75% ? Поднять оклады разработчикам с KPI более 120% ?

При любом раскладе компании-конкуренты будут рады притоку новых кадров на рынок :)

Ответить
Развернуть ветку
Nikolay Pasynkov
Автор

Ответил примерно на это выше, но повторюсь.

По большому счету показатель эффективности у каждого специалиста будет разнится исходя из профессионализма его коллег и типа задач.

Если грамотно подойти к анализу можно вывести что некий разработчик эффективнее работает с таким-то менеджером и над задачами такого-то типа. И имеет смысл его ставить именно туда.

Увольнять, понижать/повышать зарплату это дело каждой компании в отдельности. Я же говорю про то что можно посчитать эффективность и повышать ее на основе этих данных.

Ответить
Развернуть ветку
1 комментарий
Любой инструмент

Которых они купят по сниженной цене,так как не пришлось переманивать

Ответить
Развернуть ветку
2 комментария
Radiodetal 6550

Тут получается неувязка: если аналитик плох, то при анализе задачи разработчику придется переспрашивать, как надо делать в неописанном аналитиком случае, а это снижает KPI. Он не будет переспрашивать, но тестировщик будет трактовать это как баг и отправлять на доработку и снижать KPI. Разработчик будет отвечать, что так в требованиях, будет постоянный срач между аналитиком, тестировщиком и разработчиком. В итоге они начнут договариваться, чтобы KPI у всех выполнялся, и в результате они будут делать не то, что нужно бизнесу, а то, что нужно, чтобы у всех троих KPI был на месте.
Это в принципе должны бы были на курсах менеджеров рассказывать, что введение численных метрик приводит в итоге к их выполнению, а не к улучшению работы в целом. Это как с палочной системой в полиции.

Ответить
Развернуть ветку
Nikolay Pasynkov
Автор

Так будет работать любая система KPI, которая привязывает зарплату к показателю.

Ответить
Развернуть ветку
Дмитрий Бабушкин

На мой взгляд было бы клёво если бы схема учитывала работу менеджеров, дизайнеров и других участников команды, поскольку их ошибки или удачные решения так же могут служить причинами доработок.
Пожалуйста отпишись о том что у тебя получилось когда ты наложил гипотезу на БД, очень любопытно.

Ответить
Развернуть ветку
Nikolay Pasynkov
Автор

Да, конечно можно сделать и так. В данном случае пример простой, с разработкой. Дизайнеры и менеджеры так же участвуют в процессе и доработка дизайна или уточнение требований - так же дополнительные затраты ресурсов.

Ответить
Развернуть ветку
1 комментарий
Nikolay Pasynkov
Автор

Удачность решений замерять сложнее. Тут придется сравнивать специалистов. Скажем у одного дизайнера фича делается столько-то, а у другого - сильно дольше. Слишком много погрешностей. Но думаю можно что-то придумать

Ответить
Развернуть ветку
Вася Пражкин

Николай, по-моему, Вам нечем заняться, а Вашему начальнику требуется пересмотреть приоритеты развития бизнеса.

Ответить
Развернуть ветку
Любой инструмент

Ваши разработчики прямо в этот момент начинают вспоминать пароль от аккаунта hh.ru...

У меня друг работает по схеме с kpi. Он поддержка во второй линии.

Рассказывает,что из-за этих kpi, людям невыгодно помогать друг другу,так как в точках рассинхрона kpi происходит вот что:

Разработчикам выгодно пилить новые фичи, у них такой kpi,а поддержке выгодно закрывать обращение к клиенту как можно быстрее.

В результате, разработчикам пофигу на kpi поддержки и они пилят новые фичи.

Я вижу тут решение просто отменить эти kpi и ввести проектные премии, например. Чтобы всем было выгодно.

Или возможно придумать что то ещё, но не вводить то,что каждый элемент в фирме начинает работать фактически как сам на себя, на свои цели. А не как часть большого коллектива с единой целью выпустить хороший продукт и получить за него денежку .

Ответить
Развернуть ветку
Александр Капцов
hh.ru

крутят диск телефона, звоня в приём объявлений газеты "Из рук в руки".

Ответить
Развернуть ветку
Антон Анискин

Командные показатели?
Не помог саппорту - запорол всем премию.

Ответить
Развернуть ветку
Дмитрий .

Сплошная утопия.
Почему в одном случае программист (над одной и той же фичей) должен работать 2 часа, а в другом 6 часов? Какой фактор так повлиял?
Почему программист, кормит весь паровоз? Лида, Тестировщика и т.д. Может наоборот, тестировщик сработал плохо, А аналитик написал не пойми чего?
Все замыкается на одном человеке в команде ?

Ответить
Развернуть ветку
Nikolay Pasynkov
Автор
Почему в одном случае программист (над одной и той же фичей) должен работать 2 часа, а в другом 6 часов? Какой фактор так повлиял?

А что если это два разных программиста? А что если в первом случае он наговнокодил, а во втором еще и порефакторить успел?

Почему программист, кормит весь паровоз?

Конечно вы правы. Программист - всего лишь пример. По работе программиста, возвратов к аналитику - мы можем посчитать эффективность аналитика. Лида считать сложнее, но тоже можно. Идея в том чтобы считать одного специалиста с учетом вовлеченности других специалистов.

Ответить
Развернуть ветку
3 комментария
Alexey Tsikov

Прекрасная формула, в которой время работы аналитика, указанное в блок-схеме "Разъяснение требований", идёт как доп затраты прогаммиста (впрочем, в примерах-то всё равно там 0, требования всегда идеальны). Ну это не говоря о том, что не все задачи одинаково ценны для бизнеса.
С такой формулой KPI никто не будет браться за важные сложные задачи с не до конца определёнными формулировками. Успехов в внедрении (на самом деле нет).

Ответить
Развернуть ветку
Denis Azarenko

Вначале бестолковое начальство отбило всю мотивацию, а потом считает kpi работника. Может начать с головы, а не хвоста?

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Любой инструмент

Менеджер, потому что он умеет фигачить красивые презентации и высчитывать пользу для бизнеса?)))) Пока основную работу делают программисты и продакты?

Ответить
Развернуть ветку
1 комментарий
Rustam Kulenov

По первой формуле вообще получается, что разработчику не выгодно комитить. А выгодно просто писать долго код, или брать в работу простые задачи, которые точно не вернут на доработку.

Ответить
Развернуть ветку
Zmitr0k

Вам там хорошо с формулами...
а вот KPI сисадмина - "чтобы всё работало!"

Ответить
Развернуть ветку
Сэнди Найтова

Карл Маркс бы прослезился

Ответить
Развернуть ветку
Alex C.

Душевно сказала, я аж сам прослезился.

Ответить
Развернуть ветку
Maxim Shuralev

Да, формула не идеальна, но хоть что-то, а здешние "эффективные" разработчики-творцы-искусствоведы, лучше бы дали дельные комментарии, как им платить зарплату не за "ковыряния в носу"...

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

Вы занимаетесь не искусством, а ремеслом!настоящее искусство - это продать ваш код!
Задайтесь вопросом, у кого покупает клиент вашей компании продукт? И за что он платит? Уж точно не у вас и не код!
Эти эффективные менеджеры кормят вас и всю вашу семью!

Умные и эффективные творцы? Идите тогда и продавайте, а не сидите и критикуйте ваше руководство, которое платит вам зарплату!

Ответить
Развернуть ветку
Любой инструмент

А вы продавайте без кода. Уверен,вы сможете продать продукт без строчки кода.

Ответить
Развернуть ветку
1 комментарий

Комментарий удален модератором

Развернуть ветку
Денис Федорец

Отличный пост. Услышав когда-то что-то подобное от финдира (только там было ещё - не нравится - ищите другую работу) я наконец решился уйти со своей первой работы. Успехов вам, всего хорошего, хорошего настроения, вы очень далеко пойдёте.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Denis Sidorov

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

Ответить
Развернуть ветку
Nikolay Pasynkov
Автор

Ставки, как было сказано в статье, взяты для простоты восприятия. По уму надо использовать какой-то коэффициент, "вес" часа, если хотите.

А в случае офиса, налогов и прочего - это уже KPI самого проекта, а не отдельно взятого специалиста.

Ответить
Развернуть ветку
1 комментарий
Rustam Kulenov

Если уж рассчитывать kpi, то, как мне кажется, надо рассчитывать агрегированый kpi, как взвешенное среднее (геом или арифм). И там должны участвовать частные kpi: прибыль\выручка компании, качество процесса разработки, качество реализации кода, грейд (senior\middle\junior).
Т.е. те параметры, которые хочется повысить\понизить.
Кому-то еще придется ставить min, max, целевые значения показателей, чтобы вычислять kpi относительно них. Значение kpi находится в диапазоне от 0% до 100%.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
3 комментария
Wasil D.

Тема очень интересная и неоднозначная. Зарубежные авторы написали на эту тему много книг, есть много исследований, начиная с 60 - х гг.... но воз по - сути и ныне там. Но скажите, а кому сейчас нужна была бы идеальная, вылизанная, абсолютно без багов Windows 98?)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Vikarti Anatra

А как оценивать ситуации вида: приложение внезапно стало говорить нечто вроде "Хьюстон! У нас проблемы" (общее сообщение об ошибке) на определенном экране. Заказчик удивляется что происходит. Анализ указывает на код разработанный конкретным программистом. Только вот реальная причина - на бекэнде по просьбе заказчика очень внезапно решили изменить формат одного из полей (и вообще вместо поля отдавать структуру). Как это будем в KPI учитывать и ЧЬИХ KPI?

Ответить
Развернуть ветку
Nikolay Pasynkov
Автор

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

В рамках текущего примера по уму надо по ушам надавать постановщику задачи.

Ответить
Развернуть ветку
Andrey Shcherbinin

Жесть. Хотел посмотреть, что в интернетах пишут про повышение эффективности работы, нарвался на вашу статью и просто выпал в осадок с комментариев. В статье и речи не шло про то, чтобы выставить какие-то рамки и тыкать людей в них носом. Как мне кажется, предложенная идея - она больше про коммуникации и аргументы в этих коммуникациях. Черным по белому написано, что лучше потратить на задачу лучше шесть часов и сделать нормально, а не налячкать за часок, чтобы потом исправлять на десять раз. Видно вовлечение в процесс и что можно дополнительно рассказать разработчику, что он не один в поле, а есть команда людей, с которыми он делает общее дело, есть процессы. Вот и иди потом, внедряй изменения...

Ответить
Развернуть ветку
Сергей Галанин

Так что, Николай, что получилось-то? Обещали отписываться. Семь месяцев прошло - ни слуху, ни духу.

Ответить
Развернуть ветку
Дмитрий Котов

Отличная статья. Сам озадачился выстраиванием KPI для своих программистов. Выстраиваю систему Scrum.
Начал встречать, что программисты часто формально сдают проект, который сделан, но после проверки выявляются недоделки по задачам, не верно сделанные задачи млм не сделанные задачи вовсе. Если внедрять форму депремирования за сдачу сырого продукта, это будет стимулировать перепроверить продукт до сдачи. А то мы уже и crm сделали, отдельного менеджера ввели который разносит подзадачи для каждого программиста.

очень надеюсь на новую систему KPI.

Ответить
Развернуть ветку
Vasilisa Safronova

Когда я вижу как грызутся разработчики и несут своё «очень важное мнение» в комментариях, вспоминаю еженедельные/ежемесячные встречи на которых слово вытянуть невозможно. И как только вопрос заходит, так чего же вы хотите? Чего вам не хватает? Как улучшим? И, ох уж, эта гробовая тишина... 

Метрики для вас как оценка в школе по которой будут оценивать дурак или молодец. Но на самом деле, метрики помогают увидеть, где же система даёт сбой, вовремя обратить внимание на узкие места и устранить. И не как не сказать, что ты дебил и не отобрать твой кусок хлеба. 

Честно сказать, я ещё не сталкивалась никогда с маразмом увольнений или лишений премий из-за метрик... А вот за хамство, подлость, длинный язык и враньё - да. 

Ответить
Развернуть ветку
Денис Федорец

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

Ответить
Развернуть ветку
Павел Сутырин

Привет, спасибо за статью! Чем кончилось дело?)

Ответить
Развернуть ветку
Читать все 79 комментариев
null