preface

Recently, I was working on a big project, and with the 1.0 release of the project, the work on this part came to an end. Since I have been in the company for more than a year, the leader wants me to take charge of this project independently. Finally, I finished it on time. During this period, I also had a lot of mistakes and gained a lot of experience. I hereby organize an article to share with you.

Sharpen the axe before you chop the tree. – Familiarize yourself with the requirements

After the requirements review, the actual construction period is not ideal for us. In the past, projects that were done in a hurry were always done as soon as they were taken, and they often ended up not meeting the needs or not thinking comprehensively. This time I redrew the flow chart according to the prototype diagram. This has two advantages:

1. As the project leader, I can know the overall process more comprehensively.

2. It is convenient for me to split the system and reasonably judge the construction period.One might argue that a prototype diagram is enough to understand the desired outcome of the product. Draw your own flow chart to understand the project from a development perspective. After the completion of the drawing is often with the product again, on the one hand to check whether our understanding is consistent, on the other hand to check whether the product logic can be optimized.

Reduce risk by using areas you are familiar with

At the beginning of the architecture, I also considered using new technologies, new components. But if the program is left to others to maintain or collaborate with, more knowledge is often required. It just adds to the cost of entry and maintenance, and I’m not much of a risk taker. The architecture was finalized using the same solution as the old system, reducing previous redundant code and simplifying configuration.

For example, instead of importing components one by one, you import them globally. I built the architecture with the idea of simplicity, high maintainability, and using as little code as possible.

The importance of proper progress assessment to the project schedule

1. Period assessment

Before the project began, the team members could not give a clear figure of their required man-hours.

First, the front-end and back-end tasks are divided into three modules: management development, front-end display development, back-end docking with other services

Then calculate the total number of pages according to the design draft:

Previous experience shows that the front-end work is divided into three parts:

Static page writing (40%), back-end interface docking and page logic adjustment (50%), self-testing (10%)

With the final delivery date as the deadline, you can get an idea of what to do and whether to delay each phase.

2. Progress follow-up

Once you’ve made the plan, you can follow up. At present, I hold morning meetings every day to keep up with the progress of team members. Team members need to update progress documents daily:

Progress documents include: time remaining, percentage remaining, what is done each day, and risks and challenges.

At key points, team members are also required to demonstrate the results. On the one hand, it is convenient for team members to get familiar with their own processes, and on the other hand, we can evaluate together whether there are still areas that can be optimized.

The lack of problems is the biggest problem

Everybody’s happy that nobody’s exposed at the morning meeting, but that’s usually the riskiest one. At the end of the morning session I will highlight if there are any questions or if there is any coordination. I’ve seen too many projects delay or go wrong because they didn’t expose their risks in time.

As an old saying goes, “For every serious accident, there must be 29 minor accidents, 300 near-misses and 1000 potential accidents”. Risks and problems exposed and solved in the first time will usually minimize losses.

I also reminded everyone to be exposed in time in my blog. Fortunately, the team members were very active and new problems were exposed every day. While I was busy solving problems, I also felt a real sense of security.

Last word

After this project management, I learned a lot. Managing a project is not about working alone. The most important thing is to listen to team members’ feedback in a timely manner. Each team member has his own advantages, and proper distribution can bring out the maximum value of each member.