10

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

  • Can you clarify what "no technical skills are required at all" means? – Jesse Dec 12 '11 at 22:46
  • I used a strong phrase to emphasize that there's nothing being built, but only maintained. Still, basic coding read skills are required. I'll fix it. Thanks for catching this. – Tiago Cardoso Dec 13 '11 at 2:50
  • 1
    You said there's no development at all but mainly investigations raised by end users. To me, that's indiciative of a much larger problem. Your developers should be developing, which might mean new features, bug fixes, writing new unit tests, or refactoring difficult code. The reasons for decisions should be captured already. – Thomas Owens Dec 13 '11 at 12:13
  • I do agree with you, @ThomasOwens... unfortunately, however, on maintenance projects we eventually have devs allocated for supporting instead of developing tasks. – Tiago Cardoso Dec 13 '11 at 12:59
11

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.

  • Hello @Piotr, valuable items mentioned, thanks! Although some of them still fits into projects where there's any kind of development, the "attitude items" still counts a lot. – Tiago Cardoso Dec 15 '11 at 10:33
  • @Piotr, I've always liked the idea of measuring; at least in part; how well someone demonstrates alignment to key tenets. On the down side, I've not seen too many managers that dig deep enough to measure most of these. – JoeGeeky Dec 18 '11 at 10:22
  • I believe your answer fits most of the possible ways to evaluate our supporting peers; for this reason, that's the chosen one. Thanks again, @Piotr! – Tiago Cardoso Dec 23 '11 at 10:37
1

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.

  • Thanks for your inputs, Morts. The scenario you put here is pretty much what we have around at the moment, and these suggested metrics sounds like a good point to start up, although it could only be useful to compare with other peers doing the same job. Thanks for sharing your experience! – Tiago Cardoso Dec 19 '11 at 18:28
1

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.

  • Hello Jonny, welcome to PMSE and thanks for your insight! I believe that offer room for growing (and see who really has usage of it) is a great way to evaluate peers (since it's far better to have a proactive member near than a lazy one). Thanks! – Tiago Cardoso Dec 21 '11 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.