In fact, being a project manager is really not a good career, it takes too much practice to cultivate. Not only does this require repeated failure-summary-failure cycles, but it also requires an incomparably strong heart, the ability to persevere and not get discouraged through countless difficult and frustrating moments. A project manager is like a general. Generals have died in a hundred battles, and the project manager, after going through countless projects, is more exhausted and vicissitudes of life. All good project managers have to go through the lessons of project failures again and again. It seems that only failures can leave them with deeper lessons and greater improvement. Of course, such failures can be big or small. Even if some projects are finally successful, it is only the success of the results, and mistakes in the process of the project, as well as the increase in cost and the twists and turns of the process, are also a failure. The difficulty of project management is evident in the difficulty of being a project manager. The real difficulty of project management is that there are too many things to pay attention to in order to do it well. Failure to do a good job in any one aspect will result in the failure of the project. The risk of software development proposed at the beginning of the article is essentially the risk of software requirements, which is demand management in project management. The failure of requirements management is the root cause of most project failures, including the accuracy of requirements understanding, the management of requirements change, and so on. This article discusses iterative development, which is to bring a way of thinking to demand management. Another very important aspect is project schedule management. After the project plan is drawn up, it must be carried out according to the project plan, and any project delay will be a huge risk. How to avoid project delay is the key factor for project success. As a project manager, how to avoid project delays? That is to clearly know "where you are" at any moment of the project, and let the user know "where you are" clearly. where you are, for us, is how far the project has progressed. We have to ask us this question at any time, evaluate the deviation of the project progress at any time, and make timely adjustments so that the project can be delivered on time. How to do this? We have formulated a detailed project plan, in which the time for each work is set out. This plan is our beacon. By comparing the plan with the progress, we can know the deviation of the project progress at any time. At the same time, make a Burn-Down Table, keep an eye on how much work is left unfinished and how much time is left, so that you can intuitively understand the progress of the project from another perspective. When the demand changes, it will inevitably lead to an increase in the workload. Readjusting our project plans is like readjusting our routes. It also includes realigning our people, our division of labor, and our schedules to match reality. Then we can move forward according to the new route (the failure of many projects in the past is precisely because the original route is still followed after the change, and the risks can be imagined). Don't forget our Burn-Down Table while finishing the project plan revision. We want to reassess our remaining workload and remaining time, plotting to the current time. Only in this way can we know "where you are" at any time and monitor the progress of the project effectively. So why make it clear to users "where you are"? The implementation of a software project is not only our own business, but also the customer's business. Once the project is carried out, the client and us are actually grasshoppers tied to a tree. Letting customers know our progress can increase their trust in us; letting customers know our difficulties will allow them to work with us to find ways to solve problems and avoid project risks. This is actually beneficial to everyone, so why not do it? Therefore, iterative development plays a huge role in effectively avoiding the risks of software development. But the problem is, how to actually use it in the project is a huge challenge. Many problems need to be solved. We can only keep searching, summarizing, summarizing, and summarizing again••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
Reprinted from http://fangang.iteye.com/blog/1222687