需求变更是指对项目功能、性能、进度、成本等的变化调整，作为一名产品经理，如何正确应对需求变更？本篇文章作者将详细为我们介绍在项目的不同阶段处理需求变更的不同方法，希望对你有帮助。

提起需求变更，多数产品经理人并不会陌生，它基本在我们日常的需求迭代中都可能会出现，控制的好，项目正常上线，项目组成员皆大欢喜。

控制不好，业务负责人、合作方、老板，包括研发兄弟们，都有可能不满，甚至情绪激愤时还会“口吐芬芳”，故此乃产品经理“荣辱之地”，不可不察也。

可是，需求变更就像五月的天气一样，说变就变，且牵涉多个相关方、上下游，如何应对？且如何在变化之中，能够快速精准识别定位变更原因，应对风险？

以下我将就自己的一些个人经验和大家分享一下。

一、认识需求变更

要搞清楚需求变更，我们先要清晰需求定义和分类。

1. 名称定义

需求变更是指在项目开发过程中，客户或相关方对项目需求的变化，包括对功能、性能、进度、成本等方面的调整。

2. 常见分类

• 用户反馈。用户使用产品后提出的反馈和建议可以导致产品需求变更。用户反馈可能包括对产品功能的需求、对用户体验的改进建议、对产品性能的提升要求等。
• 市场调研。市场变化可能是产品需求变更的原因之一。竞争对手的发布、市场趋势的变化、新技术的出现等都可能导致产品需求变更。
• 业务需求。公司的业务需求也可能导致产品需求变更。例如，公司可能需要推出新产品以扩大市场份额，或者需要将现有产品与新的业务线进行整合。
• 法律法规。突然更新的法律法规的变化也可能导致产品需求变更。例如，某些国家可能颁布新的隐私法规，这可能会导致公司在产品设计中需要进行相应的调整。
• 技术限制。技术限制也可能导致产品需求变更。例如，在某些情况下，技术限制可能会导致产品无法实现某些功能，或者需要使用新技术来实现。
• bug修复。产品中的错误和漏洞可能需要修复，这直接会导致产品需求变更。

二、需求变更的生命周期

产品的生命周期分为：需求调研、产品方案初步阶段、详细阶段、方案评审、研发阶段、上线验收。

需求变更在产品生命周期的整个周期内都可能会出现，而每一个阶段应对措施是不一样的，为什么？

因为在每一个阶段需要花费的时间和人力资源成本是不同的，这也决定了应对措施的不同效率和应对方案。其中，最重要的一项：成本控制。

成本的控制影响到你的需求方，合作方的直接收益，以及研发兄弟们的付出能不能应对老板年底述职的“灵魂拷问”，自然也包括你自己。

三、分阶段逐个击破

原则：明确当前阶段，识别风险程度，快速正确响应、同步相关干系人。

以下是具体实战措施：

1. 需求变更沟通前

线下组织沟通会，可以是正式的，也可以非正式会议，重点在将需求变更聊透彻。

• 把握重点。确定产品定位，把控业务发展方向、渐进明确，挖掘业务侧显性与隐性需求，重点在于将需求聊明白（可落地的层面）。
• 信息拉齐。同业务方leader、各相关方，保持理解一致，形成明确结论，并邮件通晒相关方（集体决策）。

这个阶段出现需求变更，保持正常的心态，积极拥抱。

因为在这个阶段，方案没有确定，调整方案的成本是最小的，但在这个阶段需要及时纸质化需求结论，并及时同步各相关方。保证信息拉齐，重要变更事项，一定邮件中颜色加粗@重要人员（保证留痕）。

2. 产品方案落地中

组织线下需求变更方案评审会。

• 主导会议方向：同业务方、合作方、运营、财税法，所有项目需求相关人员，线下组织产品方案评审会，沟通确认变更流程，主导方案会议方向，给出合理落地建议（识别关键决策人）。
• 注意事项：不要局限在方案原型设计，系统交互上，以及接口细节中，重点在判断业务需求变更合理性与系统可行性，提出专业性建议。

会议开始前，提前重点和关键决策人，沟通项目可能面临风险，获取其应对变更预期（包含上线时间，成本收益），在会议中做到有的放矢。

会后形成需求变更邮件，并保证信息拉齐，及时邮件同步项目组全员。

3. 方案确认中

同关键决策人沟通需求变更项，确认变更内容。

识别关键人：线下干活沟通的人可能没有决策权，多数情况下只负责需求的传递，往往在需求传递中，真实信息就会衰减。为了避免上线后，做无用功识，需求变更方案最后确认阶段，一定和关键决策人达成共识。（关键决策人即是为项目收益直接负责的人，简单点理解，对其OKR、晋升有重要影响的人）

重点和关键决策人确认变更方案，达成共识，并邮件同步各相关方，保证信息及时拉齐。

4. 方案实施研发中

识别变更来源，确定需求变更优先级。

1）来自内部（这里特指需求发起方【外】和执行方【内】），包括研发、测试。

场景类型：

• 设计缺陷、代码bug。
• 直接影响业务发展，包含敏感数据、错误信息。
• 上线后可造成直接资金损失或重大舆情风险问题。

以上场景发生，即刻应对变更：

• 及时邮件同步各相关方，并确保关键人识别该风险紧急程度。
• 组织关键人和各相关方积极采取应对措施。

2）来自业务方（需求发起方），主要包含商务BD，产品运营等。

① 是否关键干系人发起的变更

是：判断合理性。

• 合理：积极应对，由业务方明确变更需求邮件（包含变更背景，带来的风险，应对措施），通晒相关方知悉变更内容。
• 不合理：陈明利害，拒绝变更。

否，与关键干系人沟通确认是否可以变更。

② 是否合理的需求变更

合理：是否可以放在下一个迭代。

• 是：放入下一个迭代完成。
• 否：积极应对，由业务方明确变更需求邮件（包含变更背景，带来的风险，应对措施），通晒相关方知悉变更内容。

不合理：陈明利害，拒绝变更。

5. 方案实施已完成

按照新需求处理！！！