编辑导读：作为一名产品经理，时常会遇到项目延期的情况。如果事情已经发生了，那我们需要做的就是寻找延期的原因，以及采取措施，争取下一次按时完成。本文作者基于自身工作经历，提出了自己的一点思考，希望对你有帮助。

作为一名产品经理，你在做项目的过程中可能经常会遇见一个问题：项目延期。

延期的原因，可能是需求不清晰，也可能是需求变更等。而不管什么原因，项目延期主要责任都会落在产品经理身上。所以降低项目延期的风险，就是在减少我们作为产品经理背锅的可能。

我们在工作中提倡用结果导向，对于产品经理来说，我们要得到的结果，就是在某个功能上线之后收集得到的市场反馈数据。一旦发生项目延期，就不仅仅是上线晚的问题，收集市场反馈的时间也被延迟了，这个后果会很严重，很可能还会导致这个项目失败，白费之前的努力。

举个例子，新冠疫情在年初很紧张，我们做了一个疫情相关的功能，但因为某些原因，这个功能没能按时上线，要推迟到现在才能上线。可是现在疫情已经减轻了，人们的需求降低了，如果功能现在才上线，那效果就会大打折扣，甚至没有上线的必要。

遇到新冠疫情这样偶然事件产生的市场是很难得的，几乎没有复制的可能，这样的小风口没有把握住，损失是非常大的。

责任在谁不重要了，毕竟损失也没有办法挽回。所以身为产品经理，我们应该做的是找到项目延期的原因，减少项目延期的可能，而不是不停找借口，下次还是如此。

延期的原因延期指的是没有按期望的时间完成项目，但这是对开发而言的延期，而不是对产品经理来说的延期。对产品经理而言，延期应该是说我们给项目完成定下的“期望完成”时间比“实际完成”的时间少。

所以说造成项目延期的真实原因，其实是我们没有提出一个合理的“期望完成”的时间，与研发人员实际完成的时间关系不大。

小明跑100米短跑，我们期望他跑完全程用5秒，但结果是他用时13秒，也就是说，他延期了。

理论上讲，小明再提升一下速度就可以更快到达终点。但在未来很长一段时间里，小明想要在期望时间内到达终点的可能性很小。要知道当前的百米世界记录，用时是9秒58分，这还是运动员训练之后的结果，对于大多数普通人来说，13秒的用时已经是快的了。

小明就相当于开发人员，产品经理就相当于提出5秒跑完全程的人。要求开发人员短时间内将速度提升上来，好按期望时间完成项目，显然不是那么容易实现的。

一个不专业的产品经理，会从研发人员的角度来看问题，认为项目延期是因为完成的时间超过了期望时间，要求研发人员提升速度或者加班，但这样只会给研发人员带来困扰和压力。

产品经理永远追求在更快更短的时间里实现一个功能。原本需要1周完成的事情，会忍不住要求3天做好，3天能做好的会给1天时间，1天能做好的会给1个小时……哪怕研发人员的研发效率提高，按期望时间完成了，到了下个项目，产品经理还是会给出一个更短的期望时间，追求更高的效率，慢慢的这就成了一个难解的死局。

就好比你的上级安排了一个任务给你，并要求你3天就出方案，但实际上这个任务需要1周才能完成。

延期的本质不知道大家有没有想过，自己预估的期望时间其实并不合理？

观察众多项目，可知延期的**原因，是产品经理用自己预估的期望时间来要求实际完成的时间。但产品经理其实并不具备预估完成时间的能力，尤其有些需求比较复杂更难预测，产品经理就更难预测出一个比较合理的期望时间，而当我们用不合理的期望时间来要求实际完成的时间，项目延期的可能性也就大大增加了。

因为即使是做一个同样的功能，不同的开发需要的时间也不会完全相同。要知道，开发一个功能，研发人员、研发环境、市场环境这些都会影响实际完成的时间。

也就是说，实际操作的开发人员提出的期望时间会比产品经理提出的时间要准确很多。当然了，你要是因此认为产品经理提不出准确的期望时间，只是因为“不懂技术”，那就太片面了。

也许产品经理会说：如果能早点跟我说这次的项目会延期，我肯定不会这样设计啊，那项目就不太可能延期了嘛。但这实施起来也很有难度：

一方面是因为产品经理没有提出一个合理的期望时间；另一方面则是我们习惯于直接用期望时间来要求实际时间，但这样我们就没有办法及时得到反馈，很可能功能快到上线时间了，我们才知道项目要延期。而这个时候想要再去调整已经晚了，项目只好延期了。

预测时间想象一下，如果有人能在产品经理提期望时间时指出项目可能延期，并说出准确的延期时间，产品经理根据提醒做出了调整，那会不会好一些？

在开发之前，了解到可能延期，那就可以对需求合理调整，或者将复杂逻辑简单化，或者去掉一些不必要功能，或者将不重要的功能优先级降低……这样可以有效减少延期的风险。

看到这里你明白了吗？解决项目延期，靠无休止的加班和换研发人员的用处不大，更应该做的是找到一个准确合理的“预测时间”，也就是预测完成该项目要多少时间。

当然这个预测时间可不是凭空而来的，找实际操作的研发人员提供会比较准确。预测时间，相当于是我们说的研发估时，只有做这个项目的开发才是最了解的，他们提供的数据才是最准确合理的。要知道，不同的开发，技术经验是不同的，所以哪怕是他们的领导，只要没有真的参与操作开发，那领导提供的预测时间也不够合理准确，要用也只能作为参考。

有些技术团队的领导比较强势，单方面就会做一些时间上的承诺：这个功能很简单，一天就能完成……

一般而言，在这样的团队工作，技术人员会比较辛苦。因为每个开发开发功能需要的时间是不一样的，能否实现一个功能也许是能力问题，而完成时间的长短则是经验积累的原因。并不是说没能按期望时间完成就是开发的能力问题，再有能力的开发也有可能缺少某方面的经验，没见过的东西自然需要花时间钻研。

也许敢承诺一天可以完成某项功能的领导自己操作真的可以一天完成，但要知道实际操作的人可不是领导，换其他人来也许需要两天或者三天也说不定。

把预测时间作为期望时间的参考，有两个优点：一个是可以有效减少项目延期的可能，一个是可以帮助研发人员在研发过程中协调管理。