最近团队的延期的情况有点多，经常有人过来跟我说，

“宝哥，这个今天提测不了，需要延期一天”

“宝哥，这个不能按时测试完了，需要往后延一下”

先说一下背景吧：我们公司被集团收购之后，持续在做技术和业务的融合。大家需要学习新的工具、新的平台、新的语言，也接手了一些历史的项目，也需要跟其他业务部门做对接的磨合。

在这种背景下，我们已经把排期放的比较宽松了，尽量让大家根据自己的情况评估工作量，但是结果仍然不够理想。

所以，为什么我们自己评估的排期，仍然经常延期？

到底是为什么

这种情况就是完全符合时间领域的一个法则，叫做侯世达法则。

事情总是比你预计的要花更长的时间，即使你考虑到了侯世达法则。 ("It always takes longer than you expect, even when you take into account Hofstadter's Law.")

举例说明下，大家就明白了。

产品提了一个需求，要修改前端页面的一个字段展示。

评审的时候，我们第一眼的感觉就是——“很简单”。后端数据驱动，从某个服务读取一个字段返回回来，完事。

动手后才发现，下游服务接口里没有这个字段。不过也还好，去改下游服务，让下游服务读数据库的时候多读取一个字段，返回回来就完事了。

可仔细一看，发现下游服务本来从数据库里读了这个字段，但是不知道为什么在返回之前特意把这个字段屏蔽了，而且前人还特意加了一行注释——该字段千万不能返回。

于是，我们开始分析历史修改记录，或者找人去问背景。可能最后我们理清楚了历史逻辑，也或者我们为了完成需求，换了一个字段来返回数据，避免对其他服务带来未知的影响。

最后，当我们以为都完事的时候，却发现前端展示还是不对。然后我们就找前端同学查，前端同学反馈说有一个A/B实验的逻辑…

于是，我们越陷越深…

这就是侯世达法则经常作用在程序员身上的典型场景。

大多数时候，出现这种情况的根源在于——我们对要做的这件事还不够熟悉。

除非我们做过这件事，并且明白这件事的每一步的操作方法和可能存在的问题，那么我们才能把时间评估的比较准确，且执行的时候才能避免各种各样的坑。

否则，在我们完全不熟悉的情况下，那些所有可能的坑都会变成各种意外。我们面对这些意外需要花很大的精力和时间去处理，甚至还有可能因为我们的不熟悉让事情变得更复杂。

如何尽量避免侯世达法则

梳理整体流程

做任何需求的时候，都要先搞清楚自己到底在做什么，业务流程是什么？也就是搞清楚——“从哪里来，到哪里去”。

如果我们明确知道数据从哪里产生，经过哪些环节流转，最终如何展示，那么在项目过程中就会减少很多这样那样的“意外”。

预留缓冲时间

不要把排期排得“刚刚好”。

除非我们对要做的事真的很熟悉，否则大家一定要尊重侯世达法则存在的事实，在评估完工作量后，一定要预留一些时间作为缓冲。

复盘问题，沉淀经验

延期不可怕，可怕的是——我们承担了延期的后果，却没有学到任何的经验。

每一个“意外”我们都要记录下来，定期做个人和团队的复盘。在复盘中，我们要认真去思考这些“意外”的根本原因到底是什么。

是需求考虑不清楚？是自己做的时候不够认真？还是自己对技术框架不够熟悉？

找到最最根本的原因，反思改进，这样我们才能避免再次踩同样的坑。

培养团队的“全局意识”

技术人习惯性只关注自己的“一亩三分地”，结果就是：前端觉得是后端问题，后端觉得是下游问题，下游觉得是历史问题…

最后大家都没有问题，可问题还是没有解决。

所以我们需要培养团队的全局意识，不要只想着是不是自己的责任或者需不需要自己开发，而是从全局的角度去看待问题，找到问题的最优解。

最后

产研项目本身就比很多其他类型的项目更复杂，“意外”也更多，所以我们必须承认侯世达法则存在的客观事实，接受延期是一种常态。

真正重要的是：从每一次延期里学到点东西，让下次坑更少，排期更准，团队成长更扎实。

祝好