编辑导语：在日常工作中，我们偶尔会遇到需求反复变更的情况，做到一半需求更改，搞得大家都很烦恼。那么，如何避免这种情况的发生以及该如何应对这种情况，协调好团队中的关系？本文从变更原因出发，总结出现需求变更的应对策略以及如何避免的方法，一起来看看。

我们在日常工作当中，或多或少都会遇到需求经常反复变更的情况。不是在需求分析当中变更要求，就是在开发过程中变更需求，搞得大家都很烦恼，那么遇到这样的情况，我们应该如何应对，才能更好的协调好各方之间的关系呢？

一、探究需求变更的原因

1. 内因

• 需求分析偏差：需要调研时信息传递会出现变差情况，即造成用户或客户的需求表达和产品经理的理解，以及需求传达过程中出现的遗漏或是失真情况（变差，是在表达、理解、传达中的遗漏和失真，这里是一个层面的意思，遗落和失真就是偏差）。
• 没有抓住需求本质：客户有时候不能真实表达其实现需求，在需求调研或分析时，产品经理只分析表象，没有抓住需求实质，就很难说服各方，容易引起变更。

2. 外因（外因应该还有：市场变化、法规变化带来的客观因素）

• 开发：开发容易在需求评审时“好好”或是没有认真进行技术评估，等开发一半时反馈做不了，提出要该需求
• 老板/业务方：老板或业务临时加的紧急需求，或是看到竞品有的需求也想要
• 战略定位：基于公司战略转型、产品定位改变而做出的需求调整变更

二、出现需求变更的应对之策

需求确认：确认需求来源，找到原始需求，最好能与需求提出方进行直接沟通，进行需求确认。

需求分析：对变更的需求进行真伪的初步分析，从需求背景，需求目标，需求解决的问题，产品所处阶段，需求成本，产生的风险进行综合评估。

替代方案：并不是所有的需求都要满足，考虑是否替代方案，现有的产品适当调整能否能满足业务方需求；是否有性价比更高的第三方现成的解决方案。

拒绝：对于伪需求或无差异需求结合产品所处阶段，竞争战略要有理有据的拒绝，接受客户想信息，但不能随意接受客户的需求。

需求评审：面对甲方爸爸或是老板金主，实在拒绝不了，就需要拉着技术以及团队成员一起进行需求评审，同时评估需求变更产生的影响，如进度，成本，风险，可能造成的延期等。

变更流程：如果内部有变更流程，走变更流程，请需求方进行确认（签字或是邮件回复确认）；如果内部没有流程，把变更需求加入需求池，做好变更记录。

信息同步：重点向需求提出方进行信息同步，同时也要在团队内部进行变更信息传达，原型以及PRD及时更新同步。

资源申请：需求变更肯定会既定项目的进度，资源，质量会有影响，需要向上反馈，申请项目资源（包括加班）。

开发排期：根据需求轻重缓急进行开发排期；不着急的需求安排到下个版本开发，着急的需求协调开发立刻解决。

风险管理：需求变更可能会原有的产品架构产生影响，以及带来其他潜在的问题，需要与开发等一起做好可能的风险管理。

相关方管理：对内需要对开发，测试，UI等内部团队做好安抚工作；对外对于需求提出方让其知道感MD这次我帮你解决了，下次变更自己掂量掂量（这是门艺术，需要好好修炼）。

复盘总结：对于产生的需求变更从内外因综合复盘总结，提高需求变更控制能力。

三、如何避免需求变更（或降低需求变更带来负面影响）

需求分析：提供需求分析能力，想清楚客户（用户）使用场景以及需求本质；客户（用户）或业务方有时并不清楚自己到底想要的是什么，需要产品经理做好需求启发工作。

控制变更流程：建立和健全需求变更流程，确定谁可以提变更，谁可以批准变更，变更需要的手续（签字还是邮件回复）；而不是业务需求方随口一句就可以变更，需要适当增加需求变更的门槛。

相关方管理：识别项目关键干系人，通过RACI工具进行管理，让关键干系人满意，与关键干系人建立好关系，让在处理需求变更时留有余地。

产品设计：在产品设计时坚持高内聚低耦合为原则，技术开发时尽量预留接口和字段，考虑可能出现的变更提前预留总结。

身为产品可能都经历过需求变更之苦，要想减少需求变更以及需求变更带来的影响根源还是产品经理自己需要提高需求需求分析能力，找到需求本质，提高需求启发能力，提高需求变更的确定性以及需求变更把控能力。

这个世界唯一不变的一切都在变化，需求变更某种程度也是对未来以及竞争的快速响应；产品经理需要摆正心态，拥抱变化。

B端话题200问系列，持续连载中，敬请期待！

本文由@产品说事儿 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。