Developer - Performance Goals/ KPI

Pho3nix

Pho3nix

The Legend
Joined
Jul 31, 2009
Messages
32,826
Reaction score
3,033
Location
On the toilet
Hi all,

Just curious as to what some of the "normal" deliverable or measurable criteria are for a Developer in relation to their KPI's.
Yes, I know getting your work out the door and such are the majority of what they are looking at but anything over an above that?
Training isn't included for the purposes of this :p

Need to draw up some of my short-term items and I'm a little stumped. Not entirely sure how you'd measure some of what I do but yeah :\
 
- Low return on tasks (tasks getting sent back from QA)
- Delivery of high/critical tasks
 
Devs are easy - in our KPI's we have:
  • Task throughput / delivery (we use Jira, so straight forward to track tasks and turnaround time and how many times reopened)
  • Error rate (very visible via our APM tool, especially after deployment)
  • We have a number of team targets (i.e. uptime, speed, end user time) which are measured via APM as well as customer satisfaction (tickets due to tech issues)
  • We also have some company-wide KPIs (financial targets etc - but some do not apply to junior staff)
  • You should have some "key projects" on your KPIs - i.e. projects which affect the bottom line of your business
  • Unlike others, we don't consider "training" a KPI - it is a KPA (similar to having documentation etc) - unless of course you want to measure pass-rate as a KPI
 
I'm also curious - are you doing this merely to keep a track on yourself, or have you been tasked with developing some sort of incentives program for a set of developers/software company?
 
KingMikel said:
- Low return on tasks (tasks getting sent back from QA)
- Delivery of high/critical tasks
Click to expand...

Thanks. Will look into how the best way to do this will be.

MagicDude4Eva said:
Devs are easy - in our KPI's we have:
  • Task throughput / delivery (we use Jira, so straight forward to track tasks and turnaround time and how many times reopened)
  • Error rate (very visible via our APM tool, especially after deployment)
  • We have a number of team targets (i.e. uptime, speed, end user time) which are measured via APM as well as customer satisfaction (tickets due to tech issues)
  • We also have some company-wide KPIs (financial targets etc - but some do not apply to junior staff)
  • You should have some "key projects" on your KPIs - i.e. projects which affect the bottom line of your business
  • Unlike others, we don't consider "training" a KPI - it is a KPA (similar to having documentation etc) - unless of course you want to measure pass-rate as a KPI
Click to expand...

Thanks :D We use Jira as well but as it's a new management tool of sorts. Don't think it would be an adequate measure of how your Task Delivery would be. Will speak to the big bosses though.
Like the Team Targets regarding Uptime :)
Mainly working on 1 project but currently it hasn't been quantified into real value.
 
ZCFOutkast said:
I'm also curious - are you doing this merely to keep a track on yourself, or have you been tasked with developing some sort of incentives program for a set of developers/software company?
Click to expand...

A mix of both. A developer myself; so this is for me and the team I am with currently. Not sure what you would measure Jnr's on though :\
 
Here's a somewhat "difficult" to quantify KPI that we have: Accuracy of estimations
 
Pho3nix said:
Thanks. Will look into how the best way to do this will be.



Thanks :D We use Jira as well but as it's a new management tool of sorts. Don't think it would be an adequate measure of how your Task Delivery would be. Will speak to the big bosses though.
Like the Team Targets regarding Uptime :)
Mainly working on 1 project but currently it hasn't been quantified into real value.
Click to expand...

If Jira is used properly, hopefully they will have projects, component leads, versions and with tasks a configuration for effort. Only discipline part of a developer is to hit that "Start work" button to measure or update time spent when closing out a task. Once you start using APM (such as New Relic) and Jira, it will become very impressive to measure uptime, error-rate etc and able to report on XX changes per release/cycle etc.
 
Lines of Code

/sarcasm ;)

But seriously, I use the number of times that a manager brings this up as a good idea as an inversely related KPI for said manager. (Fortunately this has never come up where I currently work).
 
We also count the number of post live faults. We have a guideline that only post lives faults within 2 weeks of release will be counted.
We also take into account the number of faults which get reopened during testing. I.e. UAT raise a fault, dev fixes it, but UAT find the fault not resolved when retesting.
 
cguy said:
Lines of Code

/sarcasm ;)

But seriously, I use the number of times that a manager brings this up as a good idea as an inversely related KPI for said manager. (Fortunately this has never come up where I currently work).
Click to expand...

Interestingly enough, my manager gave us his performance agreement to give us idea's as to the best way we should come up with our own measures.
My performance wasn't mentioned although Up time of the system was which I suppose is directly proportional to me doing my job properly :p
 
cguy said:
Lines of Code

/sarcasm ;)

But seriously, I use the number of times that a manager brings this up as a good idea as an inversely related KPI for said manager. (Fortunately this has never come up where I currently work).
Click to expand...

If you really want to take productivity to zero, then you should introduce what a "very clever" executive at one of my previous financial companies introduced: Get points for finding bugs in your peers code - depending on the severity of the bug you got 1, 5 or 10 points and you could offset your points by finding bugs in other people's code. So naturally, everyone spent all their time finding bugs and no-one wrote code
 
I saw one guy's KPI once, all it had on there was "Learn Excel"

... :(
 
"Developers are the only group where they are asked to do something which has never been done before, and tell someone else how long it will take before they even know what actually needs to be done"

Read that somewhere and it stuck in my head.
 
EtienneK said:
"Unit test coverage %" should be one of them.
Click to expand...


Unit test coverage % is the biggest farce. Just because the code is covered by a test doesn't mean that the test is any good. But they see "code is 90% covered" and they feel all comfortable.

Writing GOOD tests should definitely be a requirement though.
 
Individual
Function point count per staff month

Defect to fpc ratio split by severity

Defect diagnosis and resolution turn around time

Team
Month 1 errors in production
 
It's always interesting seeing the ways people try to come up with to measure something that, at least for now, cannot be reliably, repeatably measured.

MagicDude4Eva said:
and no-one wrote code
Click to expand...
That's one way to drastically reduce the number of bugs.
 
Hamster said:
Unit test coverage % is the biggest farce. Just because the code is covered by a test doesn't mean that the test is any good. But they see "code is 90% covered" and they feel all comfortable.

Writing GOOD tests should definitely be a requirement though.
Click to expand...

I agree. But what's an objective way of measuring "good" tests? The only way of seeing this is if you wrote a test for something and that something breaks in production. In other words, you can only measure this when something breaks.

Test coverage % is an okay measurement, since having some tests (even though they aren't 100% correct) are better than having no tests.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X