Shulou(Shulou.com)06/03 Report--

There is often a long period of time before a project is launched to discuss and review requirements.

Development, product, operation and other parties are all important participants. In fact, the core person of the requirements is the product manager (PD). PD is responsible for the preparation of requirements documents and the definition of business processes. The requirements of operators can not be directly put forward to the development, but analyzed and filtered through PD. Such three different interest groups (let's just use the word) are prone to heated disputes at demand-related discussion meetings, which usually have two outcomes: one is to reach a consensus, and the other is that there is no following. In a real project, the first situation is almost impossible, or it takes repeated bargaining to achieve it to a certain extent. Because developers are not familiar with specific market and business scenarios, they are often unable to understand some of the inherent meaning of the requirements of PD, so they will think that the requirements are unreasonable, while the operation and some PD that do not understand technology will often put forward a lot of technically infeasible requirements for development. The personnel of the three parties see the problem from different angles and think differently, which leads to a lengthy and procrastinating disaster. Often, more important contents such as the analysis of business processes and the discussion of function points are not discussed. Everyone is wrestling with and arguing about those hot issues. This is a very bad phenomenon, but also very dangerous. In the later stage of the project, those hidden business points may suddenly burst out, resulting in risks that are difficult to control. A very important root of these problems is that the three parties have not formed a basis for discussion, and people often interfere with the design of requirements on the basis of their own experience and preferences, and the subjective factors are very strong and lack of strong arguments to support their views. No one can convince each other. If the demand is matched with objective and impartial data or market research reports, the discussion will tend to be smooth and the entanglements will be reduced. As a result, the following laws are summarized: 1, the demand on the demand side is best supported by arguments. Without these arguments, it will be very difficult for us to find a common basis for discussion. 2. Try not to involve too many subjective factors in the process of discussion and review. 3, it is best to sort out a glossary according to the requirements document, many times when we discuss the vocabulary is not unified, it is easy to have deviations and misunderstandings. 4. The project manager assigns the work of the developer's development function module before the review, and the detailed requirements are confirmed one-to-one by PD and the developer. After all, requirements discussion meetings cannot fully cover all business points. If problems are encountered in this process, they should be thrown up and thrown to the project manager to focus on dealing with them. Of course, this point on the requirements of the project manager is relatively high, the specific situation to deal with.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.