你会拆分产品待办项（PBI）吗？

将产品待办项（Product Backlog Item，简称 PBI）拆小，是所有产品负责人的必备技能。更小的产品待办项有助于提高团队的灵活性、可迭代性，并更好地应对变化。今天我们就来探讨一下如何更好地拆分 PBI。

产品待办项（Product Backlog Item，简称 PBI）多小才合适？

尽可能小，但仍然有价值。

产品是提供价值的工具，每个产品待办事项（PBI）应该提供增量的价值。

“我们需要像一块蛋糕的垂直切片一样思考。即使是最小的垂直切片，我也能享受到蛋糕的美味。”

Product Backlog Item

产品的核心在于 提供价值。这既是为用户和客户提供价值，也是为企业提供价值。

为了提供这个价值，需要进行许多活动。以软件开发为例，这可能包括：

• 设计用户体验（UX）

• 创建用户界面（UI）

• 分析和添加功能和非功能细节

• 编写代码和进行同行评审

• 构建数据库

• 验证期望的功能是否按预期工作

• 部署功能到生产环境等

很多团队有时会将这些任务分解为价值单元，并开始将这些任务当作产品待办事项。但 请停止这样做 。

是的，这些活动很重要，但它们本身不能为用户、客户或企业提供价值。

产品待办事项应该是真正的价值单元，即 可以被客户使用的项目，能够帮助我们获得真实反馈。

split-product-backlog-items

拆分产品待办项的五个方法

产品待办事项（PBI）应当是具有实际价值的项目，即 它们应该是可供客户使用的有形内容，同时旨在协助产品开发团队获取真实反馈。

我们来探讨一下如何在不降低价值的前提下创建小型的 PBI。

▶ 按用户角色拆分

一种常见的拆分方法是根据不同的用户角色。不同的用户群体可能有不同的需求或问题，因此在拆分 PBI 时应考虑这一点。 例如，我们正在构建一些与电子商务相关的产品和一个产品功能，我们关注的是“购物车”。让我们将这个功能称为“查看购物车”。 对于购物车，顾客在结账之前会检查金额和数量。然而，“查看购物车”的功能也可以被客户服务团队使用，他们在结账过程中帮助顾客解决问题。

在这种情况下，两种用户需求是不同的，可能存在其他解决方案。这为产品团队提供了将“查看购物车”产品拆分为两个 PBI 的机会：

• 作为在线顾客，我想查看我的购物车，以便在结账之前检查数量和金额。

• 作为客户服务执行人员，我想查看购物车，以便在结账过程中帮助遇到问题的顾客。

这两个 PBI 都是独立的价值单元，可能有不同的解决方案来满足特定的需求。更小但同样有价值。然而，不要就此止步。继续提出问题，比如：

• 是否可能存在不同种类的客户或用户？

• 如果是的话，是否有比其他更多的需求/问题？

• 他们与我们的产品/系统互动的方式是否不同？

• ……

split by user roles

▶  按工作流步骤拆分

许多用户旅程涉及客户或用户从开始到结束的多个步骤，或者正如我们通常所说的“端到端旅程”。然而，我们有时忽略了这些步骤中的每一个都可以为用户和客户提供价值，并且也可能为企业提供价值。

例如，我参与了一个构建学习管理系统（LMS）的项目，在这个项目中，我们设计了一个能让学习者进行评估以验证他们的学习的功能。

基于“按用户角色拆分”，这可以被拆分为：

• 创建评估的培训师/内容创建者

• 验证他们的知识/学习的学习者

• 想要收到通知的学习者的直线经理

让我们详细看一下“验证他们的知识或学习的学习者”。 工作流程中的典型步骤可能是：

• 学习者登录到 LMS 门户

• 搜索可用的评估

• 注册可用的评估

• 进行评估

• 学习者获得结果

以上每个步骤都为用户提供了价值，所有这些步骤都可以作为独立的产品待办事项，可能进一步细分。 更小但同样有价值。

split by workflow steps

▶  按操作拆分

不同的操作或操作规则也会影响许多功能。这些操作规则可以应用于数据或资源的存储和管理方式。 典型的操作规则包括：

• 创建（C）：添加新记录

• 读取（R）：检索现有记录而不修改它

• 更新（U）：修改现有记录

• 删除（D）：删除现有记录

例如，如果我们正在构建一个人力资源（HR）系统，业务操作规则和政策可以帮助我们将 PBI 进一步拆分。以下是可能导致更多价值单元的问题示例。

• 创建新员工记录：谁可以执行此操作，如何执行此操作，是否存在多种创建记录的方式，是否可以进行批量创建。

• 读取员工记录：谁可以阅读员工记录，直线经理可以看到哪些细节，HR 管理员可以看到哪些细节。

• 更新现有员工记录：哪些角色可以更新员工记录，直线经理可以更新哪些记录，HR 管理员可以更新哪些记录。

• 删除现有员工记录：谁可以执行删除操作，删除记录时会发生什么。

以上每个问题都可以成为一个独立的 PBI，对某些问题的回答可能会创建更多的 PBI。 更小但同样有价值。

split by operations

▶  按场景/用例拆分

我看到过许多 PBI 的验收标准非常庞大，涵盖了一个 PBI 中的多个场景和用例。这些庞大的 PBI 包含进一步拆分为独立价值单元的机会。

例如，我们正在为系统添加登录功能。这项任务可以根据用户角色和场景进行拆分。一个场景可能是快乐路径，即在正确的用户名和密码组合之后成功登录。但还有多个快乐路径和非快乐路径的场景。

• 用户名正确但密码不正确

• 用户名不正确但密码正确

• 忘记密码

• 多次尝试使用不正确的凭据

• 记住我的登录信息

• 通过我的 Google 账户登录

• 通过我的社交媒体账户登录

• 通过单点登录进行登录

并非所有这些在早期开发阶段都是必需的。有些可能永远不需要。但这些都是较小的 PBI，可以帮助产品负责人更好地设置工作的优先级。 更小但同样有价值 。

▶  按业务规则拆分

许多企业和产品遵循各种业务规则，这些规则可以单独实施。有时，并非所有这些业务规则都需要同时执行。

举例来说，用户在我们网站上购买课程。在结账时，作为英国的增值税（VAT）注册企业，只有当客户来自英国时，我才需要收取增值税。

这可以分为两个 PBI：

非增值税客户的故事：

• 当我调和公司的月度支出并更新财务记录时

• 我希望收到清晰指示无需支付增值税的发票，

• 以便我能够高效管理会计流程，确保财务报告准确，并避免有关税务责任的混淆。

增值税客户的故事：

• 当我审查公司采购并准备报税时，

• 我希望收到详细列明增值税费用的发票，

• 以便我能够准确计算和报告增值税费用，确保遵守税收法规，并促进简化的财务审计。

更小却同样有价值 。

结 语

在产品开发领域，有效拆分产品待办事项（PBI）不仅仅是一种技能，更是一种必备的本领。通过将较大的任务分解为更小、更易管理的部分，我们提高了清晰度和专注力，促进了工作流程的更顺畅进行。

我们在拆分 PBI 的讨论中揭示了关键的策略，但其中的核心主题是“ 更小却同样有价值 ”。

本质上，精通产品待办项的拆分并不仅仅是任务管理的问题；它涉及赋能团队、加强协作，并最终交付那些能经受住时间考验和变革的卓越产品。因此，持续不断地完善和迭代，让您的产品待办事项成为引领您的敏捷之旅通向成功的明灯。