Сегодня получил очередной комментарий к довольно старой теме “Интересная дискуссия о KPI для программистов”:
Любой человек "очкует" когда его пытаются оценить. У программистов это явно выражено. Да, программирование сродни хотьбе по лабиринту, я соглашусь с этим. Но а что. работа менеджера по продажам не сложна? А работа врача? Почему-то для продавцов можно KPI разрабатывать а для программеров нет.
Я руковожу программистами и знаю как это непросто. Но я уверен, что "неоценивать" работу разработчиков нельзя. Должны быть критерии.
Вообще, судя по статистике, с поисковых сайтов по запросу “KPI программиста” ко мне в блог заходит изрядное количество посетителей (в Yandex-е по этой фразе я вообще затесался на третье место среди результатов, что свидетельствует, имхо, о крайней нераскрытости темы). Посему я решил дать ответ на комментарий в виде отдельной заметки.
Не могу объективно сравнивать критерии оценки работы программиста с другими областями деятельности, поскольку мало в них разбираюсь. Не имею понятия о том, как оценивается работа врача (опять же, какого – ведущего прием участкового терапевта или анестезиолога в кардиологическом центре?) И о том, как оценивают агентов по продажам. Слегка наслышан об оценке рабочих на производствах, где есть нормы выработки и нормативы на время производства конкретных изделий по конкретным спецификациям. Так же приходилось слышать об оценке научной деятельности по количеству публикаций статей/монографий и количеству докладов на конференциях (что так же не слишком тепло встречалось самими научными работниками).
Однако, предположу, что в каждой профессии есть свои специфические особенности из-за которых не получится перенести хорошо работающие в одной профессии оценки на представителей другой профессии. Поскольку KPI в программировании привнесен извне, то уже одно это должно бы наводить на размышления. Особенно, если KPI пытаются выводить по каким-то количественным, а не качественным показателям.
В вопросе о KPI для меня самым непонятным моментом является цель этого дела. Зачем нужен KPI программистам вообще? Допустим, у вас есть коллектив разработчиков, который справляется со своей работой – укладываются и в допустимые сроки, и в приемлемый бюджет, и проекты с должным качеством выполняются, и приносит компании прибыль.
На мой далекий от бизнеса взгляд это уже зашибись! И тут в пору вспомнить основной принцип программизма – если что-то работает, то не трогай – пусть работает дальше. А то ведь время от времени встречается информация о том, что по каким-то там оценкам изрядный процент программных проектов превышает сроки и бюжеты, а то и вовсе закрывается как провальные. Если к такой информации прислушиваться, то вокруг все просто жуть как плохо, а у вас все хорошо. Ну так и не трогайте :)
Если же все не так радужно и с проектами беда, то нужно ли пытаться решить проблемы начиная с KPI самого нижнего слоя пирамиды – с разработчиков? Рыба известно откуда гниет. И если проект трещит по швам, то может лучше начать с другой стороны? Вдруг это кто-то там наверху выбрал сроки и бюджет из политических, а не реалистических соображений? Или проект был поручен горе-менеджеру, который знает очень много правильных слов и блестяще ораторствует на советах директоров, но не может донести до команды точные цели проекта и конкретные пожелания заказчиков? А если все руководство, включая непосредственно работающих с программистами тим-лидов, супер-пупер профессиональное, то как тогда получилось, что у них в подчинении совершенно бестолковые разработчики, не способные писать нормальный код?
Или может KPI нужен для того, чтобы размер зарплаты и премий рассчитывать? Если у Феди показатели по KPI на 15% выше, чем у Васи, то Федя получит премию, а Вася нет. Уж не в этом ли цель KPI?
Эту цель хотя бы понять можно. Однако, почему такой подход лучше, чем делегирование распределения премиальных конкретному менеджеру или тим-лиду? Тем, что объективнее? Да фигня это все! В управлении субъективизма изначально настолько много, что попытка подвести какой-то формальный базис под распределение премии выглядит… Как трусость она выглядит. Потому что если руководителю нужны какие-то формальные отмазки для ответа на прямой вопрос “Почему мне премию не дали?”, то руководитель этот такой же формальный.
Ну да все это лирика и риторика. Суть-то в другом.
Как ни крути, но руководителю все равно приходится оценивать своих подчиненных. Чтобы решать, кто и чем будет заниматься в очередном проекте. Кому можно поручить самые важные куски, кто будет заниматься рутиной, кто будет гоняться за злобными багами. Очень нужны оценки для предсказания сроков разработки. Поскольку Федя может сделать за месяц, а Вася за полтора. А Гена за две недели, но только если ему задача понравится.
Поэтому руководитель вынужден заниматься оценкой работы своих подчиненных. Пообещал Гена уложиться в две недели, а реально потребовалось три. Значит для его оценок нужно вводить коэффициент поправки 1.5, а то и больше. Уложился Вася в срок – хорошо, на баги затем пришлось десятками ловить, значит в следующий раз за Васей более серьезный присмотр нужен. Федя может сделать все быстро и качественно. Если не забудет и не отвлечется на очередной pet project. Поэтому для Феди нужно выделять по 15 минут в день для раздачи поджопников напоминаний.
Но все это проблемы руководителя. И пусть он сам выбирает для себя критерии, которые считает нужными. Подберет удачно – хорошо. Не подберет, команда перестанет работать, придется выдумывать что-нибудь другое. Нормальный процесс проб и ошибок. Который, однако, должен быть скрыт от программиста.
И именно это является основной мыслью данного поста. А именно:
Критерии оценки работы программиста не должны быть известны программистам.
Только так.
Поскольку если программистам будет объявлена система оценок и будет показано как их благосостояние зависит от нее, то у программистов возникнет совершенно определенная цель – улучшение собственных показателей в рамках системы.
Зависит зарплата от количества строк написанного за день кода? Нет проблем – copy-and-paste. И нафиг мне два дня думать, как сделать что-то 10 строчками кода, если я могу за три дня написать то же самое в 1500 стоках говнокода.
Поставили зарплату в зависимость от количества багов? Ну тогда сложные задачи идут лесом. Пусть их Пушкин делает и баги затем расхлебывает. А уж если поручили, то я лучше буду на каждый чих разрешение у тим-лида или менеджера спрашивать – пусть эти баги будут и на их совести, да и в следующий раз подумают, следует ли меня чем-нибудь нетривиальным грузить.
Оценивается точность предсказания сроков? Отлично, будем их изначально завышать в 2*PI раза.
Почему так? Да потому что так! Я ведь не ящики с места на место таскаю. Мне нужно выдумать что-то, чего нет. Зачастую убив кучу сил и времени на то, чтобы выяснить, что же именно надо. После чего воплощаю это в коде и заставляю работать как нужно. И то, чего изначально не было вовсе, вдруг появляется и, зачастую, работает!
Все это хождение по лабиринту с ежедневным насилованием собственных мозгов за заранее оговоренные деньги. И если кто-то задается вопросом “А качественно ли ты насилуешь свой мозг? И не переплачиваю ли я тебе за это?”, то мне не остается ничего другого, как сделать честную рожу – качественно, не переплачиваете. И если для этого мне нужно скорректировать несколько формальных параметров, то я это сделаю и переживать по этому поводу не буду.
