Do you like people? More specifically do you like meeting clients? What do I mean?
And why the developer SHOULD be doing these meetings, not someone else.
Recently I sat with a number of senior managers and directors for a particular group. Not one of them has any interest in what happens deep under the hood when we are talking software. They are interested in making their work easier and more accurate. The session is part criticism and issues, not just positive feedback.
I conduct the meeting in a simple way. A few coloured pens, a hard back plain A4 notebook and a question. “Is it ok if I sit and listen to your questions in turn, make notes and then work out some answers with you?”
Some folks take longer than others to voice their specific issues but everything is written down and I take care to ensure that everyone is able to see what I note and how I *understand them. Repetition is common; I request clarification until I’m sure. About halfway through, the main issues that people have wanted to get off their chest are written down. Everything from here on is refinement.
I take a look at the points and begin with the ones that seem the most pressing, based on the way they are expressed and how important the issue is in the wider context of what they are doing. Then start working out possibilities.
This is the fun bit. Sometimes it’s easy to think users don’t know what they want; often this is partway true. However, this is a limited view. The reality is, given the opportunity, users have a damned fine idea of what they want – they often don’t quite realise it yet.
How does this change? They become aware of possibilities through daily use. Before you had Microsoft Word, did you know you would want auto save, spelling correction or even mail merge?
Before you had GPS in a car, did you know you might need to save favourite places? Search by postcode OR part address? Auto traffic alerts?
Why not? You’d not had a reason to consider the possibility.
Every feature in software has the potential to generate dozens of requirements, new things that people realise are important.
A great requirements meeting is not passive. You don’t sit there with a “customer is right” attitude. You don’t send out a verbal or written survey and hope for results.
You have to get in there and communicate. Encourage their debate and criticism, hell, if they are passionate enough to be somewhat hostile, it can be even better (said with intense caution!). Why? Because they care enough about the needs the software is supposed to meet to gift you with their time, attention and emotion on the subject.
The response to intense criticism should have an attitude of “make me understand and here are some possibilities”.
Ignore how you are going to do it under the hood, forget limitations of technology-the client doesn’t care ultimately about this part-they have **expectations and it’s your job to figure out how to manage AND meet those expectations. Often these are out of reach or possibly on the surface of it, unreasonable. They didn’t think that was the case when they formed them. From their perspective, it’s obvious and natural that feature X should happen “like this” or “look like that”.
My own experience taught me that clients, who are not technical but know their world well, may actually translate a paper based process into a literal screen version of that paper. This isn’t wrong but it can be a weak metaphor and metaphors are the real translation tool for producing real world work from a computer.
When clients discuss their needs, they are translating things that matter in their day to day work. A good developer translates the entire context of their work into something that gives the client this leverage. To give this leverage, it is rarely good enough to simply provide a computer equivalent of what they would otherwise hand write.
A case in point: There is a specific type of reading that is required very regularly, for multiple individuals. The original client request was for a blank sheet-a template-of the form that could be printed and filled in or written on when back at the computer. The form was a periodic set of values per person for a day.
On examination, I gave him the following story: “What if you staff can walk into a room with ANY suitable phone, tap it and see the person in front of them on the phone. From this point on, every single tap could be a reading being recorded. The process takes no longer than the physical act of getting the correct reading and writing it down; it may even be quicker as writing by hand takes a minute. Then the phone is put away, forgotten, whilst the real work is being done. The results end up directly in the persons files from which reports and forms can be generated.”
When the notion was laid out, the client realised I understood the work they were doing and why. I understood his world and had taken the trouble to look beyond the surface impression of the stated need.
This idea was far more welcome than the original paper template idea. The idea uses no more technology than most staff are used to-a mobile phone or indeed for many, a tablet. In addition, many people understand the use of a sat nav, so a phone knowing where it is in a building is a natural leap.
Metaphor is all that a client has when handling a computer. Get this wrong and your software is sunk. We click, swiped, pinch & shrink; open/close and many others. We don’t “0101101”.
Why does anyone bring a computer into the equation? Because they want leverage over their work; they want to it faster, have it be more accurate, more secure, more consistent and far more convenient thus giving them more time to do their real work.
It would be easy for me to get distracted by the programming specifics only; however, I truly believe a really good developer is literate, articulate and keen on understanding their client. They may well engage 50% of their attention to the specifics of their toolkits – frameworks, methodologies, platforms, but the other 50% is on domain expertise of their clientele. If you write software for doctors, you should know common doctor terminology, processes and concerns; understand their job-stopping short of actually being able to do it – this is the ideal of course.
*How you understand something, deep down, defines everything you can reason about it. If you get a subject by rules alone then everything you think of is bounded by the rules not by the principle that underlies those rules. If you understand client need X in a literal sense, you may be limited your solutions deeply to this understand. If, you understand the drive and context for need X you may find a much richer structure upon which to base your new solutions. You job is open up these possibilities, only after understanding the requirements properly.
** Managing expectations is a whole skill in its own right. This is down to how you sold the product in the first place – if the sun, moon and stars were promised, you have a long way to go back tracking in later meetings. On the other hand, if you sold your product on a fairly limited premise then trained your clients well and were consistently receptive when they need help, you shouldn’t get wild expectations-most of the time.