The main problem is the difference between what customer says and what he wants. At this point, it is very important to gather and understand requirements accurately. So, what should we do to gather accurate requirements?
I absolutely don’t mean that customers are liar. One of the important reasons of why customer could not express what he wants is assuming that you are an employee of 10 years in that company. In fact, there are tons of hidden details in the background. So much so that, two different employee may tell two different stories on the same property. It may be a good idea to gather information from the customer continuously without giving up and to examine the work where it is done in order to reveal those hidden details. One of the best practices of Lean philosophy, Genchi Genbutsu (現地現物?) , means “go and see” should be applied certainly.
Another type of customer is interested in the project so much. Because of that, the project may turn into a “garbage of features” and most of these features will not be used.
The famous Italian economist Pareto’s principle, also known as 80-20 rule, fits well to software projects. So, 20% of a software project is used indeed, but the remaining one, 80% part of the project is almost not used. Shortly, wastage is at stake here.
We should accept that designing software look likes dealing with the obscurity. By the way, I want to share the following articles from the book “Business Model Generation” which represent designer and design facts in a very good way:
“A designer’s business involves relentless inquiry into the best possible way to create the new, discover the unexplored, or achieve the functional. A designer’s job is to extend the boundaries of thought, to generate new options, and, ultimately, to create value for users”.
Here are some suggestions that you can apply when designing:
Become a Customer
You can empathize with the customer, so what do you do if you were a customer? It might be a good idea to use “Customer Empathy Map” that was issued by XPLANE Company.
According to this empathy map, it is so simple to try to understand the customer. At this point, you should absolutely make use of post-it notes.
Visualize the Problems
Visual thinking turns abstract cases into concrete ones. It reveals the relationship between elements. It also simplifies what is complex. Visual thinking allows you to see the big picture. What is important here is to provide communication and understand the essence of the matter. You can make drawings on a blank piece of paper or on a blackboard explaining the topic. A picture is worth a thousand words. Do not think to use UML while I am telling these things. What I want to tell you here is beyond UML.
One of the best ways of dealing with obscurity is to create prototype(s). Creating prototype turns abstract ideas into concrete ones and provides detection of errors more quickly just as visual thinking.
Real content of this post, can be accessed in http://en.kodcu.com/2013/06/english-why-doesnt-the-customer-tell-the-truth/
Apply Domain Driven Design
DDD is not a technology, it is a methodology. Basically it tells us that business and the logic of the business is more important than anything else. I mean business-oriented thinking, not technology oriented one. I want to share with you a few DDD rule:
- Common language is everything. Learn the language of the work done. For example, if your work is about accounting, you should learn what general ledger means and then adopt it. Otherwise, you cannot understand the customer and project collapsed.
- Communication is everything; don’t muddy the work done by using the jargon of programming world.
- The customer should easily understand the modeling (if it exists).
- Click http://domaindrivendesign.org for details.