Maintenance Project: How to evaluate team's performance?

Question

Year end is approaching, and on the company I'm working (and pretty much all other IT companies) it's time for year's performance evaluation.

Evaluating people is always a sensitive and insightful task, specially on IT where deliverables depending on numerous factors. It's hard to define what has been 'accomplished' and what's not (like what we have here).

During project's concepts / planning / development, there are objective skills to be evaluated. But what about the maintenance phase? In case there's no development at all but mainly investigations raised by end users (why X is like this and not like that?), how to evaluate our peers?

There are the basics, like 'communication' and 'investigation' skills... but as an IT company,

• How to keep our team improving their tech background on a project where no complex technical skills are required?
• How to compare them with people working on pure development projects?

Have you faced similar scenarios? Any thoughts / experiences to share?

Cheers

Answer 1

I work in a team where our main goal is to maintain large projects. I pay attention to numerous things connected with technical skills in my team:

• Tests - Is this person writing tests? How do they look? Does he tests before, or after? Does he write tests for bugs reported by client? We've decided that automated tests are crucial to sleep well and not to spend whole weeks in debug, so programmers should focus on writing tests.
• Helping others - Is this person helpful? Is he interested in others' tasks, problems, etc.? In team of 14 people there is no chance to have deep knowledge about every line of code, so we have to help each other when somebody works with code he is not so familiar with
• Not adding crap - When we modify the system or when we add new feature is this person doing it according to SOLID principles, does this code have tests? Are the methods short? Are the names readable?
• Not using copy/paste anti-pattern - Is this person using copy/paste method to add functionality or is he rearranging existing code into resuable units, avoiding duplication.
• Understanding the code - Does he understand what the code is responsible for before modifying it?
• Breaking builds - How often does he commit changes that cause the build to fail because of compilation errors or tests failures
• Attention to details - Does he pay attention to details like providing proper data in delivery e-mails (contact phone number, application version, changes despriction), adding comments to changeset, changing status in issue tracking system, etc.
• Refactoring - Is he changing the code leaving the code base a little bit cleaner than when he got there
• Automation and improvements
• How can I help you *attitude* - Is he delivering ideas what can be done better with the solution, what can be automated, how can we make some areas less error prone.

I'm sure there are more aspects I take under consideration, but those came to my mind right now.

Answer 2

The task you described looks like application management - solve users' queries, fix small bugs, create reports and change small parts of the code.

This requires developers but the work is not as fancy as "creating" new code... it is just maintenance.

If you have a system to record all requests from your users, you can start measuring the performance of your team - number of tickets solved, satisfaction level, re-opened requests, complains... - and use this to evaluate and motivate the team.

If your organization has room for new projects, try to get the maintenance team involved, even in smaller projects. Maintenance is not too challenging, and the standard developer profile usually does not fit in a maintenance team.

Answer 3

In addition to measuring the basics of "it's only maintenance", how about encouraging those who go above and beyond and help the company make money?

So for example a typical change request might be "we are going to add a new color widget to our product line and the color is vermillion but the input box on the form only takes 9 characters". Programmer A might just expand the field and the database (if required) and be done with it - in other words do the minimum necessary to satisfy the specific requirement. Another programmer B might start doing the same thing and discover that the way the color change procedure was coded against the database it was not properly updating the online catalog so that website visitors were not seeing the new colors. He then comes to you and offer to fix that "oversight" while he is in the program making the first change and the firm sells more widgets as a result.