In the best case, managing software projects is also very difficult. Unfortunately, many new project managers are essentially not trained on their posts. There are 20 successful management experiences for the project manager's reference.
1. Define criteria for successful projects
At the beginning of the project, it is necessary to ensure that risk owners have a unified understanding of how they determine whether the project is successful. Often, meeting a predefined schedule is the only obvious success factor, but there must be other factors, such as increasing market share and obtaining a specified sales volume or sales volume, obtain the satisfaction of a specific user, eliminate a legacy system with high maintenance requirements, obtain a specific transaction processing volume, and ensure correctness.
2. Identify project drivers, constraints, and Degrees of Freedom
Each project must balance its functionality, personnel, budget, progress, and quality objectives. We define every aspect of the above five projects as a constraint. You must operate on the constraint or define the driver corresponding to the project success, or define the degree of freedom to pass to success. You can adjust it within a specified range.
3. Define product release standards
In the early stage of the project, determine the criteria used to determine whether the product is ready for release. You can set the release standard based on the number of high-priority defects, performance metrics, and specific functions that can be fully applied, or other aspects that indicate that the project has achieved its purpose. No matter what standard you choose, it should be achievable, measurable, documented, and consistent with the "quality" that your customers refer.
4. Communication commitment
Despite the stress of committing events that are impossible, never make a promise that you know you cannot guarantee. Communicate with the customer and management personnel about what can be actually obtained, and have a good reputation. Data from any of your previous projects will help you make convincing arguments, although this does not really defend against unreasonable people.
5. Write a plan
Some people think that it is better to spend time writing code to write a plan, but I do not think so. The difficult part is not writing a plan. The difficult part is to make this plan-think, communicate, weigh, communicate, ask questions, and listen. The time it takes you to analyze and solve the problem will reduce the project's future surprises.
6. Split the task into small circular stones in inches.
An inch-sized round stone is a milestone for narrowing down. Breaking up large tasks into multiple small tasks helps you estimate them more accurately and expose work activities that you might not think of in other situations, it also ensures more accurate and fine-grained status tracking.
7. A common large task Development Plan Worksheet
If your group often undertakes certain common tasks, such as implementing a new object class, you need to develop an activity check list and a plan worksheet for these tasks. Each check list should include all the steps that may be required by this large task. These checklists and worksheets help the team members determine and evaluate the workload associated with each instance of the big task they/She must handle.
8. modifications should be made after the quality control activities in the plan
Almost all quality control activities, such as tests and technical reviews, will discover defects or other possibilities for improvement. Your project progress or work breakdown structure should include the modifications made after each quality control activity as a separate task. If you don't actually need to make any changes, well, you are already ahead of the plan for this task. But don't count on it.
9. Schedule for process improvement
Your team members are already drowned in their current projects, but if you want to upgrade your group to a higher level of software engineering capabilities, you must invest some time in process improvement. Set aside some time from your project progress because software project activities should include process improvements that can help your next project be more successful. Don't invest 100% of the time your project members can use in project tasks, and be surprised why they are not making any progress in active improvement.
10. Manage project risks
If you do not identify and control risks, they will control you. Spend some time in project planning to discuss possible risk factors, assess their potential hazards, and decide how you can mitigate or prevent them. A Brief Guide to software risk management.
11. Estimate based on the work plan rather than calendar
People usually use calendar time for estimation, but I tend to estimate the number of Work Plans associated with the task (in person-time units) and then convert the Work Plan into Calendar time estimates. This conversion is based on how many hours I have spent on project tasks every day. I may encounter any interruptions or sudden adjustment requests, meetings, and all other places that will make time disappear.
12. Do not schedule more than 80% of their time
It is surprising to track the average number of hours your team members actually spend on the specified work in the project per week. The overhead of task switching related to the many activities we are requested to do significantly reduces our work efficiency. Don't just assume that someone spends 10 hours a week on a particular job. Assume that he or she can do four of these jobs right away. If he or she can finish three jobs, you are lucky.
13. Put the training time into the plan
Determine the amount of time your team member spends on training each year and deduct the time that the team member can work on a specified project task. You may have earlier lost the vacation time, illness time, and other time in the average value, and the training time should also be handled.
14. Record your estimation and how you achieved the estimation
When you are about to estimate your work, record them and record how you complete each task. Understanding the assumptions and methods used to create estimates makes it easier to guard against and adjust them when necessary, and it will help you improve your estimation process.
15. Record estimation and use estimation tools
Many commercial tools can help you estimate the entire project. Based on the huge database of their real project experience, these tools can give you a possible schedule and staffing options. They can also help you avoid entering the "impossible Area", that is, the product size, group size, and schedule. If they are combined, there is no known project success. The estimate pro of software producticentre (www. SPC. ca) is a good tool.
16. Follow the learning curve
If you try a new process, tool, or technology for the first time in a project, you must acknowledge the cost of reducing productivity in the short term. Do not expect amazing benefits from the first attempt of the new software engineering method, and consider the inevitable learning curve in the schedule.
17. Unexpected buffering considerations
Things won't be as accurate as your project plan, so your budget and schedule should include unexpected buffering at the end of the main phase to adapt to unexpected events. Unfortunately, your manager or customer may use the buffer as a filler, rather than wisely admitting that this is true. It indicates some unpleasant accidents of the previous project to illustrate your foresight.
18. record the actual situation and Estimation
If you do not record the actual working time spent on each task and compare it with your estimation, you will never be able to improve your estimation capability. Your estimation will always be a guess.
19. The task is considered completed only when task 100% is completed.
One benefit of using an inch-sized xiaoyushi is that you can differentiate whether each small task is completed or not completed, this is much more than the estimated percentage of a large task completed at a specific time. Do not let people simply ignore the completion status of their tasks; Use clear standards to determine whether a step is actually completed.
20. Publicly and fairly track the project status
Create a good atmosphere, so that project members can accurately report the status of the project and feel safe. Efforts should be made to allow projects to run on an accurate, data-based basis, rather than a misunderstanding of optimism arising from fear of reporting bad news. Use the project status information to perform corrective operations when necessary and give praise when conditions permit.
These tips cannot guarantee your success, but they will help you to gain a solid lead in your project, make sure that you have done everything you can to make the project succeed in this crazy world.