With a small development team, how do you organize second-level support?

Question

Say, you have a team of 5 developers and your inhouse customers demand a reasonable support availability of say 5 days a week, 9am-6pm.

I can imagine the following scenarios:

• the customers approach the same guy, every time. Downside: single point of failure, if the guy is unavailable.
• each developer is assigned one week of support duty. Downside: how to you distribute the work evenly in times of planned (vacation) and unplanned (sickness) unavailability?
• each developer is assigned one day of support duty. Downside: similar to above, but not as bad.
• a randomly picked developer handles the support request. Downside: maybe not fair, see above.

What is your experience?

Answer 1

In your scenario, the whole team should handle support tickets until they are all replied at least twice a day. If one has finished before the others, he helps the others with their ticket.

The process should be triggered:

• One time just after the stand up meeting (if you have one).

• A second time in the afternoon.

Don't specify any rule. Let the team organize itself.

If it doesn't work, change something.

Answer 2

I would guess it's going to depend on your product, but there is a lot to be said for having the person responsible for the code in question do the support. It allows them to learn from their mistakes and see how the customers are using what they wrote.

If support is eating up a lot of time you may want to consider hiring on someone to handle that and filter out anything that does not actually require a programmer. This would generally be someone at a lower pay grade and would allow your coders to spend more time on what you are really paying them for - progamming. (also, I know a lot of programmers that don't have interpersonal skills on par with their programming skills so this could be better for the customers as well)

Answer 3

Just make sure you capture the questions and answers and create a FAQ or some other sort of resource. Subsequent queries can then first be directed toward the existing entry. You also need to track areas that generate a lot of calls as those may need rework. It's a pain, but eventually it pays off more than constantly answering the same questions over and over.

Answer 4

Adding to Pierre 303 response

• The tickets should be assigned on priority based on the tasks at hand already on the developers table
• While it might be a good idea to let every one handle all types of tickets.
• It would still be best decided on the priority of the request and the relative exposure/experience proficiency areas of the developers.
• Do you already use Trac or somethig similar?