Зачем вообще измерять работу

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

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

Тут я буду произносить слово "KPI", но не всегда буду говорить именно о ключевых показателях эффективности в строгом смысле. Скорее речь про любые способы оценивать работу человека: формальные метрики, 360° review, качество кода, попадание в оценки задач, обратную связь от коллег и похожие штуки.

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

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

Где начинается проблема

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

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

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

Это не значит, что метрики бесполезны. Просто метрика - это не реальность. Это способ посмотреть на кусок реальности под конкретным углом. Проблемы начинаются тогда, когда этот угол объявляют объективной картиной всей работы человека.

Почему с программистами сложнее

Критериев оценки эффективности работы много, и многие из них применимы только к определённым профессиям. У отдела продаж можно смотреть на количество подписанных контрактов. У поддержки - на скорость реакции, качество ответов, процент довольных пользователей. Там тоже всё не идеально, но хотя бы понятно, где искать прямые показатели.

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

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

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

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

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

Что считать объективной метрикой

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

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

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

Какие метрики можно смотреть

Предсказуемость работы

Один из полезных показателей - насколько разработчик попадает в оценку задачи и как ведет себя, когда оценка начинает ехать.

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

Тут полезно смотреть не только на точность оценки, но и на поведение:

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

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

Качество и безаварийность

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

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

Но это не значит, что качество нельзя учитывать. Можно смотреть на повторяющиеся паттерны:

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

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

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

360° performance review

360° review - это не совсем критерий, а способ собрать то, что плохо формализуется. Разработчика оценивает не один человек, а несколько коллег из разных ролей. Да, это субъективно. Но нельзя просто сказать, что раз мнение субъективно, его не нужно учитывать.

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

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

Для 360° review хорошо подходят такие вещи:

• умение работать в команде;
• лидерские навыки;
• коммуникация;
• организаторские навыки;
• способность помогать другим;
• отношение к проекту и команде.

Через 360° review можно косвенно увидеть и более технические вещи. Например, кто чаще оставляет после себя проблемный код, кто систематически завышает оценки, кто берет задачи и потом пропадает, кто помогает разруливать сложные места. Коллеги часто видят это лучше, чем менеджер, особенно если менеджер далеко от кода.

Но 360° review тоже можно испортить. Если нет анонимности, люди будут осторожничать. Если нет нормальной культуры обратной связи, оценка превратится в конкурс популярности или способ отомстить. Если менеджер заранее выбрал виноватого, он может вытащить из обратной связи только удобные куски. В итоге инструмент вроде хороший, а результат снова зависит от того, насколько честно им пользуются.

Субъективные оценки

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

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

Что точно не стоит делать главным KPI

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

Количество commits. Его легко накрутить. Один человек сделает один нормальный commit, другой разобьет то же самое на десять. По цифре второй будет выглядеть активнее, хотя смысла в этом нет.

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

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

Story points. Они нужны для планирования, а не для оценки личной эффективности. Если сделать из них персональный KPI, команда начнет играть в оценки. И тут уже можно хоронить нормальное планирование, потому что оно перестает быть инструментом команды и становится инструментом личной защиты.

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

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

Что делать с незаинтересованным сотрудником

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

С незаинтересованным сотрудником всё иначе. KPI не делает человека заинтересованным. Он может показать симптомы: задачи закрываются медленно, качество плохое, коллеги жалуются, оценки постоянно едут. Но сама по себе таблица не превращает безразличие в мотивацию.

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

Тут уже вопрос не в KPI, а в управлении. Может быть, человеку не подходит проект. Может быть, он выгорел. Может быть, ему плохо объяснили ожидания. Может быть, он правда не тянет роль. Может быть, менеджер сам не понимает, что от него хочет. KPI может помочь зафиксировать проблему, но не заменит разговор и решение.

Как я бы это использовал

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

Например, человек быстро закрывает задачи, но после него много возвратов с ревью и регрессий. Это один разговор.

Человек медленнее других закрывает задачи, но берет сложные места, чинит старые проблемы и после него код становится устойчивее. Это другой разговор.

Человек нормально пишет код, но команда постоянно жалуется на коммуникацию. Это третий разговор.

Человек не самый сильный технически, но хорошо оценивает риски, помогает новичкам и стабилизирует процессы. Это тоже нужно видеть, иначе можно легко недооценить его вклад.

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

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

Итог

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

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

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

И вот эта попытка, кажется, чаще всего всё и ломает.