To B | 需求频繁变更,怎么办?

2 评论 8356 浏览 50 收藏 12 分钟

编辑导语:产品经理在日常工作中经常会接收到各方来的需求,对于这些需求需要进行评估和取舍,选择性的实现需求,而后期对于需求的更新迭代也有着一定的逻辑;本文作者分享了关于To B需求频繁变更应该怎么控制的方法,我们一起来看一下。

作为产品经理,最常打交道的一个词就是“需求”,从需求调研、需求池、需求优先级、需求文档(PRD)、需求排期、需求迭代、需求分析,“需求”贯穿整个产品设计的过程。

不同产品经理的PRD风格多样,但是必有一个共通点,就是《版本/需求变更记录》,可见需求变更是一个十分常见的场景。

下文将根据笔者的工作经验,从需求变更的原因、类型、应对方法以及如何控制变更来做一下总结,抛砖引玉。

一、为什么需求会频繁变更?

1. 业务不稳定,需求跟随业务发展变动

这种情况多发生在创业型企业,或者信息化程度比较初级的传统型企业中。

创业型企业,自身的业务模式没有稳定下来,温饱存亡是日日奋斗的目标;管理流程也没有标准化,这种情况下,软件需求的设计,必定要随着业务的变动,同步进行调整。

现在中国企业的发展逐渐正规化,很多民营企业发展的也不错;于是很多在企业内部推行信息数据化,这对企业的作业流程、管理方式产生了较大的影响。

在企业传统管理方式转变为信息化管理的过程中,线下业务与线上操作的冲突摩擦,导致需求不断变更,甚至有可能出现相互矛盾的情况。

2. 需求预测出现偏差,需求设计的结果不正确

对需求进行调研与设计,十分考验产品经理对于行业的理解程度,业务的了解深度,当前信息化系统的业务覆盖范围。

在需求变动的相同现实下,优秀的产品经理对需求方向和范围变动预测的准确性更高。如果能准确预测需求将往哪个迭代,那么在设计需求的环节,就可以合理规避一些变更。

3. 需求调研偏差,业务场景覆盖不全面

笔者在之前的一篇文章中《B端需求调研,牢记“人、场、文”三字诀》提过,需求调研需要了解业务中的角色、业务场景、输出文档。

如果对其中环节有遗漏或者考虑不全面,上线的需求要么就是使用率低无法解决业务问题;要么就是需求方向偏差,紧急下线,改版重新上线。

二、需求变更的类型有哪些?

需求变更的类型,可以归纳为以下几种:

1. 功能性需求变动

即解决这个业务问题,需要上线什么功能。比如合同签约系统中,为了保证线上签约人员的真实性,需要上线人脸识别功能。

2. 体验型需求变动

一般产品介绍C端产品和B端产品的区别时,一般会提及C端注重交互体验,而B端注重企业降本增效;这里的交互体验,也属于体验型需求的一种,为非功能性需求。

体验型需求一般涉及界面的变动,需要的功能支撑较少。

比如B端的后台收到用户抱怨,说信息录入过于混乱,希望技术部门予以解决;UE/UI设计师在界面上做了步骤条拆解录入流程、对于相似信息进行分层、复杂名词给予详细说明协助用户快速理解,上线后得到用户好评。

3. 数据类需求变动

例如根据角色做数据隔离;例如报表系统上线,协助业务部门分析决策;例如系统迁移、对接,接口字段的定义、互传等。

4. 规则类需求变动

规则类需求变动,可大可小,一般会和数据类需求、功能类需求一同出现;例如优惠券的规则是一个用户仅可领取一张变为一个用户最多领取5张。

大的规则类需求的变动,可能会导致产品架构大规模的调整,甚至推到重来,此类不在本文讨论。

三、需求变更如何应对?

上文讲述了需求变更的可能原因以及变更的类型,那么对于频繁变更的需求,我们除了做好心理建设,在实际工作中,应该如何处理呢?

1. 需求优先级划分,保证需求迭代紧跟核心业务指标,解决用户痛点

相信产品经理们都有做需求池的习惯,不管是通过Excel表格、World文档、记事清单等。只要业务在稳定运转,需求就不会有枯竭的那天,否则技术部门就要集体失业了;需求池中的需求,都是按照一定的准则,做了优先级的划分。

常见需求优先级划分规则有:四象限法则/矩阵分析法、KANO模型、成本效益核算模型、二八原则、谁的权力大听谁的模型…做需求迭代;笔者认为需要关注两点,一个是用户,一个是核心指标。

企业是盈利性的组织,必定要考虑商业利润最大化的问题。比如你的产品的核心指标是用户留存,对比之下用户注册率是一个不那么重要的指标;根据这个指标,你推算出在注册环节,应该要求用户填写详细的信息过滤掉非意向客户,而非通过第三方快速登录,无法有效的后续跟进客户。

领导认为这种注册方式用户体验不好,但是你很明白核心指标是什么,产品应该为核心指标服务。关于核心指标的确认,《精益创业》一书有很精彩的讲解,建议有兴趣的人了解一下。

用户,更加不用说,产品的核心就是在解决用户痛点;产品需要同理心,时刻站在用户的角度去发现问题,设定解决方案。

2. 拆解目标,做好版本规划,控制研发成本

确认要做需求变更之后,评估变更对需求池中、研发中的需求的影响;预测对现有软件架构的影响;以及技术实现的难度。

权衡利弊,做好版本控制,MVP简化上线,快速验证调整,再次迭代。

好的需求,解决的问题多于制造的麻烦。

3. 建立统一需求渠道,减少需求变更对工作的影响

需求的变更,参与方包括需求提出方、产品经理、研发部门、需求上线使用者。

为了减少需求变更对多方工作的影响,最好是在需求设计阶段,邀请各方深度参与产品方案的评估,一来可以确认变更方向无误差;另外可以让研发部门了解需求的方向,做好应对措施;对于不现实的需求,也可以尽早暴露出来;毕竟产品的实际效果,是业务、产品、研发多方共同努力的成果。

另外可以建立统一的需求变更渠道,尽量将需求变更的传达者、上线后的反馈者固定在指定的人员之间,减小沟通的成本;设定公开透明的平台,和各方分享需求即将进行的方向,保持信息的透明度和传达的效率。

笔者最近在尝试做一个公共的需求看板,将当前研发的需求,未来规划的需求,临时插入的需求,变更的需求标记出来,分享给各业务部门;需验证一段时间之后,再来总结实际效果。

4. 脱离软件设计,提供其他途径的解决方案

不给自己设限,也不给产品方案设限。需求变更的本质原因在于业务遇到了难点,解决的方式可以有多种,不一定是在软件系统上做需求迭代;或许可以通过需求调研,头脑风暴发现业务中不合理的地方,协助业务解决。

5. 需求变更,事后评估及时复盘,升级认知

上文有说到,需求的变更,有可能是产品经理对行业的预测、业务的了解深度、系统的业务覆盖范围不够而引起;产品经理除了需要加深自身的认知,还需要对需求的变更及时进行复盘,实践出真知。

6. 合理拒绝需求,控制需求的范围

笔者在面试过程中会问应聘者如何设定需求的优先级,有人讲述了领导要求紧急上线需求,最后拼命压缩时间,按时上线的案例,这实际上是一个比较失败的答题方式。

虽然前文有戏谑领导可以决定需求的优先级,但这句话隐含的是,领导在自己的领域内是专业的,可以确定自己负责的业务内需求的优先级。

但是需求的具体实施,是需要结合软件系统的实际情况、研发团队的资源配置情况、需求在产品设计中的合理性、需求的ROI,多方平衡之后再做取舍。

笔者认为,有理有据的拒绝需求的时候,是一个小白产品成长的里程碑。

四、总结

需求可能因为业务不稳定、需求调研不准确、需求预测出现偏差,导致变更。

作为需求实施人,产品经理可以尝试这样应对:

  1. 划分需求优先级,确认需求为核心指标服务;
  2. 拆解目标,做好版本规划,控制研发成本;
  3. 建立统一需求渠道,减少需求变更对工作的影响;
  4. 脱离软件设计,提供其他途径的解决方案;
  5. 需求变更,事后评估及时复盘,升级认知;
  6. 合理拒绝需求,控制需求的范围。

 

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

题图来自 unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 其实最大的问题在于,如何能把规范的需求变更流程按规范走完,同时如何拉通业务干系人完成评审,有的人怪你没拉通到位有的人当时不吱声,事后出问题才说…我觉得最大的不确定性因素都是人,但人是最难管的

    来自上海 回复
  2. 需求评审会确实很必要,不能因为合同时间节点比较紧而忽略,后期会出现开发与需求理解不一致等一系列问题。降低团队的整体开发效率。得不偿失。

    来自湖北 回复