Recently, I was lucky enough to be assigned as the main R to take charge of two projects spanning two months and involving multiple people, which was a challenge and learning opportunity for me without much project management experience before. In the process of advancing the project, I have learned a lot, so I decided to record my experience, either from my superiors or from myself, for everyone to learn. Some may seem naive, but everyone has a process of never getting there.
1. Buffer time/reserves
A project should normally have a certain amount of buffer time, because unexpected transactions, or even urgent requirements, will always come in and occupy the original development time. According to the time estimation habit brought by the superior from Baidu, a one-week working day buffer time is generally reserved for a one-month project (1.5-2 months +).
Two, hand over your work
When bringing in a new person, or a new member of your team, have the goal in mind and in your development plan to be able to hand off most of the work to the new member. In this way, it not only ensures the mutual preparation of research and development, but also enables the main research and development to have the energy to hold multiple projects without having to take care of everything, so as to avoid being involved in too many specific affairs and losing the overall grasp, and even the main research and development can be a pioneer to consider more long-term problems.
Third, conservative scheduling
When a project is committed to completion, give a conservative deadline. It is better to be seen as inefficient than to give a risky deadline with a little optimism. Failing to deliver on a promised schedule affects both impressions and performance.
If the project completion time is given externally and high quality needs to be met, schedule the project in reverse order.
It is necessary to confirm with PM external/superior requirements on project completion time to avoid: optimistic r&d schedule -> PM schedule and superior commitment -> superior attention to this matter, become a demand for high quality response -> R&D needs strong guarantee of completion on time, become the sword of Dagmoris hanging over your head.
Iv. Grasp of progress and manpower in the process
In the process of project implementation, as the main R, every day to grasp the progress and human input and output.
The first is to ensure that the progress is in line with expectations. Daily follow-up of the project progress and according to the plan can ensure that the project is completed on schedule. If the actual progress is found to be inconsistent with expectations after the project has started for a period of time, it may cause delay. The project schedule should be re-planned based on the actual development progress and synchronized to the superior and relevant departments. It is better to synchronize the schedule change earlier than the time when the project needs to be extended. For example, if the project needs to be extended by 2 weeks, the schedule should be replanned within 2 weeks after the project starts and a new schedule including the extension time should be given.
The second is to facilitate flexible scheduling of manpower to make up for the lack of project planning. For example, a sub-task takes less time than expected and has been completed in advance by team members. If the progress is mastered, subsequent sub-tasks can be assigned. If a subtask is more complex than expected, the task can be repeated according to the manpower of each task.
It is recommended to use gantt chart as a tool to plan the project schedule (You can draw gantt chart in Excel directly, or OmniPlan with appropriate learning costs). On the horizontal axis, the granularity is from time to day, and on the vertical axis, tasks are marked with cells in granularity from large to small, one minimum cell for each subtask, and the corresponding responsible person is signed. The time of the task is represented by a bar, and the color of the bar is changed if the task is completed. Example:
V. Evaluation and control of core work/key and difficult points
In the design of the scheme, the complexity of the core work/key and difficult points should be taken into account. It is necessary to think deeply about the key and difficult points and consider their feasibility, costs and benefits. These work should be presented in written form to be questioned in the scheme review. It is desirable to have experience in extrapolating approximate development costs. What can’t be confirmed in the development of core work (whether the technology can meet the requirements, meet the performance, etc.), it is best to demonstrate in the way of small-scale development and testing and learning from others’ projects before the start of the project. As long as the design of the core work is feasible and the schedule is reasonable, the whole project will not get out of control too much.
Clear goals and quantifiable expectations
In addition, in the design of the plan to always compare with the needs, to ensure that the plan does not deviate from the goal, for whether to achieve the goal, the plan is best to give quantifiable indicators, so that the superiors have confidence in your plan. For example, the new solution has been tested to support 5000 QPS, the new solution will reduce the calculation time from 2 hours to 30 minutes, and so on. It’s best not to use ratios, such as 2-10 times faster, 50% less storage, etc., because if the base value is low, your development costs may still be considered uneconomical and unnecessary by the superior. Example:
About resources: the human efficiency that a system needs to maintain, that is, the cost of human maintenance is very important. If the system, in pursuit of efficiency, improves the cost of human maintenance on the basis of effectively improving performance, that is, makes the system more complex, then unless the performance is a life-or-death line, it is highly likely to be rejected by the superior scheme. The principle of (computing/storage) resource use is that it is acceptable, even if it is used heavily, as long as it is not wasted.
Vii. Keep documents and development progress in sync
Project development often lags behind the development of documents, and due to the busy development work and cumbersome business details, there is generally not much subjective initiative to update business documents after development. However, backward documents may lead to increased communication costs when connecting with the outside world, and the cost of handing over people or training new people. Therefore, the benefits of keeping documents up to date are also worth the time spent in research and development.
It can take the scheme document before development as the skeleton, and fill in the content continuously during development. All the business knowledge and technical content needed to understand the business can be filled into each directory according to the rules, and the changes, to-do items and known problems of the scheme can be updated at any time during development. For example, if your company uses a wiki as a documentation tool, create a catalog page for the project and attach the subpages, starting with the project proposal page.
Test cases
This should be something most developers know, write test cases first, then code. If you write the code before you write the test case, you may think of exception cases in terms of code logic rather than business logic, and you may not be able to detect actual problems. Test cases can also be synchronized to documentation so that they can be used for later accountability or refactoring.