产品经理如何应对需求变更

产品经理经常会在项目中遇到需求变更的情况，哪怕你计划做的再详细，也免不了受到一些需求变更的困扰，变化不可怕，(毕竟这个世界本身就变化的很快)，关键是要建立起来应对变化的机制，在发生变化的时候，按照预先制定的机制来管理变更。

通常对发生的变更需要识别是否在既定的项目范围以内，如果在项目范围之内，就需要评估变更造成的影响，以及应对措施，及时通知受到影响的各方，如果在项目范围外，就需要商务人员主动和外部沟通，看是否需要增加费用和时间，还是放弃变更。

1、需求管更原因

1.1 需求定义不明确

如果产品经理自己对需求都没了解清楚，就让技术同事进行开发，最后开发出来的东西只能是回炉重造，我之前做EHR项目的时候，因为薪资模块上线比较急，说实话，我之前是做金融的，对薪资模块的业务根本不是很了解，只是简单的写了一些需求，就让技术小伙伴开发，估计技术小伙伴也懵懵懂懂，结果做出来的东西各种bug，不得不回炉重造，我重新梳理细节需求，不断的给大家宣讲。

1.2 需求理解有歧义

你说的是，其他项目组其他成员理解的是贾玲，所以我一般在项目评审的时候，都会让技术的小伙伴主动的说一下他们理解的需求，这种做到彼此信息的理解没有偏差。

1.3 业务需求变更

这个也是我们最讨厌，和最无法可控的，再启动开发之前变更需求还好，在开发启动变更之后，对士气的打击很大，所以产品经理要不断给业务灌输一个意识，一定要明确需求，不能反复变更，如果逼不得已变更，外包的话，就要向业务方要时间要钱，自己公司内部的业务方需求，就需要给团队要时间，让业务方知道，经常变更需求该来的弊端，以此掣肘业务方的需求变更。

1.4 项目周期过长

这也是为什么推荐敏捷开发的原因之一，项目周期过长，容易发生变化，比如技术人员变动，导致的人力短缺，市场环境发生变化，导致业务需求发生变化，古人说的夜长梦多就是这个意思。

2、需求变更来源

需求的变更来源分为两个部分，一个是内部来源，一个是外部来源。

2.1 内部来源：

内部来源又分为两个部分，一个是产品经理变更需求，一个是技术的小伙伴变更需求。

产品经理自己变更需求，主要原因分为以下这些：

1、需求没有考虑清楚，逻辑有遗漏

2、产品设计变更

3、临时插入需求，比如交互要调整、要加字段等。

技术小伙伴变更需求，主要原因分一下这些：

1、技术方案变更

2、人员的变更

说完内部来源，我们再来看看需求变更的外部来源有哪些：

2.2 外部来源：

外部来源有用户、公司的同事、领导、以及市场政策等

1、用户。比如产品的目标用户的需求变了

2、公司的运营、市场、业务等部门变更需求。

3、公司的高层(分为本公司的领导、外部门的领导、以及公司的大boss，这里顺表说一下，职场一定要和领导接近，那些决定你能升官的领导才是你真的领导)。

4、市场政策变化(比如政府政策的调整、潮流趋势、以及突发的黑天鹅事件)。

3、需求变更的目的

记住，所有的变更目的最终一定是能够更好的实现目标，不是追责，也不是扯皮。

产品经理变更需求是为了贴近产品设计;

开发变更需求是为了技术方案更加合理化，便于实现;

用户变更需求是为了贴近自身需求;

公司高层以最小的代价实现目标;

市场人员变更需求是为了适应市场变化;

政策变化是为了产品更加合法化。

4、需求变更的影响

需求变更首先要评估一下需求影响的范围，然后评估一下对现有进度的影响，对项目交付质量的影响，是否需要增加成本(比如人力资源成本、服务器成本等)，以及需求变更带来的潜在风险点。

5、预防需求变更

与其发生问题想办法，不如在问题发生之前去预防。

所以在考虑需求变更之前，我们先想想如何预防需求变更，产品经理提的需求，设计师设计的ui设计图一定要经过团队内部的充分评审，让大家充分发表意见，做到需求理解一致，并最后邮件确认，也许你一个人无法发现问题，但是大家一起头脑风暴，就容易发现问题。

针对技术实现方案，技术团队的同事也要充分沟通，反复研讨，务必把一切能想到的问题提前想到。

对于外部的需求一定要充分沟通，能不变就不。

同时保持对业务环境的敏感，知道业务同事的习性，提前做好应对措施。

针对业务同时可能变更的需求，提早分析，做好预案。

6、接受OR 拒绝需求变更?

针对变更的需求，我们是接受还是拒绝呢?在说拒绝还是接受之前，我们先说一下PM的态度问题，针对变更的需求，PM一定要保持积极的态度，不能消极对抗对于变更的需求一概拒绝，在高度重视的同时，要有全局意识，要能看到变化给每个模块带来的影响，以及给整个全局带来的影响。

那我们判断是否接受变更可遵循以下三个原则：

1、变更对项目是否有利，如果无利，我们肯定拒绝，如果有利，

2、如果变更对项目有利，那我们要接着看，变更需要投入的成本和变更带来的利益，也就是看投入产出比(ROI)如何，然后根据投入产出比判断是否值得更改。

3、如果值得更改，那接着看是否紧急，如果变更带来的收益不是我们目前急需的，也可以往后放。只要那些重要且紧急的变更需求，我们才考虑插入。

7、变更的流程

7.1 收集

对于变更的需求，需求变更方需要通过一定的流程提交给产品经理，不论是邮件还是流程协作工具confluence这种，亦或是自己做的企业效能工具，通过系统的好处就是做到有迹可循，责任到人，事后也方便对需求变更进行统计，以分析变化的原因，降低变化。

7.2 评估

将变更的需求提交给变更控制委员会评审，变更委员会可根据上面的拒绝OR接受需求变更原则进行评估，这个评估的过程就是需求分析的过程，也是头脑风暴的过程。需求变更委员会最好由项目所涉及的多方人员共同组成，应该包括产品经理、项目经理、用户方和开发决策负责人等。

7.3 变更

需求如果确认变更，那就走变更的流程，变更的需求再开一次评审会，给项目团队的成员详细讲解一下。

7.4 修改

评审过后的需求，产品经理要修改对应的文档，开发计划的排期也需要重新排。

7.5 归档

妥善保存变更的相关文档，无论是以后自行查阅还是给到接盘者，让接盘者接手，都很有意义。

对于变更的需求，产品经理对上要反馈现状、明确目标、提出解决方案，对下要组织变更评估，明确目标，体现团队工作成绩。

当然，最好的情况是不变更需求。