需求变更：产品经理如何快速正确应对？

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

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

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

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

一、认识需求变更

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

1. 名称定义

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

2. 常见分类

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

二、需求变更的生命周期

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

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

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

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

三、分阶段逐个击破

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

以下是具体实战措施：

1. 需求变更沟通前

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

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

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

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

2. 产品方案落地中

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

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

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

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

3. 方案确认中

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

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

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

4. 方案实施研发中

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

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

场景类型：

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

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

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

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

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

是：判断合理性。

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

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

② 是否合理的需求变更

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

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

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

5. 方案实施已完成

按照新需求处理！！！