对于产品经理而言，日常工作中需要处理的需求复杂多样，那么该如何制定功能的优先级呢？本文结合相关案例，谈谈如何制定优先级，提升工作效率，一起来看看吧。
产品经理工作的常见内容之一就是要制定产品功能的优先级。目前常见的优先级排序主要是艾森豪威尔矩阵，今天我们深入来聊聊怎么在日常优先级排期中使用艾森豪威尔矩阵的思想。
艾森豪威尔矩阵是以美国总统德怀特-大卫-艾森豪威尔的名字命名，这个优先级框架将帮助你按照重要性和紧急性来开展你的任务和行动。
这个工具通常也用在时间管理中，下表大家一定都很熟悉：
在产品优先级制定中，如果使用这个矩阵，核心是如何区分（量化）重要和紧急。在我看来，重要度和紧急度，可以继续细分为以下2个维度：
功能覆盖面覆盖面分为人群覆盖和频次深度，也就是功能上线后能够解决多少用户及使用频次的问题。
功能可替代性：
现在用户解决这个需求是否有可替代方案/功能，解决用户痛不痛的问题。
产品经理是纠结论缠身者，对于新手来说，优先级排序充满了不确定性，大家疑惑“如何说服我自己这个排序是正确的吗？”时，可以用评分卡来量化优先级得分，解决不确定性。
我们来看一下功能优先级评分卡：
说明：评分卡的权重均摊即可（毕竟是自己手头的小工具，不必太认真）。现在大家可以看出来，这个卡片里面主要是针对需求的问题域进行了细化分析。
不过如果是数据类/算法类的功能点，只看问题域可能是不够的。我们需要考虑技术可实现性，也就是这个功能点的研发成本如何，理论上来说，技术不成熟、数据准备不成熟的功能点，需要付出的成本也越高，甚至有可能是当前团队能力是无法完成的。
针对数据/算法的功能，还需要增加一些维度，我们来升级一下这个评分卡：
可以看到，能力满足度是针对于问题的解决能力域的。
下面我们看一个例子，该案例是一个电商仓库的数据看板需求。经过需求梳理，我们已经得到了2个功能点，现在需要使用这个功能评分卡来判断优先级：
上架主管每天时刻要关注积压、时刻要关注上架效率，提供一个自动预警积压功能。
分析评分维度：
（1）影响的业务范围（用户规模/频次）
功能上线后，所有仓库的上架主管使用，每天都会用，在高峰期会经常用。
（2）影响业务的程度
当发生大量上架积压时，可能影响销售（前台用户购买时显示无货）。
（3）替代方案
主管会安排专人盯或者自己随时查看从各个系统查信息，手动估算上架速度，评估是否会积压。
（4）替代方案的问题
主管可能对任务完成情况发生误判，介入晚了。
（5）当前数据可满足程度
已有现成数据了。
（6）当前算法/技术可确定性
方案比较简单:初版可使用【上架任务数量/上架效率】得到预计任务完成时间与任务要求完成时间进行比较，进行预警。
仓库工作量没有现成的报表，系统提供一个每日自动统计的数据报表，用户可以每天直接在系统中看到工作量汇总。
分析评分维度：
（1）影响的业务范围（用户规模/频次）
功能上线后，每个仓库每天出报表人员会使用（报表每天出1次）。
（2）影响业务的程度
没有影响，不影响主业务流程。
（3）替代方案
去作业系统查看订单流水，然后人工每天计算汇总工作量。
（4）替代方案的问题
不够直观方便（制作报表耗费时间大概半小时）。
（5）当前数据可满足程度
已有现成数据了。
（6）当前算法/技术可确定性
无需算法。
分析完毕之后，我们进行量化：
量化之后可以看到，功能点1的综合得分0.83是比功能点2高的，如果研发团队只能做1个功能，那么我们应该做功能点1。这个方法是我经常推荐产品新人用的，通过对功能点进行分析和量化，最后得到一个有逻辑性的排序结果。经常使用这个工具，逐渐就可以锻炼出自己的手感。
你有什么排优先级的诀窍吗？
作者：薄荷点点，“数据人创作者联盟”成员。
本文由@一个数据人的自留地 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。