5

Has anyone ever come across this problem? When you have a team of developers working on a project, how can you measure their contributions to said project? Is there a "formal" way of doing it? Number of commits? Number of bug fixes? Lines committed? Or maybe on a ticket basis?

I'm trying to think of a workflow where a group of developers can work seamlessly interchanging tasks and at the end of the month, getting paid for they contributions (or merit if you will).

I hope this question is not entirely out of place here, if it is, feel free to close it.

Deleteman
  • 283

2 Answers2

10

There's no way to accurately do this. For example, who contributes more: someone who commits 1000 lines of code in a month, or someone who spent most of his time thinking really hard, and then committing 100 lines of code that replace the 1000 lines of code? Or how about somebody that goofed off most of the month, then found those same 100 lines of code in a blog?

Who contributes more: someone who generated 100 image assets, or someone who spent weeks thinking about usability, and eventually checked in just a half dozen wireframes for a highly usable application?

In other words, how do you measure the amount of intangible work that most high performers do on a regular basis?

Bryan Oakley
  • 25,479
1

I don't think you can do this, at least in the sense you suggest. Bryan's answer, and several answers in the question linked by gnat discuss several intangible (perhaps we should call them "immeasurable" in this context) productive activities.

Specifically, this:

I'm trying to think of a workflow where a group of developers can work seamlessly interchanging tasks

seems like it will set up a perverse incentive for the developers not to focus their efforts where they're most productive, but instead to pretend to be interchangeable resource units to fit your measurement scheme.

One approach would be to simply ask everyone to estimate everyone else's work, and average it into some kind of rough productivity consensus. This might just lead to (some) people talking up the complexity of their bugs or features around the water cooler though.

A more manageable way would be to just use peer reviews once or twice a year, where team members give ratings for each others' relative productivity.

  • because this isn't done every week, or per fixed number of stories, it's harder to game
  • because everyone on the team is already equipped with a large squishy computer which is carefully calibrated to assess group relationships, you can use these as a proxy
    • everyone knows the value of favours done or received, even if they're hard to quantify
    • if team members review each others' code, they'll have a feeling for who is storing up the most technical debt for the future
    • this allows developers to play to their strengths (ignoring personal development and team-building in this context, this should be the most productive)
Community
  • 1
Useless
  • 12,823