需求池模板的填写顺序可以概括为：先保证编号唯一、描述可判断，再补齐来源与提出信息，随后按统一规则维护分类、状态、优先级、负责人和目标版本，最后处理重复项关联与更新记录。本文提供一张可直接复制到表格工具中的空白需求池表，并逐字段说明填写方式、必填规则，附一条从录入到待排期的完整示例。
要点总览（TL;DR）
- 需求池模板至少包含15个字段：编号、名称、来源、提出人、提出日期、描述、业务场景、分类、状态、优先级、负责人、目标版本、重复项关联、最近更新时间、备注，可直接复制空白表使用。
- 录入时必填八项：编号、名称、来源、提出人、提出日期、描述、状态、负责人；业务场景、分类、优先级在评审阶段补齐，目标版本在排期阶段填写。
- 填写顺序为：先保证编号唯一、名称可判断、描述写清现状与完成标志，再补来源和提出信息，最后按统一规则维护分类、状态、优先级和重复项关联。
- 选填字段留空表示暂无，不用“待定”“无”占位；必填字段缺失时需求不得进入下一环节。
- 模板长期使用要控制字段总数在15列以内，定期收敛分类与状态选项，每周检查重复项、每月清理积压，并记录模板版本变更。
可复制空白需求池模板
下面这张表是全文的主交付物，可直接复制到 Excel、飞书表格、腾讯文档等表格工具中，删除示例行后即为空白模板。字段顺序与后文字段说明、必填规则、填写示例保持一致，便于对照使用。
| 需求编号 | 需求名称 | 来源 | 提出人 | 提出日期 | 需求描述 | 业务场景 | 分类 | 状态 | 优先级 | 负责人 | 目标版本 | 重复项关联 | 最近更新时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
这张表覆盖了一条需求从提出到进入排期的基本信息。团队规模较小、需求来源单一时，可以先保留编号、名称、描述、状态、优先级、负责人六列起步；需求来源渠道多、评审环节多时，再补齐来源、提出人、目标版本等字段。字段取舍的原则在第五节展开。
每个字段填什么：字段说明与填写规范
字段填写的共同目标是让另一位同事只看这一行，就能判断这条需求是什么、谁提的、现在该谁处理。下面逐字段说明含义、填写方式和常见写法。
| 字段 | 含义 | 填写方式与常见写法 |
|---|---|---|
| 需求编号 | 需求的唯一标识 | 按固定规则生成，如“REQ-2025-001”，年份或月份加流水号；全表唯一，不复用已删除编号 |
| 需求名称 | 一句话概括需求 | 用“对象+动作+结果”写法，如“订单列表支持按支付状态筛选”，控制在20字左右，避免“优化一下”“改进体验”这类无法判断的表述 |
| 来源 | 需求从哪个渠道进入 | 使用固定选项，如客户反馈、销售、客服工单、内部运营、数据分析、竞品观察；同一渠道用同一名称 |
| 提出人 | 具体提出这条需求的人 | 写姓名或“姓名+部门”，便于后续回访确认；来自客户时写对接的销售或客服人员，客户信息放备注 |
| 提出日期 | 需求首次被记录的时间 | 统一格式如“2025-03-12”，用于计算等待时长和判断积压 |
| 需求描述 | 说明要解决什么问题 | 写清现状、期望结果和判断标准，2至5句；描述问题而非直接指定方案，方案细节留给评审 |
| 业务场景 | 需求发生的具体情境 | 写角色、操作和触发条件，如“财务在对账日导出多张订单表时，需要逐张核对”；场景越具体，评审时越容易判断价值 |
| 分类 | 需求所属的功能或业务模块 | 使用团队约定的固定分类，如订单、支付、账号、报表；分类层级控制在两级以内 |
| 状态 | 需求当前所处环节 | 使用固定状态集，如待评估、已评审、待排期、已排期、开发中、已完成、已关闭；每次变更同步更新“最近更新时间” |
| 优先级 | 相对处理顺序 | 使用有限档位，如P0至P3或高、中、低；填写时附一句理由，如“影响付费流程，P1” |
| 负责人 | 当前对这条需求负责的人 | 录入时可以是产品经理或需求对接人；进入排期后改为具体跟进人，一条需求同一时间只保留一个负责人 |
| 目标版本 | 计划交付的版本或迭代 | 评审排期后填写，如“V2.3”或“2025年4月迭代”；未排期时留空，不用“待定”占位 |
| 重复项关联 | 标记与其他需求的关系 | 填写被合并或相似需求的编号，如“与REQ-2025-007重复，已合并至本条”；保留原编号便于追溯 |
| 最近更新时间 | 本条记录最后一次修改时间 | 每次修改状态、优先级、负责人等关键字段时更新，用于识别长期无人处理的需求 |
| 备注 | 补充信息 | 记录客户原话、沟通结论、依赖条件、暂缓原因等；内容较多时写摘要并注明详细材料存放位置 |
填写时有三个容易出问题的点值得单独说明。需求名称和需求描述要分开写：名称回答“做什么”，描述回答“为什么做、做到什么程度算完成”。来源和提出人要区分：来源是渠道，提出人是具体的人，两者混填会导致后续无法回访。状态和负责人要同步维护：状态变为“已评审”时，负责人应明确到具体的人，避免需求停在“待评估”却无人推进。
必填与选填：哪些字段不能空
需求池的字段不必在录入时一次填满，但必填项缺失会让这条需求无法被判断和处理。建议按阶段区分填写要求。
| 阶段 | 必填字段 | 说明 |
|---|---|---|
| 录入时 | 需求编号、需求名称、来源、提出人、提出日期、需求描述、状态、负责人 | 这八项保证需求可识别、可追溯、有人对接；描述写不完整时至少写清现状和期望结果 |
| 评审时 | 业务场景、分类、优先级 | 评审需要判断价值和归属，场景缺失的需求退回补充后再评 |
| 排期时 | 目标版本、优先级确认 | 进入迭代前必须明确交付版本，优先级需在评审会上确认而非录入人自定 |
| 全程维护 | 最近更新时间 | 任何关键字段变更都要更新，作为积压判断依据 |
选填字段包括重复项关联、备注，以及部分团队的提出日期精确到日即可、无需精确到时刻。重复项关联只在发现重复或合并时填写，没有关联时留空，不要写“无”。备注按需填写，用于承载不适合放进描述的信息。
字段留空需要统一规则：必填字段缺失时，需求状态不得进入下一环节，例如描述为空的需求不能标记为“已评审”；选填字段留空表示“暂无”，不用“待定”“无”“/”等占位符，避免后续统计时把占位符当成有效值。团队可以在表格中设置条件格式，对必填列为空的单元格做颜色提示，减少人工检查。
完整填写示例：一条需求从录入到待排期
下面用一条演示需求说明各字段如何配合。该示例为演示情景，用于展示字段之间的对应关系。
| 字段 | 填写内容 |
|---|---|
| 需求编号 | REQ-2025-018 |
| 需求名称 | 订单列表支持按支付状态筛选 |
| 来源 | 客服工单 |
| 提出人 | 李敏（客服部） |
| 提出日期 | 2025-03-12 |
| 需求描述 | 目前客服处理退款咨询时，需要在订单列表中逐页翻找特定支付状态的订单，单次处理平均耗时较长。期望订单列表支持按支付状态筛选，筛选结果可直接导出。完成标志为：客服可按“已支付、退款中、已退款”筛选，并导出筛选后的列表。 |
| 业务场景 | 客服在退款高峰期处理用户咨询时，需要快速定位处于“退款中”的订单并核对金额，当前只能逐页浏览。 |
| 分类 | 订单 |
| 状态 | 待排期 |
| 优先级 | P1（退款咨询量大，影响客服响应时长） |
| 负责人 | 王磊（产品） |
| 目标版本 | V2.3 |
| 重复项关联 | 与REQ-2025-011相似，已合并至本条，原需求关闭 |
| 最近更新时间 | 2025-03-20 |
| 备注 | 客服提供了近一个月退款咨询记录，详细数据存放于客服部共享文档 |
这条需求的填写过程体现了几个配合关系。描述中写明了现状、期望结果和完成标志，评审时可以直接据此判断工作量；业务场景补充了触发条件，帮助评审理解为什么优先处理；状态从录入时的“待评估”变为“已评审”，再变为“待排期”，每次变化都更新了最近更新时间；目标版本在排期阶段才填写，录入时留空；重复项关联保留了原编号，说明合并关系而非直接删除。
如果这条需求在评审时被判定为暂缓，状态改为“已关闭”并在备注中写明原因，例如“V2.3资源不足，顺延至下季度评估”。保留记录而不是删除，可以在下次出现相似需求时快速查到历史判断。
模板调整与日常维护方法
模板用起来之后，需要按团队实际情况调整字段，并建立定期维护节奏，否则需求池会逐渐变成难以检索的流水账。
字段增删的取舍原则是：新增字段要能改变处理动作。如果某个字段填了之后没有人据此做判断或分配工作，就不必加。例如团队没有多版本并行，目标版本可以简化为迭代名称；需求来源只有内部团队，来源字段可以合并进提出人。反过来，当需求需要跨部门评审时，补充“评审结论”字段比增加更多描述性字段更有用。字段总数建议控制在15列以内，超出时优先合并同类信息。
分类与状态选项需要定期收敛。分类选项随产品模块变化调整，每季度检查一次是否有长期空置的分类；状态选项保持有限且有序，每个状态对应一个明确的下一步动作，例如“待评估”对应安排评审，“待排期”对应进入排期会。新增状态前先确认现有状态是否已经覆盖该环节。
重复项关联和积压清理建议按固定节奏进行。可以每周花固定时间检查新增需求中名称或描述相近的条目，发现重复时合并并保留原编号；每月检查一次超过约定天数未更新状态的需求，逐条确认是继续等待、关闭还是重新评估。清理时保留记录和关闭原因，不直接删除行。
模板版本变更需要留下记录。修改字段名称、增删字段或调整选项时，在表格的说明页或单独文档中记录变更日期、变更内容和影响范围，例如“2025年4月起新增‘评审结论’字段，历史需求该列留空”。这样后续查看旧需求时能理解字段含义的变化。
当需求数量增长、多人同时维护时，表格容易在状态同步和重复项追溯上出现偏差。ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，可将本文的字段和状态规则落到统一的工作项中；在 ONES 敏捷研发管理方案中，还可以用工单收集各方反馈并转化为需求，按实际场景自定义工作流规范需求流转，产品负责人再依据优先级将需求规划至对应迭代。工具承载的是字段和流程的管理动作，填写规范本身仍按本文的字段说明执行。
常见问题
需求池模板里的“来源”和“提出人”有什么区别，能不能只填一个？
两者记录的信息不同，建议都填。来源是需求进入的渠道，如客服工单、销售反馈、内部运营，用于统计哪类渠道贡献了多少需求；提出人是具体的人，用于后续回访确认细节。只填来源，评审时找不到人核实；只填提出人，无法按渠道做汇总分析。来自客户的需求，提出人写对接的销售或客服人员，客户信息放在备注里。
需求还没评审，优先级和目标版本怎么填？
录入阶段可以先留空。优先级在评审会上确认，录入人自定的优先级只作为参考；目标版本在排期阶段填写，未排期时保持空白。如果团队要求录入时必须有优先级，可以先用“待评估”档位占位，评审后再改为P0至P3中的具体档位，并附一句判断理由。目标版本不建议用“待定”占位，留空更便于筛选出尚未排期的需求。
发现两条需求重复，应该删除一条还是保留记录？
建议保留记录并做关联，不直接删除。做法是把其中一条作为主需求，在“重复项关联”字段写明“与REQ-2025-011相似，已合并至本条，原需求关闭”，原需求状态改为“已关闭”并注明合并原因。保留原编号的价值在于追溯：下次出现相似需求时，可以查到之前的判断依据，也避免提出人重复提交后找不到历史记录。
需求池里的需求长期没人处理，怎么清理？
先建立判断依据，再逐条处理。可以每月检查一次超过约定天数未更新状态的需求，结合“最近更新时间”和“提出日期”判断等待时长，逐条确认三种去向：继续等待并写明原因、关闭并记录关闭理由、重新评估后进入排期。清理时保留行和关闭原因，不删除记录。如果团队用工具承载需求池，可以按状态和更新时间筛选出待清理条目，减少人工翻表。
团队规模小，模板字段能不能精简？
可以。字段取舍的标准是新增字段能否改变处理动作：填了之后没有人据此做判断或分配工作，就不必保留。需求来源单一时，来源可以合并进提出人；没有多版本并行时，目标版本可以简化为迭代名称。起步阶段保留编号、名称、描述、状态、优先级、负责人六列即可运行，随着评审环节增多再逐步补充业务场景、分类、目标版本等字段。字段总数建议控制在15列以内。
