变更是项目中最常见的场景，也是最让PM“秃头”的难题之一。

大概一提起变更来，大家脑海中浮现的场景就是：

客户拿着一沓材料对项目经理说，“小王啊（不是我），我们增加两个需求，明天给我做个原型出来。什么？还要钱？这个需求很简单的，就是增加一个审批节点，让程序员改两个小时就行了。就这样吧，明天我要看”。

以上场景不知让多少项目经理头秃。

所以，我们迫切的希望，能更了解变更，更能管控变更，更能降低变更带来的问题和风险，更多享受变更带来的红利。

变更真的被人那么讨厌吗？

是否有人喜欢变更呢？

简单分析一下，不难得到以下结论：

1.谁喜欢变更：

甲方、乙方领导（以及其他享受变更红利的人员）。对于甲方来说，变更可以帮助甲方修正思维偏差，更接近需求；对于乙方领导来说，变更带了直接的收益，和潜藏的机会（新的合同、商机）

2.谁讨厌变更：

乙方团队（其他因变更成本过高造成损耗的团队）。

通常意义下，变更会带来额外的工作量，轻则导致成本增加，进度延迟，重则导致成本过耗，进而直接影响项目交付以及组织发展。

想要对变更有更深入的掌握，就要对变更本身有深入的了解，所谓“知己知彼”，才能“百战不殆”。

根据PMBOK的定义，变更是超出项目基准范围外的工作，也就是说，变更的判定的是基于基准的，并非所有额外新增的工作量都应该当做变更来对待。

变更，顾名思义，变，就是不同于基准；更，就是要执行这个变更带来所有的制度上、流程上、文件上、意识上以及人员上的刷新。

变更的本身，是基于基准进行的，是需要进行一系列更新的，是涉及成本的，是会引发交付风险的。

所以，遇到任何变化之前，均需要与项目各项基准进行比较，真正发生改变的才是真正需要考虑的变更，而其他的，类似于由于很多其他原因导致的，不遵守基准、不守规矩的额外工作量并不是真正意义上的变更，是伪变更。

我们真正需要去评估影响、提交需求、走变更手续评审的是真变更，需要抵制的是伪变更。

为了更好地识别变更，我们也应该做到建立一个符合项目交付要求、可验证、可实现、具有指导作用的基准体系。

注：本文重点分析变更，关于基准内容可以后面再研究（可催更）

为什么会引发变更呢？

在变更的场景里，甲乙双方都是变更的常客。

除了因为不遵守规则产生的偏离（伪变更）外，真变更的核心原因主要包含以下两个方面：

1.客户方面：思维验证慢，更新成本低

原因：甲方是出钱方，其供需关系位置导致其话语权大，对整个需求方向有指导性作用，且不关注如何实现，主要输出的是想法、思维和逻辑。

在没有落地之前，思维更新的速度、迭代频率是非常高的，且思维创新成本很低。

此外，甲方除了项目诉求外，主要负责人往往还承担其他诉求：令高层领导满意、令用户满意、个人业绩等方面。

因此“一天一个想法”“一会一个想法”“改了9版还是用第1版”的现象发生，也就不奇怪了。

分析：对于甲方的这类行为，项目经理应该进行充分理解并进行引导。

对于客户而言，也许并非其本身意愿，也许在客户角度，“变更”是解决方案，能够帮助其解决眼前的困境，因此一定要协助其充分挖掘变更的根本原因，并找到替代方案。

另一方面，要进行沉浸式管理，打造“同甘共苦”的团队环境，让甲方深刻了解项目变更带来的成本和问题，并指导其为结果负责。

变更并非简单的改变，任何的“牵一发”都有可能“动全身”。

措施：①站在客户视角分析梳理变更，找到替代方案；

②充分引导客户，让其为决策结果负责。

2.团队方面：视角窄化，技术膨胀

原因：乙方团队也是变更中的常客。

对于项目团队核心成员（尤其技术成员，尤其资深技术成员），对变更的不重视程度跃然纸上。

一方面，技术人员过分迷信技术能力，通常以为“顺手调整”就能解决问题，忽略了一个改动带来的影响，忽略了交付目标之间的偏差，并让项目经理“后知后觉”。

另一方面，乙方团队成员的视角相对比较窄化，每人各自负责一块，缺少全局视角的判断力，自然就无法对“变更”有一个全面的评估。

分析：项目经理要背这个督促不严格的锅。

作为PM一定要有基准的概念。在项目立项初期，一方面要规定交付物的标准规范，大家能够达成共识，共同为这个目标去奋斗。

另一方面，也要规定交付过程标准规范，比如项目管理制度、岗位职责说明、沟通规范、驻场交付行为规范、范围管理规范、需求管理规范等制度文件，并严格在项目组内进行推广。

说白了就是给大家立规矩，让大家知道如何规范地开展工作。

比如常见的两个现象，团队成员私自修改架构，属于不符合团队管理规范；私自修改需求，越过项目经理，也属于不遵守沟通规范、需求规范。

对于这些点，在变更前就作为风险灌输给团队，在项目初始就予以明确说明，应该可以规避很多不必要的工作量。

措施：①对目标达成共识，随时纠偏，防止偏离；

②设计可量化基准和制度规范，宣贯给每个团队成员，保证大家遵守。