The law of construction 800 characters Feedback

Recently saw the "8.6 Plans and estimates" section of the Law of construction, a lot of feelings. Over the years, different stages have different knowledge and mastery of the project plan.

Reference was made to several concepts of planning: objectives, estimates and determination.

Goal: Indicates a state of hope to be reached. For example, the software "51" before you put on the market! At the 100 anniversary of the school built our school into a world-class university! No matter how important such goals are, they may not be achievable.
Estimate: With the current understanding of the situation and the resources available, it will take much human and material time to achieve something.
Determination: Ensure that pre-defined functions and quality are fulfilled at a certain time. For example: We run forward, the whole people steelmaking, two years of super-English drive the United States!
Sophomore summer vacation, from the school BBS on a reverse telecommuting, to help people do an office OA system, the first independent to do the project, the employer gave me a person's office system, let me imitate to do a, functional interface style are the same, gave one months of time, the result is my last week in the computer room to boil a lot of days overnight, Came out before the point of time. Now look back, this is actually only the goal and determination, without any estimate, if the target is a little bigger, if it is not young when the body good to stay up late, is not likely to complete.

But even if there is an estimate, it does not mean that a reasonable plan can be made. After graduating from work, in a project, the project manager assigned me a more complex function, let me estimate the time, I am optimistic about the estimate, think three weeks can be done, the project manager is not at ease, give me a one-month time count, as a result of my eager to apply some unfamiliar new cool technology in the project, Addicted to technical details, resulting in a one-month time or failed to finish on time, resulting in the overall project delay, the final project manager was criticized.

I've made a similar mistake, and I've seen a lot of programmers make a similar mistake: to indulge in technology, ignore progress, and cause the program to fail on schedule, so I try to make some changes later on:

For unfamiliar and immature technology, do not apply to the project as far as possible, use the time outside the project to learn the experiment, and then apply it after validation.
The project plan is refined, can not say a functional module for a week, to the effort to refine the plan to the day, so that early detection of problems.
Set the key point in time, at this point in time, need to deliver certain things out, so that you do not dare to waste too much time in a particular detail.
Later, when I started to do project management, in the project plan when the relative experience, in fact, self-management is the most difficult to manage others to be relatively easy. But even so, there are a lot of problems when it comes to project planning.

The first problem is how to do the team project plan, the previous self-planning, relatively easy, but if the whole project plan to do together is more troublesome, each person's ability level is different, the estimated project optimism is not the same, it is not easy to coordinate.

At the beginning, I tried to write the code in accordance with their experience to assign tasks and plans, such as the user registration module I think I need three days, to Zhang San do, Zhang San experience than I rich, then Zhang San should be four days to fix, give him four days time. The plan was soon made, but the problem was coming:

First of all, the accuracy is not high, the error is relatively large, each person actually in the process of doing will encounter a variety of problems, such as mentioned earlier let a three or four days to complete the registration module, perhaps he has not done before, and just the environment is not familiar with, then perhaps four days at the end of the impossible. It's also possible that he was using some of the existing third-party modules and completed this function in a day or two.
Then, when the plan is inaccurate, the project members will have emotions. For example, the registration module let three or four days to complete, the result is more complex than expected, resulting in Zhang three overtime to reluctantly complete, Zhang San will think, this function I thought four days not enough, you only give four days, this is not deliberately embarrassed me?
So try to make adjustments, the Functional module Division and division of Labor, let team members to estimate time, in the implementation of a period of time, everyone's enthusiasm is improved, their own plans, with tears to finish on time, but there are new problems:

The previous plan is the project manager handedly, and now need to make plans for themselves, many people in the planning time to understand the project needs, in the case of the need to make a plan is not reliable
Some people's plans are too optimistic, not to anticipate the complexity of the project, resulting in the final project is difficult to complete, some people are lazy, the plan is always very loose.
Obviously project managers want to be Shang is unrealistic, so later in the project planning, I usually divided into the following steps:

The first step is to start estimating the project plan when the target (project needs) is clear, and the accuracy does not need to be too high to be accurate to weeks.
The second step is to synchronize the project requirements and team members to ensure that the project members fully understand the project requirements and assign the tasks to the project members to evaluate their own project plans.
The third step, the project members of the plan of one by one verification, referring to the first step of the estimated time, for overly optimistic and too loose, should be together to refine the plan, details carefully discussed, to ensure that the plan is scientific and reasonable
Fourth, complete the final plan and identify several key milestones to ensure that certain content is delivered at the milestone

This way down, the plan is relatively more reasonable, keep track of progress, especially the milestone point of the grasp, there is basically no too much problem.

But the project plan is still vulnerable to external influences. In the law of construction, it is mentioned that the time estimate of a software project can be viewed from two aspects:

From bottom up. Team members each estimate the time required for the underlying modules and individual functions (and unit tests), plus the time for integration and basic testing, which is the approximate development time. This does not take into account the interdependencies between the modules.
Backtracking. The team pushed backwards from the day the project was finally delivered.
Unfortunately, most of the projects I've seen are using backtracking to make plans, such as the client says, I have to go online next month, for example, if you report to your boss in accordance with the 2-month project plan that you've made at the bottom up, the boss says 2 months is too long and hopes to see it in 1 months.

In fact, the problem in software engineering is a very typical problem, some of the more slippery project managers will be reported to the boss of the progress of a larger buffer, such as the original two months can be done, the report is three months, then the boss pressure, there are two months time, this is not happy! However, this is only "surgery", play more is exposed after the no play.

So what is "Tao"? In the construction of the law there is a "function/resource/time Balance Chart", very vividly illustrates the relationship between these elements of the project.

Project management is also a way to balance, now in the case of resources unchanged, time is shortened, either to sacrifice the function, or to sacrifice quality. Generally in this case, if it is not a one-time product, I usually choose to sacrifice functionality, the quality of the debt owed is to be doubled, the function can be improved through the version of the iteration.

In addition to the shortened time that leads to a change in the plan, there is also an important element of a plan change that comes from a change in demand! It is said that because of the change in demand, the product manager or the boss was cut by programmers many examples! In fact, the change of requirements in the Software project development is the norm, there is no need to be too inconsistent, but the need for scientific management. In general, the longer the project cycle, the greater the impact of changes in demand! So now the general Internet projects, are compared to the pursuit of functional streamlining, fast online, after-line continuous iteration.

In the face of some problems affecting the project plan, I generally deal with the following principles:

For the need to shorten the planning time, according to the situation to reduce some features or sacrifice quality, and bear the corresponding consequences
For changes in requirements, the assessment has a greater impact on overall progress:
If the impact is not large, then the overall project plan is not changed, only local adjustment
If the impact is large, then to re-establish the overall project plan, take the corresponding requirements change process
At the same time, in order to be able to change the corresponding requirements in time, it is necessary to select the function of each phase of the project, rationally match the core function and peripheral function, and make the project cycle in a relatively controllable range.

Project planning is a very important part of project management and does not plan to be non-managed. Different projects of different teams, the way the project plan is different, but original aim, is still in the software engineering construction of the law to master and use.

The law of construction 800 characters Feedback