需求池分类要围绕“谁看、按什么决策”来定维度，常用组合是需求类型、来源、业务域、状态和优先级档位，每个需求落在唯一的主分类上，辅助标签按需多选。维护则靠固定节奏和明确角色：统一入口收集、定期评审去重合并、状态按规则流转、过期需求定期清理，并保留变更记录。本文给出可直接套用的分类字段表、状态流转规则、维护操作清单和完成检查表，适合正在建立或整理需求池的产品与研发团队参考。
要点总览（TL;DR）
- 分类维度从“谁看、按什么决策”倒推，常用组合是需求类型、来源、业务域、状态和优先级档位，维度总数控制在五到七个。
- 每个需求只落在一个主分类上，来源、涉及端等作为可多选的辅助标签，避免同一需求被重复统计。
- 状态集合建议控制在六个以内，每个状态写明进入条件、责任人和下一步；需求进入迭代后移交迭代管理，池内只保留状态和关联。
- 维护靠固定节奏：统一入口收集、每周评审去重合并、按触发条件调整优先级、定期清理过期与搁置需求，并保留变更记录。
- 用字段完整性、主分类唯一性、状态一致性、评审节奏和清理结果五项做月度检查，不通过项指定责任人和整改期限。
需求池分类先定哪几个维度
分类维度从使用场景倒推：谁在看需求池、看完要做什么决策。产品经理排优先级时需要区分需求类型和业务域；研发评估工作量时需要知道来源和影响范围；管理层看整体投入时需要按状态和优先级档位统计。维度选得准，需求池才是一张能支撑决策的表，而不是一堆标签的堆叠。
常用维度可以归纳为五类。需求类型回答“这是什么性质的需求”，如新功能、功能优化、缺陷修复、体验改进、合规要求；来源回答“谁提出的”，如客户、销售、内部运营、技术支持、管理层；业务域回答“影响哪个模块或业务线”，如订单、支付、账号、报表；状态回答“当前处理到哪一步”；优先级档位回答“相对重要程度”，用P0/P1/P2/P3或高/中/低这类有限档位，具体评分方法归需求优先级评估主题，本文只使用档位结果。
维度取舍遵循两条原则。第一，主分类唯一：每个需求必须且只能落在一个主分类上，通常选需求类型或业务域作为主分类，保证统计口径不重复。第二，辅助标签可多选：来源、涉及端、关联客户等作为标签补充，用于筛选和检索，不参与主口径统计。维度总数控制在五到七个，超过这个范围，填写负担上升，字段空置和随意填写的情况会明显增多。
常见的过度分类问题有三类：一是把每个业务细节都做成独立字段，导致字段几十个、实际只有几个被稳定填写；二是同一含义设置多个字段，比如“来源”和“提出方”并存，统计时口径打架；三是把临时性信息做成固定维度，比如某个活动名称，活动结束后字段就废弃。判断一个维度是否保留，可以问：未来半年是否会用它筛选或统计？答案是否定，就先不做成字段。
下表是一份可直接采用的分类字段表，团队可按实际情况增删取值，但建议保持字段数量和必填规则稳定。
| 字段名 | 取值示例 | 必填 | 维护人 |
|---|---|---|---|
| 需求标题 | 一句话描述需求目标 | 是 | 提出人 |
| 需求类型（主分类） | 新功能 / 功能优化 / 缺陷修复 / 体验改进 / 合规要求 | 是 | 需求负责人 |
| 来源 | 客户 / 销售 / 内部运营 / 技术支持 / 管理层 | 是 | 提出人 |
| 业务域 | 订单 / 支付 / 账号 / 报表 / 其他 | 是 | 需求负责人 |
| 状态 | 待评估 / 已确认 / 排期中 / 已交付 / 已关闭 / 搁置 | 是 | 需求负责人 |
| 优先级档位 | P0 / P1 / P2 / P3 | 是（评审后填写） | 需求负责人 |
| 提出人 | 姓名或部门 | 是 | 提出人 |
| 需求负责人 | 产品经理姓名 | 是 | 评审时指定 |
| 关联客户/工单 | 客户名称、工单编号 | 否 | 提出人 |
| 目标版本或时间期望 | 版本号或期望上线时间 | 否 | 需求负责人 |
需求从进池到关闭的状态流转规则
状态是需求池的动态分类，规则写清楚，需求才不会长期停在“待评估”里无人推进。建议状态集合控制在六个以内：待评估、已确认、排期中、已交付、已关闭、搁置。状态过多会让填写人难以判断，状态过少则无法反映真实进度。
每个状态都要写明进入条件、退出条件和责任人。进入条件回答“满足什么才能改成这个状态”，退出条件回答“什么情况下必须离开这个状态”，责任人回答“谁有权改”。下表给出了一套参考规则。
| 状态 | 进入条件 | 责任人 | 下一步 |
|---|---|---|---|
| 待评估 | 需求已登记，必填字段完整，尚未评审 | 需求负责人 | 进入定期评审，判定确认、合并或关闭 |
| 已确认 | 评审通过，需求价值与范围明确，信息可支撑排期 | 需求负责人 | 等待排期，或补充信息后重新评审 |
| 排期中 | 已确定目标迭代或版本，进入排期计划 | 需求负责人与开发代表 | 进入迭代后移交迭代管理 |
| 已交付 | 对应功能已上线或已交付使用方 | 需求负责人 | 确认验收结果，归档 |
| 已关闭 | 评审判定不做、重复合并或已失效 | 需求负责人 | 保留记录，不再跟踪 |
| 搁置 | 有价值但当前资源或条件不具备，暂不推进 | 需求负责人 | 设定复查时间，到期重新评估 |
状态修改权限要收敛。提出人可以修改自己提交需求的描述信息，状态变更由需求负责人执行；评审小组在评审会上可以集体决定确认、关闭或搁置；开发代表在排期环节确认排期中状态。每次状态变更都应记录变更时间、变更人和原因，便于回溯。
需求池与迭代排期要有明确边界。需求进入“排期中”并确定目标迭代后，具体的任务拆分、进度跟踪和验收归迭代管理，需求池只保留状态和关联链接，不在池内重复跟踪开发进度。这样需求池保持“候选与决策”的定位，迭代看板承担“执行”的定位，两边职责不重叠。
需求池日常维护的操作步骤
维护不是一次性整理，而是按节奏重复执行的一组动作。建议以周为最小节奏、以月为复盘周期，每个动作都明确输入、动作、输出和完成标志，避免“有空就整理”导致需求池长期失修。
第一步：统一入口收集与登记。输入是各方反馈、工单、会议记录和客户沟通信息；动作是提出人通过统一渠道提交，填写标题、类型、来源、业务域、提出人等必填字段；输出是一条字段完整的需求记录；完成标志是必填字段无空缺、需求负责人已指定。入口分散是需求池混乱的首要原因，销售群、客服系统、口头沟通各提一遍，同一件事会重复进池。
第二步：定期评审。输入是本周新增和状态为待评估的需求；动作是评审小组逐条检查，识别重复需求并合并、补充缺失信息、判定状态和优先级档位；输出是更新后的需求记录和评审纪要；完成标志是待评估队列清空或每条都有明确结论。评审频率建议每周一次，单次控制在半小时到一小时，需求量大时可分批。
第三步：优先级档位调整。触发条件包括客户影响范围变化、合规时限临近、依赖的技术条件具备或失效、上级目标调整。调整由需求负责人提出，评审会确认，调整时记录原档位、新档位和调整原因。没有触发条件就不频繁改动，避免优先级天天变、排期无法稳定。
第四步：过期与搁置需求清理。对超过约定时间（例如三个月）没有状态变化、且无人跟进的需求，评审时逐条判断：仍然有效的重新确认并设定复查时间，失效的直接关闭并注明原因。搁置需求设定复查日期，到期自动回到评审队列。清理动作要保留记录，关闭不等于删除。
第五步：变更留痕。每次修改字段、状态或优先级，记录谁在何时改了什么、为什么改。变更记录是后续复盘和争议处理的依据，也是判断需求池是否被认真维护的直接证据。
这些动作落到工具上时，需要工作项能承载自定义字段、状态和变更记录。ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，团队可以把上面的字段表和状态集合配置到需求工作项中；来自各方的反馈可通过 ONES 工单收集整理，处理后再转化为需求进入池内；状态流转也可按团队规则自定义工作流。这样分类字段、状态规则和评审记录集中在一处，减少表格与沟通工具之间的来回同步。
角色分工与各环节交付物
需求池维护涉及四类角色，每个角色在收集、评审、流转、清理四个环节中承担不同职责，产出不同交付物。角色不清，评审会容易变成讨论会，清理动作也无人执行。
| 角色 | 收集环节 | 评审环节 | 流转环节 | 清理环节 |
|---|---|---|---|---|
| 需求提出人 | 提交需求，填写必填字段，提供背景信息 | 按需到场说明需求背景 | 接收状态变更通知 | 确认需求是否仍然有效 |
| 需求负责人（产品经理） | 审核登记信息完整性，指定负责人 | 组织评审，判定去重合并、状态与优先级 | 执行状态变更，维护字段 | 提出关闭或搁置建议，记录原因 |
| 评审小组 | — | 集体决策确认、关闭、搁置与优先级档位 | — | 复核清理名单 |
| 开发代表 | — | 评估技术可行性与工作量量级 | 确认排期中状态，移交迭代管理 | — |
评审会议的参与人建议固定为需求负责人、开发代表，必要时邀请提出人和业务方。决策方式采用当场结论制：每条需求在会议上给出确认、合并、搁置或关闭中的一个结论，无法当场决策的指定跟进人和截止时间，避免悬而未决。会议输出评审纪要，记录结论和变更，作为需求池变更记录的补充。
各环节的交付物要可查：收集环节是字段完整的需求记录，评审环节是评审纪要与更新后的需求状态，流转环节是状态变更记录，清理环节是关闭或搁置清单及原因。交付物固定下来，需求池的维护质量才有可核对的依据。
一个需求池分类与维护的示例
以下为演示情景，用于说明字段填写和一次评审的处理过程，不代表真实项目数据。
某团队收到三条反馈：客户A希望订单列表支持按金额排序；销售B转达同一客户对订单排序的需求；运营C提出报表导出速度慢。按字段表登记后，第一条记录为：标题“订单列表支持按金额排序”，类型“功能优化”，来源“客户”，业务域“订单”，状态“待评估”，优先级暂空，提出人客户成功同事，关联客户A。第二条记录标题“订单排序功能”，类型“功能优化”，来源“销售”，业务域“订单”，状态“待评估”。第三条记录标题“报表导出提速”，类型“体验改进”，来源“内部运营”，业务域“报表”，状态“待评估”。
周评审会上，评审小组发现第一条和第二条指向同一功能，判定合并：保留第一条为主记录，第二条关闭并注明“与需求#101重复，已合并”，关联客户信息补充到主记录。第三条经开发代表评估，确认导出慢与数据量增长有关，判定为“已确认”，优先级定为P1，需求负责人补充目标版本。另有一条三个月未更新的旧需求“个人中心头像框样式调整”，提出人已离职、业务方确认不再需要，评审判定关闭，原因记为“需求失效”。
变更记录体现为：需求#101状态由待评估改为已确认，优先级由空改为P1，修改人为需求负责人，时间为评审当日，备注“评审会确认，补充目标版本”；需求#102状态改为已关闭，备注“重复合并至#101”；旧需求状态改为已关闭，备注“业务方确认失效”。一次评审完成去重、状态推进和过期清理三类动作，需求池条目减少、信息更完整，后续排期可以直接使用。
维护机制是否到位的完成检查
需求池维护是否到位，可以用一张检查表逐项核对。建议每月执行一次，由需求负责人组织，评审小组抽查。
| 检查项 | 通过标准 | 不通过时的整改方向 |
|---|---|---|
| 字段完整性 | 抽查需求中必填字段无空缺，比例达到约定要求（如95%以上） | 在提交入口增加必填校验，评审时补录缺失字段 |
| 主分类唯一性 | 每条需求只有一个主分类，统计口径无重复计数 | 清理多选主分类字段，明确唯一主分类规则 |
| 状态与实际一致 | 抽查需求的状态与实际情况相符，已上线需求不停留在排期中 | 要求需求负责人在交付后及时更新状态，评审会核对 |
| 评审节奏执行 | 按约定频率召开评审，待评估队列无长期积压 | 固定评审时间，控制单次评审需求量，分批处理 |
| 记录完整性 | 状态、优先级变更均有变更人和原因记录 | 将变更记录设为评审必查项，缺失的补录 |
| 过期需求清理 | 超过约定时间无变化的需求已逐条处理，关闭或搁置均有原因 | 每月生成长期未更新清单，评审会上逐条判定 |
检查结果建议形成简短记录，列出不通过项、责任人和整改期限，下次检查时复核。连续两次检查通过的团队，可以适当放宽检查频率，把精力放回需求评估和排期本身。需求池的价值在于让决策有据可依，分类字段、状态规则和维护节奏三者稳定运行，需求池才能持续支撑产品规划。
常见问题
需求池的字段是不是越多越好？怎么判断一个维度该不该保留？
字段多不等于管得细。判断一个维度是否保留，可以问两个问题：未来半年团队是否会用它筛选或统计？填写人能否稳定给出取值？两个答案都是肯定，才值得做成固定字段。字段数量建议控制在五到七个，超出后空置和随意填写会明显增多。临时性信息（比如某次活动名称）不要做成固定维度，活动结束后字段就废弃，反而增加维护负担。
需求提出人很多、入口分散，怎么保证需求都进同一个池？
先统一提交渠道，再规定登记必填字段。销售群、客服系统、口头沟通各提一遍，同一件事就会重复进池。可以让提出人通过统一入口提交，填写标题、类型、来源、业务域和提出人；需求负责人审核信息完整性并指定负责人。来自客户或外部反馈较多时，可先用工单渠道收集，处理后再转化为需求进入池内，ONES 工单与需求工作项可以承担这一衔接。
需求进入迭代后，需求池里还要继续更新进度吗？
不需要在池内重复跟踪。需求确定目标迭代、状态改为“排期中”后，任务拆分、进度跟踪和验收归迭代管理，需求池只保留状态和关联链接。这样需求池保持“候选与决策”的定位，迭代看板承担“执行”的定位。如果两边都维护进度，状态会不一致，评审时难以判断需求真实进展。
搁置的需求和关闭的需求有什么区别，分别怎么处理？
关闭表示评审判定不做、重复合并或已失效，保留记录但不再跟踪；搁置表示需求有价值、当前资源或条件不具备，需要设定复查日期，到期自动回到评审队列重新评估。两者都要写明原因和操作人。清理时关闭不等于删除，历史记录是后续复盘和争议处理的依据。
评审会开成讨论会、当场定不下来，怎么改？
把决策方式改成当场结论制：每条需求在会议上给出确认、合并、搁置或关闭中的一个结论；确实无法当场决策的，指定跟进人和截止时间，下次评审先处理。参与人固定为需求负责人和开发代表，必要时邀请提出人说明背景。会议输出评审纪要，记录结论和变更，作为需求池变更记录的补充。单次评审控制在半小时到一小时，需求量大时分批处理。
