Backlog（需求池）里总有几十上百个可以做的项目，从哪些方面考虑prioritization？

本文将从投入产出比，成功率，其他因素等三个方面讨论如何进行项目Prioritization。

一、考虑价值/成本

当我们进行项目prioritization的时候，一般来说是希望找到投入产出比最高的项目先做。

1. 项目价值衡量

那我们如何衡量各个项目的价值呢？我认为，能帮助团队实现目标的项目就是有更高价值的项目。

第一步：只做产品战略相关的项目

团队每年都需要定义和重新审视产品的战略目标，制定产品策略。策略不仅是要做什么，更是不要做什么。

一个团队的精力一定是有限的，时间有限的情况下，不可能在相关领域全都做的非常好；这个策略目标的取舍需要定义清楚，才可以作为后期项目取舍的准绳。

Tips：

• 一个项目可以对几个战略目标都有帮助，也可以只对一个战略目标有帮助。
• 可以设置战略目标的权重（weight），也可以长期给特定目标有限的时间/资源；比如说，每个季度10%的时间可以用来debug，20%的时间用来团队内部流程/工具建设。
• 有时也需要计算某段时间内roamap里的项目对各个战略目标的总实现程度，不然可能项目全都只实现某一个战略目标，发展不均衡，短板太明显。
• 有时也会将战略简化为一个关键指标（北极星指标）。
• 产品策略受公司发展阶段影响，但具体这里不讨论。

第二步，考察项目对战略目标的满足度

决策选项决定决策的上限。要做出好的决策需要有足够多的好的选项；所以，确定战略以后，需要有一定的时间对能达到战略目标的项目进行探索，再对探索出的可行方案进行优先级排序。

这里只讨论排序，默认项目前期发散已经做过。

达成同一个战略目标的项目可以有非常多，但哪一个是目前看来最有效果的呢？

不同的项目类型有不同的衡量方式。

1）产品设计项目的价值

产品设计项目的价值可以通过以下metrics判断：

Framework 1

常用于衡量某个新功能对用户行为的影响。

• Reach：能触达哪些人。
  • Number：人数数量有多少： 当前一个client还是所有clients？这个client里的所有人还是一部分人？
  • Quality：这些人是哪个群体（比如现有customer还是prospects，是kol吗）？这个群体对于现阶段的产品有多重要？
• Impact：对触达的人群能带来多大影响。
  • Breadth：被触达的人有多少作出反馈。
  • Depth：反馈行动有多强烈，对目标/战略的实现度有多高。
  • Persistence：反馈行动持续多长时间。

Framework 2

常用于衡量提升现有用户体验的项目。比如说，现在有一批bug（众所周知bug是修不完的），那先修哪些呢？

• Frequency：这个问题会出现在多少人的产品使用体验中？
• Impact：这个问题会多大程度上影响用户完成任务？影响的是主任务吗？
• Persistency：这个问题是出现一次以后用户就知道如何解决问题了吗，还是每一次出现都给用户带来困扰？

2）团队流程/工具项目的价值

我入职以来就做了不少团队development的项目，比如说design system, data tracking, set retrospective meeting, backlog building之类的。

但我有时候就会想，对于一个startup来说，这些基础设施建设到哪个程度是Sweet Spot？我的时间花在产品项目上会不会对整个公司来说更有价值？将这类项目的价值量化，和产品类项目拉通排序，就可以解决这个问题了。

团队流程/工具项目的价值可以这样衡量：

帮助团队高效地做事：

• Breadth：现在做了这件事，整个团队将在哪些方面提升效率？
• Depth：一年能省下多少时间？
• Scalability：随着团队壮大，这件事情的价值又会如何变化？

帮助团队做出正确决定/做正确的事：

• Breadth：这个项目能帮助进行哪些决策？这些决策发生多少次？这些决策都有多重要？（比如说产品早期可能找到PMF很重要，那能帮助identify产品PMF的工具/流程就很重要，提高UX的项目就可以缓缓。）
• Depth：不同类型的决策的成功率将如何提高？

3）对Sales的价值

作为B端SaaS产品，是要卖的呀。大家都知道B端的客户和用户是分开的，那这个功能对用户的价值和是否能提高客户的购买欲望是不同的两件事。

• Reach：能为哪些客户带来价值？客户的体量多大？是否是典型客户？
• Impact：对客户的影响
  • 流程优化类：
    • 现在Sales funnel 的主要问题集中在哪里？
    • 这个功能能多大程度提高Sales funnel转化率？
  • 新增功能类：
    • 客户愿意出多少钱来买这个功能？（可以自行估计）
    • 如果今天不做这个功能，我们将失去多少客户，多少收入？

Tips：

• 项目的价值可以用公式计算出来。
• 当我们需要在不同类型的项目进行选择时，需要将他们拉到同一个水平线再进行对比，如何设置这个水平线依然取决于第一部分说到的各目标的权重分配。

2. 项目成本衡量

在定义清楚项目价值后，我们还需要估算，上线这个项目需要多少精力？

Tips：

• 工作量的估算单位可以以人/月，人/sprint，小时，人/天 为单位。
• 需要估算团队的所有成员（产品，设计和工程）的总时间。
• 当团队某个工种（产品/设计/开发）的时间紧张的时候，可以将该工种需要的时间分开计算。
• 在让团队开始估算之前，可以先根据MoSCoW的框架分解项目任务。这将有效帮助团队成员理解项目具体要做什么，以及更高效准确的估算任务量。

二、考虑成功率

对于简单可预测的项目来说，上面的价值/成本衡量已经能很好地解决优先级问题；但有时项目价值很难预期，我们希望加入成功率的因素考虑。

1）项目背后的假设

这是我们需要考虑项目成功背后关于用户需求，关于市场反应的核心假设是什么，比如说“用户在平台的核心诉求是找到能帮他们解决工作上的问题的人。”

这个假设非常重要，最好在项目开发前就明确清楚，并时刻关注项目结果以判断这个假设知否正确，以后是否可以复用。

2）假设成功的概率

这个假设是否经过验证？是否有数据支持？成功率是多少？

如果成功率比较低，现阶段是否需要进行进一步验证再进行下去？还能进一步验证吗？

这个项目是否值得冒险？冒险的成本是什么？机会成本又是什么？

三、考虑其他因素

1）Dependency

这个项目和其他项目是否有关系？

他们是否形成飞轮/闭环？是否互相增强？是否1+1>2?

某项目是否是另一项目的前提条件？

一起做是否能大幅降低成本？

2）Scalability

这个项目里建设的系统能力是否可复用？

做成可复用组件的成本是多少？以后来做会不会更合适？

3）Risk

这个项目有什么法律，政策方面的风险吗？

如果项目失败，是否会造成严重后果？

4）Unpredictability

这个项目中是否有不可控的，变数很大的部分？变数的range有多大？最坏结果是什么？

可以留出一些机动时间给最新遇到的问题（需要灭火的地方，比如现有大客户提出的维护需求）

需要注意的是，以上metrics颗粒度非常细。能相对精确地衡量项目价值的同时也需要付出更多时间进行判断。大家按需取用就好。

四、Prioritization公式

在对项目价值，风险，其他补充信息进行思考后，我们又将如何进行最后一步的prioritization呢？相信大部分小伙伴看了分析已经知道怎么写公式了。

这里可以放上我在使用的公式：

• Value = (Sales Value + User Value + Team Value + Other Values)*Confidence*Urgency/Effort
• Sales Value = “Sales Value” * 2
• User Value = Sqrt( “User Reached” * “User Impact” )
• Team Value = “Team Time Saved” + “Helps to Do the Right Thing”
• Urgency = “Urgency”/2 + 1
• Effort = (“Product/Design effort” + “Development Effort”)/2

Tips：

• 公式中的常数，比如2，1等都可以根据自己产品的情况修改。
• 带引号的数值为输入数值。
• 至于每个要素，比如“Sales Value”如何定义，大家可以继续细化为公式，也可以考虑上main列出的sale value要点后心算，最后直接给出数值。