Product Backlog 产品待办列表
在计划开发产品功能时,都希望产品功能上线后,用户能够喜欢并经常使用。
因此在开发产品新功能时,就要衡量哪些产品需求是对用户最有价值,这是最应该思考的问题。
然后把这些有价值的需求集合放在一起。当然,也有与需求实现相关的其它工作项。
在 Scrum 框架中,把产品待开发的功能集合放在一起就叫产品待办列表(Product Backlog)。它是 Scrum 团队实现产品目标所需完成的所有工作项的集合,是 Scrum 团队进行工作规划和执行的来源。它由产品负责人维护。
英文 backlog 意思是:大量堆积、积压的事物或工作,也指“尚未完成的工作”,或“需要尽快处理的事情”。
在产品待办列表中的工作项叫产品待办事项(Product Backlog Item)。
如果待开发功能很多,那哪些功能优先开发?这就需要对产品待办列表里的功能集做一个优先级排序,优先级高的率先开发。
当然,随着开发的持续进行,产品待办列表中可能有不止功能性需求,还有非功能性特性。
比如:bug缺陷修复、基础技术任务、比较大的用户故事(Epic)、代码改进、架构优化、功能优化等等。
产品待办项的需求来源
需求主要来源:
客户调研、反馈,用户调研、反馈,市场调研,公司高层,数据分析,产品经理,Scrum 团队成员,竞品分析等。
产品待办列表特点
-
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 模型
此模型通过客户对功能满意度来确定优先级,将功能分为必备型需求、期望型需求、魅力型需求、无差异需求、反向型需求。
from: https://baike.baidu.com/item/KANO%20%E6%A8%A1%E5%9E%8B/19907824
KANO模型需求分类:
-
必备型需求(属性 )(一定要有):有的也译作基本型需求(属性)。用户认为理所应当、必须要有的需求,这些需求必须被满足。当这些需求不被满足时,也就是不提供这些需求,用户满意度会大幅降低;当这些需求被满足时,用户满意度不会得到提升。例如:手机打电话、发短信。
-
期望型需求(属性):满足此需求时,用户满意度会提升;不满足此需求时,用户满意度会降低。
-
魅力型需求(属性):用户对这种需求没有太大期望,需要产品经理对用户有深刻的洞察才能挖掘到此隐性需求,属于给用户惊喜的需求。不满足此需求,用户满意度不会降低;满足此需求,用户满意度会急剧提升。有时是产品很 有竞争力的体现。
-
无差异需求(属性):无论是否满足此需求,对用户满意度都不会产生影响。
-
反向型需求(属性):有无此类需求,用户根本不在意。若满足此需求,用户满意度反而会下降。
它们的优先级排序为:
必备型需求 > 期望型需求 > 魅力型需求 > 无差异需求
四象限法
四象限法是按照 重要 和 紧急 2 个不同的纬度进行划分,将需求放在二维或三维角度进行优先级的决策。
按重要和紧急 2个维度,将需求任务划分为【重要且紧急】、【重要不紧急】、【不重要但紧急】以及【不紧急不重要】四类。
需求任务分成四个象限:重要紧急 > 重要不紧急 > 不重要但紧急 > 不重要不紧急
- 重要紧急:重要紧急的需求任务,对产品影响很大,第一时间处理。
- 重要不紧急:这种类型的任务可以把它纳入计划,按计划完成。
- 不重要但紧急:如果任务小花费时间少,可以马上去执行完成。如果比较耗时,可以另外安排时间或交付给他人去做。
- 不重要不紧急:可以尽量不做。
注意点:
紧急不等于重要:紧急的任务,不等于重要的任务。比如当我们时刻关注用户反馈,每天都有很多问题,这些有的是紧急但对产品影响不大的问题,在某个时间点完成就可以,对最终结果影响不大。
需求是变的:一般我们都是关注重要且紧急的任务,但是随着需求的调整,其它类型的任务也会上升到重要且紧急的任务象限内。
RICE 框架
RICE 这个框架由 Intercom提出,旨在平衡成本和收益的系统,对需求进行评估。
RICE 框架是一种量化需求优先级的模型,通过 4 个维度来给需求打分,然后算出最终得分。通过比较每个需求的得分来排定需求优先级顺序。
(from:intercom:rice-simple-prioritization-for-product-managers)
RICE 框架是由 4 个英文单词的首字母组成,代表的意思分别是:
- ®each:触达的广度。需求覆盖的用户广度,触达的用户数量或比例,在给定时间内影响多少产品用户。可以通过埋点获取指标、百度统计等系统来统计一段时间内的一些指标。
比如“每个季度影响多少客户”。例如 项目 1:每月有 500 名客户到达注册漏斗中的此点,其中 30% 选择此选项。每季度覆盖率为 500 × 30% × 3 = 450 名客户
- (I)mpact:影响的深度。需求对每个用户影响的深度。比如 “当客户使用该功能时,该功能将提高多少转化率?20% 提高到了 27% 吗?”。这个指标很难准确评估,这部分评估更加主观一些。
Intercom 对这种主观评估提供了一种评分方法,如下:
Intercom 用 3 - 0.25 的量表来评分:
- 3 表示 “影响力巨大”。
- 2 表示 “影响力高”。
- 1 表示 “影响力中等”。
- 0.5 表示 “影响力低”。
- 0.25 表示 “影响力最小”。
这些数字会乘以最终得分,以将其调高或调低。
- ©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):不需要的功能,回报率很低,不会列入当前开发计划中。代表最低优先级。
产品Backlog需求清单模板
产品负责人维护管理的一个已排序,已估算,有用户或商业价值度量的一个需求清单列表。每次开会时可对这个列表进行增加、调整列表里的需求。
一般会用在线敏捷开发软件来记录产品backlog需求清单。简单的话可以用 Excel 表格记录。
清单模板如下图:
这只是一个示例模板,里面的每一格标题(如商业价值、实现难度等等)可以根据自家需求情况进行增加、删除和调整。
欢迎到公号评论:敏捷开发:Scrum 中的 Product Backlog 详细介绍
参考资料
- 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