.png)
首页>做项目的人，大概都有过这样的经历：项目快收尾了，测试都跑了好几轮，客户突然跑过来说，这个功能得改一下，那个流程得调整调整。你嘴上说好的好的，心里其实已经在崩溃了。我那段时间就是这么过来的，无数个通宵，每次系统的基本功能都按照客户的要求完成了，进入到最后的测试阶段，客户又提出某些功能、某些流程需要修改，真是欲哭无泪。
这种反复修改对整个团队的士气打击很大。大家加班加点赶出来的东西，说改就改，之前的工作好像白做了一样。更让人无奈的是，这种修改好像没有尽头，看不到希望，项目永远没办法终结似的。那时候我觉得，需求变更就是项目管理里最让人头疼的事，没有之一。
后来项目进行到一半，我参加了项目管理的系统学习，这次学习让我受益匪浅，也让我对需求变更加了一层新的认识。需求是永远都会有的，因为客户永远都会有新的或者更好的想法，市场环境也在变，技术也在迭代。我们要做的不是堵住变更，而是学会正确面对不断变化的需求，在不镀金的前提下提高客户满意度。
需求变更为什么不可避免
很多项目经理把需求变更当成敌人，觉得客户就是故意找茬。其实换个角度想，客户提变更，说明他在乎这个项目，希望结果更好。如果客户什么都不说，你交什么他收什么，那才危险——要么是他根本不关心项目结果，要么是他已经放弃了。
需求变更的来源很多，常见的有这么几种：一是客户在项目初期没想清楚，做到一半才发现原来的设计不符合实际业务；二是市场环境变了，竞争对手出了新功能，客户不得不跟着调整；三是技术方案落地时发现原来的设想有问题，需要修正；四是政策法规变了，项目必须合规调整。这些情况都不是客户故意为难，而是项目本身的不确定性决定的。
所以，与其抱怨变更多，不如承认变更的必然性，然后建立一套机制来管它。管得好，变更不会拖垮项目，反而能让最终交付的东西更贴近客户真实需求。管不好，就是我之前那种状态，团队疲于奔命，项目遥遥无期。
控制变更的第一个关键：建立变更管理流程
很多项目出问题，不是因为变更多，而是因为变更没有流程。客户一句话，开发就改了，改完才发现影响了别的功能，或者成本超了、进度拖了。没有流程的变更，就像没有红绿灯的十字路口，迟早出事。
我们后来建立了规范的需求变更管理流程，事实证明，流程不是项目成功的绊脚石，恰恰相反，对变更管理的有序进行，会对项目的成功起到事半功倍的效果。一个完整的变更流程大概是这样的：
|
步骤
|
关键动作
|
责任人
|
产出物
|
|---|---|---|---|
|
第一步
|
变更请求正式提交，书面记录变更内容和原因
|
提出方（客户或内部）
|
变更申请单
|
|
第二步
|
评估变更对范围、进度、成本、质量的影响
|
项目经理及核心团队
|
变更影响评估报告
|
|
第三步
|
提交变更控制委员会或相关干系人审批
|
变更控制委员会
|
审批结果（批准/拒绝/暂缓）
|
|
第四步
|
批准后更新项目计划和基线，安排实施
|
项目经理
|
更新后的项目计划
|
|
第五步
|
执行变更并验证结果，记录到变更日志
|
执行团队
|
变更验证记录
|
这个流程的核心是"先评估、再审批、后执行"，任何变更都不能跳过评估直接改。刚开始客户可能不习惯，觉得走流程麻烦，但当他看到每次变更都有明确的影响分析和时间成本预估，反而会更慎重地提变更，不合理的变更自然就少了。
控制变更的第二个关键：做好风险和成本评估
作为相关干系人，一定要做好变更的评估工作，因为只要是变更，就意味着风险，只要是风险，就意味着对项目一定会存在冲击。很多项目经理犯的错就是客户说改就改，根本不算账，改到一半才发现这个变更要多花两周时间、多花十几万成本，这时候再跟客户说，客户也不乐意了——你早干嘛去了？
变更评估要考虑三个层面：
第一是成本影响。这个变更需要多少人天？要不要额外采购？会不会导致其他工作返工？把账算清楚，给客户一个明确的数字。
第二是进度影响。这个变更会不会影响关键路径？会不会导致交付时间推迟？如果会，推迟多久？这些都要明明白白告诉客户。
第三是风险影响。这个变更会不会引入新的技术风险？会不会影响系统稳定性？有没有替代方案？风险应对策略是什么？
把这些评估结果摆到桌面上，客户才能做知情决策。有时候客户听完评估，发现这个变更性价比太低，自己就撤回了；有时候客户愿意承担额外的成本和时间，那我们就按变更后的计划执行，双方都没话说。我们要做的就是考虑到所有相关的成本、风险以及风险应对策略，以确认客户能接受相关评估。
控制变更的第三个关键：加强沟通
沟通是解决问题的有效途径。在遇到变更发生时，应该多和客户进行沟通，确保所提出的变更需求合情合理，用心给客户讲解相关道理及风险。很多变更其实是信息不对称造成的——客户不知道这个改动背后有多大工作量，项目经理不知道客户为什么非要改。坐下来聊一聊，很多问题就迎刃而解了。
沟通有几个技巧。一是尽早沟通，不要等变更已经造成影响了才说，在变更评估阶段就把客户拉进来一起讨论。二是用数据说话，不要说"这个改动很麻烦"，要说"这个改动涉及三个模块的修改，预计需要五个工作日，可能会影响交付时间"。三是给方案，不要只说不行，要告诉客户"如果一定要这个功能，我们可以这样做，代价是什么；或者用另一种方式实现，成本更低"。
当然，有的变更会给我们带来意想不到的收获。客户提的某个需求，可能正好补上了产品的一个短板，或者打开了一个新的业务方向。所以，用平常心去对待工作中发生的每一次变更，不要一听到变更就抵触，先听清楚客户想要什么、为什么要，再判断怎么处理。
变更管理不是挡箭牌，而是安全阀
说了这么多变更管理的方法，其实核心就一句话：变更不可怕，失控的变更才可怕。建立流程、做好评估、加强沟通，这三件事做扎实了，变更就从项目的敌人变成了项目的一部分。
我自己的体会是，自从把变更管理流程建起来之后，团队的加班反而少了。因为每个变更都走评估审批，不合理的变更在评估阶段就被过滤掉了，合理的变更有明确的时间和成本安排，不用再临时插单、通宵赶工。客户满意度也提高了，因为他知道每个变更都会被认真对待，而不是被敷衍。
这些方法不是我自己摸索出来的，而是在PMP的学习中系统学到的。PMBOK里的整合管理知识领域专门讲了实施整体变更控制，从变更请求到影响评估，再到审批和执行，有一套完整的方法论。优培东方的PMP课程在讲这部分的时候，老师会结合大量真实案例，把变更管理的流程、工具、常见坑都讲透，不是照本宣科念定义，而是真的能用到工作中去。学完之后再回头看自己之前做的项目，很多问题其实在PMP的知识体系里都有标准答案。
如果你也在被频繁的需求变更折磨，建议系统学一下项目管理，不是为了拿证，而是为了让自己的工作更有章法。需求永远会变，但我们应对变化的能力可以变强。
粤公安备案 44010602008731号