I just read an article about Planning For Fun In Game Programming. It starts with a discussion of requirements and solutions. The essential is:
"It can be compelling to write solutions instead of requirements. It is tempting to design a solution to a requirement at the same time as writing the requirement -- especially the interesting ones! Writing solutions feels more authoritative, more formal, more precise and more accurate. But it is counterproductive. By prescribing a given solution, we preclude any potential superior solutions. Prescribing solutions also limits our understanding of the problem domain and intent of the requirement."
This is so true.
Programmers and especially lead developers work by requirements. The lead developers plans and the programmer implements to meet the requirements. But very often the so called requirement paper comes as a series of solutions. Business development, product management, sales, and marketing know what users need. They offer their advice about the next killer feature or the next product in form of requirements papers. Sometimes they even explain in detail what needs to be implemented with examples. This is the point where requirements turn into proposed solutions. This is done in good faith, but with the risk as described in the article above.
Cast:
Development (a lead developer)
Marketing (any other non-technical person)
Marketing: "can we add a cookie?"
Development: "yes, we can."
Marketing: "... and then we can always recognize a user?"
Development: "wait, do you want a cookie or do you want to recognize the user?"
Marketing: "recognize the user!"
Development: "but you said cookie."
Marketing: "It thought this is the same."
Development: "Not in our case, because this is not a Web application."
This is a short example, solved in 2 minutes. But the same problem can easily waste weeks of development time in more serious cases. Whatever Development gets, it is always the task of Development to understand the problem, not the proposed solution. If Development slavishly implements a proposed solution and it turns out to be the wrong solution, then it is the fault of Development.
Marketing tries to specify problems as good as it can. If it is very good, then we (Development) get a requirements document. Otherwise we get solutions. Usually we get a mixture, which is the best case. But we must not fall victim to proposed solutions and examples.
Whatever we get, it is our responsibility to "reverse engineer" the problem. To find out what they really want in order to produce the optimal result. We must not hide behind "their" requirements document and just do. Proposed solutions are just a tool to understand the real problem. It is our job, because we can.
happy_backtracking()
1 Kommentar:
Damn, it is so true!
There is not one project, where you get real requirements. Always, they already more or less know, what exactly has to be coded - or at least, they think so.
That is, when you come around and think: "What the hell do they realy want to achieve with that solution?"
And you start to interrogate the truth out of them. In most cases the result is more or less exact knowledge about what really has to be done.
Its natural behaviour to think about the solution on encountering a problem. It is how human brains work (and they are right to do so). So it is true: We, the developers, have to think twice before we execute orders. What they tell us to do is not often what they really want us to do.
Always be curious when marketing or management staff comes around with solutions...
Kommentar veröffentlichen