Some of my project management experience

I have not updated this blog for half a year, so I feel a bit embarrassed. However, I went to my friend's blog, and some did not update it for even a year. I can't help but think that updating blogs also requires perseverance. Many times we have been struggling with this kind of things and gradually left out what we once fell in love. At this moment, I think of the sentence "Many people are under pressure from reality ".

You can't talk nonsense, but you can't say more. Let's get started. From the recent project management process, I have summarized some superficial experiences and listed them here:

1) project cycle Estimation
Several factors must be taken into account during project cycle estimation: the technical level, professional quality, and incentive level of the project members. If you are not sure about it, we should try our best to make pessimistic estimates by first estimating the normal cycle and then multiplying a coefficient.

2) QC (Quality Inspection) as soon as possible)
In many cases, the skill level of team members often fails to meet the required goal. It would be too late to check the quality of the solution again when the solution stage is about to end, either get a summary design that is inferior, rough, and basically unusable, or prepare to announce a scheme stage extension. Therefore, QC should be started when the scheme design achieves stage results, and QC should be continuously implemented. Every key delivery should be QC (usually Requirement Analysis Report, Requirement Specification, summary design,CodeQC is required for testing cases and switching schemes ).

3) Output
The output in the development stage is not only code, but may also have performance optimization reports (for performance requirements) and configuration instructions (Configuration Module). These should be clearly arranged in the WBS (work breakdown structure).

4) tracking of fuzzy tasks
When switching close to the phase, there are many fuzzy tasks that need to be tracked using checklist. For example, when switching to the SIT (System Integration Test) phase, it is necessary to track the implementation of design review opinions and code review opinions, and this tracking should be conducted as early as possible, and members should be reminded to give feedback as soon as possible.

5) clear tasks
Do not assign fuzzy tasks to project members. Any task must have clear output. Similarly, a clear template should be specified for document writing tasks.

6) reserved uncontrollable time
There are a lot of progress that cannot be grasped by the PM. For example, if you submit the official tr (Review), you should reserve enough time to avoid adverse impact on the overall progress of the project.

7) Test
The test plan of the system is required. Like the test, a matrix is used for tracking. Each Function Point and unexpected situation must be tracked. Blind tests often detect problems, but they are more likely to miss out more important problems.

8) work logs
No matter what the project members do, they should be asked to use work logs to record them. This prevents laziness.