Меня зовут Антон Омельяненко, я Head of Software Development в EXANTE. Менеджер управляет командой так, чтобы она приносила бизнесу результат. Чтобы понимать, насколько хорошо люди справляются с задачами, ему нужны данные о работе и система оценки. С разработкой это сложнее, чем кажется.

В статье я разберу три вопроса: почему классические метрики не подходят для оценки эффективности разработчиков, как измерять её правильно и что делать, если вам кажется, что сотрудник работает не только на вас.

Строчки кода, коммиты и стори-поинты: почему они не работают

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

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

Коммиты. Продуктивные разработчики действительно чаще коммитят несколько раз в день. Но обратное неверно: если человек коммитит реже, это не значит, что он работает хуже. Задачи разные по сложности, объёму и смыслу, а считать коммиты — значит поощрять дробление работы ради цифры.

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

Все эти метрики считают количество, а не качество. Мы в EXANTE перепробовали их и увидели, что реальную эффективность они отражают слабо. Но бизнесу всё равно нужно понимать, что разработка работает эффективно, поэтому мы продолжили искать решение.

AI открывает путь к объективности

Так появился DevMind — наш внутренний инструмент на основе AI. Он собирает данные из GitLab и Jira и строит отчёт по каждому разработчику. Вот что он анализирует:

  • Коммиты. DevMind оценивает их сложность и качество по десятибалльной шкале. Если оценка низкая, он объясняет, почему.

Интересно, что оценка по этому пункту верная примерно в 80%, были случаи когда коммиты AI оценил ниже среднего, а по оценке тех-лида там все нормально и обоснованно.

  • Задачи. Из Jira он берёт, сколько задач закрыл разработчик, сколько раз они возвращались из тестирования в работу из-за багов и какие стори-поинты закрыты за спринт.

  • Митинги. DevMind оценивает участие в дейли: что человек говорит и насколько это отражает реальную картину.

Два замечания о точности, из нашего опыта работы с инструментом. 

Оценка коммитов верна примерно в 80% случаев: бывали случаи, когда AI оценил коммит ниже среднего, а тех-лид счёл работу качественной и обоснованной. 

Оценки по задачам и митингам оказались надёжнее.

Но даже полный отчёт — это ещё не оценка. DevMind собирает объективную картину, а выводы по ней делает человек. Причём не посторонний, а тех-лид, который работает с этими людьми каждый день. Только он может сказать, правильно ли AI оценил сложность коммита и качество кода.

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

Итог такой: объективная оценка от DevMind плюс субъективная — от людей, которые работают с командой каждый день. Вместе это точнее любой отдельной метрики.

Мы обязательно расскажем о том как устроен DevMind более детально в следующих статьях.

Эффективность — не постоянная величина

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

Если продуктивность просела, тех-лиду не нужно в ту же минуту бежать с претензиями. Сначала стоит задать наводящие вопросы: есть ли сложности, чем помочь. Часто этого достаточно. Но если эффективность не восстанавливается и через какое-то время, можно прийти с прямым разговором: раньше ты делал X, сейчас — половину, что случилось? Иногда причина оказывается неожиданной.

Как быть, если дело в поливоркинге

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

В удалённой среде это встречается чаще, чем принято признавать. Один из наших лидов однажды наткнулся на форуме на пост своего разработчика: тот с гордостью описывал проект, который сделал «на работе», и приложил скриншоты. Джира на них была чужая. Так мы узнали, что у человека есть вторая работа — и, судя по всему, более приоритетная.

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

Что тогда делать менеджеру? Не увольнять с порога и не искать виноватого. Лучшее, что можно сделать, — максимально ясно проговорить, какой результат вы ждёте. Например: «Мне нужно, чтобы за спринт ты закрывал такой-то объём задач. Считаешь такую нагрузку адекватной? Да. Тогда договоримся так: разово из-за форс-мажора можно сдать меньше, это нормально. Но если так повторяется два спринта подряд, я не смогу оставить тебя на проекте — работа не должна тормозиться».

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

Вывод: следите за динамикой, доверяйте обеим оценкам

Если собрать всё вместе:

Классические метрики по отдельности не отражают реальную эффективность — строчки кода, коммиты, стори-поинты считают количество, а не качество.

Измерять правильно — значит сочетать объективную оценку (DevMind, данные Jira, стори-поинты) с субъективной (фидбек тех-лида и продакт-оунера, опрос 360 градусов). По отдельности ни та, ни другая полной картины не даёт.

Следите не за моментальным состоянием, а за динамикой: эффективность в конкретный момент — ненадёжный показатель, важна тенденция.

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