需求积压的判断口径可以概括为：待评估需求持续增长、状态长期不流转、重复与过期项越攒越多，而细化与评审跟不上。处置主线是先把新增入口收紧，再按状态和时效盘点清理，最后用指标验证恢复并建立定期清理机制。本文聚焦需求池本身的维护，迭代排期与优先级评分方法不在讨论范围内。
要点总览（TL;DR）
- 先判断是否属于需求积压：待评估数量持续增长、状态长期停留、重复与过期项增多、细化滞后，多项叠加且持续数周才按积压处理。
- 成因按入口、状态、重复与过期、细化评审的顺序用数据验证，先处理上游入口问题，再解决下游评审瓶颈。
- 处置顺序为先冻结或收紧新增入口止住增量，再按状态与停留时长盘点，合并重复、关闭失效项，对保留项补充分级与细化。
- 批量关闭与合并前先备份数据、小范围试点、双人确认，并设定误操作后的停止点。
- 清理后连续观察四到六周，用积压总量、平均停留时长、关闭合并数量、状态流转率验证恢复，靠入口准入与定期清理例会防复发。
需求积压有哪些典型症状与影响范围
判断是否属于需求积压，先看需求池的存量与流动，而不是看某个迭代排得满不满。积压通常同时出现几类可观察症状，单独出现一项可能只是阶段性波动，多项叠加且持续数周，才值得按积压问题处理。
- 待评估数量持续增长：每周新增进入“待评估”或“待评审”状态的需求数，长期高于每周完成评估的数量，存量曲线单向上行。
- 状态长期停留：大量需求停留在同一状态超过既定周期，例如“待评审”超过两周、“已确认”超过一个月仍未进入细化。
- 重复项增多：不同渠道反复提交相似诉求，池内出现多条内容接近的记录，彼此没有关联说明。
- 细化滞后：已确认要做的需求缺少验收标准、范围描述或责任人，无法进入评审和排期决策。
需要与 Sprint Backlog 排期问题区分开。需求池积压表现为“池子里的东西越来越多、越来越旧”；迭代排期问题表现为“已选入迭代的工作做不完或频繁变更”。前者是需求集合的维护问题，后者是迭代容量与执行问题。两者可能同时存在，但处置动作不同：池子问题先清理和设门槛，迭代问题调整容量与范围。若把池子积压误当成排期不足，常见结果是不断加人加会，积压依旧增长。
范围界定要落到三个维度，形成一份可核对的说明：一是来源渠道，确认积压集中在客服反馈、销售诉求、内部提议还是线上监控中的哪几类；二是状态段，确认堆积发生在“待评估”“待评审”还是“已确认待细化”；三是责任人，确认哪些需求没有明确负责人或负责人长期未处理。三个维度交叉后，往往能定位到一两个具体环节，而不是笼统的“需求太多”。
积压症状自查清单
| 检查项 | 判断标准 | 记录内容 |
|---|---|---|
| 存量趋势 | 连续四周待评估数量净增长 | 每周新增数、完成评估数、期末存量 |
| 状态停留 | 存在超过约定周期未流转的需求 | 状态、停留天数、责任人 |
| 重复情况 | 抽样发现内容相近的记录未关联 | 重复组数、涉及渠道 |
| 细化完备度 | 已确认需求缺少范围或验收标准 | 缺失字段、缺失比例 |
| 责任归属 | 存在无负责人或负责人空缺的需求 | 数量、所属状态段 |
积压的常见原因与排除证据
积压的成因需要用证据确认，不能凭印象下结论。下面四类假设覆盖多数情况，建议按“入口—状态—重复与过期—细化评审”的顺序排查，因为上游问题会放大下游症状。每类假设都给出验证证据，排查后记录判定结果，避免同一问题反复争论。
| 原因假设 | 验证证据 | 排查顺序 | 判定结果记录 |
|---|---|---|---|
| 入口无准入标准，低质量需求直接入池 | 抽样近期新增需求，统计缺少提出背景、使用场景、影响范围的比例；对比入池量与评估通过量 | 第一步 | 低质量占比、主要缺失字段 |
| 状态与责任人缺失，需求长期不流转 | 按状态统计停留时长分布；统计无负责人记录数；查看状态变更记录是否稀疏 | 第二步 | 超期停留数量、集中在哪些状态 |
| 重复与过期需求未合并或关闭 | 按主题关键词抽样比对；检查超过约定时效仍未推进的记录是否仍处于开启状态 | 第三步 | 重复组数、过期未关闭数量 |
| 细化与评审资源不足，需求无法进入可决策状态 | 统计待评审队列长度与每次评审实际处理量；统计已确认但缺细化信息的需求比例 | 第四步 | 评审吞吐缺口、细化缺口 |
排查时注意区分相关与因果。例如“评审会开得少”与“积压增长”同时出现，只能说明两者相关；进一步看每次评审的处理量和待评审队列的增速，才能判断评审吞吐是否真的是瓶颈。若入口质量很差，即使增加评审频次，积压也会继续增长，此时应先处理入口假设。
判定结果建议写成一句话结论加数据支撑，例如“近四周新增需求中约六成缺少使用场景描述，入口假设成立，优先收紧准入”。结论明确后，处置动作才有针对性，也便于后续验证是否有效。
按步骤处置：清理、合并与恢复流转
处置遵循“先止增量、再清存量、后恢复流转”的顺序。存量清理涉及关闭和合并等破坏性操作，每一步都要明确操作对象、责任人和停止条件，避免误伤有效需求。
第一步：冻结或收紧新增入口
在清理完成前，暂停接收新需求，或改为只接收带完整背景、场景和影响范围的需求，其余进入暂存区等待补全。操作对象是各来源渠道的提交入口，责任人是需求池管理者与各渠道对接人。停止条件是清理完成且准入规则正式生效，此时恢复入口。这一步的目的是让存量不再增长，使后续盘点结果可比较。
第二步：按状态与停留时长盘点
导出全量需求，按状态分组，再按停留时长排序，标记出超期项、无责任人项和长期无变更项。盘点结果形成待处置清单，每项标注建议动作：保留、合并、关闭或补信息。责任人为各状态段的负责人，需求池管理者负责汇总核对。盘点期间只标记不操作，避免边盘边改造成口径混乱。
第三步：合并重复需求并关闭失效项
对内容相近的记录，确定一条主记录，保留完整的背景、场景和反馈来源，其余记录关联到主记录并注明合并关系，反馈人信息不丢失。对已失效的需求，例如业务场景取消、问题已由其他方式解决、长期无人跟进且无明确价值依据的，执行关闭并记录关闭原因。关闭原因要具体到类别，便于后续统计哪类需求最容易过期。
第四步：对保留项补充分级、责任人与细化信息
保留项需要补齐三样东西：分级结果、明确的责任人、足以支撑决策的细化信息，包括范围边界、验收标准和依赖说明。功能复杂的需求可拆成子项，分别关联后续的研发与测试工作。补全后，需求才具备进入评审和排期的条件。此步可与评审会结合，按批次处理，避免一次性补全所有记录造成新的积压。
第五步：设定在制品上限与清理节奏
为处于评估、细化、评审各环节的需求数量设定上限，超过上限时先处理存量再接收新增。同时固定清理节奏，例如每周一次短会处理超期项，每月一次全面盘点。上限值和节奏由团队根据实际处理能力确定，初期可设得宽松一些，运行几周后再收紧。
破坏性操作的风险边界
- 批量关闭或合并前，先导出全量数据留存备份，确认备份可读后再执行。
- 先在小范围试点，例如选一个来源渠道或一个状态段，核对结果无误后再扩大范围。
- 合并时保留主记录与原始反馈的关联，关闭时保留原因字段，确保可追溯。
- 设定停止点：一旦发现误关或合并错误，立即暂停批量操作，从备份恢复后再继续。
- 批量操作需双人确认，操作人与确认人分开，确认人核对清单与备份状态。
在工具承载上，需求池的状态维护、属性自定义和筛选定位是清理工作的基础。ONES Project 支持建立需求池并自定义需求状态与多种属性，配合多重条件筛选可快速定位超期或缺失责任人的记录；ONES 工单可用于收集各方反馈并转化为需求，自定义工作流有助于规范需求流转。对于需要拆解的需求，可用子工作项关联研发与测试任务。重复项关联与合并的具体操作方式，以及按停留时长统计的能力，需结合实际环境确认后再纳入流程。
如何验证恢复并防止再次积压
处置是否有效，用指标对比来判断，而不是凭感觉。建议在清理前记录一次基线数据，清理后按固定周期观察，连续观察四到六周，确认趋势稳定再宣布恢复。
| 验证指标 | 口径 | 恢复的判断参考 |
|---|---|---|
| 积压总量 | 各状态开启需求数之和，按周记录 | 停止增长并逐步下降，稳定在设定上限以内 |
| 平均停留时长 | 需求在当前状态的平均天数，按状态分段统计 | 超期项占比明显下降，各状态停留回到约定周期内 |
| 关闭与合并数量 | 每周关闭数、合并数及原因分布 | 清理期集中上升，之后回落到日常维护水平 |
| 状态流转率 | 每周发生状态变更的需求数占开启总数的比例 | 流转率回升并保持稳定，说明池子在流动而非沉淀 |
对比基线要使用同一口径，例如都按周末快照统计，避免因统计时点不同造成误判。若指标改善后又反弹，说明防复发机制没有落地，需要回到入口和清理节奏上检查。
复发预防机制
- 入口准入规则：明确入池必填字段，包括提出背景、使用场景、影响范围和提出人；不满足的记录进入暂存区，补全后再入池。
- 定期清理例会：每周固定时间处理超期项与无责任人项，每月全面盘点一次，会议产出为关闭、合并和补信息的处理结果。
- 状态与责任人规范：每条需求入池即指定责任人，状态定义写清楚进入和退出条件，避免状态形同虚设。
- 在制品上限：各环节设置数量上限，超限时暂停接收新增，优先消化存量。
- 指标例行查看：把积压总量和平均停留时长纳入例行查看，出现连续两周上升即触发排查。
这套机制的关键在于把清理变成固定动作，而不是积压严重时的临时运动。入口规则控制增量，状态规范保证流动，定期清理消化沉淀，指标观察提供预警，四者配合才能让需求池保持可用的状态。
常见问题
需求积压和迭代排期做不完，应该先处理哪一个？
先确认问题出在需求池还是迭代执行。需求池积压表现为池内记录越来越多、越来越旧，状态长期不流转；迭代排期问题表现为已选入迭代的工作做不完或频繁变更。两者可能同时出现，但处置动作不同：池子问题先收紧入口、清理存量；迭代问题调整容量与范围。如果池内还有大量未评估、未细化的需求，优先处理池子，否则排期决策缺少可靠输入。
清理时如何判断一条需求可以关闭？
常见可关闭情形包括：业务场景已取消、问题已由其他方式解决、长期无人跟进且缺少明确价值依据。关闭时记录具体原因类别，便于后续统计哪类需求最容易过期。对于暂时无法判断的记录，可以先标记为待确认并指定责任人，在约定周期内给出结论，避免直接关闭造成反馈信息丢失。
合并重复需求时，原始反馈信息怎么保留？
先确定一条主记录，保留完整的背景、场景和反馈来源，其余记录关联到主记录并注明合并关系，反馈人信息随关联保留。合并前导出全量数据备份，先选一个来源渠道试点，核对结果无误后再扩大范围。若发现合并错误，立即暂停批量操作，从备份恢复后再继续。
在ONES中承载需求池清理，哪些环节需要提前确认？
ONES Project 支持建立需求池并自定义需求状态与多种属性，配合多重条件筛选可定位超期或缺失责任人的记录；ONES 工单可用于收集各方反馈并转化为需求，自定义工作流有助于规范需求流转；功能复杂的需求可用子工作项拆解并关联研发与测试任务。重复项关联与合并的具体操作方式、按停留时长统计的能力，建议结合实际环境确认后再写入清理流程，避免流程设计与工具实际能力脱节。
清理后指标短暂改善又反弹，应该检查什么？
反弹通常说明防复发机制没有真正落地。先检查入口准入规则是否仍在执行，不满足必填字段的需求是否真的进入暂存区；再检查每周清理例会和每月盘点是否按节奏进行，超期项是否有人处理；最后确认在制品上限是否被突破后仍继续接收新增。指标连续两周上升即可触发一次专项排查，回到入口和清理节奏上找原因。
