为什么你的项目总是延期交付？
在软件项目中，有很多都是无法按时交付的，原因可以说是各有千秋，解决方案当然也有多种多样，今天我根据自己的经验来分析一下项目延期的一些常见原因以及我能给出的解决方案。
需求理解不清
造成项目延期的最大原因是需求分析阶段没有正确理解客户需求。技术人员一般都是非常自负的，觉得你说的需求我都理解了，甚至在客户还没把需求完全讲清楚之前，就已经开始写代码了，以显示他的能力和能耐。我在前面一篇文章中提到了沟通能力对于技术人员的重要性，在这里就是非常典型的场景。
客户描述需求是从自身的理解和角度出发的，客户跟技术人员是完全不同的两个视角，这就势必会让技术人员得到的需求并不是客户最真实的需求。那么客户在什么时候会发现开发实现的产品跟自己需求有偏差呢，越早发现对项目进展越有帮助，但真实情况是技术没把产品完全做出来之前，客户来确认的东西都是不真实的，等客户发现需求理解不对的时候，要再做调整就已经来不及了，离最初要求的交付时间已经很近很近了，只能接受项目延期的事实，或者接受一个需求不对的产品。
对项目的难度估计不足、工作量估计有偏差
在初步拿到需求的时候，技术人员对需求里面的逻辑和细节理解是不够的，往往会对项目的难度估计不足，绝大部分技术人员在对需求评估工作量的时候都是比较乐观的。例如一个功能他评估出来的时间会是他自己实现的时间，但很少会去考虑如果出现意外需要处理呢？需要跟其他模块的联调呢？出现Bug后的多次修复时间呢？可能很多时间他都不会考虑进去的，而仅仅考虑自己独立实现的工作量。
需求变更
这个也是造成项目延期的重要原因之一，前面讲的是需求理解不清楚，而更多的时候是客户对需求的描述，尽管在需求分析阶段都经过再三确认，但随着时间的推移和环境的变化，客户的需求也会随着变化的。一旦需求有变更，对技术人员来说是最麻烦的事情，可能从设计、编码、测试都需要重新再走一遍，前面做的几个星期的工作量都白干了。
沟通不到位
在理清了需求的情况下，整个软件项目是由一个团队来完成的，这其中就会涉及到人与人之间的沟通和协作。我们知道一个人自己做事情，所有事情的细节和顺序都会在自己脑子里，基本上不会出错的。但一个团队做事情，就要求团队所有人能像一个大脑那样干活，需要长时间的磨合以及各自状态、进度的随时暴露，很多团队很难做到这样协调的配合。一旦有需要合作的人之间沟通不到位，就会产生不必要的耗费，累计多了对项目按时交付也是有较大影响。
针对以上常见原因，按我自己的经验，有以下解决方案以供借鉴：
需求反复沟通确认
跟客户讨论需求的过程要尽可能细致，宁愿前期多花时间进行需求沟通和确认，也不要将需求的沟通放到研发开始之后。一般我会建议按照以下五个步骤进行需求沟通和确认：
1、让客户将需求讲解出来，详细讲解各个细节；
2、根据客户的讲解，将需求以原型文档的形式整理出来，在整理过程中及时跟客户确认疑问点；
3、将原型讲解给技术研发人员，确保客户的需求是在技术上可实现的，同时听取研发的意见和反馈，调整原型；
4、将调整后的原型跟客户讲解，以便客户理解原型的方式和所做的更改；
5、让技术研发人员对原型进行讲解，确保研发人员对需求的理解和客户的需求保持一致。
一般经过这5个步骤后的需求沟通确认，在实施过程中导致需求返工的可能性就比较小了。
正确评估工作量
根据需求进行工作量评估，是所有项目都需要进行的环节，我的经验是由研发人员对需求进行拆解，尽可能将工作任务拆解到1-2天的工作量，只要你能将任务拆分开，表示你对需求的理解透彻，表示你对工作量的评估相对较准确。类似庖丁解牛，在庖丁眼里，整条牛已经分成了若干个器官组合，他非常清楚哪块是什么器官，该怎么下刀子，在庖丁眼里，拆解一条牛需要多少刀、需要多少时间都是非常准确的。同样，在对需求的理解和工作量评估中，只有你能将需求、任务拆解到1-2天的工作量，那说明你对需求任务的理解才到位了，评估出来的工作量才相对准确。
另外，有一个业界常用的做法，就是在研发工程师评估出来的时间基础上，乘以1.5-2倍的系数，得出来的真正工作量时间也是相对靠谱的。
正确管理需求变更
有一句话说：唯一不变的是变化。项目过程中需求变更是非常常见的，而且是一定会存在的。作为项目管理者，对需求变更这个事情要有正确的认识。有些项目管理者对客户说，不允许变更，否则项目就延期。这样的做法可能可以保证项目按时交付，但客户满意度就很低了，因为客户的需求没有得到正确的处理和满足。
我的建议是这样：跟客户要从认知上达成一致，项目按时按质量交付是最重要的，相信客户也一定会认可这个目标。
在这个基础之上，我们要对需求变更进行管理，根据需求的重要性进行分级。如果某个需求变更不做进去，按时交付的项目版本可能就有瑕疵或者不能使用，那么我们就必须得把这个变更做到当前版本中。这时我们还需要去分析引起这次变更的原因，如果是我们自身的原因，那可能跟客户讲清楚后我们自己想办法把它消化掉，如加班啊、加人啊啥的（虽然加人一般是没用的）。如果是因为客户的原因引起的，那我们需要评估这个加进来的任务，对开发进度的影响有多大。需要跟客户沟通清楚，将这个变更的需求加进来，但为了保障项目的按时交付，需要从原有功能列表中减掉一部分优先级低的功能需求。
那些从当前需求拿出来的，或者变更部分不影响当前上线的，也需要排一个功能需求优先级，告知客户在确保这次按时交付后，会根据优先级顺序将这些需求功能尽快处理掉。
只要将这些原则性的东西跟客户沟通清楚，一般客户都是能理解的。
希望这篇文字能给你的项目带来一些帮助，能交付的产品永远都比完美的产品更有价值。
