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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 开发前调整

减少项目延期最有效的方法，是在开发之前就对比期望时间与预测时间，并对需求进行调整。

期望时间大于预测时间，项目不大可能延期。这种情况下，我们有比较富足的时间，可以尝试增加更多功能，或者完善部分功能，追求更好的功能体验，或者分一部分精力去做市场预热也是可以的。

期望时间小于预测时间，项目很可能会延期。两者相比，差距越大，项目越可能延期。出现这样的情况时，应该减少一些不必要的功能，或者对需求进行一定的简化，以求能够缩短预测时间。当然，对一些需求来说，要让期望时间和预测时间比较接近，还可以上下调整期望时间。

这是目前已知的效果最好的其中一个减少项目延期的方法。

预测时间，是只根据正常的工作时间来计算的，休息时间在没有特别提醒的情况下是不包括在内的。关于这一点，产品经理有义务主动提醒研发人员。

根据工作时间预测了时间之后，再对应到团队每天可以加班的时间，得出的数据，就是我们要找的风险阈值。

如果预测的时间加上加班的时间与期望时间很接近或者相等的时候，延期的风险就是可以控制的。不过，真的要加班，可要提前和团队沟通，明确告知。

突然加班这种事总是令人反感的，但提前告知要加班就会好很多，因为我们可以提前安排好生活，减少加班对生活的影响，这是应该给予团队的最基本的尊重。

每个团队每个开发的情况是不一样的，风险阈值也是不一样的，这个可以根据需要调整，不一定要求一样。

2. 上线后复盘

在功能完成之后，我们还要做好复盘，这样才能让团队成长更快。市场竞争总是越来越激烈的，要想走得长远，就要不断的成长，提升团队的竞争力。复盘的其中一项参考数据，可从期望时间和预测时间的对比中得来。

在功能上线后做好对比总结，追求预测时间和期望时间更为接近的可能，可以提升团队的预测能力。不断实践，不断总结经验，才能不断提升团队的实力，让团队越来越强。

如果项目在预测时间范围内完成，且还有比较多的富余时间，那就是估时还不够准确，也许是错估了需求的复杂性，也许是开发对团队不够了解，所以还预留多了时间。

如果项目完成的时间超过了预测时间，也说明开发没有准确评估需求的复杂性，还有可能是研发的功能没有达到预测，在研发过程中多次变更需求。

3. 动态调整

当项目完成的时间比预测时间少，解决办法是减少预测时间；反之则可以在估时时预留一部分时间。

运用好上面提出的三个时间，项目延期的可能性可以大大降低，而且这种降低可以在往后的时间里持续很久。

也许刚开始会觉得不太好操作，但是渐渐你会发现，项目延期的风险会不断降低，直到最后0偏差。

总结不要害怕出现问题，对于产品经理而言，问题就是产品经理的财富。发现了问题，就有可能从中发现需求，再根据需求提出解决方案，好满足需求，将问题解决掉。

将延期的原因归到开发身上，不是产品经理该做的事，因为我们不可能做开发，帮开发写代码，没有办法从开发身上找到解决的方案。

而当我们将延期的原因归到自己身上，从产品的角度去分析项目延期的原因，调整方案，降低延期的可能就是可以实现的了。这才是我们身为产品经理，应该解决的问题。

作者：氟西汀，公众号：氟西汀终究还是没了

本文由 @氟西汀 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议