产品待办列表与需求池常被混用，实际是上下游关系：需求池负责把来自各方的需求收得全、筛得准，产品待办列表负责把确认要做的条目排得清、做得动。两者的差别集中在归集范围、细化程度和迭代衔接三点。下面用统一口径对照两个集合，说明各自的边界、移交条件，并给出一条从需求池到待办列表的流转路径。
要点总览（TL;DR）
- 需求池是需求的归集与筛选容器，收录来源广泛、颗粒度不一；产品待办列表是确认要做、按优先级排序、可直接进入迭代的条目集合，二者是上下游关系。
- 判断条目归属看三个信号：来源是否收敛、描述是否细化到可估算、是否进入近期排期，三者都满足才适合放进待办列表。
- 需求池移交待办列表的触发条件是：价值已确认并纳入规划、目标用户与场景清晰、范围可界定、无未解决依赖，移交时留下评估记录。
- 待办列表的就绪标准包括目标明确、范围清晰、验收条件可检验、工作量可估算、依赖已识别；待办列表本身不等于迭代范围。
- 需求来源单一的小团队可合并为一个集合用状态区分，来源多、多迭代并行的团队建议分设两个集合，判断依据是条目成熟度而非集合数量。
同口径差异对照：归集范围、细化程度与迭代衔接
判断一个条目该放在需求池还是产品待办列表，可以看三个信号：来源是否已经收敛、描述是否细化到可估算、是否已进入近期排期。三者都满足，条目才适合放进待办列表；只满足第一条或都不满足，留在需求池更合适。下表按同一组维度对照两个集合。
| 对照维度 | 需求池 | 产品待办列表 | 一句话解读 |
|---|---|---|---|
| 定义与定位 | 需求的归集与筛选容器，承接尚未确定要做的事项 | 确认要做、按优先级排序、可直接进入迭代开发的条目集合 | 前者是入口，后者是执行准备区 |
| 归集来源与收录范围 | 来源广泛：用户反馈、销售诉求、内部提议、竞品观察、线上问题等都可登记 | 只收录经过评估、确认纳入产品规划的需求 | 需求池求全，待办列表求准 |
| 条目细化程度 | 颗粒度不一，允许一句话描述、附件、原始记录 | 需具备目标、范围、验收条件，复杂需求已拆分 | 细化程度决定条目能否被估算和排期 |
| 优先级排序方式 | 可做粗排序或打标签，主要用于筛选和批量取舍 | 按价值、成本、依赖关系做明确排序，顺序即开发顺序 | 需求池排序服务于决策，待办列表排序服务于执行 |
| 与迭代的衔接点 | 不直接进入迭代，需先移交 | 迭代计划会议从中选取条目形成迭代范围 | 待办列表是迭代的直接上游 |
| 状态与责任角色 | 产品经理或需求接口人负责登记、初筛、合并 | 产品负责人负责排序与就绪判断，团队参与评审 | 责任随条目细化程度转移 |
| 维护频率 | 持续收录，定期批量清理 | 每个迭代前后调整，保持顺序最新 | 需求池重周期整理，待办列表重持续重排 |
这张表的核心结论是：两个集合的差异来自条目成熟度，而非管理偏好。条目从需求池进入待办列表，本质是完成了一次从“可能有价值”到“确认要做且能做”的判断。
需求池的边界：收什么、留多久、何时移交
需求池的职责边界是“管到评估结论为止”。它需要保证来源不遗漏、重复可识别、去向有记录，但不承担详细方案设计和开发排期。把需求池管成一个小型待办列表，会让登记门槛变高，反而丢失早期信号。
收录范围与条目形态
- 典型来源：客户与用户反馈、销售和售前诉求、客服工单、内部团队提议、线上问题复盘、竞品与市场观察。
- 条目形态允许不完整：一句话描述、原始聊天记录、工单链接、截图都可以先登记，后续再补背景和目标。
- 登记时至少保留来源、提出人、场景描述和期望结果四项，便于后续判断价值。
粗筛、合并与保留
粗筛的判断依据通常有三条：是否落在产品定位范围内、是否已有同类需求、是否具备可描述的用户场景。同一场景下的重复诉求应合并为一条主需求，并在条目内记录关联来源数量，来源数量本身可以作为价值判断的参考。需求池条目的保留期限没有统一标准，常见做法是按季度或半年度清理一次：已明确不做的标注原因后归档，长期无来源追加的条目降级或关闭，保留可追溯记录即可。
向产品待办列表移交的触发条件
条目满足以下条件时，适合从需求池移交到产品待办列表：业务价值已确认并纳入产品规划；目标用户和场景描述清晰；范围可以界定，能判断大致工作量；没有未解决的依赖或前置决策。移交动作本身应留下记录，包括评估结论、评估人和移交时间，便于后续回溯为什么做或为什么不做。
产品待办列表的边界：细化到什么程度才算可开发
产品待办列表的边界是“管到可排期为止”。条目在这里要完成从想法到工作项的转换，判断标准通常称为“就绪”。就绪不是写得长，而是团队看完能估算、能拆任务、能确认完成条件。
就绪条目的判断标准
- 目标明确：说明解决谁的什么问题，预期产生什么结果。
- 范围清晰：包含哪些功能点、不包含哪些，边界无歧义。
- 验收条件可检验：能用具体场景或规则判断是否完成。
- 工作量可估算：团队能给出相对规模判断，不依赖未决的技术方案。
- 依赖已识别：与其它需求、外部系统或数据的依赖关系已记录。
拆分粒度与排序规则
拆分粒度以“一个迭代内可完成、可独立验收”为宜。功能复杂的需求可以拆成多个子条目，分别关联研发和测试任务；拆得太细会增加管理成本，拆得太粗则无法排期。排序依据通常综合价值、成本、风险和依赖关系，形成一条从高到低的顺序。调整频率建议每个迭代前后各重排一次，迭代中途只处理紧急插入，避免顺序频繁变动影响团队节奏。
与迭代范围的交接点
待办列表本身不等于迭代范围。迭代计划会议上，产品负责人按优先级提出候选条目，团队评审后确认本次迭代承接的部分，剩余条目继续留在待办列表中等待下一轮。这个交接点的完成标志是：迭代范围确定、每条目有负责人、验收条件被团队认可。
两者如何衔接：一条需求从池子到待办的流转路径
下面用一条演示路径说明两个集合之间的动作、角色和状态变化。情景为演示设定，不代表特定团队的实际流程。
- 登记入池。客服转来一条客户反馈，需求接口人将其登记为需求池条目，状态记为“待评估”，附上来源和原始描述。
- 评估与筛选。产品经理在定期评审中判断该需求是否在规划范围内、是否与已有条目重复。重复则合并并累加来源；不在范围内则标注原因后关闭。
- 细化与拆分。确认有价值后，产品经理补充目标、范围和验收条件，复杂部分拆成子条目。状态从“待评估”变为“已确认”，条目仍留在需求池，等待排期决策。
- 移交待办。该需求被纳入近期规划，产品经理将其移入产品待办列表，状态变为“待排期”，并按优先级插入顺序中的合适位置。
- 排入迭代。迭代计划会议上，产品负责人提出该条目，团队评审通过后将其纳入本次迭代范围，指定负责人，状态推进为“开发中”。
- 搁置或退回。若评审认为条件不满足，条目退回待办列表继续等待；若规划方向变化，则退回需求池并记录原因，保留来源信息以便日后重新评估。
这条路径中，需求池承担登记、初筛、合并和保留，待办列表承担细化、排序和就绪判断，迭代范围只承接其中一部分。团队采用 ONES 时，这套动作可以在同一套工作项体系中完成：用 ONES 工单收集和整理来自各方的反馈，处理后将工单转化为需求，整理出产品 Backlog；需求支持自定义状态与多种属性，便于标记评估结论和就绪情况；复杂需求可用子工作项拆解并关联研发、测试任务；产品负责人按优先级将待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审。上述能力适用于采用 ONES 敏捷研发管理方案的团队，具体状态字段和移交规则需按团队流程配置。
常见混淆与适配场景：你的团队该用几个集合
最常见的混淆是把需求池直接当待办列表用：所有反馈一进来就排进开发顺序，结果是顺序频繁被新诉求打乱，团队反复切换，评估结论也无处记录。另一个反向问题是待办列表里堆着大量未细化的条目，迭代计划会议变成现场澄清会，排期失真。
易混点清单
- 需求池条目多，不等于待办列表条目多；前者是候选，后者是承诺。
- 待办列表排序不等于价值评分，排序是执行顺序，评分是评估工具，两者可以配合但不互相替代。
- 待办列表不等于迭代范围，迭代范围是某一轮从中选取的子集。
- 条目退回需求池是正常动作，通常发生在规划方向调整、前置条件消失或评估结论被推翻时，退回时应记录原因。
按团队情况选择集合划分
| 团队情况 | 建议做法 | 判断依据 |
|---|---|---|
| 需求来源单一、团队规模小、迭代周期短 | 可合并为一个集合，用状态区分“待评估”和“已就绪” | 登记与排期由同一人完成，拆分两个集合的交接成本高于收益 |
| 需求来源多、有专职产品角色、多个迭代并行 | 分设需求池与产品待办列表 | 需要把“收得全”和“排得清”分开考核，避免新诉求冲击执行顺序 |
| 对外承接定制或项目制交付 | 需求池按客户或项目分组，待办列表按产品统一排序 | 来源需要可追溯，执行顺序需要跨项目统一 |
| 处于探索期、方向频繁调整 | 先只维护需求池，待方向收敛后再建立待办列表 | 过早排序会产生大量返工 |
合并维护时，关键是给条目设置清晰的状态门槛，确保未细化的条目不会被直接排进迭代；分设两个集合时，关键是定义移交条件并留下评估记录，避免两个集合之间来回搬运却没有结论。无论选哪种方式，判断标准都应落在条目成熟度上，而不是集合的数量上。
常见问题
需求池里的条目一直没人评估，越积越多怎么办？
积压通常来自缺少固定的评估节奏。可以设定定期评审，例如每两周一次，由产品经理或需求接口人集中处理新登记条目，逐条给出“纳入规划、继续观察、合并、关闭”四类结论并记录原因。对长期无来源追加的条目，按季度或半年度降级或关闭，保留可追溯记录。评估节奏稳定后，池子的规模会自然收敛到可管理的范围。
待办列表里的条目在迭代评审时被判定条件不满足，应该退到哪里？
分两种情况处理。如果只是本次迭代条件不满足、方向仍然成立，条目退回产品待办列表继续等待，保持原有优先级位置或重新排序。如果规划方向变化、前置条件消失或评估结论被推翻，则退回需求池并记录原因，保留来源信息以便日后重新评估。退回是正常动作，关键是留下结论，避免两个集合之间反复搬运却没有判断。
小团队合并维护一个集合时，怎么防止未细化的需求被直接排进迭代？
核心是给条目设置清晰的状态门槛，例如“待评估—已确认—已就绪”三档，只有“已就绪”的条目才能被迭代计划会议选取。同时约定就绪的最低要求：目标、范围、验收条件、工作量估算四项齐全。状态门槛由产品负责人在排期前检查，团队评审时也可以退回不满足条件的条目。合并维护省下的是交接成本，状态规则不能省。
需求池和产品待办列表需要分别统计和考核吗？
可以分开看但不必分别考核。需求池更适合观察来源结构、登记量和处理时效，例如各渠道反馈数量、平均评估周期；待办列表更适合观察就绪率和排序稳定性，例如迭代计划会议中因未就绪被退回的条目比例。把两个集合的指标混在一起考核，容易诱导团队为了数字把条目提前推进或长期滞留，反而失真。
用工具管理时，需求池和待办列表必须建成两个独立项目吗？
不必。常见做法是在同一套工作项体系中用状态和视图区分：工单收集反馈，处理后的反馈转化为需求，需求按状态区分待评估与已就绪，产品负责人按优先级把就绪需求规划至迭代。是否拆成独立项目取决于团队规模和协作边界，来源多、多迭代并行时拆开更利于分工，小团队在同一空间内用状态区分即可。具体字段和流转规则需按团队流程配置。
