需求，是项目经理的紧箍咒。
开发说到需求，项目经理磨破嘴；
甲方说到需求，项目经理跑断腿。
其实需求本身不可怕，
大家怕的是它后面跟着的“变更”。
那么问题来了，
为什么需求会变更？
我堂堂项目经理，还控制不了它吗？
为了签合同不择手段
对客户要求大包大揽
客户：这世间所有的功能，我全都要。
售前：好！可以！没问题！
开发：不行，没戏，实现不了。
客户：我不管，你答应我的，给我改。
三方沟通不顺畅
甲方和开发之间隔着一个宇宙
客户：马冬梅
需求文档：horse winter flower
开发：玛丽莲
客户：？？？
启动阶段需求分析不足
给客户留下了钻空子的空间
开发评估：APP识别不了手机壳的颜色！什么XX需求！
项目经理：客户爸爸，APP识别不了手机壳的颜色呀
客户：你怎么不早说？别家都说这个识别不了，就你们没说，我才选择跟你们合作的，退钱！
答应的太痛快
让客户以为变更成本很低
客户：项目经理，有个小需求要改一下
项目经理：您看这个变更流程...
客户：不用不用，小事一桩，一句话就说完了
项目经理：那您说
客户：这版不行，全部重做。
我们是项目经理，
我们不怕变化，
我们怕的是跟不上变化的步伐。
怎样不被变更牵着鼻子走？
这里有6个办法可以参考
把风险提前解决
在签订合同的时候，先约定哪种情况的变更可以接受，哪种部分接受、哪种不能接受。
虽然我们也知道，在签订合同时，我们做不到精确定义每项要求，但合同只要签了，就能具备一定的约束力。在你被客户和开发两面夹击生不如死的时候，或许一份合同条款，就能救你于水火之中。
规范变更流程
流程麻烦吗？麻烦。流程必要吗？必要！
流程就像减速带，为的就是让客户把速度降下来，把脑子跟上去。有些需求变更只适合过过嘴瘾，一旦要写下来，客户自己都觉得浪费墨水。
在审批不合理需求的过程中，客户失去了张口就来的快感，又能意识到需求的不合理性，自然可以减少无效变更。
分级管理变更
当客户的需求变更突破了前面的两层防御，直奔项目经理而来的时候，说明这个需求是非改不可了。
这种情况下我们可以给客户提出建议，把新需求按重要和紧迫程度分档，作为需求变更评估的一项依据，在需求变更会议上专门讨论。
变更会议后，给客户提交一份需求变更计划，告知各项变更可能引起的时间、资金成本，要求客户配合需求变更计划，保证大局稳定。
一般来说，只要客户的需求不是拍脑袋而来，此时就会考虑接受变更的代价；如果变更可有可无，客户就很可能会取消变更。
建立完善的变更管理还有一个好处：即使没有达到最理想的结果，也可以避免项目经理同时遭到客户和开发团队的里外埋怨。
专人负责变更管理
如果有条件，我们也可以专门派一个工作人员管理需求变更，专门负责客户和开发成员的沟通和跟进。
当然这种操作对大部分人手不足的项目组来说，都是比较奢侈的，这里仅作建议，大家量力而行就好啦！
让客户参与需求评审
如果条件允许，我们也可以请客户参与需求评审，作为需求的提出者，他们理所当然是最具权威的发言人之一。实际上，在需求评审过程中，客户往往能提出许多有价值的意见。
同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。
前面说的终归是补救措施，而亡羊补牢，永远比不上未雨绸缪。
要减少需求变更导致的加班，项目经理可以把时间更多地用在前期，尽可能挖掘客户的潜在需求，发现可能会产生变更的地方，让客户在前期确定，是否需要进行相应变更，而系统开始运行后，就不再接受类似的变更需求。
这种做法在合同的约束下，可以发挥出更好的效果。虽然前期会花费较多时间，但能够有效减少后期扯皮，简直是功在当代，利在千秋。
我们都能理解，并不是所有变更都不好，很多时候客户提出的需求，确实能让产品更完善。只是需求万千种，并不是每一种都适合做出来。
摒弃零碎、非必要的需求，规划好必要的、逻辑清晰的需求变更，是我们项目经理的天职，也是责任。
你是谁？
我是需求变更
你从何处来？
从售前、甲方、老板、用户处来
你往何处去？
往项目经理锅里去！
