需求池是团队集中存放、持续维护待处理需求的集合，把来自用户、业务和内部团队的需求收拢到同一处，按分类、状态和优先级线索持续梳理，作为后续评估与排期的输入。本文说明需求池的定义、包含与不包含的内容、字段与状态组成，并区分它与迭代待办、优先级评估等相邻概念。
要点总览（TL;DR）
- 需求池是团队集中存放、持续维护待处理需求的集合，常对应 Product Backlog（产品待办列表），属于输入集合而非执行计划。
- 需求池维护包括需求归集、分类、状态维护、重复项关联和积压清理；Sprint Backlog 归迭代管理，价值评分归需求优先级与价值评估。
- 一条需求在池中通常记录来源、描述、分类、状态和关联关系，状态经历新进入、待梳理、已细化、已排期、已关闭或归档。
- 需求池与迭代待办、优先级评估、需求文档、需求列表职能不同，混用会导致把“池中有多少条”误当成“有多少工作要排期”。
- 需求池的日常工作是补信息、处理重复和清理积压，评分排序只是梳理中的可选环节。
需求池是什么：一句话定义与核心特征
需求池可以概括为：一个团队用于集中存放、持续维护待处理需求的集合。它把分散在各处的需求收拢起来，保持可查、可分类、可追踪的状态，为后续的需求评估和排期提供输入。在敏捷研发语境中，需求池常对应英文 Product Backlog，中文也译作产品待办列表，两者指向同一类事物：产品层面尚未进入当前迭代、但需要被持续管理的需求集合。
理解这个定义，需要抓住三个核心特征。
- 集中存放。需求池把来自用户反馈、业务方提出、内部团队发现、线上问题转化等渠道的需求放到同一处管理。集中存放的价值在于让团队对“有哪些待处理需求”有一份共同可见的清单，避免需求散落在聊天记录、邮件、会议纪要和个人笔记里，讨论时各说各话。
- 持续维护。需求池是动态的，需求会不断进入，也会被细化、合并、关闭或归档。团队需要定期梳理，补充信息、调整分类、处理重复项、清理长期无进展的条目。一个长期不维护的需求池会退化为堆积清单，条目越多越难使用。
- 待处理。进入需求池的需求处于“尚未进入执行”的状态。它们可能信息还不完整，可能优先级尚未确定，可能还在等待评估。需求池保存的是候选需求，而不是已经承诺交付的工作。
由此可以得出一个关键判断：需求池是输入集合，不是执行计划。它回答“团队收到了哪些需求、这些需求目前处于什么梳理状态”，不回答“这个迭代谁在什么时候做完哪件事”。单个迭代内的任务拆解、责任分配和进度跟踪属于迭代管理的范围，需求池为这些环节提供来源，本身不承担执行调度职能。
需求池包括什么、不包括什么
需求池的边界常被模糊，原因在于“需求”这个词在日常使用中覆盖面很广。把属于需求池维护的动作和属于其他环节的动作分开，可以减少概念混用。
属于需求池维护的内容包括：
- 需求归集。把各渠道的需求录入或转入池中，记录来源，保证需求不丢失。
- 需求分类。按业务模块、需求类型、来源渠道等维度打标签或分组，便于检索和批量梳理。
- 状态维护。记录每条需求当前处于新进入、待梳理、已细化、已排期还是已关闭等状态，让团队知道哪些需求还需要处理。
- 重复项关联。当多个渠道提出实质相同的业务需求时，把它们关联起来或合并为一条主需求，保留来源记录，避免重复评估和重复排期。
- 积压清理。对长期无人推进、信息缺失或已不符合业务方向的需求做关闭或归档处理，控制池子规模。
不属于需求池维护、应归其他管理环节的内容包括：
- Sprint Backlog（迭代待办列表）。迭代待办是某个迭代内团队承诺完成的工作集合，包含任务拆解、工作量估算和执行安排，归迭代管理。需求池中的需求被选中进入迭代后，才在迭代待办中展开为具体任务。
- 价值评分与优先级评估。对需求做价值判断、成本估算、打分排序，属于需求优先级与价值评估的工作。需求池可以承载评分字段和排序结果，评分方法和评估决策本身是另一项管理活动。
- 搜索关键词去重。这是检索或数据清洗场景中的技术处理，针对文本或关键词的重复。需求池中的重复项关联针对的是业务需求本身，判断依据是需求描述指向的用户问题和业务目标是否相同，两者不是一回事。
把这条边界说清楚，团队在使用需求池时就不容易把“池子里有多少条需求”误当成“有多少工作要排期”，也不会把评分讨论和池子维护混在同一次会议里。
需求池的组成：一条需求在池中的关键字段与状态
需求池由一条条需求条目构成，每条条目通过字段记录信息，通过状态反映梳理进度。字段设置因团队而异，下面列出的是一组常见且实用的基本字段。
| 字段 | 作用 | 维护要点 |
|---|---|---|
| 来源 | 记录需求由谁、通过什么渠道提出 | 保留原始提出方，便于后续回访和验证 |
| 描述 | 说明需求要解决的问题和使用场景 | 先记录问题，细化阶段再补充方案细节 |
| 分类 | 按业务模块、需求类型等维度归类 | 分类维度不宜过多，保持可检索即可 |
| 状态 | 反映需求当前所处的梳理阶段 | 状态定义与团队实际流程一致 |
| 关联关系 | 指向重复需求、相关需求或来源工单 | 合并时保留被合并条目的来源信息 |
状态流转是需求池运转的主线。一条需求通常经历以下阶段：
- 新进入。需求刚被录入池中，信息可能不完整，尚未经过任何梳理。
- 待梳理。已确认需要处理，等待补充背景、明确问题或与提出方沟通。
- 已细化。需求描述、场景和验收要点基本清楚，具备进入评估的条件。
- 已排期。需求已被选中进入某个迭代或版本计划，从池中“出池”进入执行环节。
- 已关闭或归档。需求因重复、失效、不做或已完成等原因离开活跃池。
重复项的处理方式值得单独说明。当梳理中发现两条或多条需求指向同一业务问题时，常见做法是选定一条作为主需求，其余条目关联到主需求并标注“重复”，或者直接合并后保留来源记录。合并的关键是保留提出方信息，否则后续验证需求时容易丢失原始场景。积压清理的判断依据通常包括：长期停留在待梳理状态且无人推进、提出场景已不存在、与当前产品方向不符、信息缺失且无法联系提出方补齐。清理动作以关闭或归档为主，保留记录以便追溯，避免直接删除造成信息丢失。
在工具层面，需求池的归集与状态维护需要有对应的承载方式。ONES 工单可用于收集和整理来自各方的反馈，处理后将工单转化为需求，整理出产品 Backlog；ONES Project 支持建立需求池、规划迭代，并支持编写需求、自定义需求状态与多种属性。团队还可以根据实际场景自定义工作流，让需求按约定的状态规范流转。这些能力对应的是池子的承载和流转，评分方法与排期决策仍由团队按自身规则完成。
需求池与相邻概念的区别
需求池容易与几个相邻概念混用，下面按同一口径对照说明差异所在。
| 概念 | 管理对象 | 核心问题 | 与需求池的关系 |
|---|---|---|---|
| 需求池 | 待处理的候选需求集合 | 有哪些需求、各自梳理到什么程度 | 本概念 |
| Sprint Backlog | 某个迭代内承诺完成的工作 | 这个迭代做什么、谁来做、何时完成 | 需求池是来源，被选中的需求进入迭代待办后展开为任务 |
| 需求优先级评估 | 需求之间的价值与成本判断 | 先做哪个、为什么先做这个 | 评估结果作用于需求池的排序，评估方法本身不属于池子维护 |
| 需求文档 | 单个需求的详细说明 | 这个需求具体怎么做、验收标准是什么 | 文档是需求细化后的产物，需求池条目可关联对应文档 |
| 需求列表 | 按某种条件列出的需求清单 | 符合条件的需求有哪些 | 列表是需求的呈现形式，需求池强调持续维护和状态管理 |
需求池与 Sprint Backlog 的区别最需要强调。需求池面向产品层面的待处理需求，时间跨度不限于单个迭代；Sprint Backlog 面向单个迭代的执行承诺，包含任务拆解和进度跟踪。需求从池中进入迭代，是一次状态变化，也是一次管理归属的转移。
需求池与优先级评估的区别在于，池子负责“装”和“维护”，评估负责“判断”。池子可以提供排序字段、评分属性，但评分标准、评估会议和决策结论属于另一项工作。把两者混为一谈，容易出现“池子里排了序就等于做完评估”的误解。
需求池与需求文档、需求列表的区别在于粒度与职能。文档描述单个需求的细节，列表是查询结果的呈现，需求池则是一套带状态和持续维护机制的集合。三者可以互相引用，职能不同。
一个具体例子：需求池如何运转
以下是一个演示情景，用于说明需求池的典型运转方式，不对应特定团队的真实数据。
某产品团队通过三个渠道收到需求：客服转来的用户反馈、销售提出的客户定制诉求、内部运营提出的流程优化建议。团队把这些需求统一录入需求池，每条记录来源和原始描述，状态设为“新进入”。一周后，产品负责人组织梳理会，逐条处理新进入的需求：信息不足的联系提出方补充，能明确问题的改为“待梳理”，明显属于同一业务问题的做关联或合并。例如客服和销售分别提出的两条需求，实质都是希望支持批量导出报表，梳理时合并为一条主需求，两条来源都保留在关联记录中。
梳理完成后，部分需求补充了场景和验收要点，状态更新为“已细化”。在迭代规划时，产品负责人根据优先级把其中若干条规划进对应迭代，状态变为“已排期”，这些需求随后在迭代待办中拆解为研发和测试任务。对于功能复杂的需求，可以拆解为子工作项，并关联研发和测试任务，把需求、研发、测试环节串联起来。季度末清理时，团队发现若干条需求停留在“待梳理”超过两个月且无人推进，提出场景也已变化，于是关闭并归档，池子规模回到可控范围。
这个例子中常见的误解有两个。其一，把需求池当成排期表：认为需求进了池子就等于排上了队，实际上池中的需求只代表被记录和梳理，是否进入迭代要经过规划决策。其二，把需求池当成评分表：认为池子的主要工作是打分排序，实际上评分只是梳理中的一个可选环节，池子的日常工作是归集、补信息、处理重复和清理积压。区分这两点，需求池才能稳定发挥“待处理需求集合”的作用。
常见问题
需求池里的需求越多，是否说明团队的工作越饱和？
不能这样判断。需求池记录的是候选需求，条目数量反映的是收集和记录的范围，与团队实际可承担的工作量没有直接对应关系。判断工作饱和度要看迭代待办中的承诺内容和执行进度。池子条目过多时，更值得关注的是梳理是否及时、积压是否清理，而不是把它当作工作量指标。
需求池中的重复需求应该合并还是保留多条？
取决于重复的性质。如果多条需求指向同一业务问题和同一目标，通常选定一条作为主需求，其余关联或合并，并保留各提出方的来源记录，避免后续验证时丢失原始场景。如果表面相似但目标用户或使用场景不同，保留为独立条目并互相标注关联更稳妥。合并的关键动作是保留来源信息，而不是简单删除。
需求池需要多久梳理一次？
没有统一频率，取决于需求进入的速度和团队节奏。常见做法是固定周期梳理，例如每周一次，并在迭代规划前集中处理待梳理条目。需求进入频繁的团队可以缩短间隔，进入较少的团队可以适当拉长。比频率更重要的是每次梳理都处理新进入条目、关联重复项，并检查长期停滞的条目。
需求被关闭或归档后，还能重新回到需求池吗？
可以。关闭或归档表示该需求暂时离开活跃池，记录通常保留以便追溯。当提出场景重新出现或业务方向变化时，可以重新打开原条目或新建条目并关联原记录。保留归档记录的价值在于，团队能查到过去为什么不做这个需求，避免同一问题反复讨论。
需求池和产品待办列表是同一个东西吗？
在多数敏捷研发语境中，两者指向同一类事物。需求池是中文里的通俗说法，产品待办列表（Product Backlog）是敏捷实践中的对应术语，都指产品层面持续维护的待处理需求集合。团队内部统一使用其中一个称呼即可，关键是保持同一套字段和状态定义。
