Skip to main content
Project Management

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

6
  • I disagree with "do it on the number of bugs fixed as a team, not raised". Put me on that team, and I will spend an hour each morning adding visible bugs that are easy to fix. Woo hoo - here comes my bonus! Commented Mar 30, 2012 at 4:10
  • I think this is a fallacy. It would be a pretty poor team and a very low team member that did this. For the most part people want to be professional. It is easy to say what you did, but I doubt you actually would do that. People generally liked to be though of as good at their job, and dislike to bring their team down. If team members did as you said, then there are much more issues with the team as a whole than individual performance. It would also not be hard to spot such an individual and much easier to remove them from the team. PM's do not just sit in an office looking at metrics. Commented Mar 30, 2012 at 5:22
  • 1
    The comment was tounge-in-cheek but it points to a flaw in the metric. A team that creates bugs and fixes them scores better than a team that gets it right the first time. Imagine a developer has spent five days working on a new feature. He's already surpassed his estimated time and just wants the feature finished. He can see a non-showstopping bug in this functionality. Does he spend the extra hour to fix the bug now? Or, does he mark the work as done, knowing it will be fixed some time in the future? If he knows that the latter option would help some score go up, then he'll leave the bug. Commented Mar 30, 2012 at 6:10
  • I don't disagree that such metrics as a performance review indicator is silly, this is why I specifically stated "as a team". I meant it in a pat-on-the-back sort of way rather than bonus linked etc. As my final comment suggested, KPI on peformance relating to bugs is never useful. I did get that you spoke toungue in cheek, but I guess we'd be surpised how many PMs out there would believe such a scenario not only possible but likely. I was a developer a long time, I would never have left a showstopper to go through the system knowingly - I would much rather go cap in hand to the PM. Commented Mar 30, 2012 at 6:36
  • @Wolf5370 - You mentioned a very great point. Buggy software isn't the same as a bug in hardware, like the chair in your example. Bugs in software can just be fixed. A bug is basically an unfinished feature. It's not like the entire project has to be scrapped and started over because of a bug, not like if it were a buggy circuit board design or a car alternator... Commented Apr 1, 2012 at 2:35