Как измерить эффективность труда программиста

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

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

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

Возникает вопрос, какие единицы оценки задач можно применить. Существует два подхода: во-первых, задачу можно оценить в человеко-часах, которые потратит на решение некий эталонный разработчик; во-вторых, оценка в абстрактных единицах. В литературе по организации разработки в команде встречается термин Story Point для обозначения условных единиц стоимости задачи.

Рассмотрим плюсы оценки задач в Story Point по сравнению с человеко-часами:

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

В нашей группе разработки используются оценки задач при помощи Story Point. В качестве элементов оценки берем степени числа 2 (1/2, 1, 2, 4, 8). Есть договоренность, что простые задачи имеют оценку 1/2 или 1. Задачи посложнее — 2 или 4. Самые сложные и объемные задачи оцениваем в 8 баллов. Если задачу не удается оценить при помощи данной шкалы, необходимо разбить ее на более мелкие либо вывести в разряд проектных разработок.

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

Кто должен оценивать работы?

Очевидно, что сложность работ по конкретной задаче должен оценивать человек квалифицированный, ведь кто-то умеет красиво подать свою работу, а кто-то нет. В большинстве случаев заказчик задачи не обладает необходимыми знаниями для корректной оценки ее сложности. Заказчик может оценить качество работ (заявленный функционал работает без ошибок, работа данного функционала облегчает труд и ускоряет выполнение собственных задач заказчика), сроки реализации задачи (задача выполнена в сроки, оговоренные заказчиком и исполнителем, и на момент сдачи работ имеет ценность для заказчика). Но сложность каждой задачи может определить только квалифицированный специалист. Наиболее распространены следующие варианты оценки задач: задача оценивается ответственным (руководителем группы, тимлидом, ведущим специалистом); задачу оценивает вся команда разработки. Каждый способ имеет свои плюсы и минусы. Если сложность задачи оценивает ответственный, такая оценка всегда субъективна и основана на опыте конкретного специалиста. В свою очередь, при командной оценке есть вероятность, что один или несколько членов команды знают более быстрый способ решения такой задачи, чем ответственный. А может быть и наоборот: при решении аналогичной задачи кто-то из команды сталкивался с подводными камнями, о которых другие члены команды не подозревают. Но идеальная оценка задач командой имеет один существенный минус: мы тратим время всей команды, чтобы вникнуть в суть задачи и обсудить ее решение. Каждая ли задача стоит таких затрат?

Оценка результата работы по периодам

По итогам интересующего нас периода выполняется анализ проделанной специалистами работы и оценки всех выполненных задач за период суммируются.

При помощи данного подхода мы определили эффективность работы каждого члена команды, а также такую величину, как мощность (производительность) команды, то есть количество Story Point, которые команда может сделать за единицу времени. После этого можно выразить полученные результаты в денежном эквиваленте либо в виде нематериального поощрения сотрудников.