Производительность ... существует бесконечное количество способов ее измерить в компании, в команде или даже на личном уровне. Но по-прежнему кажется, что есть только пара способов, которыми компании делают это. Главный способ, как я испытал, - это использовать статистику, которую они получают от используемого ими программного обеспечения для отслеживания ошибок, например, сколько задач каждый разработчик закрывает в один момент времени и сколько было повторно открыто.
Лично я твердо верю, что этот тип измерения производительности говорит лишь очень небольшую часть того, что все происходит.
Но не поймите меня неправильно. Не помешает знать такую статистику. Это может указывать на разработчика, который, возможно, не очень хорошо знает определенную часть программного обеспечения, конкретный разработчик переживает что-то, из-за чего он не может сосредоточиться, или что разработчик слишком много делает и не может потратить достаточно время на каждую задачу, чтобы уделить ей все необходимое внимание. Опять же, эта статистика показывает только симптом того, что происходит. Чтобы выяснить, в чем заключается проблема, потребуется гораздо больше, чем просто нажать кнопку, чтобы открыть отчет и просмотреть его перед утренним статусным совещанием.
Я поделюсь своим опытом работы с этим в довольно большой компании, которая измеряла мою продуктивность точно так же, как указано выше - глядя на статистику моих отчетов об ошибках.
Продукт, над которым я работал, был серверным компонентом настольного приложения, и с некоторыми его частями я был не знаком. Я даже не очень разбирался в самом бизнесе, и мне приходилось учиться на ходу.
Проблема и, честно говоря, основная причина, по которой я был исключен из проекта, заключалась в том, что у меня был самый высокий процент повторно открываемых заявок, чем у других разработчиков. Вот и все. Из всего того, что мне сказали, на это не смотрели ничего другого. Никакой документации, которую я добавил, чтобы повысить продуктивность всей команды. Ни одна из нескольких новых функций, которые я добавил, не приводила к возникновению очень немногих проблем. И они определенно не заметят никакой поддержки, которую я оказал другим людям в команде. Вы могли подумать, что по крайней мере часть этого была объяснена, но, по-видимому, нет: все, что они упомянули, это один факт о возобновленном подсчете билетов.
Черт, единственная хорошая обратная связь, которую я получил, - это то, что им понравилось, что я продолжал просить больше поработать, когда меня не было. Честно говоря, я не думаю, что они даже знали о других моих вкладах.
Из-за этого - они явно не признают те другие взносы, которые, как я считаю, определенно перевешивают проблему повторного подсчета заявок - я даже не хотел бы работать на них снова, если бы они предложили.
Опять же, плохо быть тем, у кого было больше всего открываемых билетов. Это определенно заставляет меня чувствовать себя ужасным разработчиком. Однако дело не только в этом. Что послужило причиной этого? Если копнуть немного глубже, когда я был там, я считаю, что в значительной степени это было связано с тем, что у меня возникли проблемы, в которых я не знал ни одной области бизнеса. Конечно, при отправке исправления что-то было упущено, и мне пришлось вернуться и разобраться с этим сценарием. Имейте в виду, это после того, как я уже написал модульные тесты для того, что у меня было и прохождение проверки кода.
Мне кажется, что хуже всего то, что они не сказали ничего из этого, пока я был там. Никакой обратной связи о том, как я на самом деле поживаю. Я даже однажды спросил, есть ли у них отзывы, и они не упомянули ничего, что я мог бы улучшить. Я услышал это только после того, как уже не участвовал в проекте. Я уверен, что значительную часть этого можно было бы улучшить, если бы я знал об этом, пока был там, и у меня было время для улучшения.
Я не хочу, чтобы вышесказанное было тирадой о том, каким был клиент. В целом, мне понравилось работать в команде, и я многому у нее научился. Хотя я определенно мог бы сделать лучше, чтобы проверить свои исправления, прежде чем проверять их систему управления версиями. В основном, я надеюсь, что это в основном помогает проиллюстрировать, что требуется больше, чем просто просмотр метрик из программного обеспечения для отслеживания ошибок, которое вы, возможно, используете. Статистика помогает, но, как правило, дело не только в этом.