需求池和迭代待办列表常被当成同一张清单使用，结果要么把远期想法直接排进迭代，要么把执行中的任务堆回需求池。两者的关系可以概括为筛选与承诺：需求池回答“哪些需求值得做、先做哪个”，迭代待办列表回答“这个迭代具体做什么、谁来做、做到什么状态”。本文围绕销售、客服与研发共同维护需求的场景，说明两者的差异、分工与交接规则，并提及ONES作为需求收集与迭代执行衔接的承载方向。
要点总览（TL;DR）
- 需求池回答“哪些需求值得做、先做哪个”，迭代待办列表回答“这个迭代具体做什么、谁来做、做到什么状态”，两者是筛选与承诺的关系。
- 判断一条内容放哪里，看它是否已通过优先级评估、工作量估算和验收标准确认，并落在本迭代容量内。
- 销售与客服负责把业务场景、期望结果和紧急程度写清楚，研发补充可行性判断，产品负责人负责排序和决定进入哪个迭代。
- 迭代中新增需求默认回到需求池排队；未完成条目按约定回流需求池重新排序、结转下个迭代或关闭并注明原因。
- 起步阶段先定清两张清单的准入条件和状态含义，再逐步补充字段；ONES 可用于需求收集、评估排序与迭代执行的衔接。
需求池与迭代待办列表的核心区别
需求池是面向未来的需求集合，承担收集、分类、评估和排序的职责；迭代待办列表是某个迭代内已承诺执行的工作项清单，承担执行承诺与进度管理的职责。判断一条内容该放在哪里，可以看它是否已经通过优先级评估、是否已确认在本迭代容量内完成。通过评估并纳入迭代的条目进入迭代待办列表，其余仍留在需求池中等待排序。
| 比较维度 | 需求池 | 迭代待办列表 |
|---|---|---|
| 回答的问题与所处阶段 | 哪些需求值得做、先做哪个；处于收集与评估阶段 | 这个迭代具体做什么、谁来做、做到什么状态；处于执行阶段 |
| 条目来源与准入条件 | 销售、客服、研发、用户反馈等多方提交，经过去重、分类和初步评估即可入池 | 来自需求池中已排序且优先级靠前的条目，需通过迭代计划确认容量与验收标准 |
| 状态流转与生命周期 | 新建、待评估、已评估、已排期、暂缓、关闭等，生命周期可跨越多个迭代 | 待开始、进行中、待验收、已完成等，生命周期与单个迭代绑定 |
| 负责人与协作角色 | 产品负责人主导评估与排序，销售、客服负责提交与补充业务信息，研发参与可行性判断 | 迭代内由研发、设计、测试按任务分工执行，产品负责人跟踪范围与验收 |
| 变更与回流规则 | 可随时新增、合并、暂缓或关闭，变更不影响已承诺的迭代 | 迭代内变更需评估对范围与进度的影响，未完成项按规则回流需求池或结转下个迭代 |
这张对照表的判断口径是：需求池管理“要不要做、什么时候做”，迭代待办列表管理“这次做多少、做到什么程度”。同一需求可以先后出现在两张清单中，但它在两张清单中的状态含义不同，不能互相替代。
销售、客服与研发共同维护时如何分工
跨角色协作的关键是让提交、评估、承诺三个环节各有明确的责任人和产物。销售与客服负责把业务侧的问题描述清楚，研发负责判断可行性与工作量，产品负责人负责排序和决定进入哪个迭代。
提交环节：销售与客服填写统一字段
销售和客服提交需求时，建议至少填写以下字段，避免研发反复追问背景：
- 需求来源与提出人：便于后续回访和确认。
- 业务场景与影响范围：说明涉及哪些客户、订单或服务流程。
- 期望结果与验收要点：用业务语言描述完成后能解决什么问题。
- 紧急程度与期望时间：作为排序参考，不作为承诺。
- 关联工单或客户记录：便于追溯原始反馈。
评估环节：研发补充可行性判断
研发在需求池中承担技术评估动作，包括判断实现路径、估算工作量、识别依赖和风险。产品负责人结合业务价值、紧急程度和研发评估结果进行排序，形成有优先级的待办顺序。评估结论应回写到需求条目上，让销售和客服能看到需求处于待评估还是已排期。
交接环节：从需求池进入迭代待办列表的条件
需求进入迭代待办列表前，需要满足几个条件：优先级已确认、工作量已估算、验收标准已明确、迭代容量允许。在迭代计划会议上，产品负责人与团队共同评审候选需求，确认范围后将其纳入迭代待办列表，并分配负责人。此时需求的状态从“已排期”转为迭代内的执行状态。
迭代中新增需求与未完成条目的处理
迭代进行中收到的新需求，默认回到需求池排队，由产品负责人判断是否影响当前迭代目标。确需插入时，应同步评估对已承诺范围的影响，并记录变更原因。迭代结束后，未完成的条目按团队约定处理：仍具价值的回流需求池重新排序，已确认继续的结转到下个迭代，失去价值的关闭并注明原因。
常见混淆场景与判断示例
混淆通常发生在两张清单被当作同一张表维护的时候。以下场景可以帮助判断边界。
把需求池当迭代清单排期
销售看到需求池里有一条高优先级需求，直接对外承诺“下个版本上线”。问题在于需求池中的优先级只代表排序位置，尚未经过容量确认和迭代计划评审。处理方式是：对外沟通时说明需求当前处于已评估或已排期状态，具体上线时间以进入迭代待办列表后的计划为准。
把迭代待办列表当需求池收集
客服把新反馈直接加到当前迭代的任务列表里，导致迭代范围不断膨胀、进度失真。处理方式是：迭代待办列表只接收已承诺的条目，新反馈统一进入需求池，由产品负责人按优先级决定是否进入后续迭代。
同一需求在两张清单中的状态对应
一条需求在需求池中可能处于“已评估、待排期”，进入迭代后对应迭代待办列表中的“待开始”，执行中对应“进行中”，完成后对应“待验收”或“已完成”。两张清单通过需求条目本身关联，状态各自表达不同阶段的含义，不应把迭代状态直接回写成需求池的评估状态。
业务重复需求与搜索关键词去重的区别
销售和客服从不同客户处收到表述不同但实质相同的需求，属于业务层面的重复需求，需要在需求池中合并并保留来源记录，避免重复评估。这与搜索关键词去重是不同的问题：前者是需求管理中的归并动作，后者属于检索技术范畴，不在本文讨论范围内。
落地建议与工具承载
起步阶段不必追求字段齐全，先把两张清单的准入条件和状态含义定清楚，再逐步补充字段和规则。
需求池的最小字段与状态设计
最小字段建议包括：需求标题、来源、提出人、业务场景、期望结果、优先级、评估结论、当前状态。状态可以从“待评估、已评估、已排期、暂缓、关闭”起步，后续根据实际流转补充。字段和状态确定后，销售、客服与研发按同一套口径填写，减少口头传递造成的信息丢失。
迭代待办列表的准入与容量检查
迭代计划时逐条检查：需求是否已评估、验收标准是否明确、负责人是否确定、本迭代总工作量是否在团队容量内。容量检查的作用是让承诺可兑现，避免迭代开始后频繁调整范围。
两张清单的关联与追溯
需求从池进入迭代时保留原条目关联，迭代结束后回看该需求的评估记录、排期时间和执行结果。这样销售和客服能回答客户“这个需求进展到哪一步”，研发也能回溯某次排期的依据。
ONES在其中的承载方式
在ONES Project中，可以建立需求池并规划迭代，编写需求时支持自定义需求状态与多种属性，便于把上述字段和状态落到条目上；需求和相关任务可以规划至迭代并分配负责人，形成从需求池到迭代执行的衔接。在ONES敏捷研发管理方案中，还可以使用ONES工单收集和整理来自各方的反馈，处理工单并转化为需求，整理出产品待办列表，并按实际场景自定义工作流，让需求流转规则与团队约定保持一致。产品负责人可依据需求优先级将待办列表中的需求规划至对应迭代，在迭代计划会议上与团队共同评审，确认验收标准后由设计、研发、测试人员拆分子任务跟踪执行。具体状态流转和回流规则的配置方式，需结合团队实际流程在工具中设定。
常见问题
需求池里的优先级很高，能不能直接对客户承诺上线时间？
不建议直接承诺。需求池中的优先级只代表排序位置，尚未经过迭代容量确认和迭代计划评审。对外沟通时可以说明需求当前处于“已评估”或“已排期”状态，具体上线时间以进入迭代待办列表后的计划为准。如果客户对时间敏感，可以先把期望时间记录在需求条目上，作为排序参考，并在迭代计划确认后再回复明确时间。
迭代进行中销售又提了一个紧急需求，应该插进当前迭代吗？
默认做法是回到需求池排队，由产品负责人判断是否影响当前迭代目标。确需插入时，要同步评估对已承诺范围的影响，例如是否需要移出等量的其他条目、是否影响验收时间，并记录变更原因。这样处理的好处是迭代范围变化有据可查，团队和业务侧对进度预期保持一致。
迭代结束后没做完的条目，是留在迭代里还是放回需求池？
按团队约定处理，常见做法分三种：仍具价值的回流需求池重新排序，已确认继续的结转到下个迭代，失去价值的关闭并注明原因。关键是回流时保留原条目关联，让销售和客服能回溯这条需求的评估记录和排期历史，避免同一需求被重复提交和重复评估。
销售和客服从不同客户处收到实质相同的需求，要不要合并？
属于业务层面的重复需求，建议在需求池中合并为一条并保留各来源记录，避免研发重复评估。合并后仍要保留每个客户的提出时间和期望，便于后续回访。这与搜索关键词去重是不同的问题，后者属于检索技术范畴，不涉及需求管理流程。
ONES 中需求池和迭代待办列表是怎么衔接的？
在 ONES Project 中可以建立需求池并规划迭代，编写需求时支持自定义需求状态与多种属性，需求和相关任务可以规划至迭代并分配负责人。在 ONES 敏捷研发管理方案中，还可以用工单收集和整理各方反馈，处理工单并转化为需求，整理出产品待办列表，并按实际场景自定义工作流。产品负责人可依据优先级把待办列表中的需求规划至对应迭代，在迭代计划会议上与团队评审，确认验收标准后由设计、研发、测试人员拆分子任务跟踪执行。具体状态流转和回流规则的配置方式，需结合团队实际流程在工具中设定。
