How to be A Good Product Manager (which is a phenomenal blog, by the way, and wish I had written most of the content) has this excellent post about requirements, and it applies requirements gathering. One of the traps that we fall into as consultants is that with certain clients, we go into the mode of just gathering requirements and not advising what the requirements should be (read: let’s design the Pontiac Aztek, quite possibly the ugliest car on the road).
Just gathering requirements is a bad idea. Advising on requirements is a better idea, because that’s how you add value.
Sure it’s like herding cats, but the reason many consultants are valuable is there’s some wonderful insight that they may have, however small it may seem, that adds phenominal value for the client. That’s why they are paying consultants what they do.
How so? We start the conversation about what the direction should be, even if it’s the wrong direction at the start. One of the essential points that the article makes is that in many cases, the customer has no idea what they want (a car), and what they may get may be anything from a Hummer or a Prius.
Our job is to ask questions that will lead to developing a better product, and not necessarily questions that lead to what we think the product should be. Many scenarios, it’s impossible to satisfy all parties, because they may ask for a car that is great for the environment (the Prius) and can run over people (the Hummer), because the requirements are conflicting. Our job is to find the best solution, not the solution that meets the needs of everyone.
Or what do they say — trying to make everyone happy will make no one happy?
Beba na Fonte: http://www.usabilitycounts.com/2008/05/08/consultant-thursdays-dont-gather-requirements-drive-them/
Nenhum comentário:
Postar um comentário