Product Backlog（产品待办列表）是产品团队维护的一份有序清单，承载尚未进入迭代、但未来可能实现的需求、改进项与缺陷修复。它由产品负责人负责排序和维护，随澄清、拆分与优先级变化持续更新。本文说明它的定义、范围边界、组成要素与维护机制，并把它与Sprint Backlog、需求池区分开；ONES在需求归集与状态维护上的能力可作为承载方式之一。
要点总览（TL;DR）
- Product Backlog（产品待办列表）是产品负责人维护的有序清单，承载尚未进入迭代、未来可能实现的需求、改进项与缺陷修复。
- 它不包括迭代内的任务分解，也不承担价值评分模型；排序依据只需简明记录，评分方法属于另一主题。
- 条目应包含标题描述、来源、状态、优先级顺序、排序依据与关联关系，细化程度随临近实现而提高。
- 维护靠固定节奏的梳理会、重复项关联合并、积压清理规则和明确的状态与排序触发条件。
- 需求池是归集入口，Product Backlog 是有序候选集，Sprint Backlog 是当期承诺，三者按流转关系衔接。
Product Backlog的准确定义
Product Backlog 中文通常译为“产品待办列表”或“产品待办事项列表”，是敏捷研发中描述产品后续工作的唯一有序来源。它回答的问题是：产品接下来可能要做哪些事，以及先做哪一件。清单中的条目在真正进入迭代之前，都停留在“待办”状态，尚未转化为团队当期的承诺。
这份清单承载的对象并不限于新功能需求。常见条目类型包括：面向用户的产品需求与功能改进、体验与流程优化、技术债务与架构调整、已发现但尚未排期修复的缺陷、以及支撑业务目标的探索性事项。条目类型可以多样，但它们共同的特征是“尚未进入迭代、需要被排序”。
产品负责人（Product Owner）对清单的内容与顺序负责。团队可以参与澄清、估算和拆分，但“做什么、先做什么”的排序权归属于产品负责人。这一责任划分让清单保持单一决策入口，避免多方各自插单导致顺序失控。
Product Backlog 是一份持续演进的清单，而非一次性冻结的文档。随着用户反馈、市场变化、技术评估和迭代回顾的推进，条目会被新增、细化、合并、重排甚至删除。清单的“当前形态”只反映此刻的认知，它的价值在于持续被梳理，而非被一次性写全。
它不包括什么：范围与边界
把 Product Backlog 与相邻概念分开，能避免清单被塞进不该由它承载的内容。以下边界用于说明本文的讨论范围，也帮助团队在日常使用中判断某类信息应放在哪里。
- Sprint Backlog 属于迭代管理。迭代计划会议从 Product Backlog 中选取条目后，团队为本次迭代制定的任务分解与执行清单是 Sprint Backlog，它由开发团队在迭代内维护。本文只讨论进入迭代之前的清单，迭代内的任务管理不在范围内。
- 价值评分与优先级评估属于需求优先级与价值评估主题。Product Backlog 需要有序，但“用什么模型打分、按什么维度评估价值”是另一套方法。本文说明排序依据应被记录，不展开评分模型本身。
- 业务重复需求处理不等于搜索关键词去重。清单中可能出现业务含义相近的重复需求，处理方式是识别、关联与合并；这与文本检索层面的关键词去重是两件事，后者不在本文讨论范围。
- 清单维护关注归集、分类、状态与积压清理。本文的维护机制围绕这四个动作展开，不涉及具体工具的选型对比或操作手册。
划清边界的实际意义在于：当团队讨论“这条要不要放进 Backlog”时，判断标准是它是否为尚未进入迭代、需要被排序的产品工作事项；迭代内的执行细节、评分模型的参数、检索层面的技术处理，都各有归属。
Product Backlog由哪些部分组成
一份可用的 Product Backlog 由条目和条目所携带的信息共同构成。条目是清单的基本单位，字段决定这条信息能否被理解、排序和追踪。以下要素可作为检查清单使用。
| 组成要素 | 作用 | 常见内容 |
|---|---|---|
| 标题与描述 | 让人快速判断这条讲什么 | 一句话标题、背景、期望结果、验收要点 |
| 来源 | 追溯需求从哪来，便于回访与澄清 | 用户反馈、工单、销售诉求、内部改进提议 |
| 状态 | 标识条目处于哪个梳理阶段 | 待澄清、已细化、待排期、已排期、已关闭 |
| 优先级顺序 | 决定先做哪一条 | 清单内的相对位置，配合排序依据说明 |
| 排序依据 | 解释为什么排在这个位置 | 业务价值判断、成本与风险考量、依赖约束 |
| 关联关系 | 表达条目之间的结构 | 重复项、依赖项、父项与子项 |
其中“细化程度随临近实现而提高”是清单保持可管理的关键。排在清单顶部、即将进入迭代的条目应具备足够清晰的描述与验收要点；排在底部、短期内不会实现的条目可以只保留标题和大致意图。若所有条目都要求同等详细，清单会因维护成本过高而迅速过期；若顶部条目仍然模糊，迭代计划就会失去可靠输入。
关联关系中的父子结构尤其重要。一个较大的需求可以作为父项，拆成若干子项分别细化与排期；子项完成后父项的整体进度才可判断。重复项则通过关联标记指向同一条目，避免同一件事被多次排入。
清单如何持续维护：梳理、细化与积压清理
Product Backlog 的质量取决于维护动作是否规律发生。维护不是一次性整理，而是由若干固定动作和明确触发条件组成的循环。以下机制可作为团队约定的基础框架。
需求归集与分类的入口动作
所有来源的诉求先进入统一入口，再决定是否成为 Backlog 条目。入口动作包括：记录原始描述与提出方、标注来源渠道、按类型初步分类（需求、改进、缺陷、技术事项）。统一入口的价值在于避免诉求散落在聊天记录和邮件中，也避免未经判断就直接插入排序队列。
定期梳理会与细化拆分
团队按固定节奏（例如每周或每两周）召开梳理会，对清单顶部条目做澄清与拆分。梳理会的产出是：条目描述补全、验收要点明确、过大的条目被拆成可独立排期的子项、必要的估算信息补齐。完成标志是顶部若干条目达到“可直接进入迭代计划讨论”的清晰度。
重复项关联与合并的处理方式
梳理时发现业务含义相近的条目，先建立关联并标注主条目，再判断是否合并。合并的处理方式是保留信息更完整的一条作为主条目，把另一条的来源与补充说明并入，原条目关闭并指向主条目。这样既减少清单冗余，也保留提出方的追溯线索。
长期未推进条目的积压清理规则
积压清理需要一条可执行的规则，例如：超过约定周期未被细化、且没有明确业务驱动或依赖变化的条目，进入待确认状态；确认后关闭或移出清单，并在关闭原因中记录判断依据。清理的目的在于让清单长度反映真实意图，避免陈旧条目稀释排序信号。
状态维护与排序调整的触发条件
状态变化应有明确触发条件：条目完成澄清后从“待澄清”转为“已细化”；被选入迭代后转为“已排期”；实现完成并验证后关闭。排序调整的常见触发包括：业务目标变化、出现更高价值的紧急事项、依赖关系解除或新增、技术评估推翻原有成本判断。每次调整保留依据说明，便于后续复盘。
在工具承载层面，ONES 敏捷研发管理解决方案在需求池管理场景中，可使用 ONES 工单收集和整理来自各方的反馈，处理工单并快速转化为需求，整理出产品 Backlog；对于功能复杂的需求，可利用「子工作项」进行拆解，并关联研发和测试任务。ONES Project 支持建立需求池、规划迭代，编写需求、自定义需求状态与多种属性。这些能力对应上文提到的归集入口、父子拆分与状态维护动作；具体功能可用性以实际部署与所购版本为准。
与Sprint Backlog、需求池的区别
三个概念容易混用，差异主要体现在时间范围、责任角色和排序要求上。下表按同一口径对照。
| 维度 | Product Backlog | Sprint Backlog | 需求池 |
|---|---|---|---|
| 时间范围 | 覆盖未来多个迭代，无固定截止 | 仅覆盖当前一个迭代 | 通常覆盖尚未排期的诉求集合 |
| 责任角色 | 产品负责人负责内容与顺序 | 开发团队在迭代内维护 | 由需求归集方或产品团队维护 |
| 排序要求 | 必须有序，顺序即优先级表达 | 按迭代内执行顺序组织任务 | 可以只做分类，排序要求较弱 |
| 内容形态 | 需求、改进、缺陷、技术事项等条目 | 为完成迭代目标拆出的具体任务 | 原始诉求与待判断事项 |
三者的流转关系是：原始诉求先进入需求池完成归集与初筛；经过澄清与判断、确认值得推进的事项进入 Product Backlog 并获得排序位置；迭代计划会议从 Product Backlog 顶部选取条目，团队据此形成 Sprint Backlog 并在迭代内执行。需求池是入口，Product Backlog 是有序候选集，Sprint Backlog 是当期承诺。
需要说明的是，需求池与 Product Backlog 的界限在实践中可以合并管理：当需求池本身已经具备分类、状态和排序要求时，它承担的就是 Product Backlog 的职能。区分二者的意义在于确认“是否已经形成明确的先后顺序”，而非强制建立两套清单。
一个具体例子与常见误解
以下为一个演示情景，用于说明清单的实际形态，不代表真实项目数据。
某团队维护一份产品待办列表，顶部若干条目依次为：结算页支持多种优惠叠加（已细化，含验收要点，排在下个迭代）；订单列表增加批量导出（已细化，待排期）；移动端登录流程简化（待澄清，需补充交互方案）；历史数据查询性能优化（技术事项，已评估成本）；某客户提出的报表字段扩展（待澄清，来源为工单）。清单底部还有若干仅保留标题的探索性条目。每条记录来源、状态和排序依据，父子关系标注在拆分过的需求上。
围绕这份清单，常见误解有三类：
- 把清单当成任务列表。后果是条目被拆成“写接口”“改页面”这类执行动作，产品负责人失去对“做什么”的排序能力，清单退化为迭代内的任务板。
- 把排序当成价值评分。后果是团队花大量时间争论评分模型和分值，却迟迟不调整顺序；排序本应表达相对先后，依据可以简明记录，不必等到评分完备。
- 把清单当成一次性文档。后果是清单在项目初期写完后长期不更新，顶部条目缺乏澄清、底部条目不断堆积，迭代计划会议只能临时补课，估算与承诺的可靠性下降。
避免这些问题的做法与前述维护机制一致：条目保持“做什么”的粒度，排序依据简明记录并随触发条件调整，梳理会按固定节奏发生。当清单能够稳定回答“接下来先做什么”时，它就在发挥应有的作用。
常见问题
Product Backlog 一定要和需求池分开建两套清单吗？
不必。需求池与 Product Backlog 的界限在实践中可以合并管理：当需求池本身已经具备分类、状态和明确的排序要求时，它承担的就是 Product Backlog 的职能。区分二者的意义在于确认“是否已经形成明确的先后顺序”，而非强制建立两套清单。团队规模较小、诉求来源单一时，一套清单同时承担归集与排序更省维护成本；诉求来源多、需要先初筛再排序时，分开管理更清晰。
清单顶部条目要细化到什么程度才算可以进入迭代？
可操作的判断标准是：条目描述足以让团队在迭代计划会议上讨论方案与估算，验收要点能够说明“做成什么样算完成”，过大的条目已经拆成可独立排期的子项。达到这个清晰度即可，不必在进入迭代前写完全部实现细节。排在清单底部、短期内不会实现的条目保留标题和大致意图即可，避免为不会马上做的事投入过多梳理成本。
积压清理会不会误删后来确实要做的需求？
清理动作建议分两步：先进入待确认状态并通知提出方，确认后再关闭或移出清单，同时在关闭原因中记录判断依据。这样即使后续业务需要重启该需求，也能通过来源与关闭记录找回原始描述，不必从零重写。清理规则应写明适用条件，例如超过约定周期未被细化、且没有明确业务驱动或依赖变化，避免把“暂时排不上”误判为“不需要”。
排序依据需要写得多详细？
排序依据的作用是让后来的人理解“为什么排在这里”，简明记录即可，例如业务价值判断、成本与风险考量、依赖约束。它不需要等同于完整的价值评分报告。若团队已有评分模型，可把结论和关键参数记入依据字段；若尚未建立模型，也不应因此推迟排序调整。每次调整保留依据说明，便于后续复盘时判断当时的判断是否仍然成立。
用工具承载 Product Backlog 时，哪些能力最值得关注？
对应本文的维护动作，可关注四类能力：统一收集各方反馈并转化为需求的入口、父子结构的需求拆解与关联、可自定义的需求状态与属性、以及按优先级把需求规划到迭代。以 ONES 为例，ONES 敏捷研发管理解决方案在需求池管理场景中可使用 ONES 工单收集和整理来自各方的反馈，处理工单并快速转化为需求，整理出产品 Backlog；功能复杂的需求可利用「子工作项」拆解并关联研发和测试任务；ONES Project 支持建立需求池、规划迭代，编写需求、自定义需求状态与多种属性。具体功能可用性以实际部署与所购版本为准。
