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

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

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

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

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

一、认识需求变更

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

1. 名称定义

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

2. 常见分类

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

二、需求变更的生命周期

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

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

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

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

三、分阶段逐个击破

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

以下是具体实战措施:

1. 需求变更沟通前

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

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

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

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

2. 产品方案落地中

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

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

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

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

3. 方案确认中

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

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

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

4. 方案实施研发中

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

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

场景类型:

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

以上场景发生,即刻应对变更:

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

2)来自业务方(需求发起方),主要包含商务BD,产品运营等。

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

是:判断合理性。

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

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

② 是否合理的需求变更

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

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

不合理:陈明利害,拒绝变更。

5. 方案实施已完成

按照新需求处理!!!

本文作者 @弘毅书声 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部