A Simple Question That Changed the Direction of an Idea
Sometimes a software project begins with an attractive idea and a great deal of confidence from the client, but a few simple questions can reveal aspects of that idea that have not yet been considered.
One of my experiences in this area involved a client who came to my office one day. He had an idea for selling a product through team building and a sales network. He spoke about his idea with great confidence and asked me to design and develop the software he needed.
Based on my experience with an insurance project, before discussing programming, I started asking questions about the business model and how commissions would be calculated.
I then asked him:
“What sales plan have you designed?”
He explained the plan to me. From his perspective, it was almost flawless, and he was very confident about its profitability.
I asked him:
“How confident are you that this plan will succeed?”
He said:
“I have absolutely no doubt.”
On the surface, everything seemed clear. But I asked one more question:
“Suppose you calculate and pay the sales representatives’ commissions at the end of each month. If one of the products sold is returned a few days later, what will you do? How will you recover the commission that has already been paid to the sales representative?”
He suddenly became silent and started thinking.
I asked:
“What happened?”
He said:
“I had never thought about this. I don't have a solution for this challenge.”
I told him:
“Whenever you find a suitable solution for this issue and are ready, come back and we can review your proposed plan again.”
Some time later, I learned that he had decided not to pursue the idea.
The Lesson This Experience Taught Me
This experience reminded me of an important point: before designing software for an idea, we need to carefully examine the business process itself.
Requirements analysis does not simply mean asking the client what features they want and then implementing those features in the software. Sometimes we need to question the logic behind a process and examine scenarios that may not be obvious at first.
In many cases, the real problem is not in the programming; it is hidden somewhere within a business process that has not yet been fully examined.
Software can implement exactly what the client asks for, but if the underlying business logic has a fundamental problem from the beginning, software cannot solve that problem.
Sometimes the best thing a developer can do before starting a project is ask the right question.
Your Comment
If you have an experience or opinion about this article, I would be happy to hear it and share it with me and other readers.