需求变更本是正常的，并不可怕，可怕的是需求的变更得不到控制。
为什么会有变更？
- 签订合约的时候，项目范围描述不清楚。这是最常见的问题之一
- 客户和项目组对写成纸面文件的需求理解不一致, 同一件事情，客户的认知和项目组的认知完全不同。
- 客户总有在结项之前把每一件事情都做得淋漓尽致的初衷
- 项目组人员总是无条件迁就客户，客户有求必应。
变更代价
但对于开发小组而言，需求的变更则意味着要需要重新进行估计，调整资源、重新分配任务、修改前期工作产品等，而作为开发商，需要增预算与投资，开发组要为此付出较重的代价。
需求变更控制的动机
对于需求的变更，在某一个程度上来说，也就是项目的范围进行了变化。而需求同时又是项目进行的基础。是非常得要的基石。通常对于需求的变更需要客户与开发方共同参与，包括负责人及市场人员。当然，我们需要根据变更的内容来灵活运用。
a. 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。
b. 如果需求变更带来的坏处大于好处，那么拒绝变更。
解决方案
需求变更控制最简单的方法，就是提高变更的代价，比如通过制定需求变更的模板及很长的审批链条来控制变更的频率。如果需求变更没有代价，那么用户提需求的时候就容易草率，对项目管理百害而无一利。
1st. 在需求整理完毕形成文档以后，最好先让项目组人员把自己总结的需求跟客户比较详细的讲一遍
2nd 如果项目前期人员对技术非常不了解，根据实际情况最好在需求每次提交给客户前与研发人员沟通
若变更不可避免
1) 评估需求变更
2) 书面形成变更说明书，包括工作量，成本，时间
3）客户确认
最后还有一个重要的过程就是要与客户确认这次沟通的结论。
最重要的原则就是
事先没有规则怎么办？
如果事先没有“游戏规则”的话，开发方的负责人需要一些社交技巧来减缓矛盾。
例如首先承认客户提出的需求变更请求是合理的，再阐述己方的难处，最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。
另外还有一种方法，可以将变更需求先进行记录，并通知给客户，当其需求变化在开发组不能接受的范围时，可以通过市场进行相关的协调。
| 
转播
