项目延期，大概是每一位产品经理都会遇到的问题，并且延期的花样也挺多的，有因为需求不清晰导致的延期，也有因为需求变更导致的延期。但最终背锅的，其实还是产品经理。
我们都提倡结果导向，而所谓的结果，对于产品经理而言，就是指某个功能投入到市场，得到市场的数据反馈，延期所导致的影响不是简单的上线时间推迟。而是市场反馈的延迟，严重时，可能会导致项目夭折，没有上线的必要了。
像是疫情相关的功能，如果现在都还没上线使用，也就没有再上线的必要性了，毕竟人们的需求已经降低了，很多人现在已经将注意力转移到工作，生活当中了。
所以，最终背锅的，还是产品经理，我们可以躲过问责，把原因归责与开发，但于事无补，错过的市场，不再回来，难得的事件也不能复制，一个小风口，就这样丢失了。
项目，为什么会延期
延期，从表面来看，是指实际完成的时间相对于期望完成的时间更迟，其实，这个是错的，视角是错的，这个是开发视角。
产品经理的视角，是和开发视角相反的，对于我们而言延期是因为“期望完成”的时间，比“实际完成”的时间更短。
张三距离终点有100米的距离，我们期望他5秒内抵达终点，但实际上他用了15秒，结果的角度来讲，张三“延期”了。
表面上，张三如果跑的快一点，或许可以更快抵达，但至少十多年的时间里，不太可能在期望时间内达成。因为当前百米世界纪录，被称为飞人的博尔特，也需要9秒58才能完成。而15秒的时间，则是大多数普通人能够完成的目标。
如果我们站在开发的视角，将延期的问题定位在实现时间超出了期望时间，就成了一个死局，而且这也是一种挺不“专业”的想法。
人是贪婪的，产品经理也不例外，我们总是想要更快实现某个功能，一周，不行，明天就要，1天，不行，只给你1个小时，最后就会陷入一种困境，不断的要求快，不断的失望，不断的提升对研发的要求。
其实问题还在，人的贪婪是无止境的，产品经理也是人，你可以一周做完，我就要求3天，你可以3天做完，那我就要求1天，如果你能1天做完，我就要求1小时，随着研发人员能力提升的同时，不仅仅是实际完成的时间再减短，产品经理期望完成的时间也在减短。
某种意义上，这种情况，就像是老板安排了一个任务，实际需要一周完成，但要求你一天给出解决方案，是相同的。
产品经理很多时候，不知不觉成为了那个让自己讨厌的人，做着自己讨厌的事，但不自知。
延期的本质
大多数延期，是因为我们将期望时间直接作用于实际完成的时间，但产品经理其实不具备时间预估的能力，尤其是一些比较复杂的需求，我们是无法进行预测的，这也就导致期望时间往往不太合理。
相同的需求，不同的技术人员需要的时间是不一样的，而且，即使需求相同，开发者相同，但代码环境不同，业务环境不同，也会导致实际需要的时间出现偏差。
所以，产品经理无法预测开发时间，并不是单纯的“不懂技术”问题，而是一个更加客观的现象，不是实际操作者，提出的预判，多数是不准确的。
很多时候，产品经理都会有这样的错觉，如果能早一点告诉我会延期，我就不这么设计了，感觉自己被坑了。
一方面，期望时间不合理，另一方面也是因为期望时间直接作用于实际完成时间，这样的反馈周期太长了，只有临近上线前，我们才能得到一个“将会延期”的反馈，极为被动，再做调整已经来不及了，只能延期。
如果，当我们提出4天的期望时间时，有人能告诉我们可能会延期1-2天，会不会好很多？
我们完全可以在开发之前，对需求做减法，把复杂的逻辑变得简单，把不必要的功能去掉，把不重要的功能优先级降低。
这样一来，就可以最大限度减少延期的风险了。
所以，产品经理解决延期问题的核心，不是加班，不是换开发，而是寻求一个“预测时间”，预计完成需要多少时间。
这个预测时间，只能由研发来提供，也就是我们所说的研发估时，也只有实际操作的研发提供的时间预测，才是可信任的，每个人的技术经验都不相同，即便是他的leader，辅助提供的预估时间也只能作为参考使用。
有一些技术驱动的团队，CTO比较强势，经常会做一些时间上的承诺，像是这个功能很简单，一天就能实现这样的。
这种团队的技术人员，通常会比较幸苦，或许cto自己来做真的只需要一天，但实际操作的人不是CTO，而是其他的技术人员，可能需要2天甚至更长的时间才能完成。
毕竟每个人的经验结构都是不一样的，能不能实现是能力问题，能不能快速完成就是经验问题了，再有能力的研发，遇见自己未做过的事情，都需要一些时间研究，都会经历由慢到快到过程。
顺带一提，此类型团队，往往也是加班和延期的重灾区。
引入预测时间，可以赋予团队两个可能性，一个有益于产品经理控制延期风险，另一个则有助于研发团队的客观协调管理。
（1）前置调整
将期望时间与预测时间进行比对，可以在最开始的环节，对需求进行调整，这是最有效规避延期的方法。
期望时间大于预测时间：代表延期的风险比较低，我们可以尝试追加一些体验需求，让产品更加完善，也可以分出一部分经历做一些市场预热的动作。
期望时间小于预测时间：代表延期风险较高，两者的差值越大，延期的风险越高，超出阀值，基本就是必然延期了，出现这种情况，我们可以尝试对需求做减法，或者简化需求等方式，减少预测时间，也可以通过调整期望时间的方式，让两者的差值见效。
这是目前降低延期率最有效的方法之一。
风险阀值：研发进行时间预测时，一般情况是按照工作时间进行预测，这点很重要，产品经理也有义务提醒研发，按照工作时间进行预测，不要默认算上休息时间，我们都不提倡默认加班。
以此为依据，同期工作时间对应的每天可加班的时间，就是浮动的上限值，这个值也被视为延期风险的阀值。
如果期望时间与预测时间的差值，可以通过这部分加班时间弥补，那么延期的风险就还是可控的，只是需要在开始前，就明确和团队沟通，为了不延期，我们这段时间都需要加班了。
所有人都反感突如其来的加班，但是预先告知的加班，却容易接受很多，因为我们可以提前安排好自己的生活，不至于手忙脚乱，这也是我们对团队的基础尊重。
假设，我们提出了一个需求，期望时间是8天，预测时间是10天，每天8小时工作时间，也就是需要额外的16小时，每天加班2小时，持续8天加班，就可以不延期完成任务了。
通常情况，预测时间与期望时间的差值，不能超过20%，但每个团队，也可以根据自身的情况，酌情调整风险阀值。
（2）后置提升
将预测时间与实际完成时间进行对比，可以在上线后，为团队提供很好的复盘依据，帮助团队成长，从长远来看，只有团队足够强大，才能在日益激烈的竞争当中抓住一线生机。
后置提升的目的，是为了让预测时间与实际完成的时间高度一致，进而在未来的迭代周期中，具备高准确度时间预测能力。
所谓的，以战养战，越战越强。
预测时间大于实际完成时间：代表估时不准确，高估了需求的复杂度，也代表了研发人员对产品经理或者团队需求质量的不信任，做了较多时间预留。
预测时间小于实际完成时间同样代表估时不准确，但这种不准确通常代表研发人员低估了需求的复杂度，在评估时，考虑不够全面，同时，也可能代表需求质量较低，过程中发生了较多的变化。
（3）动态调整
后置提升的目的，是对团队的整体提升，既能反映出需求质量问题，也能反映出研发实际操作的问题，但其核心仍然在于发现问题以后的调整，进而推动团队的成长。
经常性预测时间大于实际完成时间，可以在时间预测时打折扣，相反，经常性预测时间小于实际完成时间时，就可以在时间预测时增加对应的预留时间。
借助，“期望时间”，“预测时间”，“完成时间”三个时间的对比，就可以最大限度的降低延期的风险，并且这种降低，是可持续的。
刚开始，或许会不太熟悉，但原本难以琢磨，难以衡量的延期，变得可以衡量了，无法控制的局面，也会逐渐变为可量化的，从十小时偏差逐渐降低到3小时偏差，1小时偏差，0偏差。
最终，持续性的降低延期的几率。
总结
产品经理是一个很特殊的行业，我们的需求来自于问题，而我们的解决方案又来自于需求，所以，有这样的一个概念，所有的问题，都是产品经理的问题。
对于其他行业而言，问题可能会直接等同于背锅，但产品经理不同，拥抱问题，才能从问题的背后，探索到需求，进而提供解决方案，满足需求，解决问题。
就像延期一样，一旦把责任定位于开发，定位于“完成时间太长”，就不太能找到解决方案了，毕竟我们没有办法让开发代码写的更快一点，也无法帮开发写代码。
只有把问题背负在自己的身上，从产品经理的角度，承担问题，对问题进行分析，才能用我们的方式，解决这个问题。
