One of the more common complained I often hear programmers make is that they don’t not get good enough requirements, and even when they get them its many time too late and more often than not they significantly changes along the way.
(and by change I don’t mean getting new requirements all the time which also happens, but to the same requirement starting as one thing and then ending as something different)
at the end of such a complaint there is always the assumption, which sometimes is said explicitly and sometimes not, that if “they” could write proper requirements all our problem will be solved.
Perfect requirements are a Myth
in order to understand this statement one must think what is the purpose of a requirement. that is why do we use this mechanism. and the goal is actually quite simple. we need to get a need which usually sit at the user/customer head and be able to move it into the programmer head in such a way that the programmer will have full and complete understanding of what’s need to be done.unfortunately the mean to pass ideas from one head to another without any lose of meaning does not exists in our world (yet), and therefore no matter how hard we try we can only do better and not perfect.
How are we doing?
Apparently not great. programmers still complain that they need to get better requirements. However I feel that we got it wrong. We have been trying for the last decade or so to make things better. Good and smart people have come up with ways to improve requirements writing and invented better way for formalization for example Tom Gilb points out that“Requirements, the root to failed projects.”and has some great ideas on how we can improve on that. but at the end this is in my opinion he wrong way to go.
if you can't beat them, join them
We programmers must accept the fact that understanding the business is our responsibility. Expecting others to explain things to us is quite a childish approach. At the end it is us who knows best how to gather the needed knowledge in such a way that we can understand it we fully understand things, therefore it is we that need to go out and follow these ways and reach the needed understanding. Fleshing out the requirements to a point in which we can implement them is our responsibility.Yes there are people who can help us along the way, and yes some of them belongs to the product side which traditionally is in charge of writing requirements. But no its not their responsibility to explain it to us. They are in charge of picking out the good features, they are in charge of finding the best ways the product can grow and serve the customer. when they do its our job to understand what they want and then implement it to the best of our ability.
It is the programmer job to understand the requirement.
4 comments:
Hi Lior,
great issue, and very well put in words.
in my personal opinion there shouldn't be your or mine responsibility rather our responsibility. (for both programmers & Project managers).
when looking at this issue in the 'Agile way' - there is a challenge, and there is a team. The team will have the best achievements when working together on it.
putting into practical - it should be a process of tuning between the programmers need and the project managers to apply.
Thanks,
Yogev Tal,
consultant & DevManage
From my experience the best way to succeed in this is communication. having frequent reviews, also including QA people, achieves the best requirements understanding and design, that all parties feel they own, since they were involved in its design. Also, different people, with different points of views see different holes in the design and usually brings different ideas for solving them.
@Yogev, if you can reach that state that is great. Most often then not people involved in defining the requirements (product, analysts,...) and the people who actually develop the feature consider themselves to be different team. which of course is one of the things that needs to be changed. in that state they find it very hard to really share responsibility. And most often they they use role & responsibility to prevent this sharing: we are the ones in charge of writing the spec, you are in charge of developing & tetsing it.
@yael, Communication is the only way to get knowledge from one place to another.
problem is, many of us developers has the notion that we can stay passive and that knowledge will be handed to us on a silver plate. When that doesn't happen we say "the requirements are not good enough"
Post a Comment