需求变更控制详解

控制变更

♪

PM吃瓜

需求变更本是正常的，并不可怕，可怕的是需求的变更得不到控制。

为什么会有变更？

1. 签订合约的时候，项目范围描述不清楚。这是最常见的问题之一
2. 客户和项目组对写成纸面文件的需求理解不一致, 同一件事情，客户的认知和项目组的认知完全不同。
3. 客户总有在结项之前把每一件事情都做得淋漓尽致的初衷
4. 项目组人员总是无条件迁就客户，客户有求必应。

变更代价

但对于开发小组而言，需求的变更则意味着要需要重新进行估计，调整资源、重新分配任务、修改前期工作产品等，而作为开发商，需要增预算与投资，开发组要为此付出较重的代价。

需求变更控制的动机

对于需求的变更，在某一个程度上来说，也就是项目的范围进行了变化。而需求同时又是项目进行的基础。是非常得要的基石。通常对于需求的变更需要客户与开发方共同参与，包括负责人及市场人员。当然，我们需要根据变更的内容来灵活运用。

a. 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 b. 如果需求变更带来的坏处大于好处，那么拒绝变更。

解决方案

需求变更控制最简单的方法，就是提高变更的代价，比如通过制定需求变更的模板及很长的审批链条来控制变更的频率。如果需求变更没有代价，那么用户提需求的时候就容易草率，对项目管理百害而无一利。 1st. 在需求整理完毕形成文档以后，最好先让项目组人员把自己总结的需求跟客户比较详细的讲一遍 2nd 如果项目前期人员对技术非常不了解，根据实际情况最好在需求每次提交给客户前与研发人员沟通

若变更不可避免

1) 评估需求变更 2) 书面形成变更说明书，包括工作量，成本，时间 3）客户确认

最后还有一个重要的过程就是要与客户确认这次沟通的结论。

最重要的原则就是

• 和客户建立变更规则
• 增加变更的摩擦系数

事先没有规则怎么办？

如果事先没有“游戏规则”的话，开发方的负责人需要一些社交技巧来减缓矛盾。 • 例如首先承认客户提出的需求变更请求是合理的，再阐述己方的难处，

最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多，

既不得罪客户，又为自己争取了余地。 • 另外还有一种方法，可以将变更需求先进行记录，并通知给客户，当其

需求变化在开发组不能接受的范围时，可以通过市场进行相关的协调。