编辑导语：在日常工作中，我们偶尔会遇到需求反复变动的情况，有一半的需求是变动的，这让大家都很苦恼。那么，如何避免这种情况，如何处理和协调团队中的关系呢？本文从需求变化的原因出发，总结了需求变化的应对策略以及如何避免需求变化。让我们来看看。
在日常工作中，我们或多或少都会遇到需求频繁反复变化的情况。无论是在需求分析中改变需求，还是在开发过程中改变需求，都会让大家非常苦恼。那么我们应该如何应对这种情况，才能更好地协调各方关系呢？
# 1.探索需求变化的原因
## 1\.内因
*需求分析的偏差：需要研究时，信息传递会恶化，即会导致用户或客户的需求表达和产品经理的理解，以及需求传递过程中的遗漏或失真(变异是表达、理解和沟通中的遗漏和失真，这里指的是在一个层面上，遗漏和失真就是偏差)。
*未能抓住需求的本质：有时客户无法真实表达自己的变现需求。调查或分析需求时，产品经理只分析表象，没有抓住需求的本质，难以说服各方，容易引起变化。
## 2\.外部因素(外部因素还应包括市场变化和法规变化带来的客观因素)
*开发：在需求评审过程中，开发容易“好”或者不认真评价技术。当开发进行到一半的时候，反馈做不到，需求就提出来了。
*老板/商家端：老板或商家临时添加了紧急需求，或者看到了竞争产品的一些需求而想要。
*战略定位：基于公司战略转型和产品定位变化的需求调整变化。
#二。需求变化的对策
需求确认：确认需求来源，找到原始需求。最好直接与需求提出者沟通，确认需求。
需求分析：对需求变化的真实性进行初步分析，从需求背景、需求目标、需要解决的问题、产品所处阶段、需求成本、风险等方面进行综合评估。
替代方案：不是所有的需求都应该得到满足。考虑是否有替代品，现有产品通过适当调整是否能够满足业务端的需求；有没有性价比更高的第三方现成解决方案？
拒绝：对于伪需求或无差别需求结合产品的阶段，竞争策略应该是正当的，拒绝和接受客户想要的信息，但不能随意接受客户的需求。
需求评审：如果甲方父亲或老板无法拒绝，需要拉技术和团队成员一起进行需求评审，同时评估需求变化的影响，如进度、成本、风险、可能的延迟等。
变更流程：如有内部变更流程，遵循变更流程，请需方确认(签字或邮件回复确认)；如果没有内部流程，将变更需求添加到需求池，并记录变更。
信息同步：重点与需求提出者进行信息同步，同时在团队内部进行变更信息传递、原型和PRD更新同步。
资源申请：需求的变化肯定会影响到既定项目的进度、资源和质量，需要向上反馈，申请项目资源(包括加班)。
开发调度：根据需求的优先级进行开发调度；不用担心需求到下一个版本开发，迫切的需求协调开发马上解决。
风险管理：需求的变化可能会影响原有的产品结构，带来其他潜在的问题，因此需要在开发的同时做好可能的风险管理。
相关方管理：在内部，需要安抚开发、测试、UI等内部团队；这次让外需支持者知道MD，我帮你解决。下次我会改变自己，权衡一下(这是一门需要好好练习的艺术)。
审查汇总：汇总综合版本中生成的需求变更
需求分析：提供需求分析能力，想清楚客户(用户)的使用场景和需求的本质；客户(用户)或业务方有时并不确切知道自己想要什么，因此需要产品经理做好需求启发工作。
变更控制流程：建立健全需求变更流程，确定谁可以提出变更、谁可以批准变更、变更所需的程序(签字或邮件回复)；而不是被业务需求方随便更改，需要适当提高需求更改的门槛。
相关方的管理：确定项目的关键利益相关方，使用RACI工具进行管理，满足关键利益相关方，与关键利益相关方建立良好的关系，并为处理需求变化留出空间。
产品设计：在产品设计上坚持高内聚、低耦合的原则，在技术开发上尽量预留接口和领域，考虑可能的变化提前预留总结。
作为一个产品，他们都可能经历过需求变化的痛苦。为了减少需求变化及其影响，产品经理自身需要提高需求分析能力，找出需求的本质，提高需求启发能力，提高需求变化的确定性和控制能力。
世界上唯一不变的就是变化，需求的变化在某种程度上也是对未来和竞争的快速反应。产品经理需要摆正心态，拥抱变革。
B-end话题200题系列，连续连载，敬请期待！
本文最初由@ Product发布。每个人都是产品经理。未经允许禁止转载。
图片来自Unsplash，基于CC0协议。
