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

Лично я твердо верю, что этот тип измерения производительности говорит лишь очень небольшую часть того, что все происходит.

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

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

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

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

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

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

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

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

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