overview
Without a special reason, the word project delay cannot be said casually. If the project has just started or half of the time is left, it is irresponsible to start mentioning the delay. Because there is still a lot of room for effort, how to solve and how to deal with it is what you should think about.
If there are some risks, it will be postponed. It is difficult to explain to the boss and the business side. At the same time, it will make the boss feel that there are problems with your attitude and ability.
However, we still need to carefully analyze the reasons that may lead to the delay of the project, and take some preventive actions, so as to avoid causing the relevant participants of the project to be in a hurry and under great pressure due to the project being out of control.
possible reasons
Product PRD Questions
-
Not clear
The PRD is not clear, and the description is not clear. After reading it, there is a feeling: guess what I want to do?
This kind of problem is almost fatal, because it will bring huge communication costs to each project stage. Whether in the requirements review phase, or in the development and testing phase.
Someone may ask, can't it be aligned during the requirements review? Don't count on the requirements review. During the requirements review stage, more than N people have doubts and feel that the PRD is not clear. After the product manager adjusts the PRD, they will temporarily reach a consensus.
But judging from the actual project experience, once the PRD is not clear from the beginning, it needs to be adjusted after the requirements review, and a bunch of unclear problems will be exposed in the follow-up. This is actually a problem of the ability of the product manager who wrote the PRD. S/he simply cannot write a clear PRD.
Subsequent front-end and back-end developers and testers will often ask questions in the group or hold meetings to align issues, which wastes a lot of time and reduces the time for developers and testers to do their jobs.
-
incomplete
That is to say, there are omissions in PRD, which are not considered, which will increase the workload of developers and testers.
-
Product function design is too cumbersome
Large, comprehensive, and complex, the design of functions that could have been simplified is too complicated, which will lead to uncontrollable and increased complexity. Product managers also need to have a project perspective, and examine the complexity of the PRD they write from the perspective of overall project execution and risk.
The product PRD is the source. If there is a problem at this stage, it is generally fatal. After the product manager finishes writing the PRD, it is best to have internal audits between products, and communicate with development and testing in advance to ensure the quality of the PRD as much as possible.
Inaccurate development and testing time estimates
In other words, it is too optimistic. It may have taken two weeks of work, but it only took 3 or 4 days.
-
Evaluation of development time
For slightly more complicated modules, it is best to let senior developers who are familiar with the business help to evaluate them, and they will be more accurate. In addition, try to have technical design and technical review as much as possible. Technical design is to force yourself to think clearly about what to do and what key tasks need to be focused on. The technical review is to invite other people to review and try to go in the right direction.
-
Assessment of test time
In the same way, it is necessary to let senior testers who are familiar with the business assist in the evaluation.
communication problem
That is to say, the risks were not synchronized in time. For example, when the developer is halfway through the development task, he feels that the implementation is very difficult, but he wants to carry it out, and he only proposes it when the key milestone node of the project is approaching, which delays the construction period. In this case, it can only be avoided by means of monitoring.
You can take the initiative to inquire and understand the progress a few days before each milestone node of the project, so that relevant personnel can speak up in time. Note that it is not meant to hold daily stand-up meetings.
The problem of third-party dependence
Because third-party dependence on it is uncontrollable, if it is not sorted out and cleared up early, and the problem is not exposed until the later stage of the project, it will really be powerless. No matter how anxious you are, it is useless. Third-party companies have their own rhythm and rules and regulations, and will not listen to you. Like Meituan, Alipay, WeChat, outsourcing companies, etc., as long as the project involves a third party, everything must be clear in advance.
change of requirements
This may be due to a problem with the quality of PRD, or it may be due to external reasons, such as new ideas from the business side or the big boss.
Regardless of whether the requirement change is large or small, from the perspective of risk reduction, development and testing need to be carefully re-evaluated, which will undoubtedly add a lot of work.
R & D process system is not perfect
Many of the reasons listed above are caused by imperfect R&D process systems. The orderly execution of the project depends not only on people, but also on the process system.
The R&D process system not only needs to be followed by internal R&D, but also by R&D external products, operations and other business parties. Therefore, it is really important to have a strong leader to implement and promote this system. If there is no such person, basically the process will be implemented well, which is extremely slim.
Finally: The complete software testing video learning tutorial below has been sorted out and uploaded, and friends can get it for free if they need it【保证100%免费】
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can help you too!
