产品需求的优先级
为什么需要确定需求的优先级#
在研发一款产品过程中，随着产品的迭代和曝光，团队会收到来自各个方面的需求。
而通常团队的资源都是有限的，确定需求优先级的目的是为了使用最小的成本达成最大的价值。
这里的成本不仅是研发所需的人力成本，也包括产品推出的时间成本，有时在重要的时间前完成某些功能会产生很大的价值，比如ToB产品客户的采购需求，或者电商平台双十一活动前的相关功能。
因此，需求优先级对产品或项目的成功有决定性的影响。
网上有一些需求优先级的框架，例如：卡诺模型，RICE，MoSCoW 等，之前在工作中经常听到产品人员抱怨这些框架都不太适用。
经过不断的实践发现，这些框架只适用于某些特定的情况或者只用于评估需求的某个方面，而全面的需求优先级评估应该是将这些框架结合起来。
例如：卡诺模型只考虑了需求对客户的价值，而不考虑需求的实施成本，所以它比较适合用来评估需求的价值，再与成本结合来确定需求优先级。
在应用这些框架时常听到的另一个抱怨是框架的使用成本太高，我认为需求评估的成本应与其实现成本相匹配，如果一个1人日就能开发完成的需求，则没有必要花上0.5人日去评估，但如果是重大的产品方向或功能，可能需要几个月甚至更长时间来实现，对其进行详细的评估则很有必要。
另一方面，高成本的框架也可以做适当的降级，例如需要进行用户调研的过程可以替换为内部人员完成调研过程。
优先级基本公式#
既然目标是使用最小的成本达成最大的价值，所以需求的优先级应该等于其价值除以其成本，即单位成本所能创造的价值。
这里的成本指的是单纯的人力成本，时间成本如何计算在内还没有想清楚。
Value vs Complexity Quadrant 框架就是使用这个基本公式，将需求放在由价值和成本两个坐标组成的象限中：
- Quick Wins：高价值底成本的需求应该优先做
- Major Projects：高价值高成本的需求排第二优先级，是主线任务
- Fill-Ins：底价值底成本的需求是第三优先级，找空闲时间来做
- Time Sink Features：底价值高成本的需求应该舍弃不做
这个框架比较适合新产品，快速识别出高价值低成本的需求和不值得做的需求，在需求量较大时，需要借助一些工具将需求划分到象限中。
RICE 框架也是使用同样的公式，区别在于其将价值分解为：
- Reach：该功能影响多少用户
- Impact：该功能对单个用户的影响效果，由高到低分为5个档 3/2/1/0.5/0.25
- Confidence：为了防止头脑过热，通过这个参数来设置对前面两个参数估值的信心，分为三档 100% / 80% / 50%
再加上 Effort 估值（开发功能所需的人月），整个 RICE 的公式为： (Reach * Impact * Confidence) / Effort。
这个公式得出的数值就是需求的优先级分数，按照分数排序即为优先级排序。
还有一个极简的 ICE Scoring Model，将 Impact，Confidence，Ease 三项按照1-10打分，每个需求的三项平均分即为优先级分数。
该方法评估的是需求的相对值，需要保证不同的人打分时对于1-10分的理解是相同的。
基本公式从逻辑上是没有问题的，在应用时如何评估需求的价值会成为一个比较难的问题。
上述的一些评估模型中的 RICE 对价值进行了分解，但其中的 Impact 如何评估依然是个问题。
评估需求的价值#
需求的价值评估应该建立在产品的目标和战略基础上，如果产品目标和战略不确定，需求的价值评估就会失去依据。
不同产品的战略方向通常不太一样，同一产品在不同阶段也会有不同的战略，例如：留住高价值用户 和 尽量获取更多的用户 就是两个不同的产品战略。
产品需求的价值取决于其能在多大程度上帮助产品达成目标和战略。
从另一方面讲，产品是给用户来使用的，能否达成目标，取决于用户对产品功能的态度和感觉。
著名的卡诺模型（Kano Model）可以用来评估需求对客户满意度的影响，由于模型比较复杂，这里就不做介绍了，可以上网搜索自行学习。 虽然卡诺模型本身比较复杂，但其思想还是有很好的借鉴意义。
Weighted Scoring 是另一种评估需求价值的模型，该模型需要先列出产品的战略方向，根据重要性，每个方向都带有一个权重，所有方向的权重相加为100%，之后对每一个需求在每个方向上的价值按1-100进行打分。 将每个需求在每个方向上的价值乘以方向的权重后求和就得出这个需求的总价值分数。 这个模型的一个好处是强迫使用者先理出产品的战略方向（也可以从需求中总结出来）以及这些方向的权重，在后面战略方向发生变化时，只需要变更其权重就可以方便的进行优先级重新排序。
MoSCoW Method 也是用来评估需求价值的模型，其将需求分为4类：Must Have（必备），Should Have（应该做），Could Have（可以做），Won’t Have（不做），将需求对应到四个分类后就完成了优先级评估。 该方法非常简单，比较适合在迭代过程中对单次迭代的需求进行分类，缺点是该方法评估出的结果主观性比较强。
Opportunity Scoring 方法认为越重要的功能，用户满意度很低，则该功能优先级更高。其通过问卷调查，让用户对每个功能的重要性和当前版本该功能的满意度分别打1-10分。 重要性 + （重要性 - 满意度） = 机会，机会高的需求应该优先实现。
在实际使用中，应根据产品情况和资源情况选择一个合适的评估方法，个人认为有方法总比没有方法拍脑袋强。
在一款2B的产品中，由于产品当前阶段需要研发出一些亮点功能来说服客户买单，所以在大的产品功能中，我采用了 Opportunity Scoring 的方法来确定哪些功能应该优先做。
然后在每个月的迭代中，使用 Weighted Scoring 方法来评估详细的需求点的优先级，通过评估每个详细需求对重要大功能的贡献程度来计算每个详细需求的分数。
整个过程并不需要太高的成本，所有产品设计人员对各项分数达成共识就可以了，最终的需求优先级通过公式自动计算得出。
实践经验与思考#
在实际的项目中，使用上面的 Opportunity Scoring + Weighted Scoring 的评估时，又有人提出某些需求很容易实现，是否优先级应该提高。
这里实际上是因为评估方法中忽略了需求的成本，后面我计划改进评估过程，将 Weighted Scoring 计算得出的分数再除以每个需求的实现成本（人日）作为需求的最终优先级分数。
Opporunity Scoring 和 Weighted Scoring 这种使用公式的方法其公式在某些情况下可能不适用，这时可以人为修改一下公式不必教条。
虽然我喜欢公式类的方法，但是简单分类的方法评估成本更低，更加适合对于一次迭代中的需求进行优先级排序。
再次强调，无论那种方法，有方法总比没有方法好，有了方法后，大家可以基于优先级评估框架的若干因子进行讨论，这种讨论会更加明确而清晰，而不是对优先级直接拍脑袋决定。
参考资料#
https://learn.marsdd.com/article/prioritizing-product-requirements/
https://www.productboard.com/glossary/product-prioritization-frameworks/
Opportunity Scoring: https://medium.com/uxr-microsoft/what-is-the-opportunity-score-and-how-to-obtain-it-bb81fcbf79b7