Product Backlog 产品待办列表
在计划开发产品功能时，都希望产品功能上线后，用户能够喜欢并经常使用。
因此在开发产品新功能时，就要衡量哪些产品需求是对用户最有价值，这是最应该思考的问题。
然后把这些有价值的需求集合放在一起。当然，也有与需求实现相关的其它工作项。
在 Scrum 框架中，把产品待开发的功能集合放在一起就叫产品待办列表（Product Backlog）。它是 Scrum 团队实现产品目标所需完成的所有工作项的集合，是 Scrum 团队进行工作规划和执行的来源。它由产品负责人维护。
英文 backlog 意思是：大量堆积、积压的事物或工作，也指“尚未完成的工作”，或“需要尽快处理的事情”。
在产品待办列表中的工作项叫产品待办事项（Product Backlog Item）。
如果待开发功能很多，那哪些功能优先开发？这就需要对产品待办列表里的功能集做一个优先级排序，优先级高的率先开发。
当然，随着开发的持续进行，产品待办列表中可能有不止功能性需求，还有非功能性特性。
比如：bug缺陷修复、基础技术任务、比较大的用户故事（Epic）、代码改进、架构优化、功能优化等等。
产品待办列表特点
-
1、优先级排序：产品待办列表是一个按照优先级从高到低进行排序的产品功能列表。它包含了产品有价值的需求、Bug修复、特性等列表项。
-
2、动 态 变 化：产品待办列表是一个动态变化的列表，随着项目功能不断开发，市场不断变化，用户持续的反馈，获取的信息和知识也越来越多，产品负责人可能会不断的更新项目列表，添加新的需求或特性、调整优先级、移除不再重要的功能等等。
-
产品待办列表的持续更新和改进有助于团队适应变化，并持续提供价值。
-
3、需求细节详情：把将要在下一个迭代（Sprint Backlog）中完成的待办项，描述时包含足够的细节。比如用户故事，大小合适并且符合 INVEST 原则，用户故事三要素俱全，分解成故事点（用于估算工作量）。
-
4、透 明 性：产品待办列表是 Scrum 团队实现产品目标所需完成的所有工作项的集合，确保团队成员都清楚产品要完成的工作项、方向和目标。团队成员需要完成哪些工作都是来自这里。
-
5、工作集：上面已经说明，产品待办列表是 Scrum 团队实现产品目标所需完成的所有工作项的集合。
产品待办列表管理
产品待办列表（Product Backlog）是由产品负责人（Product Owner）负责管理的。
随着产品功能不断开发，用户持续反馈，市场不断变化，获取的知识增多，涌现新的想法，待办列表里的工作项会不断进行改变和调整。待开发项（item）是随用户、市场不断变化、持续演进的。
（from：https://www.visual-paradigm.com/cn/scrum/what-is-product-backlog-in-scrum/1000）
那怎么管理变化，把这种变化反映到开发项中呢？那哪些又是不变的呢?
产品愿景。这是不变的，它将作为指导产品待办列表中工作项的创建、移除、修改。
变化的工作项，定期进行梳理，可以用 梳理会议 来进行管理。产品负责人可以通过定期举办梳理会议来梳理产品待办列表。
梳理会议 的一些关键活动：
- 1、梳理产品愿景。
- 2、创建、移除、调整产品待办列表项。
- 3、拆分大的待办项，比如 Epic（史诗）。产出合适大小的用户故事。
- 4、澄清待办项。
- 5、排列、修改优先级排序。
- 6、利益相关者的沟通。
- 7、产品阶段性目标。
- 8、待办项的估算。
会议参与方：
产品负责人、Scrum Master、产品开发人员、业务部门人员（市场、销售、业务、客服等）、产品经理、产品设计人员
为什么会有这么多人参与呢？
- 因为产品待办项的内容来源，是由上述人员或部门提出的。他们会根据市场需求、用户反馈、功能改进、技术重构等因素提出新的需求或改进点。
注意点，整理待办项时需注意点：
- 这时候需求不需要事无巨细，做到最基本的描述，力求简洁。
- 可以用户故事来描述需求，用卡片方式，前一节有讲解。
- 低优先级的需求条目可能数量大，而且是粗粒度。
- 非功能性需求，尽早描述详情，因为可能对整个产品体验产生很大影响。
用户故事拆分方法
把比较大的故事比如 Epic，拆分成小的故事。用户故事的一些拆分方法：
- 按照工作流程步骤拆分。要完成一个故事，需要哪些步骤，按照一个步骤一个步骤来进行拆分。
- 按照不同业务规则拆分。
- 按照操作来拆分。比如增加、删除、管理等操作来进行拆分。
- 按照依赖先后顺序拆分。比如一个故事开发依赖后一个故事，那么这个后一个故事先开发。
- 按简单/复杂进行拆分。比如先做简单的故事，后做复杂的故事。
产品待办列表优先级评估介绍
产品待办列表里有很多待办项，哪些待办项首先做，哪些后面做？可以对待办项进行优先级评估然后排序。
对这些待办项进行排序后，接下来，在冲刺（Sprint）计划会议就可以安排哪些待办项先进行开发。
优先级评估的原则依据有哪些？
- 价值（用户价值和商业价值）
- 成本
- 实现难度
- 风险大小
- 可发布性
用户价值、商业价值：
做产品，是解决用户问题，给用户带来价值。需经常问自己：“做这个需求能给用户解决什么问题带来什么价值；不做呢？产品会有什么损失，用户会有什么损失？”
当然，更希望产品给公司带来商业价值。
成本：
估算实现的成本。比如人工成本，工作量大小，协同成本。
实现难度：
实现这个需求或特性，技术难度高不高。比如：实现此需求代码改动大；需进行技术预研；依赖其它需求的实现等等。
需求细化成更小故事后，可以用工作量来衡量。
风险大小：
做需求或特性，风险点有哪些，然后进行讨论评估。比如说做创新产品，不确定性肯定高。
可发布性：
对于产品功能，开发后的产品增量需要尽快发布，更早得到用户反馈。
优先级评估方法或模型介绍
产品待办列表的需求评估优先级，可以采用多种方法，下面列举一些常见评估方法。
KANO 模型
此模型通过客户对功能满意度来确定优先级，将功能分为必备型需求、期望型需求、魅力型需求、无差异需求、反向型需求。
KANO模型需求分类：
-
必备型需求（属性 ）（一定要有）：有的也译作基本型需求（属性）。用户认为理所应当、必须要有的需求，这些需求必须被满足。当这些需求不被满足时，也就是不提供这些需求，用户满意度会大幅降低；当这些需求被满足时，用户满意度不会得到提升。例如：手机打电话、发短信。
-
期望型需求（属性）：满足此需求时，用户满意度会提升；不满足此需求时，用户满意度会降低。
-
魅力型需求（属性）：用户对这种需求没有太大期望，需要产品经理对用户有深刻的洞察才能挖掘到此隐性需求，属于给用户惊喜的需求。不满足此需求，用户满意度不会降低；满足此需求，用户满意度会急剧提升。有时是产品很 有竞争力的体现。
-
无差异需求（属性）：无论是否满足此需求，对用户满意度都不会产生影响。
-
反向型需求（属性）：有无此类需求，用户根本不在意。若满足此需求，用户满意度反而会下降。
它们的优先级排序为：
必备型需求 > 期望型需求 > 魅力型需求 > 无差异需求
四象限法
四象限法是按照 重要 和 紧急 2 个不同的纬度进行划分，将需求放在二维或三维角度进行优先级的决策。
按重要和紧急 2个维度，将需求任务划分为【重要且紧急】、【重要不紧急】、【不重要但紧急】以及【不紧急不重要】四类。
需求任务分成四个象限：重要紧急 > 重要不紧急 > 不重要但紧急 > 不重要不紧急
- 重要紧急：重要紧急的需求任务，对产品影响很大，第一时间处理。
- 重要不紧急：这种类型的任务可以把它纳入计划，按计划完成。
- 不重要但紧急：如果任务小花费时间少，可以马上去执行完成。如果比较耗时，可以另外安排时间或交付给他人去做。
- 不重要不紧急：可以尽量不做。
注意点：
紧急不等于重要：紧急的任务，不等于重要的任务。比如当我们时刻关注用户反馈，每天都有很多问题，这些有的是紧急但对产品影响不大的问题，在某个时间点完成就可以，对最终结果影响不大。
需求是变的：一般我们都是关注重要且紧急的任务，但是随着需求的调整，其它类型的任务也会上升到重要且紧急的任务象限内。
RICE 框架
RICE 这个框架由 Intercom提出，旨在平衡成本和收益的系统，对需求进行评估。
RICE 框架是一种量化需求优先级的模型，通过 4 个维度来给需求打分，然后算出最终得分。通过比较每个需求的得分来排定需求优先级顺序。
(from：intercom：rice-simple-prioritization-for-product-managers)
RICE 框架是由 4 个英文单词的首字母组成，代表的意思分别是：
- (R)each：触达的广度。需求覆盖的用户广度，触达的用户数量或比例，在给定时间内影响多少产品用户。可以通过埋点获取指标、百度统计等系统来统计一段时间内的一些指标。
比如“每个季度影响多少客户”。例如 项目 1：每月有 500 名客户到达注册漏斗中的此点，其中 30% 选择此选项。每季度覆盖率为 500 × 30% × 3 = 450 名客户
- (I)mpact：影响的深度。需求对每个用户影响的深度。比如 “当客户使用该功能时，该功能将提高多少转化率？20% 提高到了 27% 吗？”。这个指标很难准确评估，这部分评估更加主观一些。
Intercom 对这种主观评估提供了一种评分方法，如下：
Intercom 用 3 - 0.25 的量表来评分：
- 3 表示 “影响力巨大”。
- 2 表示 “影响力高”。
- 1 表示 “影响力中等”。
- 0.5 表示 “影响力低”。
- 0.25 表示 “影响力最小”。
这些数字会乘以最终得分，以将其调高或调低。
- (C)onfidence：对需求的信心。表示产品经理对该功能或需求的实现难度和成功率的信心，更多是产品经理对需求和用户痛点的理解程度，对估算的信心水平，可以用百分比来表示。
Intercom 提供了一种量表来表示，如下：
用一个百分比量表来表示，避免决策困难
- 100% 表示 “高度信心”。如果有定量的数据支撑 Reach，定性的数据支撑 Impact，且开发评估了较准确的 Effort，那么 Confidence 就是 100%。
- 80% 表示 “中等”。有定量的数据支撑 Reach，开发也评估了 Effort，但是 Impact 没有数据支撑，那么 Confidence 就是 80%
- 50% 表示 “低”。有数据支撑，但是数据的可信度较低，Effort 的波动也可能较大，那么 Confidence 就是 50%.
- 低于这个数字就是 “完全不可能”。
请诚实地问自己：你的估计到底有多少信心支持？
- (E)ffort：工作量。研发的成本，表示开发该功能或需求所需的工作量和资源投入，多个团队合作的人，比如有市场、商务等，涉及团队越多成本越高。工作量预估不确定因素较多。有一些方法：比如人天来估算；以故事点来估算。
Intercom 是用人月来估算-即是一名团队成员一个月能完成的公工作。他坚持使用整数（或 0.5，用于一个月以下的工作），以保持粗略的估计。
Intercom 中关于 RICE 分数的计算：
- Reach：这将影响多少人？（在规定的时间段内进行估算。）
- Impact：这将对每个人产生多大影响？（巨大 = 3 倍，高 = 2 倍，中 = 1 倍，低 = 0.5 倍，最小 = 0.25 倍。）
- Confidence：对需求成功的估算有多大信心？（高 = 100%，中 = 80%，低 = 50%。）
- Effort：这将需要投入多少“人月”？（使用整数且最少半个月 - 不要陷入估算的泥潭。）
(from：intercom：rice-simple-prioritization-for-product-managers)
MoSCoW 模型
MoSCoW 模型是一种需求优先级管理模型。
-
M（Must Have）：必须有的功能。这些功能必须要实现的，没有这些功能，产品不能发布。这些都是产品成功的关键任务，通常是最小的 MVP 任务。代表最高优先级。
-
S（Should Have）：应该有的功能。这些功能重要，但不是必须，如果时间不急或有其它方式来实现，可以推迟到下一个阶段或稍后来实现。代表次高优先级。
-
C（Could Have）：可以有的功能。这些功能是客户期望的，锦上添花的功能，但不是必须的，可以提高客户体验或客户满意度。如果时间允许资源充足，就可以实现这些功能；如果没有时间，就会在下一个阶段做。代表次次高优先级。
-
W（Won’t Have）：不需要的功能，回报率很低，不会列入当前开发计划中。代表最低优先级。
参考资料
- https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers RICE 框架
- https://www.visual-paradigm.com/cn/scrum/what-is-product-backlog-in-scrum/1000