在互联网公司创业的项目中，很多是无法按时完成的，原因各有不同，解决方案当然也多种多样。今天我根据自己的经验来分析一下项目延期的一些常见原因及我能给出的解决方案。需求理解不清。造成项目延期的最大原因是需求分析阶段没有正确理解客户需求。技术人员一般非常自负，觉得你说的需求我都理解了，甚至在客户还没把需求完全讲清楚之前，就已经开始写代码了，以显示他的能耐。我在前面一篇文章中提到了沟通能力对于技术人员的重要性，在这里就是非常典型的场景。

客户描述需求是从自身的理解和角度出发的，客户跟技术人员是完全不同的两个视角，这就势必会造成技术人员得到的需求并非客户最真实的需求。那么客户在什么时候会发现开发的产品跟自己的需求有偏差呢？越早发现对项目进展越有帮助。等项目快完成客户才发现技术人员对需求的理解不对，那么再做调整就已经来不及了，离最初要求的交付时间已经很近了，客户只能接受项目延期的事实，或者接受一个需求不对的产品。

对项目的难度估计不足、工作量估计有偏差。在初步拿到需求时，技术人员对需求里的逻辑和细节理解是不够的，往往会对项目的难度估计不足，绝大部分技术人员在评估工作量时都比较乐观。例如技术人员对一项功能评估出来的时间是他自己的实现时间，但很少考虑如果出现意外需要的处理时间，需要跟其他模块进行联调的时间，以及出现漏洞后的多次修复时间……很多时间他可能都不会考虑进去。

需求变更。这个也是造成项目延期的重要原因之一。前面提到了因需求理解不清楚造成项目延期的情况，而更多的时候，造成项目延期是因为客户对需求的描述一直在变化。尽管在需求分析阶段已经过再三确认，但随着时间的推移和环境的变化，客户的需求也会随之发生变化。需求有变更，对技术人员来说是最麻烦的事情，可能从设计、编码、测试都需要重新再走一遍，前面几个星期的工作都白费了。

沟通不到位。整个项目是由一个团队来完成的，这其中就会涉及人与人之间的沟通和协作。我们知道一个人做事情，所有细节和顺序都会在自己的大脑中，基本上不会出错。但一个团队做事情，就要求团队所有人能像一个大脑那样干活，这需要长时间的磨合，而各自状态、进度的随时暴露，很多团队很难做到这样协调的配合。一旦合作的人之间沟通不到位，就会产生不必要的耗费，累计多了就会对项目的按时交付有较大影响。

针对以上常见原因，根据我个人经验，有以下解决方案以供借鉴。

需求反复沟通确认。跟客户讨论需求的过程要尽可能细致，宁愿前期多花时间进行需求沟通和确认，也不要将需求的沟通放到研发开始之后。一般我会建议按照以下5个步骤进行需求沟通和确认。

1.让客户将需求讲解出来，详细讲解各个细节。

2.根据客户的讲解，将需求以原型文档的形式整理出来，在整理过程中及时跟客户确认疑问点。

3.将原型讲解给技术研发人员，确保客户的需求在技术上是可实现的，同时听取研发人员的意见和反馈，调整原型。

4.就调整后的原型与客户沟通，以便客户理解原型实现的方式和所做的更改。

5.让技术研发人员对原型进行讲解，确保研发人员对需求的理解和客户的需求保持一致。

一般经过这5个步骤后的需求沟通与确认，返工的可能性就比较小了。

正确评估工作量。根据需求进行工作量评估，是所有项目都需要进行的环节。我的经验是由研发人员对需求进行拆解，尽可能将工作任务拆解到1～2天的工作量，只要你能将任务拆分开，表示你对需求的理解透彻，你对工作量的评估相对较准确。这类似庖丁解牛，在庖丁眼里，整只牛已经分成了若干个器官组合，他非常清楚哪块是什么器官，该怎么下刀子。在庖丁眼里，拆解一条牛需要多少刀、需要多少时间都是非常明确的。同样，在对需求的理解和工作量评估中，若你能将需求、任务拆解到1～2天的工作量，就说明你对需求任务的理解到位了，评估出来的工作量才相对准确。

另外，有一个业界常用的做法，就是在研发工程师所评估出的时间的基础上，乘以1.5～2倍的系数，将计算后得出的时间作为真正的工作量时间，这也是相对靠谱的。

正确管理需求变更。有一句话说：唯一不变的是变化。项目过程中发生需求变更是非常常见的，而且是一定存在的。作为项目管理者，对需求变更这个事情要有正确的认识。有些项目管理者对客户说不允许变更，否则项目就延期。这样的做法可以保证项目按时交付，但客户的满意度就很低了，因为客户的需求没有得到正确的处理和满足。

我的建议是：跟客户要从认知上达成一致，项目按时、按质量交付是最重要的，相信客户也一定会认可这个目标。在这个基础上，我们要对需求变更进行管理，根据需求的重要性进行分级。如果某个需求变更不做进去，按时交付的项目版本可能就有瑕疵或者不能使用，那么我们就必须把这个变更做到当前版本中。同时，我们还需要分析引起这次变更的原因，如果是我们自身的原因，那就跟客户讲清楚，然后想办法消化掉多余工作量，如加班、加人等（虽然加人一般是没用的）。如果是因为客户的原因引起的，那我们需要评估这个加进来的任务对开发进度的影响有多大。跟客户沟通清楚，可以将这个变更的需求加进来，但为了保障项目的按时交付，需要从原有功能列表中减掉一部分优先级低的功能需求。从当前需求拿出来的，或者变更部分不影响当前上线的，也需要排一个功能需求优先级，告知客户在确保这次按时交付后，会根据优先级顺序将一些需求功能尽快处理掉。将这些原则性的东西跟客户沟通清楚，一般客户都是能理解的。

能交付的产品永远都比完美的产品更有价值。希望这篇文字能给你的项目带来一些帮助。