(and how your Client can Delight You)

Yesterday’s post reminded me just how much value I have begun to place in my working-relationship with our on-site client-liaison. She has a fiery temperament, is outspoken and very different from me, differences which I have come to appreciate. And let’s not forget, in an otherwise all-male office, she is a she and, sad but true, it really does help to have a little bit of a mix of the sexes.

I said yesterday that her feedback, really mostly positive (or maybe an occasional considered negative) was so appreciated that we feel valued. When I first started at the company, it was so small and one of the two owners would give us our payslip at the end of the month with a brief word or two of feedback – also highly appreciated – but now his time is so full, or something has changed, and this does not happen so much any more. I kind-of know that I am valued, hopefully even a key and respected team member, but hearing positive words or getting a positive email really are more important than I can ever have imagined. I mean, I’ve worked in a companies before where we have fun, and I’ve worked in companies where there is a lot of respect for each other… but this is the first company I have ever worked for where I might be told once a week or perhaps even once a day:

“You ROCK!!!!”

or

“Have I told you recently how much I LOVE what you are doing to the system?”

(or words to that effect).

So that’s the subtitle covered, here are some of the ways I think I have managed to provide positive and useful functionality to my client:

1. Listen and learn about how they use the system now, and how they want to be able to use it;
2. Try and understand the business. You are probably safe with the starters:
   ‘They want more customers’,
   ‘They want to make more money’…
   …and they want to do it all easily;
3. Test the code you write;
4. And have some fun too.

Actually, I think the key point is Testing.

When you test end-user changes to a system, you will be using it in the same or similar ways that the user will be too. If you get frustrated that once you get to a particular screen, the only option to get back to where you were is with the Back button (but now that screen is out-of-date and needs refreshing) then you can be certain that many of the users will be feeling that pain too. If you get frustrated that the tab-order of fields is out-of-sequence, some of your customers will be frustrated as well (even if most of them will continue to use the mouse to click between every single bloody field), and so on.

Of course, the list of things that you might think would be useful to you could be endless, and perhaps most importantly, may not have been thought possible by the client, or not have been worth asking for specifically.

To be honest, I’ve been surprised to speak to my colleagues and find out that many of them are not used to testing their own work very thoroughly at all. This comes a lot from their different backgrounds in programming – whereas I have spent a lot of time in live-support environments where much of the work was on the live database; it perversely makes testing rather difficult – but also makes you appropriately cautious about what you release and how. Also, I shouldn’t forget my initial programmer training where we were very-much expected to debug thoroughly before even thinking about passing the code on to a business-analyst to test – though that was all batch-stuff and there was no real ‘end-user’ as such.

Of course, in my time with this employer and client I have made some fairly dumb mistakes that did get as far as the client seeing them, but on the whole, I do believe that testing my work myself has substantially improved my understanding of the system and meant that overall my work is somewhat less likely to come with unknown side-effects.