I think of myself as much as a student of business analysis as a practitioner. I love coming across new ideas, or even old ideas stated in new and interesting ways. I also like to share the good stuff I come across in my studies with my readers here at JB.com.
Today I came across a new blog that I think is a great read for business analysts and want to recommend. It’s the Ulterior Motive Lounge by Martin L. Shoemaker (The UML Guy). I’ve already subscribed to his blog and bookmarked a couple posts. The content is great for BA’s – or UML users in general, and the light, humorous tone makes the reading enjoyable.
Here are a few excerpts from a couple articles I liked, but I do advise you to go check the site out yourself.
From The Echo Effect:
The primary conundrum in requirements analysis is simple: how can you be sure that you understand what the user said or wrote? Analysts have to master the terminology and domain of the customers. Only customers can verify that analysts have done so. This is made more difficult by many forces… The answer to these forces is The Echo Effect: ensure that analysts restate the requirements to the customers, but not in the same words the customers used… Early on, the goal is not to be right, but rather to be wrong in interesting, illuminative ways. Oh, it’s nice to feel like a genius when you do get it right the first time; but that’s rare. Much more common is that you think that you got it right, because your customer nods and doesn’t say much, when what’s really happening is that he’s too busy and just wants this meeting to be over. So being “right” in your early Echoes can lead to a false sense of security; and trying too hard to be right right away is misplaced effort and worry. Be as correct as you can manage, but recognize the limitations of your current knowledge.
I think that this is wise counsel for all analysts, and perhaps especially for the less-experienced BA. I recall instances of mistaking the nodding head for real agreement. I remember feeling like there was really nothing to this whole requriements thing after getting buy-in on a spec after a single interview. I can recall worrying about the impression others might get if my spec wasn’t “perfect” after the first walk-through. And I can also attest that the nodding heads and signatures didn’t provide much residual comfort upon seeing a solution delivered that didn’t meet the customer’s needs and expectations.
I think with time we begin to recognize software engineering for the complex and unpredictable animal that it is. We learn that constructive feedback beats a nodding head any day of the week. We learn that getting requirements right often takes multiple iterations of gathering – and then echoing – the requirements. We learn that there is a point of diminishing returns where constructive requirements re-work and review ends, and analysis paralysis begins. We learn that even after multiple iterations, we’ll probably have changes to make. And that’s ok, as long as we get it right in the end.
From Process is a Lie:
Process is a lie, because process is a plan for how we’ll work. And plans are lies. All of them. A plan says, “This is what will happen, and this is what we’ll do.” A more realistic plan says, “This is what will happen, and this is what we’ll do. These are things that could happen instead, and this is how we’ll handle them.” And a truly realistic plan says, “This is what will happen, and this is what we’ll do. These are things that could happen instead, and this is how we’ll handle them. And in case something happens that we haven’t foreseen, these are the resources we keep in reserve and the options we keep open.” … Process is never enough. But it’s still essential. Process failure might indicate a flaw in that particular process; but often, it indicates that no process survives contact with the enemy. … [A] plan can be (will be) wrong in details and yet still be right overall. Like all plans, your process is what you expect to do, not what you actually end up doing. A process or plan establishes a basic framework for how you’ll handle the simple, mundane matters that arise; but realism tells us that things are going to happen that aren’t covered by the plan. The process guides you in handling what you can foresee, so that you can spare more attention and thought for the eventualities you can’t foresee.
I particularly enjoyed this post because I think it is easy for us to become disgruntled with process. Sometimes we might place an inordinate amount of blame on process for not solving problems it was never meant to solve. A good process isn’t going to remove all uncertainty and ambiguity from a project. It isn’t intended to. Process helps us plan for the predictable, and mitigate risk for the unexpected. To borrow another line from the UML Guy, “The plan or process lets you handle simple stuff without thinking, so you have more thought to devote to the hard stuff.”
Now, please don’t misinterpret my comments. I’m not saying process should be above scrutiny. In fact, most of our development processes and methodologies probably have room for improvement.
The trick is finding the right process, one that fits well how you’re already working. Then try to describe that process so that you and your team can reach a common process. Then document that process. Then apply that process, and see where it falls short, and make it better over time.
So, there are a few teasers and a some of my thoughts on content from Ulterior Motive Lounge. Now, go have a look for yourself.
And if you come across any other new blogs or informational sites that you’d recommend as good reading for BA’s, please return the favor and let me know!
Комментарии