Author: Karl E. Wiegers Source: systems analysis window
Even under the perfect conditions, it is also difficult to manage a software project. Unfortunately, many new project managers are essentially not subject to any in-job training. Here is 20 successful management experience for project managers. However, relying only on one of the two "计", it is unable to complete the project.
1. Define the standard of successful project
At the beginning of the project, it is necessary to ensure that the parties have a uniform understanding of whether the project is successful. Usually, the scheduled progress is the only obvious success, but there are other factors, such as increasing market share, obtaining a designated sales volume or sales, achieving a specific user satisfaction, eliminating a high maintenance demand Legacy system, etc.
2. Grasp the balance between various requirements
Each project needs to balance its function, personnel, budget, progress, and quality goals. We integrated each aspect of the above five projects into a constraint, you must operate in this constraint; you can also define the driving force corresponding to the successful corresponding to the project, or define the freedom to success. . Can be adjusted within a specified range.
3. Define product release standards
In the early stage of the project, we must decide what criteria to determine if the product is ready to be released. You can put the publishing standard based on: how many high priority defects, performance metrics, fully operable, or other aspects indicate that the project has reached its purpose. No matter what standard you have chosen, it should be realized, measurable, documentated, and consistent with the "quality" referred to by customers.
4. Communicate commitment
Although it may be inadvertently committed to impossible, don't be a promise that you can't guarantee. Advanturely communicate with customers and managers those practical results. Any previous project's data will help you to persuade their arguments, although this is no truly role for people who don't say.
5. Write a plan
Some people think that it is not as good as spending time to write code, but I don't think so. The difficulty part is not a write plan, and the difficult part is to do this plan - think, communicate, weigh, communicate, ask questions and listen. You need to analyze the problem that the problem needs to be taken, and it will reduce the accident after the project will bring you.
6. Decompose the task into "small round stone"
"Small round stone" is a narrowed milestone. Decompose big tasks into multiple small tasks to help you estimate them more accurately, exposure to work activities you may not think in other cases, and ensure more accurate, fine status tracking.
7. Develop plan worksheet for large tasks
If your group often assumes a specific general task, you need to develop a list of event checks and scheduled worksheets for these tasks. Each checklist should include all steps that this big task may need. These checklists and worksheets will help team members to determine and evaluate the workload associated with the big tasks he must handle.
8. In the plan, there should be modified work after quality control activities.
Almost all quality control activities, such as testing and technical reviews, will find defects or other possible possibilities. Your project progress or work segmentation structure should be modified after each quality control activity, as a separate task involves it. If you don't have to do any changes, you have already walked in front of the plan.
9. Arrange time for "process improvement"
Your team members have been flooded in their current projects, but if you want to upgrade your group to a higher software engineering ability, you must vote for some time on "process improvement". Leave some time from your project schedule, because software project activities should include process improvements that can help you get a more successful next project. Don't put 100% of your project members into project tasks, and then surprised why they don't have any progress in active improvement.
10. Risk of management projects
If you don't identify and control risks, they will control you. Take some time collective discussion possible risk factors while the project plan, assess their potential harm, and determine how you mitigate or prevent them. 11. Estimate the work plan rather than calendar
People usually make estimates in calendar times, but I tend to estimate the number of work plans associated with tasks ("people" as the number of "and then convert the work plan to the calendar time. This conversion is based on how much effective hours spending on project tasks every day, and any interrupts or burst adjustment requests, meetings I may encounter, and all other places will take time.
12. Don't arrange the number of tasks more than 80% of working hours
Tracking your group members average the average number of hours actually spent on the project specified in the project, it will be surprised. The overhead of the task switches related to our many activities we have to do, significantly reduced our work efficiency. A employee worked in a week, but not just because someone spent 10 hours a week, he would assume that he or she could do 4 this task immediately. If he or she can handle 3 You are very fortunate.
13. Place the training time in the plan
Determine how much time your team spent annually, and subtract it from the group employee to the available time on the specified project task. You may have subtracted vacation time, time and other time in the average, and the same processing is also processed for training time.
14. Record your estimation and how you estimate
When you are ready to estimate your work, record them and record how you complete each task. Understand the assumptions and methods used to create estimates, making them easier for protection and adjustments when necessary, and it will help you improve your estimation process.
15. Record the estimation and use the estimation tool
There are a lot of business tools to help you estimate the entire project. These tools can give you a possible schedule for you, based on their real project experience. They can also help you avoid entering the "impossible area", which is about to combine the task, group labor, and progress arrangements. It is impossible to succeed.
16. Comply with the learning curve
If you try new processes, tools, or technologies in the project, you must withstand the cost of productivity reduction in the short term. Don't expect to get amazing benefits in the first attempt of the new software engineering method, consider inevitable learning curves in progress arrangements.
17. Consider unexpected buffering
Things will not be performed as accurate as your project plan, so your budget and schedule should include some unexpected buffers at the later stage to accommodate unpredictable events. Unfortunately, your administrator or customer may use these buffers as your truth, rather than understanding facts in mind. Show them some unexpected unexpected incidents, and you will understand your deep.
18. Record the actual situation and estimation
If you don't record the actual working hours spending on each task, you will never improve your estimation ability, and your estimation will always guess.
19. Only when the task is 100% complete, it is considered that the task is completed
One advantage of small round stone using inches is: You can distinguish whether each small task is either completed, or not. This is much more than estimating how much a big task has completed at some time. Use a clear standard to determine if a step is true.
20. Open, fair tracking project status
Create a good atmosphere, let the project members feel safe about the status of the project accurately. Strive to make the project on the exact, data-based facts, rather than the misunderstanding optimism caused by fear of reporting messages. Use the project status information to correct the operation when necessary, and praise when the conditions are allowed.
