项目延期，大概是每一位产品经理都会遇到的问题，并且延期的花样也挺多的，有因为需求不清晰导致的延期，也有因为需求变更导致的延期。但最终背锅的，其实还是产品经理。

我们都提倡结果导向，而所谓的结果，对于产品经理而言，就是指某个功能投入到市场，得到市场的数据反馈，延期所导致的影响不是简单的上线时间推迟。而是市场反馈的延迟，严重时，可能会导致项目夭折，没有上线的必要了。

像是疫情相关的功能，如果现在都还没上线使用，也就没有再上线的必要性了，毕竟人们的需求已经降低了，很多人现在已经将注意力转移到工作，生活当中了。

所以，最终背锅的，还是产品经理，我们可以躲过问责，把原因归责与开发，但于事无补，错过的市场，不再回来，难得的事件也不能复制，一个小风口，就这样丢失了。

项目，为什么会延期

延期，从表面来看，是指实际完成的时间相对于期望完成的时间更迟，其实，这个是错的，视角是错的，这个是开发视角。

产品经理的视角，是和开发视角相反的，对于我们而言延期是因为“期望完成”的时间，比“实际完成”的时间更短。

问题不在实际完成的时间，而在我们提出的期望完成时间。

张三距离终点有100米的距离，我们期望他5秒内抵达终点，但实际上他用了15秒，结果的角度来讲，张三“延期”了。

表面上，张三如果跑的快一点，或许可以更快抵达，但至少十多年的时间里，不太可能在期望时间内达成。因为当前百米世界纪录，被称为飞人的博尔特，也需要9秒58才能完成。而15秒的时间，则是大多数普通人能够完成的目标。

如果我们站在开发的视角，将延期的问题定位在实现时间超出了期望时间，就成了一个死局，而且这也是一种挺不“专业”的想法。

人是贪婪的，产品经理也不例外，我们总是想要更快实现某个功能，一周，不行，明天就要，1天，不行，只给你1个小时，最后就会陷入一种困境，不断的要求快，不断的失望，不断的提升对研发的要求。

其实问题还在，人的贪婪是无止境的，产品经理也是人，你可以一周做完，我就要求3天，你可以3天做完，那我就要求1天，如果你能1天做完，我就要求1小时，随着研发人员能力提升的同时，不仅仅是实际完成的时间再减短，产品经理期望完成的时间也在减短。

某种意义上，这种情况，就像是老板安排了一个任务，实际需要一周完成，但要求你一天给出解决方案，是相同的。

产品经理很多时候，不知不觉成为了那个让自己讨厌的人，做着自己讨厌的事，但不自知。

延期的本质

大多数延期，是因为我们将期望时间直接作用于实际完成的时间，但产品经理其实不具备时间预估的能力，尤其是一些比较复杂的需求，我们是无法进行预测的，这也就导致期望时间往往不太合理。

相同的需求，不同的技术人员需要的时间是不一样的，而且，即使需求相同，开发者相同，但代码环境不同，业务环境不同，也会导致实际需要的时间出现偏差。

所以，产品经理无法预测开发时间，并不是单纯的“不懂技术”问题，而是一个更加客观的现象，不是实际操作者，提出的预判，多数是不准确的。

很多时候，产品经理都会有这样的错觉，如果能早一点告诉我会延期，我就不这么设计了，感觉自己被坑了。

一方面，期望时间不合理，另一方面也是因为期望时间直接作用于实际完成时间，这样的反馈周期太长了，只有临近上线前，我们才能得到一个“将会延期”的反馈，极为被动，再做调整已经来不及了，只能延期。

第三个时间：预测时间

如果，当我们提出4天的期望时间时，有人能告诉我们可能会延期1-2天，会不会好很多？

我们完全可以在开发之前，对需求做减法，把复杂的逻辑变得简单，把不必要的功能去掉，把不重要的功能优先级降低。

这样一来，就可以更大限度减少延期的风险了。

所以，产品经理解决延期问题的核心，不是加班，不是换开发，而是寻求一个“预测时间”，预计完成需要多少时间。

这个预测时间，只能由研发来提供，也就是我们所说的研发估时，也只有实际操作的研发提供的时间预测，才是可信任的，每个人的技术经验都不相同，即便是他的leader，辅助提供的预估时间也只能作为参考使用。

有一些技术驱动的团队，CTO比较强势，经常会做一些时间上的承诺，像是这个功能很简单，一天就能实现这样的。