Also talk about how to deal with changes in demand

Cause

I accidentally saw an article written by a friend in the blog Park to cope with changes in demand. I was suddenly interested. demand changes are very common in the software development process, it is also a headache for programmers and friends. If this problem can be solved well, it must be a very good thing for software development. Although it is not an innovation, however, it can at least be attributed to a technological reform. Therefore, if there is one or more good solutions to cope with demand changes, then its importance is self-evident. Because there is no silver bullet in any method or solution, the practical and industrial applicability of the solution has become a problem that we should consider.

When I saw the article of this garden friend, I replied with great enthusiasm: "I only gave my thoughts and didn't provide a solution ."

I received the following reply this morning: "ideas are more important than solutions ".

So I made the following reply: "The article is less practical ".

Obviously, in this way, it is easy to fall into a stubborn, biased, slot ...... It is difficult to use one or two sentences to summarize what you think, or make it clear that it is not just a dozen lines of text.

The purpose of writing this article is to remind me of the role of throwing a brick and mortar. I hope to discuss with you more about what you think, and how we can cope with such changes in requirements when faced with such problems.

Agenda

1. What are the differences between the articles and opinions of yuanyou and me?
2. What are the reasons for demand changes?
3. How should we deal with these reasons?
4. Response Cases

I. What are the differences between the articles and opinions of yuanyou and me?

1. Considering the breadth of the problem, the problem is narrow enough.

The requirement includes both functional and non-functional requirements. The garden friend only gave some immature ideas about how to deal with CRUD in functional requirements. In many cases, non-functional requirements are the most disruptive and even more difficult to cope. For example, architects often need to consider performance, concurrency, security, scalability, and maintainability. Before doing a project, these non-functional requirements should be considered first, after a project has worked hard, the test was launched without any problems, but it was found that the concurrency and performance could not meet the requirements of the enterprise. As a result, the entire project could not be applied. Once the architecture is finalized, in the end, restructuring the architecture is tantamount to re-development. Therefore, the response to demand changes should not only consider the impact of functional changes on the program, but also the impact of changes in non-functional requirements.

2. Poor Maturity

This article is just some immature ideas of the author, which is far from the true application in the enterprise, and is very likely to cause a flash of cake, even Microsoft often says that the solution is not equal to the solution.

3. No specific solution is provided, but the problem is thrown out.

What enterprises need most in the end is how to do it, instead of simply throwing out a problem, but not providing a solution, even a guiding solution.

4. opinions may be misleading to garden friends.

Is thinking really more important than a solution?

Frankly speaking, looking for a new solution to respond to demand changes is itself a technological reform. Although there is no real innovation, at least everyone thinks it is an innovation. Let me take this as an innovation. The main reason for this idea is that you do not understand the innovation process and management of the innovation process.

The innovation process should be discussed in the following aspects:

• What is innovation
• Why Innovation
• Creativity in management
• Manage innovation process

Due to space limitations, this article will not discuss this big topic.

I want to summarize the following:

• Innovation is a production process, and information is its raw material. It must improve the efficiency of information collection and make use of information creativity.
• Information collection is important, but information creation and processing and post-processing results (solutions) are more valuable.

Ii. Reasons for demand changes

Li Qian of IT168 divided the reasons for demand changes into the following categories. Interested readers can refer to the original article "demand development and management of software projects".

1. Users cannot correctly express their own needs

2. insufficient support from business personnel

3. Constantly changing user requirements

4. Completeness of requirements

5. Details of requirements

6. Ambiguity of Requirement Description

7. Ignore user features

8. Insufficient time guarantee for demand development

Iii. How should we deal with these reasons?

1. We must maintain a good mentality and regard it as a normal state.
2. Solve different problems. Strategic decision-making, team building, architecture design, and program design ......
3. The Design of different solutions and software architecture should be given priority in programming to cope with some changes.
4. Change the development process to minimize risks.
5. Make expansion during design to avoid making too many changes. It applies the idea of object-oriented and design patterns to solve the problem.

Iv. Response Cases

In the face of the challenge of changing requirements, we have previously considered architecture design and programming. However, here I want to share with you the development process.

The development process uses the prototype instead of the traditional waterfall model.

Before development, the development manager or product manager should use the model design software to build a model, then present the model to the customer, and continuously communicate with the customer during the demonstration. When the prototype is relatively stable, it enters the development stage. The following are the benefits:

1. Customers often don't know what they want, but they only know what they don't. Through continuous demonstration and communication, the customer will gradually be infinitely close to what the customer wants.
2. This greatly reduces the development cost. After all, it is much easier to change the document or model than the code. It is absolutely impossible to enter the encoding stage in advance when the requirements are unclear.

Conclusion: No matter from which aspect to cope with the changes in demand, different companies always have their own set of things. Many times, it does not mean that they can be done or can be well solved, we also hope that we can use the information we know and explore good strategies for coping with this issue. We hope that this article will serve as a reference and share our ideas with you.