理想主义
PMBOK中的变更有一套详细的流程，涉及到基准、CCB、项目团队。
大概的规则是：
提交了变更之后，需要经过项目团队的判断。
变更涉及到基准的，需要上报CCB，经过CCB同意的才可以变更且存档，否则不可以变更，并且需要记录这个被否决的变更，下次再有人提出则可以拿出存档否决
变更不涉及到基准的，项目经理可以自己做决定，并且记录存档。
理想是美好的，大家钥匙都可以和和气气的按照标准流程走，那当然是美滋滋，然而，现实往往会给你一记重拳。
应对实际的变更，往往会有如下说辞：
“小王啊，你看着功能也不难，你们技术这么厉害，随便加加就可以了嘛”
“老刘，我可不管啊，我们这么多年交情，加一个功能怎么了，加，必须加”
“这个必须改，要不然这个阶段不验收，我这还有个会，你们自己看着办”
“这个问题很难解决么，不行我找别人了，你们太菜了”
……
OH NOOOOOOOOOOOOOOO！！！
面对这些，我们需要更多细节的操作，仅仅只靠流程，是没有办法说服甲方爸爸的。
具体如下。
血泪教训
在甲方面前别打肿脸充胖子，该哭哭，该撒娇撒娇，我们不是要避免变更，而是管理变更，不是所有的甲方都明白，乙方项目经理得把他们引导，引导甲方向咱们想要的方向去，晓之以情，动之以理。
关于CCB：
项目经理可自己组建CCB，定期举行会议，增加仪式感，使各方慎重决定，聚焦于产品。
学了PMP落地要根据实项目际，没有变更管理委员会，可以把关键相关方召集经常开个汇报会，把项目管理中的各方面说清楚公司没有CCB。
PM根据项目要有意识组建CCB，增加仪式感，让相关方提需求更慎重。
领导或者客户教育很难，我们能做的其实是在项目中保障项目中的信息尽量跟客户和相关方透明对等。
压力分摊，基于信息的基础，在我们作出变更的时候，让各相关方了解变更对项目产生的影响，把进度、成本质量的压力分摊到所有的相关方身上我们没有CCB，但CCB的设立也可以参考这样的原则。
关于存档：
规范变更流程，杜绝来路不明的变更。
给变更定个值，用这个值来判定变更。
PM随时准备好一张需求表，相关方来找PM提需求，变更留痕。变更留痕，避免扯皮。
针对碎片化的变更一定要做好留痕，统一和关键相关方评估确认。
变更确定后，立马要更新WBS，确定交付标准。
合同要完善，现代项目管理边界都在往前往后拓展，前期项目谈判项目经理就介入，另外变更等注意保留证明。
都是同一条船上的蚂蚱：
面对变更，一定要有基准的概念，面对变更，项目一定要有共同的目标，基准即将被打破，项目经理须综合评估项目价值，控制基准还是以项目价值为准。
甲方变更原因：甲方是出钱方，不关注如何实现，其思维创新成本很低。因此需要引导甲方，进入沉浸式管理，将团队工作与甲方产生关联。
把自己的良好实践分享给项目参与者，从而达到管理变更的目的。
同意变更时候，可以提出条件，综合考虑，均衡利弊。
涉及到钱的时候，PM不要硬抗，让商务参与进来，让公司高层管理参与进来。
相关方提出变更，抛出问题变更是为了什么，价值点在哪里，引导相关方深入思考为什么要变更，帮助客户弄清楚自己想要的，后面的工作会变的越来越轻松。我们最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求化，以简洁为本，它是极力减少不必要工作量的艺术。
变更要慎重次生风险，从乙方视角说，能不变尽量少变，但从需求方说，客户方满意，已经不仅仅是契约精神了。
甲方、客户、老板很难教育，先让团队成员明白变更带来的影响。告知成员不好拒绝的时候，可以把项目经理喊来一起参与变更的沟通
如何引导甲方谨慎变更？
分析：
鱼骨图找原因①业务流程问题②需求判断不足③变更管理没做好④客户关系问题⑤对变更跟踪不足⑥变更反馈没有
解决办法：
根据业务流程拆解工作任务，全部分成功能模块，以便客户选择。客户需求发生变化，我们同时引导进度变更，你变我也变，但要和客户讲清楚，不能硬碰硬。
操作技巧：
梳理业务看流程，需求判断看价值，变更处理看引导，客户维系看效能，变更跟踪看成果，效果反馈看评价。
