二十三、建立需求变更流程

项目管理三角形中定义了项目进度，质量，成本和范围之间的关系。对于一个项目经理而言，控制项目范围是重中之重。

当一个项目的需求肆意蔓延的时候，会导致项目的失控，具体体现在：

1.团队平白无故莫名加班还是赶不上进度。

2. 交付的功能和需求的功能匹配不上，不是多了就是少了。

3. 项目成本超过预算，整个项目像无底洞一样需要一次又一次的增加预算。

而上面每一个对于项目而言都是毁灭性的。所以在项目开始阶段，定义需求变更流程是十分必要的。

《一》 定义变更流程的意义

1.项目中的变更可以追根溯源

每一次的变更对应的会有变更号，并且有对应的对于项目的影响分析。比如项目的工时需要增加，项目需要延期多久等等。最终由客户选择是否要将该变更放入项目中。一旦客户批准了，项目经理就可以更新项目范围，和项目计划。同时在RQM里增加该功能。

所以针对每一个变更，有会有一个变更明细，具体罗列：

a. 变更的功能是什么

b. 变更的影响是什么

c. 客户是否接受该变更。

从而，对于每一个变更都可以在任何时候追踪到。

2.  项目的变更对于项目的影响更为透明

因为针对每一个变更，都会有影响分析，方便项目中每一个相关干系人了解，当前变更的状态，是否被接受，是否已经添加打项目范围中。

从流程上避免了随口一说就要加功能的现象。

3.  避免只加工时不加预算的现象

由于影响分析还会牵涉到对于交付日期，需要工时，特殊技能的分析。一旦客户批准了该变更，表明客户是承认对于项目计划，预算的修改的。所以项目经理可以名正言顺的更新项目计划，该延期的延期，改加资源的加资源，该申请预算的申请预算。

从而达到避免只加工时，不加工期，不加预算等弊病。

现实项目中经常听到程序员抱怨加班多，来不及做，很大程度上都是在位项目需求变更得不到有效控制而买单。当然软件开发这行也加班在所难免，偶尔的赶工对于万不得已的情况下是需要的。但是如果把加班也算到项目日成里去，这是不对的，对于项目来说，风险也是很大的。

毕竟，如果加班都做不完怎么办？ 不交付了吗？

《二》 如何定义变更流程

清楚了项目变更流程对于项目的意义，那么我们怎么定义项目的变更流程呢？莫斯觉得可以从下面两点出发：

1. 项目变更需要由专人维护。

主要体现在几个方面：

a. 每个团队处理变更的人要有，也只能有唯一一个。

对于多团队协同合作的场景，常常会遇到其他团队的某个队员向我方团队的某个队员说要改个某某功能。这种情况下改还是不改值得商榷。第一该队员是否能够代表他们团队，而他的改动要求是否得到了客户的同意？第二我方团员听到的改动是否是客户的原本要求，理解上会不会有歧义？

鉴于以上情况，对于项目中的每一个团队，指定一个作为双方交流变更的联系人会是一个不错的选择。

b. 每个变更需要由专人follow，确保快速及时的给到客户反馈。

因为每一个变更需要经历多个状态，比如收到变更，组织相关人员分析变更影响。然后发送回客户等待批准。最后批准后，通知项目经理更新项目计划。

每一环都需要时间，而这时间长则几个星期，短则几天。只有专人处理，才能确保每一个变更及时有效的走到最后环节，无论是配准还是拒绝，都是一个结果。

c. 每一个变更需要有记录，对于批准的变更，需要及时加入到项目计划中。

我们在交付的时候经常会碰到某些功能做了，但是根本不知情，或者客户要求做的功能，团队遗漏了。

这其实是需求变更维护没有做好，对于每一个需求的变更，只有在客户批准之后才能够添加到项目计划中，同时为了维护好功能和交付的对应情况，还需要在RQM中添加该功能，以保证在交付的时候避免遗漏。

2. 制定变更流程，并告知相关人员

接下来说说变更流程怎么制定。

首先，定义变更的状态，比如，拟定需求变更，影响分析，客户认定结果，是否更新项目计划。

然后，定义相关阶段又哪方控制。比如，我方团队负责影响分析，以及更新项目计划，而客户团队负责拟定项目变更和客户认定结果。

最后之作流程图，将如何处理变更简单明了的告诉所有相关人员。可以是邮件，可以是在会议上同意说明一下。

下面是一个变更流程的定义，仅供参考，具体情况还是要和客户沟通后确定的：

​