产品经理在日常工作中经常会接收到各方来的需求，对于这些需求需要进行评估和取舍，选择性的实现需求，而后期对于需求的更新迭代也有着一定的逻辑；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

需求变更的类型，可以归纳为以下几种：

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. 合理拒绝需求，控制需求的范围。