Личный опыт Nikolay Pasynkov
6 566

А давайте все-таки посчитаем 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, обсудим детали.

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Nikolay Pasynkov", "author_type": "self", "tags": [], "comments": 79, "likes": 21, "favorites": 51, "is_advertisement": false, "subsite_label": "life", "id": 47709, "is_wide": false, "is_ugc": true, "date": "Thu, 11 Oct 2018 15:40:20 +0300" }
{ "id": 47709, "author_id": 137368, "diff_limit": 1000, "urls": {"diff":"\/comments\/47709\/get","add":"\/comments\/47709\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/47709"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123 }

79 комментариев 79 комм.

Популярные

По порядку

Написать комментарий...
23

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

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

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

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

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

Ответить
7

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

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

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

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

Ответить
5

Господи,да вы задолбали! Откуда разработчик может знать, сколько времени займет у него создание нового кода?!
А вдруг, там откроются новые обстоятельства и придется переписывать всю нижележащую подсистему, так как она не справляется с нагрузкой, например.
Программирование все ещё не ремесленничество. И не кручение гаек одинаковых из смены в смену. Что за индустриальный подход в постиндустриальную эру?!

Программирование это почти как научная работа: тоже непонятно что в итоге получится .

Ответить
3

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

Ответить
1

Мне кажется, автор больше обеспокоен добросовестностью подхода разработчика. Учитывая, что разработчиков на рынке не хватает, компании что только не придумывают для привлечения специалистов. Кто-то этим пользуется, а понять, что разработчик халтурит не разработчику трудно.

Ответить
–1

Откуда разработчик может знать, сколько времени займет у него создание нового кода?!

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

Ответить
2

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

Ответить
0

Разве я писал, что не работал с большими проектами? Я прекрасно знаю как большие проекты выглядят изнутри на собственном опыте. И то, что оценку разработчиков нужно умножать на пи я тоже знаю. Но это не значит что разрабочик не может оценить, сколько у него времени займет СОЗДАНИЕ НОВОГО кода. В больших проектах требуется сопровождать СТАРЫЙ код, вникая, порой, в извращенную логику предыдущих писателей и дописывая или переписывая их код. В таких проектах оценки сроков мало чего стоят.

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

Но возвращаясь к теме - речь идет о KPI с желанием подставить какие-то цифры в какие-то формулы. Я как раз утверждаю, что считать KPI таким образом - это получить на выходе полное фуфло. Даже если разработчик - это специалист своего дела, способный дать примерную оценку [новому коду], а не эникейщик, способный сделать все, но без оценки сроков.

Ответить
1

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

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

Ответить
2

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

Ответить
1

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

Ответить
0

Вы преувеличили)

Ответить
0

Так вы тоже :)

Ответить
0

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

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

Ответить
2

Вопрос о целесообразности менеджеров здесь не стоит.
Сколько вы работали на технической позиции?

Ответить
0

Чуть больше 20ти лет. Долгое время сам был программистом, да и до сих пор нет-нет, а приходится засунуть в код свои потные ручёнки.
Однако, основной посыл был про ненужность KPI. ))
не нужен, вреден, но очень хочется

Ответить
12

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

Ответить
0

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

Ответить
0

А ещё задача может вернуться после тестирования на доаналитику например )

Ответить
0

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

Ответить
12

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

Ответить
10

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

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

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

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

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

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

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

Ответить
1

hh.ru

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

Ответить
–1

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

Ответить
8

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

Ответить
0

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

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

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

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

Ответить
4

А не посчитать ли нам, уважаемые кроты? Классика.

Ответить
3

Идея в том чтобы считать одного специалиста с учетом вовлеченности других специалистов.

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

Ответить
1

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

Ответить
6

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

Ответить
3

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

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

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

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

Ответить
0

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

Ответить
2

Это пример кривого втыкания "а навайте как-нибудь внедрим кипиай, я в книжке читал что то круто", не понимая нафига в данной конкретной компании, команде и ситуации это делать или не делать.
Тут вы правы.
Кстати любимый многоими нормальными менеджерами Элия Голдратт в своей теории ограничений как раз пишет то же самое, о чём вы говорите - локальные показатели эффективности бессмысленны. И даже вредны.
Так как результат даёт вся система целиком. И если у нас например узкое место это деплой (бывает ли такое?))) или там тестирование, то глупо оценивать работу разработчиков по количеству доставленных в прод задач, так как они не могут повлиять на то узкое место, которое определяет, сколько же задач доедет в единицу времени.

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

Ответить
0

Почему вы ставите KPI целью? И уж тем более целью команды?

Ответить
1

Потому что по ним меня будут оценивать. Значит,нужно выполнять в первую очередь свой kpi,а не соседа.

Ответить
2

А вы боитесь оценки? Или думаете что без KPI вас никак не оценивают?

На одном проекте у меня была добрая команда фронтов, 6 человек. Каждый из них работал на "отлично", но один хорошо пилил маленькие штуки, другой лучше справлялся с логикой, третий самостоятельно запиливал большие блоки. Каждого из них я пощупал и давал те задачи с которыми он лучше справиться, что ему больше понравится.

Та же самая оценка, просто без KPI. Разница только в наличии аббревиатуры.

Нет такого понятия "Выполнять KPI", это привито продавцами чтобы мотивировать их зарплатой. В разработке такое не зайдет.

Ответить
2

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

Ответить
1

Я про это и говорю,что не надо выставлять жёсткие рамки. Кто то лучше пилит одно,кто то другое.

Ответить
0

Ни о каких жестких рамках не идет речи.

Ключевые показатели эффективности (англ. Key Performance Indicators, KPI) — показатели деятельности подразделения (предприятия), которые помогают организации в достижении стратегических и тактических (операционных) целей. Использование ключевых показателей эффективности даёт организации возможность оценить своё состояние и помочь в оценке реализации стратегии. (с) Вики

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

Ответить
1

Я говорю о том что мы можем взять реальные данные и посчитать

Не можете. Вы постоянно упрощаете задачу и этим теряете главное.

Ответить
0

а главное - это что?

Ответить
0

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

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

Ответить
0

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

Ответить
0

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

Ответить
3

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

Ответить
2

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

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

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

Ответить
1

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

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

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

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

Ответить
1

Более того. На основе этих метрик можно выводить массу других историй:
- Плохая кодовая база
- Недостаточно глубокий анализ
- Уровень оценки рисков
- Повышенная сложность системы

Ответить
0

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

Ответить
2

ИМХО, если говорить про Москву и миллионники, то переход программиста на новое место с потерей в деньгах - ситуация невероятная :)

Ответить
0

Речь не про меньшую зп, речь про затраты на хантинг (премии агентам, программа лояльности деньги работникам за привлечение друзей, не надо предлагать +30% можно предложить +10% и нормальные условия)

Ответить
2

1. Манагер криво написал условия задачи, и разработчик потратил треть отведенного времени на выяснения деталей
2. Вторую треть отведенного времени разработчик потратил на ресерч как именно реализовывать задачу
3. Последнюю треть отведенного времени разработчик потратил на экспресс-реализацию, с сопутствующими багами
4. Еще треть времени ушла на багфиксы
5. Манагер все это время считал KPI, смотрел видосы с ютуба и курил с коллегами
6. Догадайтесь со второго раза, кто более полезен для компании

Ответить
0

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

Ответить
2

Нет, еще крутит шашни с секретаршей, но та ему не дает, поэтому он вводит новые коэффициенты в kpi.

Ответить
2

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

Ответить
2

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

Ответить
2

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

Ответить
0

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

Ответить
2

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

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

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

Ответить
2

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

Ответить
0

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

Ответить
0

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

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

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

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

Ответить
4

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

Ответить
0

Вопрос курицы и яйца. Все важны и все нужны. А ещё важно правильно построить команду и процессы.

Ответить
3

Разработчики не Микелянджело с Давинчи, они работники сложного умственного труда, которые просто хотят работать комфортно. Потому что дискомфорт сильно снижает качество их работы. Манагеры же считают что разрабы - ремесленники и рабы на галерах, что 1) в корне неверно, 2) демонстрирует средневековое мышление манагеров, 3) повышает самооценку манагеров, но негативно влияет на качественные характеристики программного продукта.

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

Ответить
1

😁 старо приданье, меня 10лет посчитать пытаются, никак не посчитают.

Ответить
0

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

Ответить
1

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

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

Ответить
0

А зачем вам кпи отдельно взятого специалиста? Вася имеет кпи в 10 раз выше всех остальных, но начальнику он не нравится своей прямотой. Васю ушли. Петя имеет кпи в 15 раз выше всех остальных, но проект ему неинтересен. Петя ушел работать в банк. "прямоту" и "интерес" помножаем на пи и и делим на вес часа, чтобы получить их истинный кпи в рамках ооо "говна и палки"?

Ответить
0

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

Ответить
0

По каким критериям собираетесь оценивать качество реализации кода? Вы вообще в курсе, что данная категория в принципе не поддается оценке?

Ответить
0

Я не Рустам, но если позволите, выскажу своё мнение - можно оценивать по таким критерим как, читабельность, покрытие тестами, наличие комментариев. Собственно есть же такая штука как код ревью, где собственно и оценивается качества кода. Другой вопрос в том, что если код ревью адекватное, то в результате весь код получится более менее качественным.

Ответить
1

Можно считать количество реопенов по результатам код ревью, багов и т.д. Это если есть в проекте однозначные критерии для код ревью. Чтобы это была не вкусовщина и настроение ревьюера, а некий прозрачный набор критериев.
И если реопенов много - то наверное лид недообучил программиста как работать в данном проекте. И вот сразу понятно что делать и как решить проблему - дообучить, пока не подтянется на общий уровень.

Ответить
0

У нас как то пытались по количеству багов считать: вылилось а то,что люди боялись заводить баги. В конце концов, отшли от такой прямой концепции.

Ответить
0

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

Ответить
0

Отличный материал

Ответить
0

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

Ответить
0

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

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

Ответить
0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Нейронная сеть научилась читать стихи
голосом Пастернака и смотреть в окно на осень
Подписаться на push-уведомления