*Изображение заголовка от Shen Comix
Производительность разработчиков — это способность разработчиков создавать высококачественное программное обеспечение, которое хорошо работает и легко поддерживается с минимальными затратами времени. После пандемии COVID-19 и массового перехода на домашние офисы компании стали проявлять повышенный интерес к способам повышения продуктивности разработчиков, в том числе к тому, как помочь разработчикам работать в потоке и не дать им перегореть.
К сожалению, вместо того, чтобы измерять производительность разработчиков, многие компании внедряют практику микроменеджмента, снижающую производительность труда, командную работу, инновации и увеличивающую текучесть кадров. Давайте посмотрим, почему производительность разработчиков так сложно измерить, какие метрики эффективны и почему.
Оглавление
Что не так с измерением производительности разработчиков?
- Отработанные часы
- Строки кода
- Исправленные ошибки, выполненные задачи или реализованные функции
- Компьютерная активность
Как измерить и максимизировать продуктивность разработчиков?
- 1. Измерять качественные показатели
- 2. Вести учет количественных показателей
- 3. Сверяйте с планом профессионального развития
- 4. Оценить свой вклад в достижение бизнес-целей
- 5. Доверяйте интуиции своего менеджера
Продуктивность разработчиков начинается здесь
Что не так с измерением продуктивности разработчиков?
Чтобы максимизировать прибыль, компании стремятся оценить производительность разработчиков путем введения количественных показателей эффективности, таких как строки кода, часы, тикеты, количество дефектов или точность оценки. Давайте разберемся, почему эти метрики неэффективны.
Отработанные часы
Количество отработанных часов — наиболее часто используемая метрика производительности. Хотя она важна для планирования проекта, особенно в сочетании с оценкой, она все же не отражает, насколько продуктивной была ваша команда разработчиков. Как говорится, быть занятым — не то же самое, что быть продуктивным, а рабочее время — это как раз про «занятое время».
Если бы эта метрика была эффективной, то мы могли бы выполнить 125% работы, если бы работали 10 часов вместо 8 ежедневно — это просто математика. Но в реальности наша производительность падает после определенного порога, что доказано исследованиями. Эта связь между временем и производительностью также известна в экономике как закон убывающей предельной отдачи: после некоторого оптимального уровня производства добавление дополнительного фактора производства (количества рабочих часов) вызывает снижение производительности и уменьшение отдачи от производства.
Итак, если ваша команда работает по стандартной 40-часовой рабочей неделе и вам нужно видеть, как эти часы распределяются между видами деятельности, отслеживание рабочих часов и анализ того, как они распределяются между задачами, эффективны для планирования рабочей нагрузки и управления командой. Но чрезмерное внимание к деталям и мелким делам не дает возможности ни повысить производительность, ни улучшить моральный дух команды.
Строки кода
Некоторые компании считают, что строки кода — это прямой продукт работы разработчика: каждая строка решает проблему и по определению лучше, чем отсутствие кода вообще, поэтому она должна быть отличной метрикой производительности разработчика. Но на самом деле это такая же ловушка мышления, как измерение продуктивности врача по количеству принятых им пациентов.
Почему использование строк кода в качестве метрики продуктивности — плохая идея:
- Это противоречит тому, чем является программирование: сокращение длины и сложности кода.
- Он не учитывает опыт разработчиков. Опытные разработчики часто используют меньше строк кода, чем их менее опытные коллеги, при одинаковой функциональности.
- Он не учитывает различия в языках. Один и тот же код может быть написан дюжиной разных способов, и каждый из них занимает разное количество строк кода.
- С этой метрикой легко играть. Разработчики смогут получать месячные зарплаты за несколько дней, написав тонны ненужного кода и не создав никакой ценности для бизнеса.
- Это саботирует процесс проверки кода, делая его более трудоемким.
- Больше строк кода ≠ более производительное решение. Короткий код может работать быстрее.
- Тонны кода трудно поддерживать. Ненужный код трудно читать и поддерживать. Более того, каждая новая строка кода увеличивает вероятность появления новых ошибок.
- Иногда удаление кода является наиболее продуктивным решением.
- Скопированный и вставленный код приводит к огромному техническому долгу, плохому дизайну и более высокой вероятности ошибок.
Самое главное, измерение продуктивности разработчиков с помощью строк кода влияет на производительность и моральное состояние разработчиков и потребует времени и усилий для расширения их кода ненужной сложностью.
Исправленные ошибки, выполненные задачи или реализованные функции
Такие показатели продуктивности, как исправленные ошибки, выполненные задачи и отгруженные функции, по сути, так же неэффективны, как и строки кода, но их сложнее использовать в игре.
Если производительность разработчиков измеряется количеством исправленных ошибок, то они могут писать намеренно глючные программы. Как в этом комиксе Скотта Адамса:
Если их цель — выпустить как можно больше функций, они могут делать это, используя низкокачественный код, накапливая технический долг и делая продукт трудно сопровождаемым. Если разработчикам нужно завершить как можно больше задач, они возьмутся за самые простые или самые переоцененные задачи. Вы уловили идею.
Компьютерная активность
С массовым переходом на удаленную работу многие компании стали беспокоиться о том, что не могут контролировать свои команды. Они подозревают, что разработчики могут халтурить, подделывать рабочие часы в JIRA или в программе учета рабочего времени или отсутствовать в рабочее время. Это породило массовое распространение программного обеспечения для мониторинга сотрудников, которое фиксирует активность пользователей в приложениях и инструментах, нажатие клавиш, электронную почту, мессенджеры и многое другое. На основе этих данных программное обеспечение рассчитывает показатели продуктивности и выделяет лучших исполнителей.
Рейтинги под диаграммами показывают самых продуктивных, непродуктивных и эффективных сотрудников на основе уровня их активности и использования приложений
Самая большая проблема с программным обеспечением для отслеживания активности заключается в том, что ни одна из отслеживаемых метрик не имеет отношения к производительности разработчика, эффективности бизнеса или его клиентов. Стали бы вы применять дисциплинарные меры к разработчику с высокими показателями, который недостаточно часто использует мышь или клавиатуру? Стали бы вы повышать в должности разработчика, который проводит много времени, набирая текст в Visual Studio, даже если с ним трудно работать? Это бессмысленно, верно?
Как измерить и максимизировать продуктивность разработчика?
1. Измеряйте качественные показатели
Если вы спросите Мартина Фаулера, дядю Боба Мартина, Стива МакКоннелла, Джоэла Спольски или любого другого светила разработки, никто из них не сможет выделить самую важную метрику производительности разработчика или разработать систему измерения производительности, основанную только на количественных метриках. Еще в 2003 году Мартин Фаулер признал, что измерить производительность разработчиков практически невозможно, а ложные показатели только ухудшают ситуацию. В 2020 году Стив Макконнелл в своих выступлениях по-прежнему называет производительность разработчиков одной из самых труднодостижимых целей.
Большинство важных факторов, способствующих продуктивности разработчиков, не поддаются измерению. К ним относятся удовлетворенность работой, обучение и развитие, вовлеченность сотрудников, цели и ожидания, инструменты и оборудование, моральный дух и культура компании. Чтобы измерить их, регулярно проводите опросы сотрудников.
Вопросы для рассмотрения:
- Составьте анкету, в которой разработчики смогут оценить свою производительность, удовлетворенность работой, цели и ожидания, инструменты и оборудование, моральный дух и другие параметры.
- Поделитесь этим списком с руководителем группы и пройдитесь по списку сами, если вы руководитель, чтобы оценить членов своей команды.
- Сравните результаты, чтобы убедиться, что вы и ваша команда разработчиков находитесь на одной волне. Уделите пристальное внимание оценкам, которые не совпадают.
2. Ведите учет количественных показателей
Отслеживание того, как разработчики тратят свое время, доказано для максимизации ресурсов и повышения эффективности работы разработчиков. Еще одна веская причина вести учет задач и затраченного времени — документировать плохую работу, чтобы вы могли подкрепить свое решение в случае необходимости увольнения. Чтобы сделать эти данные еще более убедительными, вы можете отсортировать их по типам деятельности в вашей системе учета рабочего времени, чтобы проанализировать работу разработчиков над схожими задачами.
Отчет «Пользовательские поля» в actiTIME, где вы можете просмотреть временные затраты по нескольким пользовательским типам задач.
Если вы заметили какие-либо аномалии, просмотрите комментарии к заданию и записи о затратах времени или попросите разработчика выяснить причины. Были ли какие-либо непредвиденные обстоятельства, например, недооценка сложности задачи или смена приоритетов? Если нет, то просмотрите детали задания, чтобы проанализировать объем выполненной работы, и обсудите причины низкого качества работы с разработчиком.
Вопросы для обсуждения:
- Как часто они пропускали сроки? Почему?
- Насколько точны их оценки задач?
- Сколько времени им обычно требуется для завершения определенных типов задач? Как его можно улучшить?
- Ведут ли они ежедневный учет рабочего времени? Если нет, объясните, как важно это делать.
- Как часто они работали сверхурочно? Почему?
- Как часто они звонили по болезни или просили о других видах отсутствия? Были ли они разумными?
- Можете ли вы выявить закономерность?
3. Сверьтесь с планом профессионального развития
Одной из лучших практик управления командами разработчиков является составление менеджерами планов профессионального развития для каждого из членов команды.
План профессионального развития документирует цели, навыки и компетенции, необходимые для успешного развития карьеры и удовлетворения потребностей бизнеса. Он предоставляет менеджерам метрики для оценки эффективности работы разработчиков и позволяет им получить четкое представление о навыках и технологиях, которыми они должны овладеть, а также о целях, которых они должны достичь в своей работе. Проверяйте этот план каждые несколько месяцев и проводите встречи один на один для анализа и обсуждения результатов работы разработчиков.
Вопросы для обсуждения:
- Как часто разработчик использовал свои навыки? Какие компетенции они применяли чаще всего?
- Как их навыки повлияли на рабочие цели, рабочий процесс и успех проекта?
- С какими трудностями они столкнулись? Как эти трудности повлияли на их работу и рабочий процесс?
- Что улучшилось за период оценки?
- Если разработчик не достиг личных и рабочих целей, следует ли вам предложить ему дополнительное обучение?
- Что необходимо улучшить в работе отдельного разработчика?
4. Оцените их вклад в достижение бизнес-целей
План профессионального развития должен включать не только личные карьерные цели, но и согласовываться с бизнес-целями. Чтобы оценить работу разработчиков с точки зрения вклада в бизнес, пройдитесь по следующему списку вопросов.
Вопросы для рассмотрения:
- Каких успехов добился бизнес, и какой вклад в них внес данный разработчик? Правильно ли они использовали свои ключевые навыки?
- Достигли ли они желаемых метрик и показателей или даже превзошли их?
- Был ли результат работы настолько выдающимся, что стоит выделить этого разработчика?
- Сыграл ли этот разработчик ключевую роль в достижении целей команды?
5. Доверяйте интуиции своего менеджера
Менеджеры так тесно сотрудничают со своими командами, что благодаря опыту, обучению и доверию вырабатывают правильные суждения. Поэтому вы можете интуитивно знать, кто является хорошим, продуктивным разработчиком, кто — средним, а кому нужно подтянуться или уйти. Примите эту субъективность. Вы должны быть в состоянии определить, кто в вашей команде суперзвезда, а кому нужно совершенствоваться.
Продуктивность разработчиков начинается здесь
Продуктивное использование времени — самый важный компонент производительности труда разработчиков и успешной реализации проекта. Рассмотрите возможность внедрения системы учета рабочего времени, которая может выполнять обе функции — служить инструментом управления проектом и регистрировать результаты работы разработчиков.
Например, actiTIME позволяет менеджерам распределять рабочую нагрузку между членами команды, уточнять детали задач и просматривать затраты времени и денег по клиентам и проектам. Заставьте членов вашей команды регистрировать свое время по видам деятельности, изменять статус задачи, добавлять заметки в журнал учета времени и многое другое с помощью онлайн-табеля учета времени, расширения браузера или мобильного приложения. actiTIME поддерживает более 2000 интеграций, включая JIRA, GitHub, JitLab и Trello. Попробуйте actiTIME бесплатно с 30-дневной пробной версией (кредитная карта не требуется).
