PM圆桌派：遇到需求更变，项目经理该如何处理？

一、理解需求更变的影响模型

首先，就是我们先看一下需求：

这个图是项目管理三角，在这个三角中，质量、成本、时间、范围四个因素构成了一个互相影响的三角形。

首先要理解这个三角形，我们可以把这个三角放到二维坐标系中，成本、时间和范围分别位于不同的坐标点，代表着现实中具体的项目成本、时间要求和项目范围，而质量就是这三个点构成的三角形的面积。

在日常实践中，质量是一系列流程、制度、人员共同作用下产生的结果，一般是稳定的，也就是面积不变。因此成本变了就要动范围、时间，时间变了就要动成本、范围，范围变了就要动成本、时间。

之所以需求变更特别 “烦人”，就是因为需求一变，肯定会有其他东西受影响，要不然成本增加了，要不然实现时间hold不住了。

“我之前做了4年的外包项目，专职项目经理做了2年，然后在一家互联网公司做了1年的项目经理，其实处在不同的角色，对于变更的处理方法也会有些差异。比如在外包项目中，甲方是我们必须服务好了。在每个项目中，需求变更是很正常的事情，因为计划赶不上变化——环境、行业、业务都是在发展的，甚至需求本身有问：题后面才发现也是有可能的。我觉得我们作为项目经理，就是要最好随时接到需求变更的准备。”

对于项目管理来说，最常见的情况就是需求变更，用户或是拍脑袋，或是基于某种战略规划，亦或是因为不可控的环境因素。对于需求变更这件事情，我们必须明确一点就是需求变更是项目的必然结果，至于为什么，相信在课上我们都学了----“渐进明细”，但是对于项目经理而言，我们需要将需求变更控制在我们所能控制的范围之内即可。如何控制呢?

二、合理的变更流程

1.客户提交需求变更单;

2.项目组评审变更合理性;

3.项目组评审变更方案和相应代价;

4.和客户讨论确认方案;

5.签署需求变更单和相关方案。这一步在公司内部项目的变更可能不需要了，取而代之的是复盘——为什么会出现这个变更、后续是否可以避免。

三、项目经理应该在变更中发挥自己的价值

1)前期准备：将变更消灭在萌芽中

在项目前期，项目经理需要深入参与到项目范围、需求的讨论确认中，发挥自己的专业能力，将自己的关注点、疑惑和干系人充分考虑讨论沟通。

有需求的时候，要想清楚、问：清楚需求的必要性、合理性，把自己的疑问：和需求方充分沟通。

确定需求的过程中，我们需要同时考虑各相关方的利益因素，首先所有相关方的利益都需要考虑进去，项目发起人、用户、公司、利益受损方。将他们分为两个阵营，共赢体(有蛋糕一起吃，大家都happy)，利益冲突(一般没办法拉拢了，就算拉拢也不是我们能解决的事儿。这是定需求的时候就得尽可能保证我方利益)。

用户不是希赛网，因此我们必须站在他们的角度以解决用户痛点为导向去确定需求，另外公司的目的是赚钱，还得考虑成本问：题，综合以上在需求初期将需求变更的风险尽可能的降低。

2)确认需求：确认需求变更的合理性

不懂业务的项目经理一定不是一个合格的项目经理。因为不同的业务有它的独特性，项目经理在思考问：题的时候如果没有代入业务场景，得到的答：案一定会有问：题。在面对需求变更时，项目经理是需要评估变更的必要性的，如果没有充分的变更理由，完全可以不予变更。

另外就是需求的优先级，优先级一定是和业务重要程度相关的。好的项目经理，一定要了解业务，如果只是套用理论，很难在实战中取得好的成果。

3)开始变更：研究变更方案

当用户提出需求变更时，我们需要评估此变更的可行性，因为其实很多时候客户自己并不了解项目的，有可能只是拍脑袋就提出来的需求，我们PM必须站在用户的位置去梳理此变更是否真的解决了用户的真实痛点，如果不满足则我们实现了对需求变更的第一个拦截。

如果需求确实解决了用户痛点，这时需要评估需求开发周期了，如果完成周期已经超过PM所能cover的水平了，则整理出此需求变更的正负面影响，并提出几个可能的解决方案，联系公司内部会议进行讨论，输出可行性解决方案(或者不可行方案)。

然后组织项目的需求变更论证会(需求提出人，和最终用户，以及项目涉及到的相关开发商)告知不可行性，并提出当前风险(可能造成延期，成本超支，系统稳定性，对线上系统的影响等)。

如果用户依旧要求变更，同时当前的项目阶段还留有余度就可以走需求变更流程了。

4)变更落地

①和客户确认方案：这个过程往往很痛苦，因为客户一般都是 “既想要这个，又想要那个”，还不肯承担代价。这个时候就要项目经理发光发热了，动之以情晓之以理、据理力争、卖人情等等。如果有必要也是可以求助场外观众的，各种看家本领轮番上阵。目的只有一个：为项目组或自己的团队争取更多有利的条件。

②需求变更之后的总结：

◎首先第一时间找出需求变更的根本原因

◎找出有利于我方的所有因素，(目的是将变更带来的影响最小化)比如这个问：题是否会导致负面风险，能否甩锅(死道友不死贫道)

◎安抚因为需求变更而受到负面影响到的人，做好善后工作

◎问：题总结：如果再出现这个情况怎么处理，如何避免

项目经理说：“我经历或者我看到的项目中需求变更也很普遍，但我真的很讨厌无法说服客户就向内施压的方法。施压就是加班，赶工，能加班到凌晨就别11点下班;周末能上班就别休息了。当然，加班费是很少的甚至没有。为什么?因为项目三角决定了，在范围变了之后，成本还不想增加，必须改变时间这个变量了。”

5)后续事宜：团队沟通

好的项目质量，是靠人做出来的，人是最不稳定的。从团队的长远角度考虑，尽量不要用内卷这种方式，而且就算用了，也最好和团队达成一致。一定要和团队沟通好，让大家认识到变更的必要性。这样做起来也不会有太多抱怨，影响团队的士气。

客户方面，客户也要向他的领导交差，压力都是层层压下来的，我们能帮他解决问：题，他肯定也会帮我们解决问：题，干系人管理非常重要。

6)群员实际案例：

“我在L公司的时候给B机构做项目，当时有个需求的工期排了2个多月，但是甲方一级领导(较高级)对这个需求关注度非常高要求一个月内完成，我跟我们研发组确认了以目前的情况来说根本不可能完成，而且这个需求里涉及到Z公司的联调，同时Z公司在做的这个需求的APP部分也是我们L公司想抢占的市场，但是我们对这个APP不完全了解，甲方也没有明确让我们来做，希望多给自己留点时间，于是我拒绝了需求变更。同时也跟我们领导汇报了实际情况，告诉他如果必须提前工期的话，当前的其他需求进展必须后延，而且也把这个事情的关注度告诉了领导，暗示用户会找他。

果然，经过领导层的沟通觉得暂停其他需求的开发(本来APP不让我们做的，结果现在让两家一起开发，谁好用谁)，全力推进这个需求进展，但是我还是没有答：应用户因为在我的预期(跟研发组讨论后得出结论)内完成不了，于是跟用户商量，先在指定时间内完成部分上线，然后两周内完成所有上线工作，最终甲方爸爸还是同意了。

然后就是各自开发了，到了联调的时候Z公司找我们联调的时候接口联调我们也是积极配合，但是系统级测试的时候我没有让测试人员和他们配合，因为我们的APP开发滞后于他们，而是让他们走了流程申请线上调试(其实可走可不走，不过除了我们L公司的人，别人不知道而已)，这样给我们APP争取到了宝贵的时间，最终我们需求上线了，也抢了山头。”

7)问答环节

问：关于成本承担的问：题，考虑一个极端的情况，就是客户要求强制变更，而且不考虑人脉，人情这些因素，还不肯承担成本，但还是想做这个项目，该怎么处理呢?

答：客户是否愿意分期上线，把核心的先上了再说，其他变更后面给他做，不可能所有的需求都是P0吧，那样就真的是在折磨乙方了。再就是看看客户的核心诉求是什么，这个很重要，我现在的中心是产品，所以对于用户的洞察就显得更重要，用户说要a功能，但你深入和他聊完之后，发现他要的是b功能。

问：如果客户就是冲着能多压榨些乙方的劳动力，提出一些合同擦边的需求该如何处理呢?

答：这个要和销售、商务沟通下，看这个客户后面还有没有更多的合作机会，如果只是这个一锤子买卖，那就没必要了。

问：有可能是锤子买卖，但甲方不给上线，且会卡后面的回款，绝大部分钱都是在上线验收后才能拿到的。

答：如果到了这个层面，可能就不是项目经理能hold住的了，赶紧找公司领导帮助吧。领导也不可能不管不问：，准备充分，和领导还是有的谈的，这就是向上管理了。