编辑导语：需求处理能力是考察产品经理核心能力的重要指标之一，本文作者分享了有关需求管理的主要痛点问题、传统需求管理方法论及其问题、需求量化方法以及相关建议，一起来学习一下，希望对你有帮助。

需求处理能力产品经理的核心能力模型的重要维度之一，作为产品经理每天要处理各种各样的需求，如果说需求分析聚焦的是单个业务或单个功能的挖掘转化，那么需求管理则更能体现一个PM运筹帷幄、有条不紊的大局观和节奏感，既能业务满意，也能研发认可，自己也不至于每天忙成小陀螺。

一、需求管理的主要痛点问题

需求源源不断，资源是一直紧缺的。我经历过的互联网企业，都是需求等人，没见过人等需求的。一旦出现人等需求的情况，那只能说岗位设置冗余，就可以考虑优化了。在此背景下，如何把好钢用在刀刃上，就愈发重要。

1. 手心手背都是肉，先做谁的需求

需求多研发资源少的情况下，需求管理首先要解决就是需求优先级顺序的问题，对口的业务多，每个人都说自己很重要，先做没意见，后做都不满意。

按照合作关系远近亲疏，还是按照提需求的时间，谁先提做谁的？对于产品、研发团队的管理者，不同产品经理、不同产品模块的需求放到一起抢占研发资源，该怎么安排，“会哭的孩子有奶吃”吗？手心手背都是肉啊。最终绩效考核的时候，总不能按照上线的需求数量来评判ABCD吧。

2. 临时的、紧急的需求，该如何协调

不管是产品还是研发都不喜欢被插入需求，排队就医、买票，插队的人总是让人心生厌烦。

但临时的需求、一些因为政策、战略等紧急的需求又在所难免，不能每次来紧急需求都要求开发加人，或者周末加班吧？

当这些插入需求来了的时候，又该如何协调各方，达成一个“一团和气”的局面呢？

3. 需求积压很多，规划却不知从何下手

新人产品经理往往容易被堆积如山的需求搞得手忙脚乱，需求池里躺着上百个需求，做产品规划时却无从下手。

感觉每个都应该做，资源受限，却好像哪个都可以不做。怎样才能挑出大的西瓜，而不至于被一粒粒“芝麻”蒙蔽了双眼。

4. 产研团队忙而无果，每天加班做需求却没成就感

研发人员像机器一样，持续不断地输入需求，变现需求。但却没有成就感，甚至觉得自己就是个变现工具人。

二、传统需求管理方法论及其问题

从“人人都是产品经理”开始，就有了各种各样的需求管理的方法论。在过去10多年的产品工作及团队管理工作中，发现很多方法论也就停留在方法论层面，实际操作时，还需要个人的“悟性”，悟性差的可能整个职业生涯中，都难以掌握到底什么样的需求才算是重要且紧急的需求。

1. 四象限分析法判断需求优先级

每个人都知道应该优先去做重要且紧急的需求，但问题是作为新人产品经理，重要程度和紧急程度的判断依据是什么？每个人都说自己的需求非常重要，并且想越快上线越好。

2. Kano模型分析划分需求类型

Kano模型按照用户对于需求的期望程度划分为基本需求、期望需求、兴奋需求等五种类别，实际操作时，该怎样客观地描述不同用户对于需求的期望程度？

3. ICE排序法定量确定需求优先级

ICE排序法按照需求影响范围、完成需求的自信程度以及开发实现难易三个维度进行需求量化评分，最终按照得分值高低，确定需求优先级排序顺序。

对于体验优化类或者流程提效类的产品，用户影响范围的权重一样是否合理呢？比如老板用的管理驾驶舱产品，就三五个高层使用，他的价值就不高了吗？

三、需求价值量化方法实操

结合各方对于需求优先级排序的诉求以及现有需求分析模型存在的问题，结合数据产品的特点所以出一套用于量化数据产品需求价值的方法，可以为你提供一些新的思路和启发。其核心思想：

1. 用户影响度

任何产品需求都是为了解决用户问题，所以需求涉及的用户范围是一个重要的评价维度，但这里需要细化不同类别的需求，比如做一个CDP精细化运营产品，主要的用户就是运营部、营销部的几个人，即使每天都会使用，但是DAU终归就那几个人。对于用户体验类的需求该维度权重可以设置30%-50%，而流程提效类15%~25%，业务增收类的权重可以适当降低。

2. 战略契合度

外部环境政策的变化或者公司新战略的推行，产品迭代时，也要考虑这个维度。如果只是闭门造车，按照已有的优先级严防死守，那对于公司的影响可能是致命的，比如《数据安全法》《个人信息保护法》施行后，应对安全合规检查的功能需求，会影响产品甚至公司的生死存亡。

此外，对于老板的需求第一时间去做或者不予重视都不可取，把战略契合度加到评估维度中，则可以有效应对这一类需求。战略契合度各类需求的权重设置控制在15以下。

3. 业务期望度

这一维度主要用于衡量用户对于这一产品功能的期待程度，不做用户感受是怎样的，做了用户是不是对产品满意度大大提升。这一维度的评分区间划分可以基于Kano模型进行，基础需求10分，期望需求8分等

4. 效能提升

对于B端数据产品，多数还是帮助业务提升数据决策和应用的效率，通过产品功能的迭代，到底可以带来多少降本增效的价值。

比如基于标签的人群自动化圈选功能，没有上线这个功能时，单个营销场景耗时3小时（SQL取数、数据上传等），每周至少2个场景应用，功能上线后业务自助圈选，30分钟搞定，那么带来的提效价值就是单次操作节约时长×操作频次×统计周期，按照节约的时间成本换算成人力成本，按照价值区间进行得分。流程提效类需求，该维度权重适当增加。

5. 业务收益

数据赋能类的需求，比如算法推荐接口、API接口，其目标是基于数据为产品提供更加智能化的应用，按照接口调用量或者用户请求UV去看，都不合理，而按照对应服务可以带来的实际业务增量，换算成“钱”再去看，就更加合适。比如按照不同功能类别，划分营收或订单增量这一维度的得分区间。

6. 实现成本

从时间成本和人力成本两个方面，如果用前面五个维度的正向得分除以成本，区间划分时，成本越大，最终得到的结果就越小，总分值就越低。

成本两个维度主要是辅助参考，这个具体操作时，需要不需要把成本作为分母，可以根据实际需求定，因为一旦相除，可能就意味着得分降低，价值度高但是开发耗时长资源投入多的需求就一直没法做了。

把不同类型的需求在以上几个维度的权重设定好，并且每个维度下的得分区间定义好后，用得分乘以权重，维度得分加和就可以得到每个需求的价值度得分，这样不管是单个产品线还是不同PM的需求放到一起，都是相同的评分体系，涉及资源抢占和优先级判断时，就更加有理有据。没人？那就有多少人干多少事，挑最重要的做。初期操作时，可以用excel的公式设定自动化的得分计算。

四、需求价值量化实施建议

需求价值量化方法实施时，有一些点需要关注，也算是过去操作过程中的一些实操建议

1. 一定要结合产品实际情况进行吸收和转化

在权重设置、每个维度的得分区间划分时，要结合产品实际情况建立符合实际的标准，不能直接拿来主义。

2. 需求方、产品、研发形成需求价值量化的统一认知

需求价值量化需要业务方配合，通过宣讲、需求流程优化等方式，让各方对价值量化的意义有更加清楚的认知，而不是为了拒绝需求或者增加提需难度，作为产品经理把需要业务侧提供的指标具象化，避免直接让业务去操作需求量化的结果。

3. 量化计算过程自动化

如果对于每个需求都需要人肉计算得分，势必会影响工作效率，当相关的权重、维度、得分区间沟通确认固定下来后，可以整合到需求管理系统，用户提交需求加上产品经理审核、处理需求时，完成对应的得分赋值，系统自动化计算最终的得分，在一个需求池列表中，确定优先级顺序。

五、所以

需求管理的好不仅是自身产品能力的体现，对于协同团队也会认为你是一个靠谱的人。需求先做哪个后做哪个，建立一个清晰、明确的价值量化标准，优先做对的，有价值的需求，这样才能在人力不够的情况下有更高人效的产出。结合文中提到的需求价值量化的思路，看看如何与当前的需求管理工作结合起来吧。