This is my answer to a question on Zhihu entitled "How does a product manager communicate with engineers about time progress?" The original post is here http://zhi.hu/d6Nj
I've been skeptical about how to estimate how long my assigned tasks will take, and every time my manager asks me this question I can't confidently give a time I feel confident and not wasting .
I have been developing at my current company for 9 years, and there is almost no delay in delivery, and I rarely need to work overtime to avoid delays. But I'm still confused about estimating the time accurately, because I feel like a big factor in the above is that our company is not a fast-paced and stressful company. In such an atmosphere, developers are allowed to give a relatively safe estimated time, and I think the price paid is that the development efficiency is somewhat low. Here are a few suggestions that I think will be helpful in estimating time accurately.
First, meet the premise before starting the estimation. I think there are two prerequisites for starting time estimation, one is to clarify the needs, and the other is to clarify the plan to be adopted. Once you know what to do and how to do it, you can talk about how much time to spend. Tasks with relevant experience for technicians may soon lead to technical solutions. However, proposing possible technical solutions for new tasks without relevant experience, verifying the feasibility itself is a time-consuming process. One option at this time is to leave it to someone more experienced to determine the technical solution. Another option is to stop estimating time and schedule a research assignment first. Give a limited time, 1 week, 2 weeks, 1 month. If you don't have a solid idea of how to accomplish the expected goal after the time limit, it's not necessarily a bad thing to abandon the project.
Second, whoever does the work is left to estimate, and the efficiency of different developers may vary by dozens of times.
Third, break down large tasks into small tasks for estimation, but reserve time for integrating the small tasks. I think the granularity of the tasks is broken down to 1 to 2 days is more appropriate.
Fourth, work efficiency is flexible, if the pressure is higher, the efficiency may be higher. But efficiency cannot increase infinitely with pressure. The completion time under pressure is not necessarily an accurate time. If it is completed this time, it may not be completed next time. This time it is completed, the process is very painful, and the next time it may be unwilling to complete it. The pursuit of efficiency should be at the value level of the entire team. By allowing team members to share the results brought about by high efficiency, let team members spontaneously and proactively give an accurate time when estimating, instead of trying to be as “safe as possible”. "time.
