在项目实践中，我们该如何应对需求变更？

在项目实践中，我们经常会遇到客户的需求变更。需求变更如果控制的不好，往往会导致风险，严重的话，会导致成本超支，项目失控，甚至项目失败，等问题。

 

那既然客户的需求变更难以避免，作为PM，我们该如何管理需求变更呢？

下面，我们从事前，事中，事后三个角度来分析：

一、事前：确定好变更管理规范，获得认同

在我们正式启动一个项目的时候，一般是需要和客户一起召开正式的项目启动会(kick-of meeting)。启动大会的目的之一，就是和客户的相关方明确变更管理规范和变更流程。我们要趁着启动会，传达给客户，要是以后在项目过程中，出现了需求变更，项目组将会如何去管理和执行。你看，这样就提前就把未来可能会遇到的问题，前置到启动会和客户正式沟通和确认，培育客户的认知和获得客户的认同。一方面，体现我们的项目管理的专业性。另一方面，我们要获得相关方对我们专业方法论的认可。假设将来发生这类问题，双方按约定的流程执行即可。

二、事中：按变更管理流程执行

在项目过程中，如果客户对已确认的需求进行变更，我们要按照变更管理的流程来执行，确保项目的 变更遵守规范且受控。

1)正式提出书面的变更请求：

要求客户提出正式的变更请求，形式可以是发送邮件抄送甲乙双方主要项目负责人，或者要求客户签署变更申请单。如果客户不愿意提出正式的变更单，我们要及时拉会沟通，要求对方走变更流程。如果没有正式的申请，我们可以礼貌地表示暂不能受理变更的需求。

2)项目组内部评估需求的合理性，可行性和实现成本，项目的风险等等。

• 评估需求的合理性：

根据客户提交的需求变更，内部组织梳理和分析这个变更是否合理？如果不合理，我们要及时告诉客户这样做变更不合理，并引导和挖掘他要变更的初衷，找出来他真正的变更需求，再进行评估。

• 评估技术的可行性：

在判断变更需求是合理的之后，我们要拉着开发一起来评估这个需求是否可以实现，具体的技术实现方案是什么样的，实现的周期要多久，工作量(成本)会增加多少，需要有一个具体的量化分析结果。（这个结果后面要正式反馈给客户，涉及到成本增加的，还需要告诉客户要额外的成本才能做该变更，等等）

• 评估变更的影响(风险)：

最后，我们还需要考虑，该变更是否会对系统其他模块产生影响，是否会影响进度，是否有其他的依赖条件等，也就是要综合考虑该变更带来的项目风险，以及对应的风险，我们是否可控。对于风险较大的需求变更，我们一定要慎重。在没有较好的风险应对措施之前，建议引导客户不要去做变更。如果客户一定要去做变更，要明确告诉客户很大概率会出现某种风险，让客户书面签字后，才能小心翼翼的执行需求变更，尽可能的减轻变更带来的影响。

3)正式答复客户变更的影响及方案：

项目组内部评估完成后，我们要配合商务(销售人员)正式地回复客户的变更申请，然后进行沟通和谈判。

4）客户的正式审批：

这个一般会存在一个双方battle的过程，有时甚至会持续很久，因为变更可能会涉及要增加新的资源，需要额外的费用等等问题，就涉及到商务谈判了。项目经理主要负责需求变更的技术细节响应和细节问题和客户沟通，商务主要负责和客户沟通变更导致新增加的商务费用，新的资源等等问题。项目经理和商务经理，都需要积极响应客户的问题或者挑战。经历过一段时间后，客户会正式地回复批准变更，并按照新的变更要求进行变更单或新的补充协议的签署，和新增费用的付款。如果协议已签署或已付款，代表客户已正式批准了需求变更，流程在此刻已全部走完。

5）执行批准的变更请求：

按照步骤2评估的方案，进一步细化，然后拆解成具体的工作任务，然后分配到具体的负责人，设定具体的交付时间节点，质量标准，按正常的需求管理去跟踪进度即可。

6）监控和检查变更的效果：

在执行的过程中，我们要监控执行的进度，和上线后，实现的效果是否符合预期，是否产生了新的风险等等。万一出现，我们要按照步骤2识别出来的风险应对措施去解决。

三、事后：复盘总结经验教训

在项目阶段结束后，需要进行总结经验教训。注意，不是要等到整个项目结束了，才去做复盘总结。

针对需求变更这种的回顾，我们要回头去审视需求变更没有管好的根本原因是什么，针对每种原因，策划相应的方案，然后选一种比较优的方案，进行方法论或管理流程的改进。经过几次回顾总结，慢慢我们就能更加的从容应对需求变更，不是怕变更。

总之，需求变更不可怕，

可怕的是我们没有需求变更的管理意识，

可怕的是我们没有建立规范的需求变更的控制程序，

可怕的是我们在需求变更出现问题后，没有复盘总结。

最后，希望各位读友可以尝试从事前，事中，事后这3个角度去应对需求变更，在实际项目中多加以实践，不断地迭代和优化自己的管理方法论。

需要项目管理资料合集的同学可留言