善变的“范围”

10月份，公司的一个项目已经接近尾声，大家都在忙碌的准备着验证材料的准备。合同范围内8000多人天的工作量，预计结项时只能发生6500人天左右，合同外还有1700人天左右的合同外需求变更。范围的如此巨大的需求变更导致了合同结项的困难重重，也引起了我对“范围”的思考。

项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作，项目管理的三大要素（成本、进度和范围）之一。范围决定着另外两个因素，成本和进度的变化。范围缩小了，投入的成本也会降低，进度压力也会减轻。范围增加意味了成本投入的增加和进度压力的增大。由此可见范围的重要性。因此，签订合同是，项目甲乙双方也以合同这一最具法律效应的形式对范围进行约束。

但我认为，项目管理三要素中，范围是最不重要的。只有范围是我们可以与客户讨价还价的。

客户最不关心范围

如果成本、进度和范围三方面之一需要折衷，默认选项一定是范围。

本月下旬，与负责人力资源核心功能开发的紫光的谈判即将破解。而此时第二阶段的开发进度几乎为零，项目组人员捉襟见肘，已无人可用；另外，上线时间也计划在10月31日，项目组对紫光开发人力资源系统时使用的JSF技术也很陌生。无路可走的情况下，项目组召开会议商议对策。根据以往经验，我们目前能想到的就是与客户进行谈判，缩减范围，求个缓刑。最终，由我和项目组的卢义飞直接找到了系统的直接客户。经过沟通，客户同意我们分布上线的方案。

范围最不可控

从客户角度上说，范围是不得不变的。此项目二期有10多个子系统的建设。没有一个是在上线后客户不提出需求变更的。其实这也很合理。一方面，二期项目中由于种种原因，没有进行根据需求制作原型文件。用文字描述的需求多少存在歧义。另一方面，就是在与客户沟通上的知识背景的差异。很多情况下，我们从计算机语言进行观点的表述，得到是客户从业务角度上的意图反馈，用驴头对马嘴，对上了才叫巧合。很多开发人员总是抱怨客户不懂系统。其实，要求一个买产品的人懂得产品的制作原理才是最大的谬论。

从签订核对角度上说，范围是对未来的预言，是对长期不变性的一种错误判断。在很多IT项目中，总是在合同附件中，添加一个产品功能列表清单，以对项目建设内容进行精确的描述和约定。合同是项目实施前签订的。里面描述的是一段时间（少则数月，多则数年）后项目的状况。这种语言的准确性是无法保障的，也是我们结项难的根本原因之一。

如何面对范围

范围不应该是目标的一部分，范围应该是在信息充分的情况下，通过不断的决定来确定的。

敏捷宣言中提到“响应变化重于遵守计划”。敏捷中的迭代开发，并且不断的获取客户反馈，以修正项目建设方向，准备描述项目范围。此种方式我想是从开发角度上去适应当前快速变化的需求的最好方式。

从合同签订上看，实施项目与运维项目绑定可能是解决公司目前问题的比较好的方法。用运维项目来吸收因需求变更导致的范围变化。