平台型需求和业务型需求，怎样做需求优先级评估？

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

在产品的日常工作中，需求优先级评估是一个经常要做的事。我们大多数产品都是自己拍脑袋定优先级，或者是使用几条固定的规则对需求进行分类。但实际上，不同的需求类别，也会导致优先级排序方式的不同，看看作者是怎么说的吧。

作者：我是开水，京东金融产品经理

微信公众号：我是开水（ID：liaochanpin）

题图来自 Unsplash，基于 CC0 协议

全文共 3282 字 3 图，阅读需要 7 分钟

—————— BEGIN ——————

在任何企业中，资源不足永远是常态，正是这种资源不足的常态，导致在产品经理的日常工作中，需要频繁面临一个问题，那就是如何合理安排需求开发的优先级。

相信大家在工作中已经形成和总结出了自己的优先级评估方法，今天，我向大家介绍一种我个人总结出的优先级评估方法，希望能够对大家的工作有所帮助。

一、平台型需求 VS 业务型需求

在开始讨论如何确定需求优先级之前，我们先来讨论一下需求的两种类型，也就是“平台型需求”和“业务型需求”。

讨论产品经理时，我比较认可的一种对产品经理的分类方式是“平台型产品经理”和“业务型产品经理”。

在这种分类方法下：

“平台型产品经理”指负责C端产品和功能的产品经理。

他们不会面对任何公司内的业务方，而是直接了解终端用户、发现用户需求，抽象需求并提供解决方案，最终落地新产品或开发新功能来满足用户需求，这样的产品经理称作“平台型产品经理”，相对应的，将这种类型的需求成为“平台型需求”。

“业务型产品经理”则是指在公司内部存在明确的业务方。

业务方可能是市场、运营、风法财、甚至是技术部门本身，产品经理通过与需求部门沟通来了解需求，并抽象需求后形成解决方案，推进项目开发，交付功能并提供使用培训，我将这样的产品经理称作“业务型产品经理”，相对应地，将这种类型的需求称为为“业务型需求”。

“平台型产品经理”和“业务类产品经理”的分类往往不是绝对的，“平台型产品经理”偶尔也会面对业务型需求，“业务类产品经理”偶尔也会开发平台型功能，这种分类方式有助于大家理解我在处理两类需求的优先级时不同的评估方式。

二、平台型需求的优先级评估模型

1. 影响平台型需求优先级的因素

影响平台型需求最重要的两个因素是“目标”和“资源”。

“目标”可根据企业在当前阶段下为团队指定的目标来设定，可以是获客、激活、活跃、留存、分享等，实际使用中，往往是更加明确的产品目标，比如DAU、MAU、7日3活、分享率等等。

“资源”则包括完成需求开发上线的所有资源，产品经理考虑优先级评估时主要考虑产研团队的人力资源投入，比如产品、设计、开发和测试的工作量。而作为公司高层管理者，在考虑优先级时，可能还需要纳入更多资源因素作为考量标准，比如流量、资金和运营投入等。

2. 优先级评估模型

为方便理解这一优先级评估方法（减少优先级评估影响因素），本文将从一般产品经理的考虑范围举例来说明这一优先级评估方法的基本思路，如需站在更高层面评估需求优先级，可按此思路纳入更多决定因素。

目标：列出产品在当前阶段最重要的产品目标（建议不超过三个），并为每个目标设定权重，权重值为0~1.0，每个目标的分值为0~5（存在一定的感性因素，分值设置过于精确意义不大）；

资源：列出产品开发过程中产研团队的资源投入，因为此时可能尚无详细需求，所以资源投入很难给出明确的工作量，精确到天即可；

模型：需求的优先级可科通以下模型得出：

目标得分÷开发工作量=优先级

具体计算时，计算方式细化为：

(目标1*目标1权重+目标2*目标2权重+目标3*目标3权重……)÷(产品工作量+设计工作量+研发工作量+测试工作量)

接下来，制作一个下面这样的表格：

表格纵向为不同的产品需求，横向第一组的三列为需求对不同目标贡献度，第二组为为实现需求所要付出的工作量，最右侧一列为优先级得分，优先级得分的计算方式参考上述计算公式——最终得分越高，需求的优先级越高。

到此，优先级评估分析的基本模型已经确立，接下来需要找到能够影响上述目标打分和工作量评估的角色来填充表格内容了。

3. 优先级评估会议

参会方：

产品、设计、研发、测试

会议过程：

首先，由产品经理逐个讲解需求和解决方案；

接下来，参会人员为不同目标打分并初步评估工作量，工作量评估由各类角色的同学自行打分，存在疑问时可协商确定最终分值；目标打分则一般由产品经理通过前期调研和分析给出，可在优先级评估会议前填好。

如其它团队成员对目标得分存在不同意见时可采取集体打分方式，即所有团队成员参与打分，在取（加权）平均值的方式，但需要保证产品经理的意见能够起到足够影响（提升产品经理在集体打分时对最终打分影响力的权重）。

通过优先级评估会议，我们可以将表格中所有影响优先级评估的因素填上分值，并通过这些分值计算出需求的优先级得分，形成以下形式的优先级评估结果：

从上表优先级结果可以看到，【需求A】的优先级为0.6、【需求B】的优先级为0.49、【需求C】的优先级为0.41，所以三个需求在开发时的优先级依次为【需求A】>【需求B】>【需求C】。

三、业务型需求的优先级评估模型

前文提到不同于平台型需求，业务型需求存在内部的业务需求方，产研团队与业务需求方间是服务关系，这个时候，需求方对需求的迫切程度是决定需求优先级最主要的因素。

1. 影响业务型需求优先级的因素

业务型需求优先级的决定因素因此调整为业务方需求迫切度和研发工作量，关于研发工作量前文有相应说明，此处不再赘述。那么，怎样描述需求的迫切程度呢？

我的方式是从最基础的“重要”和“紧急”两个维度来描述需求迫切度，即将重要性分为1至5五个等级，将紧急度同样分为1至5五个等级，由需求方为每个需求打上重要性和紧急度分数，然后使用后面的优先级模型计算优先级得分。

2. 平台型需求的优先级评估模型

不同于平台型需求不同目标间的累加关系，重要和紧急两个维度间我用相乘的方式，即业务型需求的优先级计算公式改为：

（迫切度*紧急度）÷（产品工作量+设计工作量+研发工作量+测试工作量）

制作成表格后，形式为：

3. 优先级评估会议

参会方：

除了产品、设计、研发、测试外，最重要的一定要有【需求方】参与。

如果涉及到多个需求方，那么一定要邀请对不同需求方拥有统一管理权的更高层级的负责人参与，统一给出重要性和紧急度分数，否则不同业务必然都希望自己的需求被优先开发，很难在需求迫切度上达成一致，或所有需求的迫切度都变成最大值，迫切度因素也就失去了意义。

会议过程：

会议过程与前文平台型需求描述的过程一致，同样是由产品经理逐个讲解需求和初步的解决思路，但需要由需求方给出每条需求的重要性和紧急度；再由产研团队给出每条需求各个开发过程所需消耗的工作量。

最后，通过这些分值、套用业务型需求的优先级计算公式得出评估结果：

从上表优先级结果可以看到，【需求A】的优先级为1.00、【需求B】的优先级为0.60、【需求C】的优先级为0.57，所以三个需求在开发时的优先级依次为【需求A】>【需求B】>【需求C】。

写在最后

因为平台型需求和业务型需求优先级决定因素不同，所以不能通过将平台型需求和业务型需求的优先级得分比较来确定平台型需求和业务型需求间的优先级。

—————— / END / ——————

每个「在看」，都是一次鼓励 ▼