When I am asked by someone who has no knowledge of software development “so, what does a Business Analyst do?”, I normally explain that I am a point of contact linking “business people” with “technical people”, the "techies" to the "talkies". I then expand on the subject, depending on who I am speaking to. Of course, this is an oversimplification, but to say “internal consultant” or “facilitator” doesn’t quite demonstrate the uniqueness of what we do. Comprehensively answering this question could itself be the subject of another blog post so for now, I want to focus on how relevant a high-level answer this is.
There is the classic example of a software engineer who is on his way home from work when his wife calls. “Please can you pop into the supermarket and buy a pint of milk, and if they have eggs, get six,” she says.
Later, he walks through the door. “I’m home, mission accomplished!” he beams.
“But you have bought six pints of milk! Why did you do that?” asks his wife.
“They had eggs.”
The message in this story is that the context is often missed in instructions. In many businesses, it is often felt that technical delivery teams (developers, testers) do not understand the basic goals, let alone overall business goals. Furthermore, in the modern world where team members have different mother tongues, the need for clear descriptions is ever more important. (Let's not also forget the different dialects across the English speaking world!)
Requirements are sometimes accompanied by a glossary. The less you need to explain in the glossary, the better. It is better to say “get a pack of 6 eggs” rather than to mark “eggs*” and explain that eggs, in a shopping context, tend to come in packs of six. Using clear language, being aware of idiomatic expressions and providing a glossary all seem to be the functions of a translator.
Requirements are sometimes accompanied by a glossary. The less you need to explain in the glossary, the better. It is better to say “get a pack of 6 eggs” rather than to mark “eggs*” and explain that eggs, in a shopping context, tend to come in packs of six. Using clear language, being aware of idiomatic expressions and providing a glossary all seem to be the functions of a translator.
Consider this example: “The page should not have adverts when accessed by mobile devices.” A developer may have a different idea to the business owner as to what constitutes a “mobile device” - is an iPad a mobile device? If so, why isn’t a laptop? A business person might just think that a laptop has a keyboard, therefore it is not a mobile device! Thus, having elicited from the business stakeholder, a business analyst would give a more precise definition perhaps along the lines of “mobile telephones or tablet devices”. Furthermore, the acceptance criteria could list operating systems that are to be excluded from seeing adverts. This removes the need for a glossary to explain “mobile device”.
But are we being too harsh on “techies”? Isn’t the eggs story, just a story? Perhaps. Doesn’t a developer know that a laptop is not generally thought of as a mobile device, even though you can carry it around? If you are working on a product that most people are already familiar with (say a cash machine - or ATM for American readers), then less context is needed for the delivery team - the business analyst does not need to define “withdrawal”.
My suggestion is that the amount of context needed depends on the organisation and, most significantly, the size. If working in a smaller company, technical representatives will likely be more intimately involved with the business discussions that take place, early on. Thus a business analyst will be using other skills in their tool kit, such as being a good facilitator and asking good questions. However, if you work for a larger company, technical staff may have been through an induction of some sort, though much of the product knowledge learned there will not be retained. In addition to this, people get moved across different projects over time, the company changes the product they originally worked on, after they moved, before they came back, and so on. Thus growing companies are increasingly seeing the need to hire more business analysts.
My experience is that business analysts are more likely to have arrived from the technical side, learning the product as they gain experience. (I have heard an estimate of 70% - however, the ideal background for a business analyst should be a separate discussion.) Thus many business analysts are comfortable dealing with the technical team members and understanding how they might interpret a sentence. Yet sometimes you need to “translate” the other way, explaining what is feasible, what the latest technologies can do, their limitations, why a request has such a large estimate and so on. At the same time, subtely in one's language is important - "defect" can be a more loaded term for a business owner than a developer.
My suggestion is that the amount of context needed depends on the organisation and, most significantly, the size. If working in a smaller company, technical representatives will likely be more intimately involved with the business discussions that take place, early on. Thus a business analyst will be using other skills in their tool kit, such as being a good facilitator and asking good questions. However, if you work for a larger company, technical staff may have been through an induction of some sort, though much of the product knowledge learned there will not be retained. In addition to this, people get moved across different projects over time, the company changes the product they originally worked on, after they moved, before they came back, and so on. Thus growing companies are increasingly seeing the need to hire more business analysts.
My experience is that business analysts are more likely to have arrived from the technical side, learning the product as they gain experience. (I have heard an estimate of 70% - however, the ideal background for a business analyst should be a separate discussion.) Thus many business analysts are comfortable dealing with the technical team members and understanding how they might interpret a sentence. Yet sometimes you need to “translate” the other way, explaining what is feasible, what the latest technologies can do, their limitations, why a request has such a large estimate and so on. At the same time, subtely in one's language is important - "defect" can be a more loaded term for a business owner than a developer.
So as a translator of sorts, which do you consider your “first language” - that of the technical team members, or that of the business?
Do you often find that developers/testers don't understand the context? What ways have you seen a business mitigate this?
No comments:
Post a Comment