KPI (Key Performance Indicators) – ключевые показатели эффективности сотрудника, которые позволяют оценить достижение поставленных целей и задач, результативность работы в компании. С продажниками все понятно. Их эффективность можно измерить по сумме прибыли, которую они ежемесячно приносят компании. А вот с IT-специалистами дела обстоят сложнее. Как оценить разработчика с точки зрения ключевых показателей эффективности? Какие KPI можно внедрить? Об этом я и расскажу.
KPI для разработчиков – быть или не быть
Оценить ключевые показатели эффективности IT-специалистов трудно. И сейчас я объясню вам почему, думаю, после этого вы со мной согласитесь:
Работа разработчиков – это не пошаговый процесс, который можно загнать во временные рамки и качественные/количественные показатели. Из-за этого невозможно разработать общую систему, которая позволит оценить работу IT-специалистов.
IT-сфера очень многогранна. У каждого разработчика своя зона ответственности, которую невозможно сопоставить с обязанностями другого сотрудника.
IT-сфера зачастую требует творческого подхода. Соответственно, одна и та же задача в различных проектах может иметь разный уровень сложности.
Разработчикам в большинстве случаев нужно работать не в одиночку, а в команде. Поэтому их эффективность во многом зависит от других ее членов.
Но, как говорится, волков боятся – в лес не ходить. Сложности, с которыми приходится сталкиваться в оценке эффективности сотрудников из IT-сферы – это вовсе не повод отказываться от KPI разработчиков.
Какие метрики для оценки эффективности IT-специалистов целесообразно использовать
Показатели эффективности сложно подобрать, но все-таки возможно. Поделюсь с вами наиболее эффективными KPI, который предназначен для разработчиков.
Безаварийность
При расчете показателей эффективности учитывается количество задач с авариями, которые возникают по вине разработчика, правившего код. Здесь все логично: чем меньше инцидентов по выпускаемым и исправляемым фичам, тем выше KPI IT-специалиста.
Попадание в оценку
Когда разработчику приходит задача от аналитика на разработку, он должен сразу озвучить то, сколько времени потратит на ее выполнение (Story Point или человеко-дней).
Когда IT-специалист озвучивает определенный отрезок, например, 3 дня и укладывается примерно в эти сроки +/- несколько часов – это хороший показатель. Если он затягивает или уменьшает сроки – это не есть хорошо. Таким образом, чем точнее сотрудник оценивает время на выполнение поставленных задач, тем выше будут критерии оценки разработчика.
Оформление задачи
Когда IT-специалист описывает задачу в трекере, он прописывает, что именно он сделал. Оформление этого должно соответствовать специально предназначенным для этого стандартам. Он пишет, когда и что исправил, что делать тестировщику, дает рекомендации для аналитиков и так далее).
Важные моменты при анализе эффективности разработчика
Как я уже говорил, разработка – это творческий процесс, поэтому измерять его исключительно по техническим параметрам будет неправильным. К примеру, эффективность не может быть оценена по количеству строчек написанного кода. Дело в том, что его можно будет увеличить искусственным образом, заполнив нефункциональными пустышками. Они придадут большой объем, да только толку от них не будет.
При оценке также следует обращать внимание на следующие показатели эффективности разработчиков:
Командная работа. Ее можно измерить путем анализа активности сотрудника и его взаимодействия с остальными членами команды, способности выдвигать интересные идеи.
Уровень сложности кодирования, производительность кода. Это возможно измерить при помощи времени, которое потребовалось на выполнение задачи, используемой памяти и остальных потраченных ресурсов.
Качество и эффективность готового продукта. Определить эти параметры можно при помощи таких показателей, как число ошибок и багов, соответствие всем нормам и стандартам кодирования.
Способность к обучению. Определяется то, насколько быстро IT-специалист учится новым технологиям и языкам программирования. Это важно, так как сфера ИТ не стоит на месте и постоянно изменяется. За этими изменениями нужно успевать.
Для облегчения учета KPI можно использовать различные инструменты. Например, специализированное ПО, системы CRM, EXCEL и другие программы ручного ввода. Только обратите внимание, что последний способ трудоемок и небезопасен, так как позволяет корректировать руками цифры и формулы расчета.
К сожалению, в IT-сфере не существует четкой системы оценки показателей KPI. Для каждой компании необходимо использовать индивидуальный подход, который подбирается путем проб и ошибок.
Комментарии (52)
offline268
27.12.2023 06:24+9Похоже не сработает
количество задач с авариями, которые возникают по вине разработчика, правившего код
Если я потрогал код и потом в этом месте валится не факт что вина моя. Может аналитик в постановке написал что сюда поступают такие-то данные, а по факту пришло что-то не то... может поднятая версия зависимости немного иначе себя ведет в некоторых редких случаях и выстрелило только сейчас... может еще что-то. Конечно разработчик сверхчеловек и должен всё на свете учесть.
он должен сразу озвучить то, сколько времени потратит на ее выполнение
Пфф, это стимулирует мне как разработчику сразу выдавать изрядно завышенные сроки, чтобы точно в них уложиться. С другой же стороны, если сроки ставит руководитель, это превращается в способ манипуляции моим КПЭ, ну чтоб на премиях сэкономить например.
Он пишет, когда и что исправил, что делать тестировщику, дает рекомендации для аналитиков
Вообще писать такие вещи очень полезно, я стараюсь писать, но не знаю как заставить других участников команды делать это тоже. И самое главное, не знаю как заставить их читать написанное. После того как я запилил какую-то фичу, потом ко мне спокойно могут прийти коллеги и задавать вопросы, ответы на которые уже написаны в задаче.
В итоге, кто и как будет оценивать такой показатель - большой вопросКомандная работа. Ее можно измерить путем анализа активности сотрудника и его взаимодействия с остальными членами команды, способности выдвигать интересные идеи
Как это оценить? Если я с коллегами политоту обсуждаю в рабочем чатике, это считается командной активностью? А кто будет считать выдвинутые мной идеи? А если я выдвинул их при походе с коллегой на обед? А если я выдвигаю интересные идеи, но 70% из них оказываются провальными, но мы потратили время на из проверку, как это отразится на KPI?
Качество и эффективность готового продукта. Определить эти параметры можно при помощи таких показателей, как число ошибок и багов, соответствие всем нормам и стандартам кодирования.
Это скорее командный показатель.
Определяется то, насколько быстро IT-специалист учится новым технологиям и языкам программирования
Сколько новых языков я должен выучить за месяц/год? А если не выучил КПЭ срезается? А если я только изучением нового занимаюсь, а на работу забил премию в полном объеме получу?
dsh2dsh
27.12.2023 06:24А если я только изучением нового занимаюсь, а на работу забил премию в полном объеме получу?
Получите. Работал я в одном месте, где всех разработчиков заставляли ставить себе цели на год. Любые. Как правило, прокатывало ставить цели типа освоить фреймворк X или язык Y. На основе кол-ва достигнутых целей принимались какие-то решения. Например премия. Если кто-то поинтересуется, как отслеживались достижение этих целей - да никак. Разработчик ставил галочку, что цель достигнута. Т.ч. повторюсь, премию вы получите. Может быть даже повышение. А работать сейчас и не требуется. Или по другому, вот это вот все они и считают работой.
panzerfaust
27.12.2023 06:24+6способности выдвигать интересные идеи.
Особенно классно, когда проект - зарегулированный сверху донизу колосс в банке или госконторе. У разраба там свободы действия - как у кота на верхушке березы. Но интересные идеи будь добр выдвигай. Мы их сразу в помойку, конечно - но ты все равно выдвигай.
Samr1
27.12.2023 06:24но ты все равно выдвигай.
О, это похоже линовские методы внедряются. Давно такого не встречал, и вот недавно был на одном мероприятии, где светлые умы собрали из разных локаций, генерили, как жить в 24м - много полезных идей предложили. Под финал вышел главный и буквально сказал "Не знаю, что вы там напридумывали, а делать это будем!". Приподнял, так сказать, мотивацию.
ruomserg
27.12.2023 06:24+5Статья - отличная иллюстрация, что неокрепшему уму MBA только вредит. :-(
Я понимаю, что когда у автора MBA по финансам, то глядя на мир, он имеет некоторое профессиональное искажение. Но если выйти за пределы этого пузыря - возникает вопрос: "KPI для разработчика чтобы что ?!". Если вы собираетесь платить за эти KPI и наказывать за недостижение - смотрите посты выше. Для сложной интеллектуальной деятельности невозможно найти простые показатели, которые бы ее адекватно оценили. Потому что сложность оценки всегда пропорциональна сложности оцениваемого процесса.
Если вы как руководитель хотите иметь некий инсайт внутрь процесса, чтобы более разумно распределять свой управленческий ресурс (смотреть и вмешиваться туда куда надо, и не лезть куда пока не надо) - подойдет почти любой измеримый KPI (я, например, много лет использовал количество строк написанных или измененных разработчиками за неделю/месяц). И подойдет любая метрика, потому что нас интересуют не столько абсолютные значения, сколько динамика. В первую очередь руководитель идет смотреть туда, где что-то поменялось (не важно в какую сторону - важно чтобы руководитель видел и понимал причины этих изменений, это его работа!).
Сформулируйте, пожалуйста, цель - чего вы хотите в конце концов добиться? А потом мы уже сможем оценить - нужны ли для этого KPI, и если нужны - то какие именно...
adurnetsov Автор
27.12.2023 06:24-4Спасибо, что выразили своё мнение. Но этот неокрепший ум эффективно 10 лет управлял, в том числе программистами. Ну и благодаря таким неокрепшим умам, компании в состоянии платить такие зарплаты программистам, которые они сейчас получают. У всего есть эффективность и целесообразность. То что кто-то считает что он может управлять чем-то и без цифр, просто интуитивно, это его право. Но к сожалению управлять "семьёй" (мини командой) и делать бизнес - делать так чтобы компания была в прибыли, это разные вещи.
Считать KPI в виде количества строк кода - самый большой бред который можно выдумать. Берешь библиотеку у индусов вставляешь десятки тысяч строк - воу крутая эффективность! Твой прогер молодец! Премию ему!?
А если тысячи строк кода написаны, но работают так что ты еле шевелишься или всё в багах? Круто для pet-проекта, но не круто для бизнеса в котором час простоя стоит например 1млн в час!
Здорово что вы посмотрели на моё образование, но не здорово, то что вы показали свою не компетентность.
В этом и проблема в ИТ, что управлять мало кто умеет. Есть завышенное ЭГО, когда ты считаешь себя богом, потому что твоя ЗП растёт чуть ли не каждый час, но это чаще не твоя личная заслуга, а ситуация на рынке. Кто-то это понимает и читает такие статьи и пытается понять, что полезного можно подчерпнуть и что автор хотел сказать, а кто-то ставит "минусы"...
Ну а если перевести на финансовую терминологию, то есть такая ошибка инвестора - когда ты купил акции и они растут, но только ты не знаешь что просто рынок прям сейчас весь растет, и это не ты выбрал правильную акцию основываясь на конкретных показателях. Потом когда ты на этом заработал, ты думаешь что ты гений трейдинга и инвестиции, но часто жизнь быстро расставляет по местам всё..
В финансах это происходит очень быстро. В работе медленней, но тоже происходит.
panzerfaust
27.12.2023 06:24+7Но этот неокрепший ум эффективно 10 лет управлял, в том числе программистами.
Я в свою бытность в Сбере наблюдал менеджеров, которые без пяти митов, трех грумингов и одного ретро входную дверь найти не могли. Сейчас, наверное, тоже говорят "Да я тут уже 10 лет пашу! Вы видели прибыль Сбера? Это все я!". Ничего личного - просто напоминание, что года стажа это просто числа. А корреляция не всегда означает зависимость.
adurnetsov Автор
27.12.2023 06:24К сожалению для вас, я могу в цифрах доказать, выручка/прибыль, на которую повлиял. Ваши примеры сбера - всего лишь ваш опыт.
ruomserg
27.12.2023 06:24+10"Всем вы хороши, дуболомы! Сильны, исполнительны. Ума бы вам побольше - но чего нет, того нет!" (C) Урфин Джюс и его деревянные солдаты :-(
Я с вами соглашусь, что управлять вообще (и управлять в сложных областях - таких как ИТ) - мало кто умеет. Это правда. Проблема в том, что факультеты менеджмента и разные программы MBA штампуют вот уже третий десяток лет примерно автора статьи: много правильных слов, синдром мессии ("я вам, сволочам, покажу как надо работать"), и при этом категорическое непонимание как роли руководителя, так и применяемых инструментов. До некоторой степени, в этом виновата методика - когда переводится (или пересказывается) западный учебник вне социо-культурного контекста цивилизации, в которой он написан. В результате, вместо понимания, у студентов в голове возникают химеры. И потом это транслируется в реальную жизнь. Философия...
Теперь давайте к практике. Как и многие другие менеджеры (а я видел и владельцев бизнеса таких же) - вы или не читаете то что написно, или не можете рационально это воспринимать. Я задал вам прямой вопрос - какая ваша цель ? Вы на него не стали отвечать. Однако (не ответив на вопрос относительно цели) - вы беретесь судить, что я делал и делаю хорошо, а что - плохо. Если бы я собеседовал вас в компанию, то на этом месте интервью, по-большому счету, уже и закончилось. То есть нет, мы бы еще поговорили - потому что мне по-человечески интересно узнать, чего в этом больше - забитых во время обучения догматов, или природной глупости - но на результат это бы никак не повлияло.
Опять же, из вас лезет финансовое MBA как тесто из кадки - во все щели. Разве я говорю, что управлять компанией можно без цифр ? Агрегированные финансовые показатели - это очень полезный и важный набор индикаторов, без которых бизнес превращается в хобби. Ваша проблема заключается в том, что вам кажется - что можно эти аггрегированные KPI раздробить на более мелкие, каждый из них соотнести с конкретным человеком, привязать к осколкам KPI систему премирования и наказания - и больше ничего не делать. В принципе, это тоже объяснимо и соответствует архетипу глубинного русского народа: один раз напрячься, совершить подвиг - но потом лежать на печи, чтобы скатерть-самобранка (ну или хотя бы Марья-искусница) сама варила и в рот подавала.
С позиции своего опыта, вынужден вас огорчить. Проблема управления не имеет простых решений. Просто потому что объект управления - человеческое общество - дьявольски сложен сам по себе (а в программировании - он еще и занят решением нетривиальной проблемы). Если вы перестанете рассматривать метрики как стимулы, а будете к ним относиться как к индикаторам (см разницу в английском языке между tools и instruments - там она фундаментальна в отличие от русского) - в вашей голове должно щелкнуть, и придти к соответствие к реальности. Почему вы считаете что количество написанных строк не дает мне инсайтов о процессах происходящих в команде? Я же никогда не платил программистам за написанные строки, и никогда не ругал за ненаписанные строки (и даже никогда впрямую не задавал вопросов типа "сколько строк вы сегодня написали" - чтобы никто не догадался что я делаю). Этот показатель (совершенно очевидно связанный с профессиональной деятельностью) давал мне подсказки, куда следует посмотреть. Точно также, если вам надо контролировать состояние двигателя в машине - вы можете выбрать любой из показателей: температура воды, температура масла, расход топлива, скорость движения машины и так далее.
Более того, когда я был начальником, меня не интересовало количество строк как таковое (хотя в долговременном плане я готов подтвердить статистику Брукса - программист производит в день в среднем от 10 до 30 строк отлаженного кода). Меня больше интересовали ИЗМЕНЕНИЯ этого показателя. Особенно - резкие изменения. Если я вижу что у человек делал 20-25 строк кода в день, а всю прошлую неделю шарашит под сотню - это повод пойти и поговорить. Не о строках кода, упаси бог - а о том, что вообще происходит в этой части проекта! Может быть там куча бойлерплейт кода, и мое вмешательство не требуется. Ну так я поговорю, буду об этом знать, и засну спокойно. А может быть выявилась неожиданная проблема и мы переписываем кучу кода. В этом случае мне, как руководителю, нужно верифицировать это решение (может быть мы это делаем зря, и есть альтернатива), или заново переоценить сроки выполнения задачи, или изменить расстановку ресурсов (чтобы два человека писали по 50 строк, а не один по 100 - иначе он попишет-попишет в таком темпе, а потом устанет-выгорит и провалится на 10 - люди не роботы!). Аналогично - если мы писали 20 строк в день, а теперь третий день ничего не пишем - надо пойти и узнать в чем дело: может смежный отдел тормозит, может трудности встретились, или еще какое-то явление личного порядка у разработчика и ему лучше отгул взять чем делать вид на работе... Первая и основная задача руководителя - работа С ЛЮДЬМИ! А показатели - это всего лишь способ узнать, куда именно нужно направлять свое внимание в первую очередь (я был бы рад постоянно направлять внимание на всех - но во-первых, тогда сотрудникам работать будет некогда, а во-вторых - мой ресурс тоже не бесконечный!).
В целом, я предложил бы вам пересмотреть свою категоричность и безапелляцонность. Очень может оказаться, что проекты (управление которыми вы ставите себе в заслугу) примерно так же работали бы и без вас. Потому что энергичный менеджер, дергающий траву за стебли (чтобы быстрее заколосилась) - на самом деле скорее вредит, чем помогает.
Но вообще, я сохраняю осторожный оптимизм. В принципе, вы человек молодой и образованный. Если будете более критично относиться к себе, если осознаете что процессы вокруг вас гораздо интереснее и сложнее схем из учебника, и наконец, если не потеряете способность слушать других и учиться - у вас все получится.
Удачи!
sir_genry
27.12.2023 06:24-2В принципе, вы человек молодой и образованный.
Вот читаю и вижу снежнобородого умудренного опытом гуру.
Спасибо, что снизошли. По плечу еще похлопать не забудьте. И руку пожать перед строем.
Очень длинный комент вы написали. Очень. И выводов понаделали неправильных. Не писал автор о том, в чем вы его обвиняете.ruomserg
27.12.2023 06:24Кроме фантазий и оценочных суждений - есть что-то сказать ?
sir_genry
27.12.2023 06:24-1Есть. И что? Вы меня услышите? Сомневаюсь
Примерно такие же KPI, как описал автор, мы используем у себя на производстве. И это необходимость.Вы же тут собрались не для того, чтобы кого-то услышать, а потешить свое эго.
Так что смысла в продолжении срача не вижу.ruomserg
27.12.2023 06:24+1"Любая, даже самая сложная, проблема обязательно имеет простое, легкое для понимания, неправильное решение." (C) Законы Мерфи
KPI в производстве, и KPI в разработке - это очень разные сферы деятельности. Чем проще производственный процесс - тем легче его оценить и установить KPI. А в предельном случае, бригаде землекопов - так и вообще можно платить сдельно за метры кубические.
Но в принципе, имеете право извращаться так, как вам больше нравится. Экономика постепенно решит кто был прав...
sir_genry
27.12.2023 06:24Абсолютно согласен с тем, что критерии оценки работы землекопа и разраба разные. Оценивать работу прогера по количеству строк кода или количеству созданных таблиц - верх идиотизма. Те, кто вводит такие KPI суть идиоты и по другому их назвать нельзя.
Но оценка все равно нужна. Для чего нужна оценка - это отдельный вопрос. Не хочу в это сейчас вдаваться. Поэтому KPI просто нужен и все. Во всяком случае в больших компаниях. Если вы самозанятый, то это излишество )
Поэтому встает вопрос: а какие KPI мы можем применить? Автор примерно ответил на этот вопрос.
Теперь по нюансам каждого из них:
1. Оценка количества аварий из-за ошибок разработки: разраб должен быть умным. Он должен понимать, что ему там понаписал аналитик. Может это был аналитик другой команды и тем вообще по барабану. Просто здравый смысл. Вот и все. Во всяком случае разрабы моей команды им обладают и явную ерунду не пропускают. А если пропустил, то должен сделать выводы: изучай систему в целом, прояви вовлеченность. И никто у нас премии (а KPI только на премии аффектится) не лишает за единичные просчеты.
2. Попадание в оценку. Просто встаньте на место бизнесов, которые вам деньги приносит, постарайтесь их понять. И тогда все станет просто и понятно.
3. Далее оформление задач. Тут вообще все просто: напиши комент ОБЯЗТЕЛЬНО. Вот и все. И очень тебе будут благодарны тестировщики, если этот комент будет полезным для них. Со временем нарабатывается соответствующий навык, который даст более слаженную работу команды. Это приведет к снижению стресса, замедлит выгорание. И даже токсичные задачи не будут выбивать из колеи.
А вообще все эти три принципа суть об одном: не будь сволочью, думай о других, работай в команде. И будет счастье в виде развития продукта, премий и т.п.ruomserg
27.12.2023 06:24+1Есть в русском языке устоявшиеся выражения: "Чесать левой ногой правое ухо", "Суп вилкой хлебать", и т.д.
Вы пытаетесь достичь правильных целей: безаварийности, предсказуемости времени разработки, наличия документации и проч. Но выбор KPI как средства достижения этого - меня повергает в шок.
Создается такое впечатления, что вы еще до некоторой степени "people company" (или что то же самое - компания на начальных уровнях CMM) - и у вас качество выдаваемого результата зависит от конкретного человека и его настроения сегодня. Поэтому вы пытаетесь ввести индивидуальные KPI, ибо других способов сделать так, чтобы все бежали в одну сторону - не видите. Я просто предупреждаю, что это путь в тупик.
Более правильным - является развитие процессов. Вы хотите безаварийность - не надо ставить KPI за безаварийность в надежде что разработчики как-нибудь незаметно совершат чудо и аварийность упадет. Есть целая дисциплина - Delivery Management о том, как управлять качеством программного обеспечения в разработке. Там есть метрики (некий аналог KPI) для процесса, но никто не пытается это дробить на конкретных людей. Вы улучшаете процесс, а не занимаетесь индивидуальным стимулированием.
Точно то же самое в оценках сроков. Бизнес невозможен без сроков - это факт. Но достигать этого надо не введением KPI за попадание в сроки, а опять-таки повышением качества процессов и уровня инженерной культуры.
И так далее... А когда вы пытаетесь достигать правильных целей путем индивидуального стимулирования - возникает именно то, что тут выше (и ниже) уже много раз написали. Как только разработчики осознают что вы им платите не за выход годного, а за показатели - они прекращают производство продукции, и приступают к выпуску показателей. В ответ, менеджмент усложняет систему показателей - но разработчики обычно умнее менеджеров, и поэтому находят новые способы производить требуемые показатели без привязки к рельной работе. В итоге, или KPI становятся слишком общими (прибыль предприятия за год) - и для разработчиков они все-равно что не существуют. Или KPI становятся многочисленны, взаимозависимы и необозримы - их невозможно выполнить, да никто и не пытается. KPI живут сами по себе, а разработчики - сами по себе. Премия при этом становится разновидностью погоды - никто не знает почему сегодня она именно такая. Ценность премиальной части утрачивается, окладная растет - и в конце опять-таки KPI как бы перестают влиять на происходящее. То есть в конце-концов, KPI для разработчиков самоликвидируются. Но вы можете потерять команду в процессе...
sir_genry
27.12.2023 06:24не я эти KPI придумал, я всего лишь тимлид. Но я с ними согласен, ибо это работает.
Весь это спор мне напоминает одну историю: каждый раз когда я заправлял свой авто в одной известной сети, расход был повышен. Но на еще одном токсичном ресурсе (дром) некие граждане размахивали бумажками с анализами, в которых было написано, что бензин соответствует всем нормам и это я все себе придумал.
Но тут есть один нюанс: мой кошелек.
Можно сколь угодно долго приводить аргументы, говорить много умных слов и т.п. Критерий все равно один: работает или нет. В моей команде вышеупомянутые KPI работают. На этом как бы все...
eao197
27.12.2023 06:24+1Но я с ними согласен, ибо это работает.
Откуда вы знаете, что "работает"?
В моей команде вышеупомянутые KPI работают.
Т.е. в вашей команде за сбои на проде наказывают допустившего ошибку программиста?
На этом как бы все...
Не-не-не. Назовите название своей организации хотя бы. Думаю, многие бы захотели обойти ее стороной.
ruomserg
27.12.2023 06:24+1Ну вот начинается: "не я придумал", "я всего-лишь тимлид", и т.д. То есть на всеобщность и принципиальную пользу внедрения KPI для разработчиков вы (в отличие от автора оригинальной статьи) не претендуете - а говорите только о личном опыте? Уже хорошо!
Что же касается вашего личного опыта - его невозможно отрицать. Однако, отказываясь от установления причинно-следственных связей и изучения альтернативных гипотез - вы рискуете уподобиться "голубю Скиннера". Напомню, что веселый американский дядька приучал голубей долбить клювом по кнопке чтобы получить еду. Но потом ради прикола сделал так, чтобы еда вообще выдавалась случайным образом (вне зависимости от поведения голубя в клетке). К его удивлению, птицы начали демонстрировать очень сложные ритуалы, долженствующие увеличить количество добываемой еды: некоторые хлопали крыльями, другие крутились вокруг своей оси, и так далее...
Впоследствие оказалось, что выдача еды закрепляла случайно продемонстрированное (совпавшее по времени) поведение голубя в момент первых раздач. И дальше птица продолжала вести себя совершенно нерационально, воспринимая случайно вылетающие порции еды как подкрепление своего поведения (и игнорируя случаи, когда еда не выпала - и даже напротив, еще усиливая свое поведение в ответ на неудачу).
Соответственно, неплохо бы установить что "a" - в вашем случае KPI для разработчиков и получаемые результаты имеют причинно-следственную связь, а не являются совпадением. И "б" - что получаемые положительные результаты не являются временным явлением и не приводят к долговременным негативным последствиям (типа разрушения команды) - о чем особенно предупреждают в нормальных книгах по управлению.
Если вы все-же получите ответ, что в ваших бизнес-реалиях - да, положительно влияют, и нет - не вызывают отрицательных последствий - то вам повезло, и именно в вашем случае оправданно их применять. Правда, я настаиваю на том, что смени вы KPI на адекватный процессный подход - можно или с теми же усилиями иметь лучший результат, или сохранить результат сэкономив усилия. Ну просто потому что чесать правое ухо легче правой рукой, а есть суп - ложкой...
Kelbon
27.12.2023 06:24+1Считать KPI в виде количества строк кода - самый большой бред который можно выдумать. Берешь библиотеку у индусов вставляешь десятки тысяч строк - воу крутая эффективность! Твой прогер молодец! Премию ему!?
Ваша проблема в том, что вы KPI хотите отслеживать, делать от него что-то зависимым. Но если за ним просто наблюдать, не забирая премию за это, либо про этот KPI вовсе никто не знает, то никто под него подстраиваться не будет, а вот резкие изменения будут видны на графике
AnROm
27.12.2023 06:24+6Вся статья - это мнение неопытного менеджера.
adurnetsov Автор
27.12.2023 06:24-1Сам диву даюсь, как такие люди, делают бизнес, управляют компанией!?
KEugene
27.12.2023 06:24+3Когда KPI начинают применять к подразделению, не связанному с реализацией продукции, у меня это всегда ассоциируется с задачей "Как заплатить зарплаты меньше и аргументировать так, чтобы не вспугнуть работников". Типа, все прозрачно, вот цифры. Но, в итоге, возникает параметр "вовлеченность в трудовой процесс", который имеет два состояния: "достаточная" и "не достаточная". Ну и значение устанавливается "экспертным путем на основе ряда допущений и оценок".
Samr1
27.12.2023 06:24+1Мне кажется, что все дискуссии разрешит конкретный пример KPI: Наблюдаемый индикатор + порог + управленческий триггер.
Ну или так:
в IT-сфере не существует четкой системы оценки показателей KPI.
Batalmv
27.12.2023 06:24+2Вступление
Василий Ивановач:
-Петька,приборы!
Петька:
-300!
Василий Иванович:
-Что 300?
Петька:
-А что приборы?В общем
Прочитав статью, хочется попросить: "Господи, держи таких руководителей подальше от разработчиков :) И вообще финансистов подальше от всего, кроме денег :)"
Теперь по сути. Прежде чем что-то мерять и начать использовать специализированное ПО, надо понимать:
измеряемым ли является предметная область средствами объективного контроля
зачем
как применить
Про измеримость?
Да все просто. Стори поинты очень условны, как и количество багов потом. Строить расчеты на базе настолько неточных данных вообще нет смысла чисто математически.Зачем мерять?
На самом деле довольно таки непонятно зачем. Поясню. Допустим я ПМ и у меня в обойме N программистов. Я и так в курсе, кто как перформит:Программисты делятся по навыкам/скилам, и это определяется просто: кому-то лид может предложить сложную задачу, а кому-то - нет. Измерить это численно - сомнительно. Для этого придумали "лычки", ранги и прочее. Что трансформируется в рейт, который оплачивается из бюджета проекта.
-
Программисты либо справляются, либо нет. Это легко видно по багам, либо по сумме задач. Можно считать, можно не считать. Но если я как ПМ плачу за разраба, я и сам померяю, потому что это бабки МОЕГО проекта. Но обычно это видно и без.
Допустим я линейный менеджер. Ну тогда у меня есть фидбек от ПМов + "спрос". Кого-то хотят, от кого-то крутят носом либо просят поменять. Чего тут мерять? Опять же, есть "лычки" и формальные (часто) нормативы для роста. Ну можно крутить всякие 360-опросы, 1-1 встречи и так далее. Представить себе линейного или ПРа с Excel - сложно.
Как применить?
Для ПМа - да просто. Я не нанимался кого-то учить за время проекта. low-перформера проще заменить, ценного - чем-то простимулировать. Все
Для линейного: тут плюшек больше. И обучение, и промо на следующую лычку, и денег докинуть.Но чего тут мерять хотите - ХЗ? линейный и так своих знает
Теперь чуток ржаки по мелким моментам
Например, специализированное ПО, системы CRM, EXCEL и другие программы ручного ввода
— Вы арестованы! Вы имеете право хранить молчание. Всё, что Вы скажете, может быть использовано против Вас!
— Арифмометр!
— Что, арифмометр?
— Используйте против меня арифмометр!Очень хочется получить комментарий, как применить CRM для описанной в статье задаче :)
Их эффективность можно измерить по сумме прибыли, которую они ежемесячно приносят компании
Прям хочется вспомнить историю с ТТХ и Стрельцовым. Если вкратце, то по легенде, перестали заниматься этой фигней, так как он был всегда внизу :) Таким вообще много страдали в советском спорте :) По идее, после провалов 1976 года дошло до всех, но это не точно
Что касается остального ... если компания продает по рейтам, то тут все просто. Процент утилизации покрывает все вопросы. Вот просто все. Если продают человека на условно 80% - вопросов больше нет. Все остальное - как раз забота финанста рассчитать рейт по спецу и роли :) Кто хоть раз считал стоимость проекта - те в курсе. Кроме автора по ходу :)
При расчете показателей эффективности учитывается количество задач с авариями, которые возникают по вине разработчика, правившего код.
Ага, а там торчат ушки аналитика, который поставил задачу, тестировщика, который тестил - в общем сразу видно бесконечно далекого человека от процесса разработки :)
Когда разработчику приходит задача от аналитика на разработку, он должен сразу озвучить то, сколько времени потратит на ее выполнение
Ага, расскажите кто-то автору про грумминг, мне уже лениво клаву топтать
svartberg
27.12.2023 06:24Имхо, автору нужно понять, что лезть не в свою область это не правильно (вы подумайте на тему того как людям работать с тем, кто практически ничего не понимает в их работе и требует с них что-то..оценивает). И стоит нанять хорошего Инжиниринг менеджера с большим опытом в разработке, который будет держать вас в курсе работы. Ну честное слово: типичный русский руководитель, который знает как правильно только потому, что он руководитель компании.
Armann
27.12.2023 06:24На Хабре чуть менее чем все так или иначе имеют опыт с KPI, а многие - и опыт в постановке KPI. Так что все понимают насколько тема сложная и поэтому все эти 'измерения командной работы' вызывают такое раздражение.
Так что совет - если описываете применение KPI, то лучше опишите свой опыт, и распишите до болтов - почему такой выбрали, как считали, кому считали, что было до, как стало после. С цифрами, разумеется.
adurnetsov Автор
27.12.2023 06:24Спасибо за конструктив, согласен. Действительно учтём в следующий раз. Попал в больную мазоль ) В основном комменты и сводятся в том что автор в этом не разбирается, но видимо треть статьи нужно расписать опыт и в цифрах, чтобы потом начали слушать... Хотя там найдутся другие возражения...(
Armann
27.12.2023 06:24Возражения обязательно найдутся :) Но тут будет о чем говорить и что обсуждать.
Как пример - мне очень понравилась статья https://habr.com/ru/companies/oleg-bunin/articles/781580/
Она не совсем про KPI, но там все что нужно - как выбирали, почему выбрали, как считают, как используют.
sir_genry
27.12.2023 06:24Разработчик всегда будет против введения KPI. Никому не нравится, когда его контролируют. Отсюда и раздражение и минусование. Только это не отменяет необходимости контроля и оценки. Пусть эти минусаторы задумаются над тем, кто им платит деньги при всем их заоблачном профессионализме.
Детский сад какой-то...
eao197
27.12.2023 06:24Знатно у вас подгорело. Любо дорого.
ЗЫ. Программисты должны программировать. Не их забота откуда берутся деньги, для этого в компаниях есть специально обученные люди, которые занимаются продажами и маркетингом.
ЗЗЫ. Работа программистов всегда оценивалась и оценивается, но вот KPI в их оригинальном смысле для этого не подходит.
sir_genry
27.12.2023 06:24подгорает у вас. А я корректно возражаю. Автор привел конкретные критерии и я с ними согласен. Если вы говорите про какие-то другие KPI, то уточняйте какие именно.
P.S. Я же с вами закончил разговор ввиду его бессмысленности. Зачем вы мне отвечаете?eao197
27.12.2023 06:24+1А я корректно возражаю
В ваших словах нет никакой конкретики кроме "я согласен с автором статьи". Да и ведете вы себя как истеричка, сперва обвиняете собеседника в том, что он
Обязательно будут оскорбления и выпячивание своего эго: вон какой я умный, целый релиз выпустил, велосипед изобрел. В одного весь этот ваш интернет запрограммировал.
А том сами же и пытаетесь взобраться на такой же трон:
Работал и работаю в достаточно крупных организациях (300 чел разрабов, тестеров, аналитиков - более 20 команд на текущем месте). Должность моя ведущий разработчик, тимлид.
Уж вы-то точно не no-name хрен с горы, а человек с регалиями, от мнения которого отмахнуться нельзя, потому что много опыта, тимлидерство и все такое.
Как это у вас получается: сперва обвиняете собеседника, а затем ведете себя точно так же?
Автор привел конкретные критерии
И тут уже несколько человек сказали почему это легко фальсифицируемое фуфло. Вы реально хотите прокатиться по этим рельсам еще раз?
и я с ними согласен.
Что наводит на мысль, что внедрением KPI и оценкой последствий вам не очень-то и приходилось заниматься. Ну, например, вот есть критерий:
Оформление задачи
Приведите объективные критерии оценки "оформления задачи" и способ их трансформации в количественную величину (например, в баллах от 1 до 5). И так, чтобы это дело масштабировалось, чтобы любой новый менеджер/тимлид (или кто там будет такие оценки выставлять) мог взять ваше описание за основу и начать расставлять такие оценки.
Попробуйте.
Если вы говорите про какие-то другие KPI, то уточняйте какие именно.
Еще раз вам повторяю: KPI для оценки программистов -- это маразм. Хотите ознакомиться с моим мнением, придется потратить время на чтение: #1, #2, #3.
И да "оценка" и KPI -- это разные вещи.
Я же с вами закончил разговор ввиду его бессмысленности. Зачем вы мне отвечаете?
Во-первых, это публичный ресурс. И обсуждение открытое. Вы не можете запретить кому-то отвечать вам.
Во-вторых, я с вами не закончил.
ruomserg
27.12.2023 06:24Разработчик не должен быть ни "за", ни "против" введения KPI. Это менеджерский вопрос. Точно так же, как например, разработчик не должен иметь отношения к бюджетированию канцелярских расходов. Если предприятие не больное на голову - у разработчиков есть ЦЕЛЬ - ради чего всем платят зарплату. Дальше разработчики декомпозируют эту цель на конкретные задачи, и занимаются их решением. Разумеется, в жизни все сложнее - потому что возникают непредвиденные сложности, внешние ограничения и прочие штуки предназначенные для того чтобы реальность не казалась слишком пресной... Но общая картина именно такова - бизнес ставит высокоуровневую цель, объясняя что им нужно для зарабатывания денег - а разработчики придумывают технические способы как этого достичь.
Где здесь KPI конкретного инженера ? А нигде. Потому что KPI - это всегда достаточно высокоуровневая и усредненная по времени оценка. И чем больше вы ее декомпозируете, и меньший срок берете - тем хуже у вас отношение сигнал-шум в измеренном значении. Если же вы по измеренному шуму еще и пытаетесь управлять - ну... такое. Лучше бы вам тогда почитать что-нибудь из теории управления в технических системах - там много интересного...
А вообще, я вам нашел хороший пример из советского ядерного проекта. Там тоже товарищ из органов страстно хотел конкретный KPI для конкретных лиц.
"После поездки к месту несостоявшегося атомного взрыва Курчатова, Малышева, Зернова, Харитона и других участников мы собрались в каземате и стали спокойно разбираться в причинах отказа. Вдруг появляется некий полковник госбезопасности. В фуражке, начищенный, с иголочки. Козырнул и обращается к В.А. Малышеву, нашему министру:
- Товарищ министр! Если я правильно понимаю, произошел отказ?
- Правильно понимаете.
- Разрешите начать следствие..."
Дальше показания участников разнятся. По одним данным - Курчатов объяснил бдительному сотруднику органов, что отказы на испытаниях - являются обычным делом, и потребовал освободить помещение. По другим - закаленный предыдущей работой с Берия, бородатый академик не отводя глаз от разложенных лент самописцев, каким-то особым тоном ответил: "Пшел нах!" - полковник побледнел и вышел...
Надо ли говорить, что ядерный проект для СССР являлся гораздо более важным и дорогим делом чем любая разработка ПО о которой мы можем спорить ?
yamakasy267
27.12.2023 06:24Если честно, я всегда нахожусь в некотором недоумении в таких вопросах. С одной стороны я понимаю желание аналитиков и менеджеров, посчитать все, что только можно, с другой стороны, как правильно написали выше, а посчитать что бы что?
Как по мне, разработка это нечто абстрактное и с элементами творчества. И поэтому вместить это в жёсткие рамки, все равно что сказать художнику, что в месяц должен создавать определенное количество картин. Непонятно каких, какого размера, качества и т.д. но точно не меньше этого количества.
Касательно определённых пунктов:При расчете показателей эффективности учитывается количество задач с авариями, которые возникают по вине разработчика, правившего код
Как правильно написали выше, программисты, просто перестанут что либо рефакторить и лезть в рабочий код, руководствуясь принципом: "Главное-работает" и забивая на оптимизацию. Кстати о ней:
Уровень сложности кодирования, производительность кода. Это возможно измерить при помощи времени, которое потребовалось на выполнение задачи, используемой памяти и остальных потраченных ресурсов
Ну время на выполнение задачи, это вообще вещь абстрактная, задай побольше человека-часов и вот уже сложная задача уже невероятно сложная. Но меня больше интересует используемая память и потраченные ресурсы. Одни из основных критериев алгоритмов в коде, это время выполнения и затраченная память и чем они меньше тем лучше написан алгоритм. Теперь получается оптимизируешь алгоритм и он затрачивает мало памяти и тиков, получается код не сложный, а если отталкиваться от того насколько программист смог оптимизировать код, то кто будет определять планку, что вот тут нужно не больше столько-то памяти и вот-такая то алгоритмическая сложность, непонятно.
Ну про оформление документации, это вообще просто желание введения бюрократии, что б жизнь медом не казалась, а то ишь с документами работать они не хотят.Кст. касательно:
Он пишет, когда и что исправил, что делать тестировщику
Мне так это всегда нравиться, что делать тестировщику пишет программист, за аварии тоже программист, а вот интересно тестировщик должен исправлять косяки программиста, или за что он отвечает в принципе? Я конечно, не говорю, что программист должен писать код абы какой и надеется , что тестировщик найдет все проблемы, но все таки, за что отвечает тогда тестировщик, если авария, это проблема программиста, а не то что тестировщик не нашёл данный баг?
Если честно, в последнее время наблюдаю тенденцию, попыток как можно больше возложить на программиста, что бы он и за деплой отвечал, и за тестирование и хорошо бы еще аналитиков понимал и давал им советы, ну и заодно видимо помогал продукт продавать. Печально как то...
Homyakin
При упоминании KPI, мне всегда вспоминается закон черных метрик из Дорофеева - для любого KPI, существует такая стратегия B, что KPI находится в зелёной зоне, а проект летит через ж* в неизвестность.
Картинка
У разработчика появляется страх совершать ошибки, и он будет делать только самый безопасный минимум.
Всегда завышаем оценку. Если успеваем раньше, специально затягиваем разработку.
Бюрократия как она есть. Можно сделать примерно ничего, зато красиво всё описать.
ИМХО, самым важным показателем, является обратная связь от тех, с кем человек работает. Вышеперечисленные показатели важны и на них стоит смотреть, но сами по себе они ничего не показывают.
Не претендую на истинность в последней инстанции, говорю с позиции разработчика.
fpga500
В чем проблема всех этих KPI на мой взгляд. Это то, что их вводят люди которые ничего не понимают в той области, в которой их поставили руководить. И из-за своего незнания предметной области они пытаются вводить всякие хитроумные метрики. Но разве можно представить, что футбольный тренер не умеет играть в футбол, а дирижер не умеет играть не музыкальном инструменте? Так и руководитель отдела программистов должен быть программистом, ну или хотя бы инженером в смежной области.
Antharas
Западные техники мониторинга команд в т.ч. скрам - не применимы к продуктовым компаниям РФ, пока существуют фундаментальные проблемы процессов. Это все только создает для рабочей среды огромную трату времени..
fpga500
Что за фундаментальные проблемы процессов?
Antharas
ЗО РП/ПМ, «долой оптимизации - даешь больше фич», нехватка ресурса.. можно долго перечислять
fr019
Эти проблемы также свойственны и западным компаниям, даже в большей степени чем у нас.
sir_genry
Описанные в статье показатели для расчета KPI весьма корректны на мой взгляд.
Но я встречался и с откровенно бредовыми показателями. Например, не очень умные начальники ввели понятие некоего лодочного принципа. Вот это так себе показатель: косячит какая-то одна команда, а огребают все остальные команды, которые повлиять на процесс вообще никак не могут
eao197
Ну афигеть, их двое!
sir_genry
не поверите, нас гораздо больше
eao197
"Количество разума -- величина постоянная, а население-то растет" (с)
Но, конечно, страшно становиться от количества альтернативно одаренных, которые, во-первых, всерьез рассуждают о KPI для программистов и, во-вторых, рассматривают такие критерии, как "безаварийность", "попадание в оценку" и "оформление задачи".
sir_genry
Но вас-то это не касается? )
Так что можете продолжать язвить и оскорблять. Вы же самый умный )
На оскорбления переходим, аргументы кончились или что?
Вы себе вопрос только один задайте: откуда деньги берутся? Кто их вам выдает? Мне можете не отвечать, я знаю ответ на этот вопрос
eao197
В отличии от вас (никому не известного анонима с четырьмя комментариями) я здесь под своим реальным именем. В профиле есть ссылка на блог, любой желающий может туда сходить и поискать заметки по ключевому слову KPI. Мне в свое время довелось плотно с этой темой под разными углами сталкиваться.
Для себя давно сделал вывод, что желающие внедрить KPI для программистов (именно для программистов) не отличаются большим умом (если говорить политкорректно). И если уж они собрались разваливать разработку таким способом, то пусть они делают это сами, без меня.
sir_genry
Очередной раз убеждаюсь, что донести свою мысль до желчного язвительного "умника" пустая затея. Обязательно будут оскорбления и выпячивание своего эго: вон какой я умный, целый релиз выпустил, велосипед изобрел. В одного весь этот ваш интернет запрограммировал.
Ну извините, что без должного пиетета обращаюсь.
Потому и не пишу, что знаю, что ничего иного ожидать не придется.
Пришли тут обхаяли человека. Обгавкали я бы сказал. А я между прочим с его мнением согласен. Работал и работаю в достаточно крупных организациях (300 чел разрабов, тестеров, аналитиков - более 20 команд на текущем месте). Должность моя ведущий разработчик, тимлид. Так что очень все это для меня близко.
Так и смысл мне писать в этих ваших форумах. Я этого добра наелся еще в 90-ые. Там народ собачился покруче. С реальными встречами.
Нет, ребята, вы не меняетесь, не растете. Какими были, такими и остались.
Спорить далее не буду. Бессмысленно. Опять в эти какашки. Нет уж увольте. Собачьтесь тут без меня
eao197
Или просто наелся побольше вашего. Но ведь вы то, что я в свое время по теме KPI писал даже не стали искать, не так ли?
И много KPI внедрили? На каком временном интервале результаты оценивали?
sir_genry
Так и должен быть безопасный работающий минимум. Не нужно делать того, о чем тебя не просили. А вот если по вине разраба у кого-то колом встает важный процесс, возникают убытки, пациенты в очереди в поликлинике застряли, то кто должен за это отвечать? Конечно же тестировщик, скажете вы. Но по моему мнению, мнению тимлида по типу играющего тренера, все же разработчик несет большую ответственность
Ага, все кругом такие дураки, что этого видят. И тимлид некомпетентный дурак, и ВП такой же... Попадание в оценку - признак профессионализма. А если разраб специально СИСТЕМАТИЧЕСКИ тянет время, то он идет искать другую работу.
Это вы бюрократии не видели значит, раз такое пишете.
Коллег нужно уважать! Тестировщики тоже люди и им очень важно знать, что именно в данной задаче реализовал разраб. И если ничего сверх ТЗ, то я не думаю, что сложно чиркнуть соответствующую строчку. Но жизнь далека от идеала и так бывает не всегда. Поэтому очень важно знать что именно тестировщику нужно проверить, на чем акцентировать внимание
Это очень хорошо, что не претендуете. Не думаю, что вы работали в больших компаниях
Throwable
Я так понимаю, это перефразированный закон Гудхарта: https://ru.wikipedia.org/wiki/Закон_Гудхарта