Project scene:
During the implementation of a project cooperating with Weibo, there were two serious problems. One was that frequent changes in requirements led to repeated delays in the launch time, and the other was that after the launch, system problems emerged one after another, both large and small, which seriously affected the customer experience.
problem analysis:
Frequent changes in requirements are a common problem encountered in project development. I am afraid that in addition to customers, personnel at all stages hate this kind of changes. Why does this happen and how to alleviate it? We summarize the reasons for issuing change requests into the following four broad categories (inspired by software maintenance classification rules):
- Corrective changes, such as functional bug fixes, which need to be determined according to their severity;
- Adaptive changes, such as adapting to business development, changes in national policies;
- Perfection changes, such as improving the requirements loopholes caused by insufficient preliminary requirements research or insufficient requirements communication;
- Preventive changes, such as complying with user operation behavior, pursuing a better user experience, and spontaneously proposing system upgrades;
For these four types of changes, we can manage changes from two dimensions: early-stage planning and later-stage control. It is impossible to eliminate change requests, but it is only about how to prevent users from randomly proposing changes through system management methods.
The second point is that there are frequent problems with the system, which seriously affect the normal use of users. This is obviously a quality problem, which will be discussed in detail in the quality management chapter .
Problem handling:
First, let's take a look at how the PMP scope management diagram regulates scope management:
The following table is an overview of the handling of changes in the project from the two dimensions of change type and management:
The purpose of defining the change process is to regulate user changes and control the situation of random changes, which can be defined as:
The requirements traceability matrix has two functions, one is to ensure traceability of requirements, and the other is to prevent omission or misunderstanding of requirements. The template can be referred to:
The Work Breakdown Structure (WBS) is a subdivision of the deliverables in various forms, with the life cycle stages as the second layer.
