编辑导语：产品经理在日常工作中经常会接收到各方来的需求，对于这些需求需要进行评估和取舍，选择性的实现需求，而后期对于需求的更新迭代也有着一定的逻辑；本文作者分享了关于ToB需求频繁变更应该怎么控制的方法，我们一起来看一下。
作为产品经理，最常打交道的一个词就是“需求”，从需求调研、需求池、需求优先级、需求文档（PRD）、需求排期、需求迭代、需求分析，“需求”贯穿整个产品设计的过程。
不同产品经理的PRD风格多样，但是必有一个共通点，就是《版本/需求变更记录》，可见需求变更是一个十分常见的场景。
下文将根据笔者的工作经验，从需求变更的原因、类型、应对方法以及如何控制变更来做一下总结，抛砖引玉。
一、为什么需求会频繁变更？
1.业务不稳定，需求跟随业务发展变动
这种情况多发生在创业型企业，或者信息化程度比较初级的传统型企业中。
创业型企业，自身的业务模式没有稳定下来，温饱存亡是日日奋斗的目标；管理流程也没有标准化，这种情况下，软件需求的设计，必定要随着业务的变动，同步进行调整。
现在中国企业的发展逐渐正规化，很多民营企业发展的也不错；于是很多在企业内部推行信息数据化，这对企业的作业流程、管理方式产生了较大的影响。
在企业传统管理方式转变为信息化管理的过程中，线下业务与线上操作的冲突摩擦，导致需求不断变更，甚至有可能出现相互矛盾的情况。
2.需求预测出现偏差，需求设计的结果不正确
对需求进行调研与设计，十分考验产品经理对于行业的理解程度，业务的了解深度，当前信息化系统的业务覆盖范围。
在需求变动的相同现实下，优秀的产品经理对需求方向和范围变动预测的准确性更高。如果能准确预测需求将往哪个迭代，那么在设计需求的环节，就可以合理规避一些变更。
3.需求调研偏差，业务场景覆盖不全面
笔者在之前的一篇文章中《B端需求调研，牢记“人、场、文”三字诀》提过，需求调研需要了解业务中的角色、业务场景、输出文档。
如果对其中环节有遗漏或者考虑不全面，上线的需求要么就是使用率低无法解决业务问题；要么就是需求方向偏差，紧急下线，改版重新上线。
二、需求变更的类型有哪些？
需求变更的类型，可以归纳为以下几种：
1.功能性需求变动
即解决这个业务问题，需要上线什么功能。比如合同签约系统中，为了保证线上签约人员的真实性，需要上线人脸识别功能。
2.体验型需求变动
一般产品介绍C端产品和B端产品的区别时，一般会提及C端注重交互体验，而B端注重企业降本增效；这里的交互体验，也属于体验型需求的一种，为非功能性需求。
体验型需求一般涉及界面的变动，需要的功能支撑较少。
比如B端的后台收到用户抱怨，说信息录入过于混乱，希望技术部门予以解决；UE/UI设计师在界面上做了步骤条拆解录入流程、对于相似信息进行分层、复杂名词给予详细说明协助用户快速理解，上线后得到用户好评。
3.数据类需求变动
例如根据角色做数据隔离；例如报表系统上线，协助业务部门分析决策；例如系统迁移、对接，接口字段的定义、互传等。
4.规则类需求变动
规则类需求变动，可大可小，一般会和数据类需求、功能类需求一同出现；例如优惠券的规则是一个用户仅可领取一张变为一个用户最多领取5张。
大的规则类需求的变动，可能会导致产品架构大规模的调整，甚至推到重来，此类不在本文讨论。
三、需求变更如何应对？
上文讲述了需求变更的可能原因以及变更的类型，那么对于频繁变更的需求，我们除了做好心理建设，在实际工作中，应该如何处理呢？
1.需求优先级划分，保证需求迭代紧跟核心业务指标，解决用户痛点
相信产品经理们都有做需求池的习惯，不管是通过Excel表格、World文档、记事清单等。只要业务在稳定运转，需求就不会有枯竭的那天，否则技术部门就要集体失业了；需求池中的需求，都是按照一定的准则，做了优先级的划分。
常见需求优先级划分规则有：四象限法则/矩阵分析法、KANO模型、成本效益核算模型、二八原则、谁的权力大听谁的模型…做需求迭代；笔者认为需要
转载请注明：http://www.0431gb208.com/sjszjzl/7787.html
