"Grasping customer needs" is a waste of Software Development

Customers do not understand their own needs. How can they tell us what we expect? How can we identify with the "requirements" collected by technical personnel and confirm the so-called "requirement statement?

The path of Software Development

Most software development practitioners often complain that it is difficult to grasp the customer's needs ". I think this sentence should not be said from a professional. Have you heard a decoration engineer tell you that he cannot grasp the customer's decoration requirements? But this is a fact. How to "Grasp the customer's needs" becomes an urgent problem in software engineering.

Many experts have published many theories about "how to grasp the customer's needs" and "what measures should be used. However, I have told you over the past 30 years of software development experience in technology enterprises that we do not have to "grasp" customers' "needs ".

The path of software development leads to another segment of IT project management. Do we continue to pursue this path or find the correct path of software engineering? It is hoped that all practitioners will make their own judgments and make appropriate conclusions.

Domestic requirements

I started to engage in software development in 1972 and became the Development Team Director in 1979. In 1984, I became a project manager. Today I have accumulated more than 30 years of development and management experience. I have been engaged in education and consulting work in China in the past two years, I found that the "requirements" mentioned by software practitioners in China are very different from the "requirements" discussed in the past when executing software development abroad.

When building a system outside China, the "requirement" is set up by technical personnel, not from the customer. However, the "requirements" mentioned by software practitioners in China are put forward by customers during the "survey" process. Frankly speaking, customers do not understand their own needs. How can they tell us what we expect? How can we identify with the "requirements" collected by technical personnel and confirm the so-called "requirement statement?

Think about it. When we want to develop a product, will we ask consumers what they want? Maybe we will ask for their opinions, but the manufacturers will formulate product functional requirements based on the consumers' opinions, the manufacturer's own understanding of the market, and the goal of purchasing the final customer base, finally, they become product specifications before they can be put into production and promoted to the market. This principle is very simple, but our software practitioners think that software engineering is different from product development, and they cannot use the same method to deal with it.

Our practice is to conduct "research" from the project (another major misunderstanding of the software industry) and interview the customer's grass-roots personnel, it is hoped that the customer can express their own needs during the survey, so as to grasp the customer's needs and compile the so-called survey report or demand manual.

In fact, the so-called research is to carry out the investigation and then conduct the research. This is two jobs, but we often turn it into a job. The domestic understanding of "gatherrequirements" (collection requirements) is to explore the customer's needs from the customer's interview, investigation, and research process. Because the customer's requirements are not clear, the technical staff cannot grasp the needs, therefore, a survey takes a long time.

Overseas translation of demand

The foreign software industry basically does not have the so-called "research" concept. In the initial stage of the project, we only have "factfinding" (or FF, that is, "Finding facts "). As the name suggests, FF aims to understand how customers perform their work. technicians interview customers to understand their current work rather than their needs. The interview report only describes how the current job is implemented in the Department. Therefore, it is often recognized and confirmed by the customer.

After the interview, they began to analyze the current situation, consider whether the entire workflow is reasonable, how to achieve the project goal, and how to achieve the project goal to determine the project requirements.

Differences at Home and Abroad

We must realize that software development aims to improve productivity, productivity, and business efficiency, rather than meeting certain needs.

If the project aims to meet certain requirements to solve some operational problems, then these are system maintenance projects, not system development projects. In addition, the requirements of these projects are usually relatively clear. The customer knows which functions need to be added and can directly tell the technical staff about the functional requirements. Add this function to the existing system to complete the project. In addition, this requirement can be recognized by all levels of personnel.

Software Development aims to provide a complete set of tools (software and hardware) to achieve the "operation goal" of a department or an enterprise. How can we use technology to make the operation more ideal, is the main reason for software development. Therefore, after the analysis, we can clearly understand which functions are required to achieve the goal more effectively for the enterprise or Department. These functions are the real requirements of the system. What we call gatherrequirements is basically the result of two phases: factfindings and analysis, it is not the result of a "survey" conducted in China.