KPI для разработчиков. Нам не хочется, но мы их используем

Константин Коногорский, заместитель директора по разработке в компании «ВИСТ», поделился своими мыслями о том, стоит ли вводить систему KPI для разработчиков (спойлер - не стоит), и почему она в компании таки есть.

KPI для разработчиков — одна из излюбленных тем в компаниях, занимающихся разработкой ПО, особенно в тех, где менеджеры — выходцы из продажников. Явление это вполне объяснимо, ведь менеджеры привыкли видеть конкретные результаты в цифрах: подписать десять контрактов в месяц, обеспечить один миллиард прибыли в год и так далее. Такие показатели очень просто измерить, и очень просто поставить на них цели. Существует известное в узких кругах выражение: «Все менеджеры обожают цифры, но цифры ненавидят менеджеров». И вот как раз в точке пересечения менеджеров и разработки эта ненависть показывается во всей красе.

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

При составлении KPI для разработчиков следует учитывать, что разработчики – очень умные, творческие и, самое главное, азартные люди. При выставлении им KPI первым делом они подумают не о том, как им надо с этим работать, а о том, как хакнуть логику этого KPI. Такова наша творческая натура.

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

Первая составляющая – это количество залоганного в таск-трекере рабочего времени. Это связано с тем, что в 2020 году мир серьезно изменился -- все ушли на удаленку. Стало совершенно непонятно, работает программист или нет. Если программист мотивирован проявлять активность в таск-трекере – этот вопрос становится чуть более прозрачен. Но это не исключает возможности сценария, когда он сделал задачу трудоемкостью в один день за полчаса, залогал в нее весь день и гулял 7,5 оставшихся часов.

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

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

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

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