2013.5.26
The demand phase is the busiest phase of the project manager and an important watershed for the project to be well done. At this stage, system requirements, work ideas, work plans, and division of labor are usually compiled, accompanied by a large number of reviews. If you are a little careless, it is easy to be pulled into the vortex, lose yourself, keep being pushed by others, feel depressed, will also lay a layer of mines for the entire project, is the real tragedy.
Because the user requirements are compiled by the supervisor/product manager, and the system requirements are compiled by the project team, the two requirements work in parallel to a certain extent, so they are written in one chapter. Project management is divided into the following five elements:
1. Stakeholder Expectations-goals
User Requirements:User requirements are usually compiled by the supervisor or product manager. The main target station is to describe the problems encountered from the customer's perspective, and abstract it to the customer's use scenarios and solutions that our project can provide. The user requirement document generally has a rough granularity in the description of the solution, because the solution ideas may be changed during the review, and the rework cost will be relatively high if the solution is refined too much. Main stakeholders of user requirements: 1) Superior leadership: evaluate the value of the project and determine whether the input-output ratio is appropriate; 2) Marketing Department: evaluate the project's publicity and promotion costs; 3) Project Team: refine system requirements based on user requirements and understand project significance
System Requirements:System requirements are usually provided by the project team and the solutions reviewed by users are embodied. The main stakeholders of this document are: 1) Supervisor/Product Manager: whether the system requirements fully meet the user requirements, have good user experience? 2) customer service department: Is technical support convenient and cost? 3) Developers: What is the project? 4) Testers: How is the project accepted, how to calculate the impact of related functions, known defects, abnormal scenes, and non-functional effects (performance, stability...) on the UI interface (and interface constraints ...).
2. Sand Table-ideas1) The project team should participate in the review during the user and system requirements stages. The project team members should participate in the review. Although not necessarily speaking during the review process, there are two important roles: a. Strong sense of project participation B. Understanding of the original needs of the Project C. Understanding of expectations of stakeholders 2) requirement Quality Assurance there are two good practices for requirement quality assurance: A. Write the requirement documents by the module authors in the next stage to ensure the author's understanding of the requirements, at the same time, errors can be corrected and understood during the review process. Since the authors of the next phase are generally more familiar with the changes or new modules, it is easier for them to discover associated changes and known defects. B. Test and acceptance of requirements I remember I attended the IBM management forum several years ago. I was deeply touched by a point of view. The general meaning is: "Only the requirements that can be accepted are the complete requirements ". It is difficult to determine whether the requirements are complete and clear through the granularity of description. I have read a very long demand document and wrote n more nonsense, however, you can find many omissions after careful consideration. This requirement is complete and clear only when the testing team obtains the requirement document and can clearly understand how to accept the requirements without ambiguity or ambiguity. The full-phase defect prevention work of testing colleagues' projects has been put into practice in our company for a long time. So far, we still have the largest Defect Prevention output in the demand phase.
3) develop a project sandbox
Project sandbox has two important parts: A. Expected Analysis and Implementation of stakeholders example: a project team has renovated all the pages of the system for better experience. At this time, the expectations of the product manager/supervisor are very clear for the customer experience. At this time, the project team should arrange an experience each time when the functions have been called during the requirement discussion (DEMO) and the interface has been initially completed to fulfill the expectations of the product manager. B. Key factors for project success analysis the key factors for project success can be analyzed using a Fishbone Diagram. For a R & D project, it is mainly composed of three major bones: human, process, and technical Example 1: A project team is mainly composed of new employees who are not technically difficult. At this time, the quality of work of new employees will become a key factor. Further analysis can be made at this time.
Example 2: The major bottleneck is the change and improvement of performance methods in a project team. Further analysis is as follows:
3. Plan Formulation
1) there is always some routine work in the project using the estimation list. The project team should sort out this list before the estimation starts to avoid missing estimation items by project team members. Some routine work, such as environment construction, daily maintenance of the building environment, migration code review, review time, test case review time, etc. If the current department or company has provided an estimation list, you only need to modify it according to the project characteristics.
2) The biggest difference between implementing the sand table idea and plan is that the latter is ready to begin implementation. The idea of not preparing for implementation is simply an idea. The sand table obtained through various analyses and various discussions is the crystallization of wisdom and needs to be planned. Generally, the sandbox Implementation Plan is the Defect Prevention Plan of the project team.
3) from bottom to top estimation, there are many methods for experts to check the estimation, which is one of my favorite methods. See section below for details: detailed project and clear milestones of the project should be generated after the end of http://blog.csdn.net/liangjingbo/article/details/9008735 estimation.
4. Risk management1) The impact of association in a complex system is not weekly. For projects that add or modify modules in the existing system, if the current system is very complex, the relevance issue may be introduced in large numbers at this stage. There are two feasible methods for this situation: a. convene expert consultation B. Analyze the module owner in advance (time required by the project team)
2) the omission of estimation items may result in inaccurate workload. Common methods are as follows: a. Use the estimation list to check whether there are omissions in routine work. B. Use the requirements. check whether there are any omissions in the requirements based on the matrix. C. Check the estimation table by experts.
3) Demand review changes. One of the problems that affect the project manager most is the change in demand. In fact, in some cases, the change is not a requirement but an understanding of the demand. To avoid the impact of changes in requirements, we need to do a good job in two aspects: A. Requirement Defect Prevention. The project manager should deliver a good sense of customer orientation to the team members, put forward some unreasonable points that can be found by the project team as much as possible in the early stage to avoid dragging to the later stage to bring a greater impact. B. When demand changes are inevitable, it is necessary to assess in a timely manner whether or not to carry out the supplementary research. I have seen many impatient project managers who are eager to push forward the project as planned and have suffered a big loss. 4) the team's organizational structure is not conducive to timely risk discovery whenever I hear the project manager say "the project quality will not be known until it passes the test, I will label this project as "high risk" and "out of control. The project is the child of the development team, and the test team is the Doctor. To have a healthy baby, work in the early stages of pregnancy is the most important thing. When a child is born, the system and health status of the child have been basically determined. If the doctor detects a serious defect (for example, the code of a module is poorly written ), so it is very difficult to remedy. Therefore, the project team must have an accurate grasp of the quality and progress of the project at all times. Accurately controlling the quality and progress of the project. There may be multiple options for large teams, such as: A. Setting up different groups. both management and technology are managed by the team lead. B. An independent and part-time technical expert team is responsible for technology. The project manager is responsible for managing C. The independent full-time technical manager is responsible for technology and the Project Manager is responsible for management... the organizational structure can be varied, but one principle is to promptly and effectively discover risks. In this regard, my partner and I have tried a method that can be used as a practice for your reference. At that time, we created a project module quality tracking table and discovered risks. The first part of the tracking table is all modules and owners of the project team. The second part is the list of experts involved. The third part is self-evaluation of the module complexity and difficulty level, and expert evaluation: self-evaluation of Module Design and expert evaluation Part 4: code quality evaluation in the coding stage, expert review and evaluation...
5. Team Management1) Team division of labor and growth plan the Team division of labor is the balance between the project needs and the needs of the team members. A project-oriented team lacks centripetal force and continuous combat effectiveness. For example: A. A very good team member, his wife has recently been pregnant and given birth soon, so the project team should not assign him a particularly heavy division of labor. B. If a well-developed expert wants to transform to a manager, it is not appropriate to arrange for him to write code. A good project manager should understand the working background, family background, and work demands of the project team members. If a team is able to take into account the needs of most or excellent personnel and develop a growth plan with them, this kind of incentive is long-term. As Drucker said: "The essence of management is to be followed by people." 2) smooth speech (RESPECT) involves the topic of respecting others. Want to see next section: http://blog.csdn.net/liangjingbo/article/details/9008761
3) the team's slogans and Cultural Team's slogans determine the team's culture. The Slogans can be discussed and formulated by everyone. Good slogans are often short for the most critical Mental Factors of project success. I have experienced two project teams with the following slogans: A. Be careful and careful. We are more careful (this project is characterized by the code of nearly 10 branches being merged together) b. Assume your responsibilities (this project is characterized by a new module with a low degree of relevance). 4) the title of rewards and punishments is false after all. After a clear reward and punishment measure is set up, it is easier to bring culture into reality. Rewards and punishments can be applied to individuals or groups. For example: a. a project team that emphasizes carefulness needs to make mistakes when compiling and packaging problems. That person buys Wang laoji for the entire team. For those who have done the best in the Code peer review stage, reward B should be given and the responsible project team should be emphasized. If the project module is not completed on schedule, the module owner should arrange for overtime, do it yourself. In addition, rewards and punishments must have a greater impact on the team. Short-term rewards and punishments are required to timely report the current situation. A. In the short term, the reward and penalty results cannot be pulled too long and cannot be assessed at the end of the project. At this time, the project itself will no longer be affected. B. Timely reporting means to report the current data statistics weekly or daily, so as to influence everyone's daily work mentality to a greater extent. 5) milestone celebration
The importance of milestone celebration, want to see next section: http://blog.csdn.net/liangjingbo/article/details/9008789
6) The routine schedule of the project team should be clarified as much as possible, so as to avoid regular interruptions and affect work efficiency. For example, a and the project team always pack the package on Friday. After the package is completed, verify the basic functions. If the basic skills are faulty, the owner must confirm the package on the same day. Otherwise, the team should work overtime on weekends. B. The new package is automatically used every Sunday, and all test environments are upgraded. C. The weekly project meeting is held every Monday. The project manager tells the current situation of the project. D. Send the daily report to the team lead every day before leaving work, the team lead will approve the request at the next morning.
