需求变更，在项目里或大或小或多或少肯定会发生的，这点在我以前的一篇「重力总是起作用的」提过，需求变更就像重力一样存在。项目经理不应该回避它而应该承认它从而积极的适应它。
在针对不同项目特点也应采取不同的方法来处理变更，这里我来说下我在交付型项目（ToG，ToB 合同类项目）和ToC（自有产品类项目）针对需求变更我的一些心得体会。
交付型项目中主要的需求变更来源于客户（甲方爸爸），只要有过交付型项目经验的应该都深有体会，在交付项目中也有少数的需求变更来源于项目团队内部（前期技术选型有问题，技术方案调整，镀金等），那针对这种情况，项目经理应该怎么应对呢？
首先，我认为当这种情况发生时项目经理不要马上给客户一个答复：做或者不做（这是不负责任的表现）。应该是先分析，找出需求变更最真正的原因，比如客户提出了需求变更，那原因是？ 动机是？ 这里有些动机总结：
1.客户前期对需求有整体的想法，但没有细节，待项目进行中客户逐渐知道他想要的细节功能。
2.上级要求。（这个在ToG和ToB项目里还是比较常见）
3.由于市场、政策、合规等因素，出现需求变更。
4.甲方关键负责人变更。
原因和动机找准后，接下来就需要协助客户梳理清楚需求，把需求变更涉及调整的业务形态搞清楚，并确保需求变更是准确的。（有些项目上遇到同一个功能需求客户多次提出变更，其实就是没准确搞清楚客户真正想要的）
需求变更搞清楚搞准确后，项目经理就需要评估本次需求变更带来的影响，这里的影响主要是分析对项目组时间进度、成本、质量、技术实现难度、技术改造等方面，毕竟交付型项目最关键的还是在规定时间保质保量在成本范围内完成项目。并且告知相关方需求变更带来的影响并一定要获得他们的认同，用户没有最终确认和认同的需求变更一定不能进入实施阶段。
所有的需求变更，不管大小都必须要做正式的书面变更记录，并且明确严格的按变更流程来执行（需求变更流程是在项目启动阶段就通过正式形式告知客户）。需求变更还有很多各式各样的情况，这就需要项目经理根据实际情况随机应变来做处理。如需求变更的大小不一样处理方式也是不一样，对进度、成本、技术实现难度影响都比较小的需求变更，按变更实施流程走就可以，不需要修改计划、变更合同和费用调整等。但如果是需求变更影响很大，就需要和用户确认需求变更优先级、变更里程碑和实施计划、变更合同和增加费用等方面，这些都需要项目经理灵活把握。要是最后项目经理自己真搞不定，那还可以借助商务优势资源同客户洽谈，或寻求高层领导帮助。
接下来说一下怎么能在项目实施过程中减少和控制需求变更，里面很关键的一点是在前期需求调研时一定要通过项目团队的专业性去梳理和引导客户需求，尽可能把用户需求梳理清楚不形成需求盲区，这样后期实施过程中出现大的需求变更的可能性也会降低。还有就是在签署合同时，一定要把需求范围列表明确的写清楚，这样也会减少用户做需求蔓延。再者就是体现我们项目团队的专业性（业务、技术、管理），让客户对产生认同和信任，这样也会减少需求变更。
需求变更不可怕，项目经理也不要怕，需求变更可能会迟到，但永远不会缺席。项目经理应该拿起自己专业知识和技能来拥抱它，是他成为项目成功交付的关键动力。
ToC（自有产品类项目），我更多的是采用敏捷开发模式来看待和处理需求变更，这一块留到下一次点滴记录里去写。
附上PM圈子百人社老师分享和总结的《项目实施过程中如何规避范围蔓延》。「刀很锋利，但主要还是看拿刀的人怎么使用它」
