Как измерить продуктивность разработчика

Проводя исследование для этого поста, я подумал о том, как друзья из некоторых компаний FAANG рассказывают о своей работе. Часто небрежно они описывают свой день как состоящий из работы по 3-4 часа, проверки рабочих билетов и отработки 40 часов полного рабочего дня. Хотя пандемия лишила их доступа к капсулам для сна и развлекательному баскетболу в кампусе, они не знают, что делать с оставшейся частью отведенных им рабочих часов. Все это стало слишком реалистичным, когда я наткнулся на сообщение на форуме Hacker News от января 2020 года. Умоляющий разработчик спросил коллег: Как я могу это остановить?»](https://news.ycombinator.com/item?id=21961560) Почти 1500 голосов «за» и чуть менее 1000 ответов — дилемма разработчиков, которая десятилетиями скрывалась от инженеров-менеджеров. превратилось для многих в лишение гражданских прав. Как вы измеряете продуктивность разработчиков и действительно ли мы видим ценность этих показателей?

Измерения входных и выходных данных: хорошие и плохие

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

:::Информация

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

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

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

Измерение продуктивности разработчиков: правильный способ

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

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

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

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

Измерение скорости и гибкости разработки

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

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

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

Третий принцип гибкости

Аджайл-манифест – это своего рода священный документ для разработчиков. В этом основатели повторяют свою миссию: «[b]создавать проекты вокруг целеустремленных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы».

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

Цель состоит в том, чтобы привить рабочую среду, которая бросает вызов и приносит индивидуализм, при этом являясь областями для роста и областями, которые позволяют создавать добавленную стоимость.

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