If one works in programming long enough, this question undoubtedly arises. Let's set the scene. The project has been humming along for a while now. The team is becoming more and more efficient in its execution as they learn how to function as a group. A new request comes in for a minor change to a feature. Someone picks up the task and completes it in quick order. QA signs off on the change and it is released into the wild. At that point, the feedback rolls in and it's not good. Customers are frustrated and confused. The unanimous feedback is: "That's not what I wanted!" This is where organizations start to play the 20 questions game. What went wrong? Why did this happen? Was the request properly documented? Was it built correctly? Is it working properly? Sometimes the answer to all of these questions is "Yes." Still confused? Don't be.
To find clarity, stop focusing on what did happen and dig a little deeper into what didn't happen. The issue was in the request itself. Instead of understanding the purpose and/or need for the request, the idea was added directly into the product. Requests should provide a sparring ground for most companies, but unfortunately these suggestions/ideas are not commonly battle-tested. Most concepts are built on incorrect, incomplete, or invalid information. It all starts with properly defining the problem to be solved. Without this foundational step, functionality will most assuredly be built on shifting sands. Understanding the problem helps drive clarity toward the proper solution. This helps define the boundaries and creates criteria that define what the solution is and is not.
Defining the problem is part of a broader What?-Why?-How? conversation. Each of these should be clearly answered before any action is taken by a development team. The first two define what the change is and why the change is taking place. This work can be completed by various sources from business stakeholders to savvy developers. The "how," on the other hand, is defined by the technical staff only after the "what" and "why" have been clearly defined and vetted. This vetting includes verifying the solution isn't influencing the true understanding of the problem.
For instance, say a request was received to provide sorting on a screen. It's important to avoid the temptation to label the problem as, "The screen doesn't sort." Although the solution might ultimately lead to sorting, proper identification of the problem will lead to a better understanding of the user's true intent. This might result in adding additional filters or providing entirely new functionality. This saves time, money, and makes happier customers.
The next time a request rolls in, stop and take the time to ask the question, "What is the true problem?" Properly identifying that question will have untold savings throughout the development cycle. CodeProject
