Love your Support Staff

Us poor souls on your Support Staff are just another kind of end-user. Our Gui is made up of logs, reports and audits. We need love too! We need the same kind of attention to our needs as you give to your end-user.

So I have an idea.

Every time I’ve seen QA raise a bug with a dev team, the dev team has requested step-by-step instructions on how the bug can be replicated. This is true of every project I’ve seen where a separate QA team have been involved.

Stop it!

By all means, QA should record how they did it, but keep it secret. Get your other end-users in first. If Support can’t diagnose what QA did, they won’t be able to work out what your end-end-user did either. If Support need to ask QA how they did it, then there might be some information which needs logging – or maybe even auditing.

It really helps if QA consists of the most cunning, mean, dishonourable scoundrels available – or at least, good method actors who can think like them. If QA try to cause problems, to get hold of free money / goods / services / time off / promotion / someone else in trouble, it helps to differentiate the things which can be communicated, from the things which need to be logged, from the things which need to be audited. It’s not just because the end-users are also scoundrels. They might be the sweetest people in the world, but mistakes happen.

You can guarantee that in a big enough system, if someone can steal sheep without anyone noticing, the sheep will go missing without anyone noticing too. And it’s no good asking us why the software thinks there should be two more sheep in the field than there actually are if you don’t keep records, five sheep died, three were legally bought, one was stolen, there’s a six foot hole in your fence and you’ve let in the neighbour’s goat.

(My current client is pretty good at counting its metaphoric sheep. Goats next iteration.)

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Love your Support Staff

  1. anonymous says:

    It really helps if QA consists of the most cunning, mean, dishonourable scoundrels available

    Most of the good QA people are very much the opposite, with the possible exception of how you define cunning.

    QA plays a different role than users – QA sees the whole system. So if I was, say, a saleman at a unnamed UK high street electronics retailer, I wouldn’t know or care if the system actually recorded the sale properly. And if I was in their back office, I wouldn’t know if there were missing sales or other transactions. This type of information can be discovered at audit time – every month or quarter) but by then the damage is done. Any business worth it’s share price has plenty of risk management procedures around loss prevention – whether its employee, customer or supplier. Making them a part of your user stories is the sign of a team that knows the domain.

    QA plays a vital role in that they look at the entire ecosystem. They are one of the few roles on a project team that do. You don’t need to be kharmically bankrupt to be good at QA.

    If what you were trying to say was that the software doesn’t operate in isolation from the business, and that the managers of a business can learn something about its busness, employees, customers, and suppliers from how the system is used, then, well, of course.

  2. sirenian says:

    What happened to the other half of my sentence – the bit which gave an alternative to kharmic bankruptcy? Or did the urge to respond kick in before you got that far?

    This type of information can be discovered at audit time

    Yes, if you’ve logged or stored the right kind of information. I believe it would help to involve the people who are going to use that information earlier on in the cycle – ie: before the poor Support staff try to diagnose a real problem using the information that someone else decided they would need.

    It’s not about the managers learning. It’s about writing software in collaboration with its end users. Support, in this context, are also end users.

    (Who are you, by the way?)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s