Project postponement is probably a problem that every product manager will encounter, and there are many patterns of postponement. There are postponements caused by unclear demand and postponements caused by change in demand.
Introduction
The project is postponed, which is probably a problem that every product manager will encounter, and there are many patterns of postponement. There are postponements caused by unclear demand and postponements caused by changes in demand.
But in the end, it ’s actually the product manager.
We all promote result-oriented. For product managers, the so-called result means that a certain function is put into the market and received market data feedback. The impact of the delay is not simply a delay in launch time, but a market Delays in feedback, when serious, may cause the project to die, and there is no need to go online.
It ’s like epidemic-related functions. If they have n’t been used yet, there is no need to go online again. After all, people ’s needs have decreased, and many people have now turned their attention to work and life. .
So, in the end, it ’s still the product manager. We can avoid accountability and blame the cause and development, but it does n’t help. The market that we missed is no longer coming back. Rare events ca n’t be copied. The air vent was just lost.
Why is the project delayed?
Extension, on the surface, means that the actual completion time is later than the expected completion time. In fact, this is wrong, the perspective is wrong, and this is the development perspective.
The perspective of the product manager is the opposite of the development perspective. For us, the delay is because the “expected completion” time is shorter than the “actual completion” time.
The problem is not at the time of actual completion, but at the time of completion of our expectations.
Zhang San has a distance of 100 meters from the end point. We expect him to reach the end point within 5 seconds, but in fact he took 15 seconds. From the perspective of the result, Zhang San has “delayed”.
On the surface, if Zhang San runs faster, he may be able to arrive faster, but at least for more than ten years, it is unlikely to reach within the expected time.
Because of the current world record of 100 meters, Bolt, known as the trapeze, also takes 9 seconds 58 to complete. 15 seconds is the goal that most ordinary people can accomplish.
If we look at the development perspective and locate the extension problem beyond the expected time, it will be a dead end, and this is a very unprofessional idea.
People are greedy, and product managers are no exception. We always want to implement a certain function faster, one week, no, tomorrow, 1 day, no, just give you 1 hour, and finally we will fall A kind of dilemma, constantly demanding fast, constant disappointment, and constantly raising the requirements for research and development.
Actually, the problem still exists. Human greed is endless, and product managersIt ’s human. You can do it in a week. I will ask for 3 days. If you can do it in 3 days, I will ask for 1 day. If you can do it in 1 day, I will ask for 1 hour. At the same time, it’s not just the actual completion time that is shortened, but also the time that product managers expect to complete.
In a sense, this situation is like the boss has arranged a task, which actually takes one week to complete, but requires you to give a solution one day, which is the same.
Many times, a product manager unconsciously becomes the one who hates himself, doing what he hates, but he doesn’t know it.
Essence of extension
Most of the delays are because we directly affect the expected time to the actual completion time, but the product manager actually does not have the ability to estimate time, especially for some more complex requirements, we cannot predict it. As a result, the expected time is often unreasonable.
The same requirements require different technicians to have different time, and even if the requirements are the same and the developers are the same, but the code environment and the business environment are different, it will lead to deviations in the actual time required.
So product managers ca n’t predict the development time. It ’s not just a “not knowing technology” problem, but a more objective phenomenon. It ’s not the actual operators. Most of the predictions put forward are not accurate.
A lot of times, the product manager will have the illusion. If I can tell me that it will be postponed earlier, I will not design it like this, and feel like I have been pitted.
On the one hand, the expected time is unreasonable, and on the other hand, because the expected time directly affects the actual completion time, such a feedback cycle is too long, and we can only get a “will be delayed” feedback before we go online. Extremely passive, it is too late to make adjustments and can only be postponed.
The third time: forecast time
If, when we put forward the expected time of 4 days, can someone tell us that it may be postponed for 1-2 days, would it be much better?
We can completely subtract requirements before development, simplify complex logic, remove unnecessary functions, and lower the priority of unimportant functions.
This minimizes the risk of delays.
So, the core of the product manager’s solution to the delay problem is not to work overtime, not to change development, but to seek a “forecast time”, how much time is expected to complete.
This forecast time can only be provided by R & D, which is what we call R & D estimation, and only the time forecast provided by actual R & D can be trusted. Everyone’s technical experience is different. Even his leader, the estimated time provided by the assistant
For reference only.
There are some technology-driven teams, the CTO is relatively strong, and often makes some time commitments, like thisThe function is very simple and can be achieved in one day.
Technical staff of this team are usually more fortunate. Maybe it takes only one day for cto to do it by itself, but the actual operation is not CTO, but other technical staff, which may take 2 days or more. Time to complete.
After all, everyone ’s experience structure is different. Whether it can be achieved is a matter of ability, and whether it can be completed quickly is an issue of experience. Then, if you have the ability to research and meet things you have n’t done, you need some time to research , Will go through the process from slow to fast.
By the way, this type of team is often the hardest hit area for overtime and postponement.
Introducing the forecast time can give the team two possibilities, one is helpful for the product manager to control the risk of delay, and the other is for the objective and coordinated management of the R & D team.
Front adjustment
Comparing the expected time with the predicted time, you can adjust the demand at the beginning, which is the most effective way to avoid delays.
The expected time is greater than the predicted time:
It means that the risk of postponement is relatively low. We can try to add some experience requirements to make the product more perfect, or we can share a part of the experience to do some market warm-up actions.
The expected time is less than the predicted time:
Represents a higher risk of delay. The greater the difference between the two, the higher the risk of delay. Exceeding the threshold is basically the delay. In this case, we can try to subtract demand or simplify demand. Method to reduce the prediction time, or you can adjust the expected time to make the difference between the two effective.
This is one of the most effective ways to reduce the delay rate.
Risk threshold:
When conducting R & D time forecasting, it is generally important to forecast based on working hours. It is very important that product managers are also obliged to remind R & D to forecast based on working hours. Do not default to rest time. We do not advocate default overtime.
Based on this, the amount of overtime that can be worked each day corresponding to the working hours of the same period is the floating upper limit value. This value is also regarded as the threshold for delay risk.
If the difference between the expected time and the predicted time can be compensated by this part of overtime, then the risk of delay is still controllable, but you need to clearly communicate with the team before the start. In order not to delay, we will You need to work overtime.
Everyone is disgusted with the unexpected overtime, but it is easy to accept a lot of overtime notice in advance, because we can arrange our lives in advance, so as not to be busy, this is our basic respect for the team.
Suppose we have a demand, the expected time is 8 days, the forecast time is 10 days, 8 hours of work time per day, that is, an additional 16 hours are required, 2 hours of overtime per day, and 8 days of overtime. The task was postponed.
In general, the difference between the predicted time and the expected time cannot exceed 20%, but each team can also adjust the risk threshold as appropriate according to its own situation.
Post Boost
Comparing the predicted time with the actual completion time can provide a good basis for the team to review after the launch, and help the team grow. In the long run, only when the team is strong enough can it catch the increasingly fierce competition. Stay alive.
The purpose of post-upgrade is to make the prediction time highly consistent with the actual completion time, and then to have high-accuracy time prediction capabilities in future iteration cycles.
So-called wars are supported by war.
The predicted time is greater than the actual completion time:
Representing the inaccurate estimation, overestimating the complexity of the requirements, and also representing the distrust of the quality requirements of the product manager or team by the R & D personnel, and more time reserved.
The predicted time is less than the actual completion time
It also means that the estimation is inaccurate, but this inaccuracy usually means that the R & D personnel underestimated the complexity of the requirements. In the evaluation, the consideration was not comprehensive enough. At the same time, it may also indicate that the quality of the requirements is low and more occurred in the process The change.
Dynamic adjustment
The purpose of post-upgrade is to improve the team as a whole. It can reflect both the quality of the requirements and the problems of the actual R & D operations. However, the core is still to adjust the problems after they are discovered to promote the growth of the team. .
The recurring forecast time is greater than the actual completion time, which can be discounted at the time of forecasting. On the contrary, when the recurring forecast time is shorter than the actual completion time, the corresponding reserve time can be increased during the time forecast.
With the comparison of the “expected time”, “predicted time”, and “completed time”, the risk of delay can be minimized, and this reduction is sustainable.
At the beginning, it may be unfamiliar, but the delays that were originally difficult to measure and difficult to measure have become measurable. The situation that cannot be controlled will gradually become quantifiable, and the deviation from ten hours will gradually decrease to 3 Hour deviation, 1 hour deviation, 0 deviation.
Finally, the chances of extension are reduced continuously.
Summary
Product managers are a very special industry. Our needs come from problems, and our solutions come from needs. Therefore, with this concept, all problems are the problems of product managers.
For other industries, the problem may be directly equivalent to backselling. However, different product managers, who embrace the problem, can explore the needs from the back of the problem, and then provide solutions to meet the needs and solve the problem.
Like extensions, once you place responsibility on development and “too long to complete”, you will not find a solution. After all, we have no way to let the developmentThe code is written a little faster, and it cannot help developers write code.
Only by bearing the problem on your own, taking the problem from the perspective of the product manager, and analyzing the problem, can we solve this problem in our way.
Author introduction
Dead leaves, 9 years experience product person,
Public Account: Dead Leaf Cafe
Write your own experiences, experiences and methods, and set up a product manager communication group to discuss with everyone, learn together, and grow together.