Wednesday, April 16, 2008

What to do, what to do

I think it must be me, because most people don't seem to see anything in it. How can you possibly have any idea how to build something before you know what to build? It's like walking into a store and the assistant hands you a pound of apples, without waiting to hear that you actually wanted a loaf of bread. Almost every project I get involved with, someone seems to know that we're going to need a 'cluster of this' or an XML schema for that - before we even know what it is that our customer wants. Do we have some kind of psychic powers that we're honing ever so carefully now, which allow us technologists a previously unknown level of insight into our customers needs.

Of course, sometimes your customer tells you what technology they want as well - this is interesting and may or may not be bad - it depends. Thing is not to take anything for granted, question everything - blindly accepting that you have to modify your product to fit a single client's unique needs will often be madness for you - and might not even be best for the client.

Call me old school, but I believe that there is much truth in the saying 'the customer is always right', so why don't we want to listen closely to what they have to say, and then actually try to understand it before we start thinking about possible solutions. The real downside with making assumptions about solutions is that it stifles the thought process, limiting your options before you've even started. Choice is a wonderful thing and delaying technology decisions making until the last minute - sort of a just enough/just in time thing - then you're not closing down potentially interesting avenues too early.

Dealing with requirements is one of the most complex things that developers have to cope with. Its so easy to introduce a subtle point, the implications of which could be huge in terms of time and cost. For this reason I like developers to be involved every step of the way as far as eliciting needs from customers is concerned, so that they can suggest the value in doing very costly features vs less costly ones. Clients are almost always unaware that option B might cost them half of option A, and B is only marginally less optimal than A.

So, should developers be involved with any client dialog - absolutely. When deciding what to build, its necessary, so that the client can make informed decisions and hopefully gain better value for their investment.

I have a pet hate of analysis paralysis, and its certainly easy to end up on that road - but that doesn't mean don't understand the problem - or part of it - before diving in with a solution. Requirements are really only a mechanism to promote a shared understanding of the business problem that we want to solve - but this process is invaluable - attempting to skip this process will end in disaster.

1 comment:

Paul said...

Requirements are really only a mechanism to promote a shared understanding of the business problem that we want to solve

Yes and it involves listening. Unfortunately listening is really hard. Playing in a technology play-pen is much easier.