Exploration_and_Questioning

12009

Overview

Questioning is the act of defining problems. Through targeted questioning, we identify the specific needs of the client and uncover the reasons behind those needs, which are the fundamental issues that need to be addressed. In the process of questioning, we form the business goals that the team aims to achieve or the business problems they want to solve. If the problem cannot be clearly defined, the answers we find will naturally be skewed. Therefore, before seeking answers, it is essential to clearly define the problem.

Discovering and identifying the true needs of users is a challenge faced by all enterprises today. By continuously asking questions, we clarify the real goals behind the client's needs, allowing us to explore more solutions to the problems, while also helping team members fully understand the business issues from the perspective of those problems.

How to Ask Questions

What to Achieve & How to Achieve It

"User stories" are widely adopted as a way to describe requirements; however, software development teams are more concerned with the question of "what the requirements are." For example, we often encounter scenarios like the following during team discussions about requirements.

Business personnel: Just develop according to the business processes and interface examples in this document.
Developers: When this process reaches this point and encounters a situation like (…), what options should be included in this field?
Business personnel: You can do it this way (…).
Developers: Then what happens next after this is handled?

The goal of the above questioning is to clarify the user's immediate needs (i.e., the solution proposed by the business personnel). From the service mindset of "meeting customer needs," there is nothing wrong with this way of working. However, can developing according to the document written by the business personnel truly meet their real needs?

Why to Achieve It

The questioning phase requires not only finding out "what to achieve" and "how to achieve it," but also understanding the real problem behind the client's needs—"why to achieve it"—to plan more convenient and efficient validation or solution strategies.

Due to role inertia, from the moment we start discussing, it is easy to skip the most important question, which is how to better solve the real problems for the client, and this is precisely what we should be doing.

Suppose we are hosting a small offline gathering with the theme of "Agile Development." An attendee wishes to have a cup of coffee. To better serve the client, as the organizers, we patiently ask him, "What flavor of coffee do you need?" "Hot or iced?" "Large or medium?" "What time do you hope to receive it?"

All these questions only inquire about "what to do" and "how to do it," without asking about the reasons. If the real problem the client wants to solve is "not missing the lecture due to drowsiness," we might have many ways to address his request. Perhaps we could record the video, so even if participants drift off during the session, they can review all the content after the gathering ends. We have many more methods to meet the user's need to not miss out on the exciting content.

To solve the client's problems, we may find many solutions, but the prerequisite is that we must discover the "correct needs." The so-called "correct needs" are those that can address the real issues the client wants to solve, which are not necessarily the solutions proposed by the client.

When we receive a work task, we should delve deeper into understanding the problem to be solved, grasping its underlying causes, and not prematurely enter discussions about solutions while neglecting the discussion of the problem. This way, we can better solve the problem, rather than just completing the development of software functionalities.

Key Points

In "Questioning," the following four points should be noted:

Representatives from both the problem domain and solution providers should try to be present and participate in the discussion.
Ask several "why" questions. Try to avoid prematurely giving up exploration because you feel familiar with the problem domain.
If conditions permit, collect data information as much as possible to serve as evidence for understanding and analyzing the problem.
Empathize and use empathy. Stand in the shoes of the client or the problem proposer to think about the problem, restoring the context of the client's issues.

## Overview

Questioning is the act of defining problems. Through targeted questioning, we identify the specific needs of the client and uncover the reasons behind those needs, which are the fundamental issues that need to be addressed. In the process of questioning, we form the business goals that the team aims to achieve or the business problems they want to solve. If the problem cannot be clearly defined, the answers we find will naturally be skewed. Therefore, before seeking answers, it is essential to clearly define the problem.

Discovering and identifying the true needs of users is a challenge faced by all enterprises today. By continuously asking questions, we clarify the real goals behind the client's needs, allowing us to explore more solutions to the problems, while also helping team members fully understand the business issues from the perspective of those problems.

## How to Ask Questions

### What to Achieve & How to Achieve It

"User stories" are widely adopted as a way to describe requirements; however, software development teams are more concerned with the question of "what the requirements are." For example, we often encounter scenarios like the following during team discussions about requirements.

Business personnel: Just develop according to the business processes and interface examples in this document.  
Developers: When this process reaches this point and encounters a situation like (…), what options should be included in this field?  
Business personnel: You can do it this way (…).  
Developers: Then what happens next after this is handled?

The goal of the above questioning is to clarify the user's immediate needs (i.e., the solution proposed by the business personnel). From the service mindset of "meeting customer needs," there is nothing wrong with this way of working. However, can developing according to the document written by the business personnel truly meet their real needs?

### Why to Achieve It

The questioning phase requires not only finding out "what to achieve" and "how to achieve it," but also understanding the real problem behind the client's needs—"why to achieve it"—to plan more convenient and efficient validation or solution strategies.

Due to role inertia, from the moment we start discussing, it is easy to skip the most important question, which is how to better solve the real problems for the client, and this is precisely what we should be doing.

Suppose we are hosting a small offline gathering with the theme of "Agile Development." An attendee wishes to have a cup of coffee. To better serve the client, as the organizers, we patiently ask him, "What flavor of coffee do you need?" "Hot or iced?" "Large or medium?" "What time do you hope to receive it?"

All these questions only inquire about "what to do" and "how to do it," without asking about the reasons. If the real problem the client wants to solve is "not missing the lecture due to drowsiness," we might have many ways to address his request. Perhaps we could record the video, so even if participants drift off during the session, they can review all the content after the gathering ends. We have many more methods to meet the user's need to not miss out on the exciting content.

To solve the client's problems, we may find many solutions, but the prerequisite is that we must discover the "correct needs." The so-called "correct needs" are those that can address the real issues the client wants to solve, which are not necessarily the solutions proposed by the client.

When we receive a work task, we should delve deeper into understanding the problem to be solved, grasping its underlying causes, and not prematurely enter discussions about solutions while neglecting the discussion of the problem. This way, we can better solve the problem, rather than just completing the development of software functionalities.

## Key Points

In "Questioning," the following four points should be noted:

1. Representatives from both the problem domain and solution providers should try to be present and participate in the discussion.  
2. Ask several "why" questions. Try to avoid prematurely giving up exploration because you feel familiar with the problem domain.  
3. If conditions permit, collect data information as much as possible to serve as evidence for understanding and analyzing the problem.  
4. Empathize and use empathy. Stand in the shoes of the client or the problem proposer to think about the problem, restoring the context of the client's issues.