Author: sodimethyl the source of this article: http://blog.csdn.net/sodmenote: This article can be copied and reproduced without the consent of the author, but any reference to this article should be retained by the author of the first three lines of the article, the source and. thank you. note: In the past, in the traditional software industry, the development process was generally: Perform requirement analysis first, then determine the function, and finally implement development. That is to say, after the demand analysis, the demand is basically changed, and a stable demand will be maintained for a long time. However, after entering the Internet Software era, things have changed. Just to address the demand, "Changing the Times" is nothing new. As a real-time player of the system, of course, we all hope that the more stable the demand, the better, but it is only an "ideal" or even, sometimes just a "dream ". For an immature market, an immature Internet product, or an immature team, the promoter of demand change may be the market or a user, it may be just a word from the boss. You cannot say that this change is correct or wrong. In many cases, we do not have the energy or time to argue who is right or wrong. For us, one of the most practical ways is to make a positive attitude and respond positively. This is a team sentiment about how to cope with changes in demand. Its core idea is: in the Internet Software age, demand changes are a norm of software development, we can no longer copy the development of internet software with the idea of developing traditional software. Internet software "requires fast changes in demand and short development cycle", and requires the team to establish the organization, process, and communication atmosphere necessary to cope with such rapid changes in all aspects. As Bottom-layer implementers, we cannot decide on demand changes in many cases (either the boss or the user or the competitor, for us, we can only make appropriate architectures and appropriate organizations as far as possible, only by taking a positive attitude and taking the initiative to cope with such changes can we push forward the pragmatic product step by step. Introducing the body ---- writing a program, what is the most painful? After a long time of hard work, I wrote the code well, but the requirements of others changed. The code I just wrote was useless and all of them were deleted. I used to think that this situation often occurs only in Internet software. However, after chatting with some friends, I realized that, the same problem exists in the traditional software industry. No matter where the demand comes from, the programmer can not only complain about it, but also make a fire (or see if there is any "qualifications"), and the work still needs to be done. During our development, we often encounter such problems. In the face of ever-changing needs, we have been annoyed, angry, and unbalanced. But when all our emotions are exhausted, calm down and think about it. For the sake of products, these new demands still make sense and must be realized. So I tried to analyze and summarize the causes and consequences of demand changes in this article, as well as our current practices and how we view demand changes, I hope this will bring you some help and inspiration. We should stick to two kinds of mentality for things that cannot be changed or cannot be decided by ourselves: 1. it is necessary to use its own actual actions to exert positive influence on it with accumulated mentality; 2. since we cannot change it, we have to accept it, adapt to it, and then guide it slowly. The same is true for changes in demand. There may be a lot of demands, why, and why it may change, but there may not be much truth in itself. The boss said that this should be changed, that should be changed, before the product is pushed to the market, before the user has a final experience, it is hard to say that this requirement is wrong or inappropriate. What should you do? Our strategy is to fight for it, communicate with each other, and think about other methods. We can't say anything, just do it. Of course, this is a passive response. We believe that this is impossible. A team needs to grow to be mature, and a boss also needs to grow to be mature. Only when he becomes more and more mature can he put forward more and more reasonable and more stable demands. On the contrary, when he is not mature, his demands cannot be stable or reasonable, at this moment, do we have to stop doing things? I think, just like this, you have not really realized what developers should be aware of: in fact, the boss is almost the same. When you change one, you may also encounter the same problem. What you can do is not to escape, but to face it positively. If his ideas are not mature, they will help him mature. if he persists, let the facts educate him. When the facts tell him again and again that your thoughts and practices are correct, he will be more willing to delegate permissions to you. Before that, you have no other better solutions, just to endure. Maybe, we often complain like this: "If we have made an agreement, we will do it according to XXX. How can we change it ". I would like to solemnly tell you: do not trust the agreement. For a project that is still in the active state, all your efforts aim to survive and develop the project, instead of making a romantic convention ". The market and users only look at the needs and do not look at what you call the "Conventions ". On the other hand, in many cases, it is not the boss who wants to change their own needs. They may be under pressure in the market environment, under the competition of similar products, or under the user pressure. In short, all reasons may cause demand changes. Therefore, we have no reason or need to keep insisting on the "demand does not need to be changed" point, which is a waste of time, what we need to do more is to consider the development methods, processes, and organizational structures within our team to flexibly adapt to this regular demand change. In addition to the above passive response, there is also an active response method, that is, as system developers, we must constantly use our own products and constantly think about our system requirements, when you use and think about it, it is easy to find some requirements that are likely to bring about changes, so that you can avoid them in advance during design and implementation. Don't think that you are finished developing a system. A lot of details are actually added after you finish the first development, and how can you discover these details, only you can continue to use your own developed system. In the face of demand changes, first of all, we need to correct our mentality: 1. Don't get angry as soon as we get up. We need to analyze why there are such demands and what are the core points of new demands? 2. Compared with the old implementation, can this new requirement be indirectly implemented by simply modifying the old box? 3. In terms of mentality, changing demand is considered a normal state of the project. However, you must learn to control the trend of such changes in demand, so you cannot let them develop. In addition to preparing the above mentality, we also need to establish an organizational structure within the team that can quickly adapt to changes in requirements. I will summarize this structure as follows: one-person responsibility system + small team collaboration + information sharing. That is to say, in all the systems we develop, there is only one owner for each specific system, and there will not be two or more owners, in this way, the time consumed by project decision-making can be accelerated to the maximum extent, facilitating quick decision-making and implementation. Small team collaboration refers to a specific system, from development to testing to implementation, involving as few people as possible, two or three people, four or five people, the best. This is because a system, from design, development, coding, to testing and delivery, may involve many steps. It is not the end of coding by programmers, but the product is not available, in the end, it is up to the customer to make decisions. Therefore, we should try our best to improve the efficiency of such a complete process from coding to delivery to user feedback, the response speed of all personnel involved in this system determines the response speed of the entire product to user requirements. Two main points of teamwork: clear division of labor and information sharing. There is a clear division of labor, which is to say which person is responsible for what they do, but in addition, what we advocate is that each person ultimately, they are all responsible for products. They cannot only focus on the work they do, but do their work well. They are just a basic premise and people with complete product ideas, in order to be qualified. Information sharing refers to notifying all involved personnel as quickly as possible through IM groups, emails, small meetings, and other methods, so that these personnel can better coordinate. In addition to the organizational structure, we also need to improve the ability of individual team members to respond to changes in needs, including improving the flexibility of the Code architecture and the adaptability of programmers. Because the code is ultimately implemented by a single specific developer, their capabilities determine their degree of pain. The code is flexible and can adapt to changes in requirements to a certain extent. However, this is not a panacea for changing demand. Because, in actual operations, we often write the code too complicated because we cannot grasp the "flexibility", and even make the Code itself easy to maintain, this is unacceptable. We believe that the bottom line of code flexibility cannot undermine the readability and maintenance of the Code. If we reach this bottom line, we would rather discard the flexibility and write the code dumbly. The method I mentioned here also has certain requirements for personnel. For example, the person in charge must be dedicated and have mature ways, methods, and attitudes, know how to implement the most effective collaboration in a high stress and a short time. Many Internet products may encounter a situation where a new version of a product has just been released. However, when a large user volume test is introduced, it suddenly finds a serious problem, this is a special test of the response capability of the person in charge. This situation is often urgent, and thousands of users may use your stuff online, you need to make effective changes within one hour, half an hour, or even ten minutes. This feeling is similar to a war. Although it is very exciting, it does need a lot of changes. At the beginning, every team may not be so perfect. There are so many people dedicated to others, but everything always has to start with. the maturity of the team does not depend on reading one or two books, you can read one or two blog posts. It requires you and your team to continue to work, improve, and summarize in specific practices.
