Developer metrics are hard. We all know this. Development is part science, part logic, and part creativity. As such, it is difficult to measure how well your developers are doing their jobs. Personally, on my teams I tend to manage by results. If the releases are on time and of sufficient quality, I'm a pretty happy guy. How do I measure quality, you ask? Well I'm about to show you how I've done it on teams I'm leading.
I'm pretty big on developers caring about doing some of their own Q/A. Even when you have a testing team available, it's no excuse for writing shoddy code and I think developers should be in the habit of writing bullet proof code, regardless of having a testing team or not, because it saves time on the Q/A side, saves developer time by not having to go back and review old code, and helps the developer think about usability and how to keep the application from crashing or not making the interface intuitive enough for the user to use without causing errors to be caught. With this in mind, when the senior developers or Q/A team do their first review, they use the same form that shows up from users after the release. By comparing the results of the Q/A and developer review to the release into the wild I can determine whether the internal review process needs improvement.
To achieve this, I break all of the functionality in the release into logical blocks. An example of this in a financial application would be Invoice Management, Payment Facility, Reports, etc. Each section gets their own heading in my master sheet where everyone collects and interprets the bug reports. Bug reports have "point values" which are as follows:
Critical 15 points: Pretty rare really, a 15 pointer means that a bug crashes the application. Prevents critical work from being done, and has no workaround. This type of bug is a "show stopper". When this type of bug gets into the wild, you need to have some meetings and accountability to figure out how it got out and how to make sure it never happens again.
Severe 7 points: Fairly uncommon in a good shop. This type of bug doesn't crash the application but can corrupt data or make important features unusable. The only thing keeping this from being critical is that a work around is available, but it is time consuming or cumbersome.
Moderate 3 points: Application runs, with minor errors. This is usually where validation checks are missing or some 'nice to have' features are unavailable. The critical portions of the application are stable and errors do not occur if the software is being "used properly".
Minor 1 point: Clunky usability, nice to have features not quite working the way the customer desires, graphical/display issues that don't greatly impact the users or only in a small percentage of scenarios.
The overall quality of the release is determined by the total number of points that are assigned to the incoming bug reports. In general I like to weight the quality target by the complexity and size of the area in question, but my base line is something like this:
Meets Standards- 24 to 30 points
Exceeds Standards- 12 to 23 points
Outstanding- < 12 points
Obviously these can be moved around however it fits your shop, the skill of the developer, and the size/complexity of the module. I should also note that a critical error merits an automatic "failure" in the review book even if it's the only bug in the whole module. Continual review is key to quality software.