预估时间的艺术：研发说「两周」时你该追问什么

微信扫一扫，分享给好友

关闭

研发说「这个功能两周」，三周后进度条走到60%——这几乎是所有产品团队的保留节目。问题往往不在研发的能力，而在「两周」这个词里压缩了太多没被拆开的假设。更麻烦的是，延期之后排期表的信用受损，下一次预估大家都会默契地先放水20%，整个团队的预估体系就此失真。

「两周」里面藏着什么

当研发说两周时，他默认的可能是：需求不变、没有线上故障、依赖方按时交付、测试环境正常。任何一个假设破产，时间都会翻倍。PM该做的不是压价，而是把假设摆到桌面上——假设被说出口的那一刻，它的脆弱性就暴露了。

追问清单

听到预估后，依次确认五件事：

• 范围边界：「两周」覆盖了哪些页面、哪些异常分支？哪些明确不在内？写下来，别留在空气里
• 风险预留：里面有多少是「有把握的时间」，多少是「拍脑袋的乐观」？乐观的部分对应什么风险？
• 依赖项：需要设计稿、第三方接口、数据同学配合的部分，各自的交付时间？依赖方的延期算谁的？
• 检查点：第几天能看到第一个可测试版本？而不是最后一刻才见到全貌
• 定义完成：上线算完成，还是稳定运行一周算完成？「完成」的定义不清，验收就会变成拉锯

更好的做法：估信心而非估死线

让团队用三档信心值表达：能确定（误差±20%）、大概能（±50%）、走着看（±100%）。对「走着看」的需求，先排一个3天的技术预研，比直接开工赌运气便宜得多。预研产出的不是代码，是「确定或不确定」本身。

两个常见的话术陷阱

陷阱一：「先做起来看看，时间后面再说。」听起来灵活，实际是把预估责任转移给了执行者，月底必翻车。

陷阱二：「你们上次类似的不是十天就做完了吗？」类比预估最大的坑在于只看见相似的功能，看不见隐藏的差异——数据量、并发、遗留代码、人员状态都不一样。

写在最后

预估不是谈判，是对齐认知。一个诚实的「我们不确定，需要预研」比一个漂亮的「两周」值钱得多——因为排期表的信用，一旦破了就再也补不回来。PM能做的最专业的事，是帮团队把模糊的「两周」拆成一堆可以分别验证的小承诺。