这是一个沉重的话题，不如从一个笑话开始:有一天一个程序员见到了上帝。上帝说:小伙子,我可以满足你一个愿望。程序员回答:我希望中国国家队能再次打进世界杯。上帝:这个啊!这个不好办啊,你还是说下一个吧！程序员想了想：那好!我的下一个愿望是做项目没有需求变更。上帝摸了摸鼻子:还是让中国国家打进世界杯吧…
做项目没有变更，这是一个美好的愿望。需求变更是所有程序猿和PM（产品经理和项目经理）的痛点。但是这是不可能的，“项目一旦启动，变更也就随之而来”，既然变更是无法避免的，与其考虑如何避免，不如想想有什么有效的方法来管理项目变更，或者使之向好的方向转变。
为什么会产生需求变更呢？为了能够获得项目，销售经理给客户描述的一艘航母的建造方案，方案到了PM手上，经过PM冥思苦想抓耳挠腮并掉了N多头发之后，交到程序猿手里之后，程序猿看到的是一艘五桅帆船。当程序猿准备开始建造五桅帆船，接到BOSS通知，为了抢占市场，需要加快进度完成，并且项目经费有限，苦逼程序猿们只好砍到一些暂时可以不做的需求，只做必要的功能，加班加点之后，终于做成了一艘小船。客户验收时，看到一艘破小船，还是靠人肉的，当然勃然大怒，自然无穷无尽的需求变更产生了，为了抚平客户的情绪，PM不得不接受客户的要求，甚至是无理的要求，于是无尽的加班降临了。
在上面的描述中，我们犯了那些错误呢？
• 需求表达不到位，理解不正确
需求描述的过于想当然，为了获得市场，失去了自己的底限，没有需求调研、需求分析、需求评审等的坚定支持，客户认可的需求与程序猿理解的需求完全不对路，造成了一艘航母和一艘小船的巨大落差。应该合理控制、规划需求，随意的增加或删减需求，都会产生不良的后果。需求的管理应该让相关人一同参与、共同把握需求。
• 没有与客户认真沟通需求
从想法到细节，没有与客户沟通，最后给了客户一个巨大的“惊”喜，如果与客户
认真沟通过，至少需求变更的后果就会大大的减轻。
• 没有邀请客户参与
客户之所以大怒，是因为他认为他看到的应该是一艘航母，而不是一艘破船，这说明在过程中没有邀请客户参与，错过了最后的弥补机会，当产品完成，客户才看到产品，得不到客户认可的产品再辛苦也是枉然。
在最后验收时，我们再次犯了错误，为了不得罪客户，再次放弃了我们的底限，正常应该做的和客户拍脑门加塞的都做了，不仅把自己搞的筋疲力尽，也让公司手忙脚乱。此时，我们应该冷静的思考一下需求变更的合理性：
• 业务方面
需求变更通常是因业务变化而产生，所以当变更发生时，也要从业务角度思考，变更是否合理，是否必要，与产品定位是否相符，如果不做是否可以？
• 技术方面
变更对开发的影响，需求变更涉及的部分之前是否已经开发？到了什么程度？是否可以通过技术框架的扩容性解决变更？
• 项目方面
变更对项目的时间、资源、费用会产生多大影响？是否能够承受？
分析清楚后，就理清了变更的脉络，变与不变、现在变还是以后变也变的有理有据。然后再设立完整的需求变更流程，自然就能做到防微杜渐、未雨绸缪。
作为PM，我们天生就是替罪羊，PM夹在客户和程序猿之间，被客户抱怨，被程序猿憎恨。这是PM既定的角色，也是PM要挑战并破解的命运，PM们准备好你们的行程了么？
