Как оценить индивидуальный вклад разработчика в проект

Зачем отслеживать эффективность

Отслеживание эффективности работы сотрудников является одной из важных составляющих работы каждого руководителя. Собранные данные позволяют компании:

• выявить узкие места, где сотрудники сталкиваются с трудностями

• своевременно поощрять результативную работу

• обнаружить как высокоэффективных сотрудников, так и тех, кто, возможно, нуждается в поддержке, адаптации в новой роли или замене

• и т.д.

Будучи тимлидом, я многократно задавался вопросом объективной оценки эффективности работы сотрудника, основанной на данных, а не только на субъективном мнении руководителя или коллег. До пандемии коронавируса преимущественно во всех IT компаниях сотрудники работали в офисах, и, если человек приходит на работу, значит он скорее всего что-то делает. В 2020 году ситуация усугубилась, все ушли на удаленку, а инструментов оценки эффективности попросту не оказалось. Более того, спустя пару лет крупные компании, включая таких мастодонтов как Google, Apple, Amazon и т.д. вновь начали выводить своих сотрудников в офис, что может служить индикатором того, что инструментов до сих пор так и не появилось.

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

От субъективных оценок к объективным метрикам

Распространенные методы оценки такие как performance review субъективны, основаны на персональных ощущениях руководителя и коллег, никак не конкретизируют те KPI, которые нужно использовать. Фактически ставятся какие-то не всегда конкретные задачи, добавляются субъективные отзывы коллег, сотрудник пишет отзыв на свою работу и в итоге руководитель на свое усмотрение ставит оценку. Кто-то умеет красиво репортить о проделанной работе, кто-то совершенно не умеет этого делать, но при этом делает очень много для проекта – все это вносит долю субъективности в итоговую оценку. На мой взгляд PR, конечно, лучше, чем ничего, но все же не самый оптимальный способ оценки эффективности.

Мне же очень хотелось получить простую, прозрачную, максимально объективную методику подсчета вклада конкретного разработчика в проект. Чтобы разработчики понимали, почему Вася работает лучше Пети, чтобы top performer’ы хотели работать в такой команде. Я убежден, что небольшая команда, собранная из 3-4 top performer’ов с соответствующим бюджетом (сотрудник, который показывает высокие результаты заслуживает высокого уровня дохода), гораздо более эффективна чем раздутая плохо управляемая из 10 человек. Такой подход выгоден и компании и сотрудникам. Разработка – это математическая профессия, поэтому в моей идеальной картине мира все должно было сводиться к цифрам, где 2> 1, а значит 2 лучше, чем 1. И неважно работаешь ты из офиса или из дома, начинаешь ты свой рабочий день в 9:00 или в 21:00, умеешь ли ты красиво говорить или же каждый командный дейлик для тебя это колоссальный стресс, самое главное – это результат.

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

Начну с того, кто же такой программист. Вот что пишет нам википедия:

Программи́ст — специалист, занимающийся программированием, то есть созданием компьютерных программ.

Из этого определения можно сделать вывод, что, в первую очередь, написание кода – это основная задача. Эти рассуждения вывели меня к казалось бы очевидной и совсем не новой идее – надо использовать строки кода, число закрытых дефектов, число merge request’ов и т.п. К моему сожалению, многие боятся это делать, считая, что интеллектуальная работа, коей является разработка ПО, гораздо сложнее, чем все эти цифры. Участие в митингах и обсуждениях архитектуры, помощь в решении различных проблем – это конечно же неотъемлемая часть работы разработчика сегодня, которая бывает тоже важна, но напрямую на программный продукт эти показатели не влияют.

Если провести параллель с open source разработкой, то, по сути, эффективность там считается именно так. Это конечно совсем другой мир в отличие от коммерческой разработки, и процесс там больше похож на искусство, чем на ремесло. Но в open source люди делают очень крутые вещи (и Docker, и Kubernetes, и Grafana и многое другое), поэтому совсем не использовать опыт данной отрасли, на мой взгляд, это преступление.

Подход к оценке

Я перепробовал достаточно большое число метрик в разных комбинациях. Но чтобы получить простую методику, мне хотелось оставить небольшое число (не больше 10), которые легко собрать, и которые будут в значительной степени определять результат (закон Парето). Например, от подсчета коммитов я отказался, уйдя в комбинацию строк кода + MR, потому что сам по себе коммит ничего не дает.

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

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

где c(d) – это конкретное действие (например, добавление строк кода), w – это «вес» каждого действия (подробнее об этом чуть ниже).

Если просто просуммировать все действия, то оценка окажется несбалансированной, потому что, например, проведенное code review (если конечно оно было проведено качественно) явно по вкладу не равняется одной написанной строчке кода. Для этого каждому действию присваивается «вес». Расчет данного параметра вызывает больше вопросов и скорее всего требует калибровки для каждого проекта. Ниже в таблице 2 приложены значения параметров, которые я использовал для анализа, от них можно отталкиваться.

В выборку должен попадать только тот код, который замерджен в master, т.е. merge request прошел все проверки, включая ревью и уже работает в продакшн среде. Тоже самое касается и задач с дефектами: нас интересуют только подтвержденные командой и/или менеджером, т.е. те, которые дошли до прода.

Сложные ситуации и их решения

Допустим есть сложный дефект, который сложно воспроизвести, но его фикс займет несколько строчек кода. Как итог – программист разработчик, который в это время решал простой тикет закоммитил 500 строк кода, а разработчик, который занимался сложным дефектом 10.
Оптимизации, сложные баги подразумевают какую-то доказательную базу – тесты, которые воспроизводят проблемы, а соответственно к фиксу в 10 строк кода добавятся десятки, а скорее даже сотни строк с тестами. Ну и на дистанции в квартал, полгода, год статистика выровняется, вряд ли работа одного и того же разработчика будет состоять только из фикса багов повышенной сложности.

А если задача сложная, сначала ее надо хорошенько обдумать, задизайнить? Документация – это тоже важный артефакт, и процесс дизайна должен быть хорошо задокументирован, именно поэтому метрики по работе с wiki – создание и апдейт страниц.

Можно легко хакнуть систему: наделать кучу merge request’ов по 3 строчки кода в каждом, как быть с этим? Ответ – не пропускать такие mr на ревью.

Как быть со страницами на wiki? Их же тоже можно править порциями по одному символу и получать за это баллы. В данном случае можно периодически проводить ревью созданных страниц.

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

А если у меня исследовательская задача, где нужно много читать, изучать и т.п.? Здесь, как и в случае со сложным дефектом – должны сохраниться артефакты на wiki, скрипты и пр., которые будут учитываться в статистики.

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

Результаты

Я провел небольшое исследование на 4 командах разработки, общая численность 25 человек. Ниже для примера привожу результаты по одной из команд, 2 таблицы – одна за более короткий интервал (3 месяца), вторая за более длинный (9 месяцев), чтобы сгладить выбросы. Немного вводных:

• flat команда backend разработчиков одного грейда

• помимо разработчиков есть QA и системные аналитики

• распределенная команда

• методология Kanban

User 1
Лидер по числу баллов как интервале в 1 квартал, так и на дистанции в 3 квартала. Набрал в разы больше баллов, чем остальные члены команды: и кода написано больше, и merge request’ов, также видно, что разработчик предлагает улучшения (10 заведенных тикетов). В данном проекте – это топ performer. Субъективное восприятие полностью совпадает со статистикой: человек – фанат своего дела, невозможно заставить его не работать по выходным, регулярно организует митапы для коллег, пишет статьи и т.п.

User 2
Большую часть своих баллов набрал за счет проведения code review. В принципе это было бы нормально для ситуации, если бы это был архитектор, через которого проходила бы большая часть merge request’ов, но в данном случае это не так. В данном случае разработчик четко следовал регламенту Kanban, где задачи в статусе review на доске располагались правее, а значит приоритетнее и дело было в остальных ребятах, которые приоритет отдавали своим задачам в колонке developing. По числу баллов находится ровно посередине, итоговая оценка – хорошо, продолжай в том же духе.

User 3
Отстает как на интервале в 1 квартал, так и на интервале в 3 квартала. Объяснения плохой статистики были разные: то приходилось коммуницировать со смежными командами, в которых он оказался не силен, то задачи на реверс инжиниринг и т.д., хотя бэклог у разработчиков один. Это пример low performer’a.

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

По данным метрикам можно увидеть проблемы или особенности процесса разработки. В данном случае user 2 провел 50% всех code review в команде. На деле оказалось, что остальные ждали, пока кто-то другой возьмет просмотр очередного merge request’а.

Данная метрика служит хорошим индикатором того, что в процессе есть проблемы, в данном случае – это несбалансированное code review.

Также это хороший способ достоверно определить low perfomer’ов – тот, кто на протяжении нескольких месяцев в конце списка, каждый раз находятся какие-то причины (как в примере с user 3). Ну и разумеется тоже самое касается и top performer’ов – в данном примере это user 1.

Данный скоринг я использую как основной показатель при оценке результатов работы за квартал/год. Дополнительно поощряется вклад в комьюнити: проведение собеседований, митапов, также показатели, связанные с менторингом и т.п., с влиянием на итоговую оценку не более 20%.

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

На протяжении года я мониторил и отлаживал данный алгоритм, и в конце концов подвел итоги года, основываясь на данном скоринге. Top performer’ы в большинстве своем оказались максимально скромными ребятами, в одном случае я услышал комментарий «Да зачем мне ваша премия? Лучше между командой разделите.» По low performer’ам реакция на 2 типа: в первом случае сотрудники согласились с результатами, совместно мы составили план развития, во втором случае были апелляции, что нельзя мерить работу разработчика по написанному коду, это творческая работа и все в этом духе.