交付管理——怎样控制需求变更

项目交付过程中最大的风险来源于客户需求的变更，需求变更对项目进度和项目成本的影响很大。很少有项目会不存在需求变更，导致需求变更的因素有很多，既有甲方的原因也有乙方的原因。

本文从实操的层面来为大家讲述怎样控制需求变更，怎样减少需求变更带来的影响。

首先，在售前阶段要防患于未然。

一个项目能否成功交付，售前阶段对需求的理解非常关键。我经常看到一些初创的软件公司以大无畏的英勇气概，贸然进入自己并不熟悉的行业，费了九牛二虎之力终于赢了单，真正做起来才发现自己的报价根本兜不住交付的成本。

问题出在哪里了？对需求的理解不够。每个行业都有自己的行业特点，有时看上去是个闭环的业务流程，其实里面还存在N多个扩展流程，而这些流程在售前阶段的调研中，如果没有行业经验是很难被全部挖掘出来的，实现这些流程往往比单纯一个基本流程要多出几倍的工作量。比如，我曾见过一家软件公司去做一个企业的核心计费系统，在他的方案设计中居然只有收款流程而没有考虑退款流程，结果到了实施阶段才发现退款流程有N多个触发条件，把这些需求全部实现，交付成本比原来的报价要整整高出三倍。

所以在售前阶段一定要有专业的，对目标行业熟悉的方案顾问，否则到了实施阶段，项目经理就算能力再强也回天乏术。

其次，在实施阶段要有控制技巧。

技巧一，需求变更必须要走变更流程。

很多时候，客户的需求变更是很随意的，往往是领导忽然冒出一个想法就要求项目团队去实现，实现完了发现并没有达到预期的效果又让改回去。如此来来回回，领导自己觉得很爽，却不知道对项目实施的影响有多大。

需求变更必须要走变更流程，每一次的变更内容客户领导都要签字，不签字就不要做，要把规矩立起来。

很多公司并不是没有需求变更流程，只是一些项目经理自己嫌麻烦，往往是在会议中和客户达成了口头约定就开始让团队开发，时间一长客户自己都记不清楚，不但不认账，还会觉得你在斤斤计较。

所以需求变更必须要有纸质的需求变更单，需求变更单不但能起到记录需求的作用，还可以有效的向客户传递压力，变更是有成本的，客户会更加慎重的考虑自己的变更要求。

技巧二，需求变更必须要把变更成本讲清楚。

软件工程不同于建筑工程，把房子拆了建，建了拆，客户看得到，有感知，知道做这些事情是有工作量的，而软件系统就是写代码，客户不懂里面的逻辑，所以很多时候会说我不就是加个字段吗，有这么复杂吗，这也算变更，也要追加费用，至于吗？

还真至于，别看只是增加一个字段，需求人员要在需求文档中修改，架构人员要在相关的数据库表中增加字段，开发人员要把和该字段相关的业务逻辑代码全都改一遍，前后端要重新联调，测试人员要重新测试，这些工作量累加起来是不少的。

怎样让客户意识到这些工作量呢？要在需求变更单中把需求修改涉及哪些文档，代码修改涉及到哪些业务模块、哪些报表、哪些数据库表，各环节的工作量分别是多少，人天单价是多少，费用投入是多少等。客户看到了这些，才会对变更成本有深刻认知。

除了变更的费用金额外，还有变更的风险成本，比如实施周期延长对于上线目标的影响，系统架构变动对于系统稳定性的影响等等，要通过帮客户算账的方式，引导客户放弃不必要的需求变更。

技巧三，需求变更必须把变更责任讲清楚。

很多时候项目经理自认为的需求变更，客户并不认同，为什么呢？因为没有把需求边界定义清楚。

每个项目在签合同时都会附带一个项目工作说明书（SOW），用来界定需求范围，但这份文档的颗粒度不可能做到很细，所以在实际操作中很难讲清楚客户的要求是否属于需求变更的范围，经常会有各种扯皮现象。

一般来说，界定需求变更的责任应遵循以下原则：

如果因为乙方售前调研做的不充分，或是对行业的了解不够，一些必要的功能没有规划进去，导致业务流程走不同，或者即便能走通，用户的操作也很不方便，根本用不起来，这个时候客户要求追加的功能即便不在需求清单上也不能算是需求变更，这是乙方自己的工作不到位，乙方的项目团队就要承担责任。

而有些是因为遵从客户的意见而形成的方案，在实施过程中发现不行，需要推倒重来，因此而产生的需求变更费用就应该由客户承担。

还有一些是出于易用性的考虑，客户要求增加的需求，就要告诉客户，做系统和装修房子是一样的，有简装，有精装，你给的是简装的钱，我不可能按精装的标准来交付，如果一定要做请追加费用。

有时候因为客观原因，双方都有责任而产生的需求变更，也可以协商一个比例，让客户也承担部分费用金额。很多项目经理是技术出身，不敢或不善于跟客户谈钱，在这里你要明白谈钱不伤感情，项目的成功离不开甲乙双方的共同努力，只要目标是一致的，就没有什么不可以谈。 如果实在过不去心里那道坎，也可以求助销售人员，让客户经理来帮你谈。

总而言之，项目经理在实施过程中要想方设法减少不必要的需求变更，确保项目进度少受影响。如果必须要变更，也要争取尽量多的变更费用，确保公司利益不受损失。

朋友们，以上是我在控制需求变更方面的经验总结，希望能帮到你。接下来我会继续分享有关项目交付方面的方法和技巧，有兴趣的朋友可以和我一起交流，感谢大家的关注！