An Effective Developer Asks Lots of Good Questions
To be an effective developer, you don't just need to know how to code well, you need to know how to code for your clients' needs.
Join the DZone community and get the full member experience.Join For Free
When new work comes in, I tend to look at the statement of work and often two things come into my thoughts:
I get extremely excited over solving a new problem and I begin mapping out the solution.
I start thinking about how fast I can get it done.
Try to restrain yourself from thinking about the above 2 items until you have a thorough understanding of what the problem statement is. Here are 3 reasons why you should dig deeper.
3 Reasons For Digging Deeper Into the Problem Statement
1. We Are Fallible People.
If we are honest, we misunderstand things more often than we like to admit. No matter how much we think we know, we should seek to clarify what the customer is seeking to gain.
2. We Assume We Know What is Best.
Sometimes arrogance gets in the way. So we read into the problem statement what is not there. Instead of building what is expected, we build what we think it should be.
3. The Customer is Fallible.
No matter how clear the problem statement is, the customer could miss an important detail. Our goal is to help the customer tease out their problem further.
Effective Questions to Understand the Customer
Due to our limitations as expressed above, it is very important to seek to understand what the customer is truly seeking to gain from their new application. Here are 3 questions you can ask to deepen your, and your customer's, understanding and get on the same page with each other.
What is Your End Goal? What Are You Trying to Accomplish?
This is an important question to ask. A lot of times this is the gap filler. It will help you and the customer see if what was listed will truly help them in the area that they are trying to solve.
What Are You Using Now That Isn't Quite Working For You?
Understanding the frustrations behind the software or process they are using now will help ensure that you do not fall into the same category of useless software. This will ensure that you do not repeat the same mistakes that caused their frustration in the first place.
What Are You Hoping to Achieve With This Software?
This further helps you and the customer to understand what is needed to make them happy with the software they receive. There is no perfect software right out of the gate. But this will generally get you enough information to seek to make it "perfect" for them in what they need now.
Walk Through Every Step of the Current Process
This is the most tedious and often times glossed over step in the process. However, it is probably the most important one we can take.
3 Reasons We Should Walkthrough Every Step:
This will help you and the customer ensure that you haven't missed anything
It will also show what steps can be combined or what needs to be simplified.
It will help expose the limitations of the current infrastructure that they are trying to plug into. Often the reality of what is wanted is limited by what the business has provided as tools to use. For instance, if they want email capabilities, but there are no SMTP servers available or firewalls prevent such activity, then this will be exposed and you can call out a workaround.
Set an MVP
What is the minimal that can be delivered that will make the customer happy? This question has to be answered from the beginning.
If you can drop some features and give a working product that alleviates some of the stress of what they are trying to solve, you will win their confidence every time.
It will also give you more time to be thorough and test well, and provide a system that can be maintained and be as bug-free as possible. Then you are in a better position to add the more complex features.
Assuming we know everything or that the customer understands their problems well is a quick way to land in the 60th percentile of failed software conversions. Be an effective question asker. Document your questions that have done a great job in getting the customer to express themselves well and where you have gotten the most understanding. Use these over and over again (no reason not to be DRY in every area of your software development career).
The above list is not intended to be exhaustive. Each case will present new questions that will need to be answered. There will also be questions to the answered questions that you need to be ready to ask. My hope is that this gives you a springboard to think well about the process of asking good questions and help you to begin to ask a lot of them.
Published at DZone with permission of Christopher Washington. See the original article here.
Opinions expressed by DZone contributors are their own.