需求收集表和需求提报单经常被混用，但两者解决的是不同问题：需求提报单是单个需求方按固定字段提交一次具体诉求的申请单据，重点在于把这一条需求说清楚；需求收集表是面向来源广泛、格式不一的原始需求做统一归集的登记表，重点在于掌握需求从哪里来、有没有遗漏。两者都位于需求进入机制的前端，提报单是单条需求的入口载体，收集表把多条来源汇总成一份可流转清单，经评审确认后形成需求池条目。
要点总览（TL;DR）
- 需求提报单是单个需求方按固定字段提交一次具体诉求的申请单据，重点是把这一条需求说清楚；需求收集表是把来源广泛、格式不一的原始需求统一归集的登记表，重点是掌握需求从哪里来、有没有遗漏。
- 两者都位于需求进入机制的前端，典型顺序是提报单或其他来源先提交，再由收集表逐条登记，评审确认后形成需求池条目。
- 提报单偏纵向，把一个诉求讲深讲透；收集表偏横向，把多个来源摆在一起看全貌，两者字段可以重叠，但目的不同。
- 需求来源单一、量小时可以只用提报单加简单登记；来源多、渠道杂时以收集表做统一入口，提报单作为标准提交模板。
- 两者并用时要明确唯一登记口径，并保留提报单编号以便追溯，避免同一诉求在两张表里重复维护。
两者在需求进入流程中各自处在什么位置
把需求进入机制拆开看，可以分成三个连续动作：来源提交、统一登记、评审确认。需求提报单承担第一个动作，需求收集表承担第二个动作，评审之后才产生需求池条目。三者的关系可以用一条文字流程表示：
提报单或其他来源（邮件、群消息、会议记录、客服反馈）→ 收集表逐条登记 → 需求评审 → 需求池条目
在这条链路里，提报单是单条需求的提交载体，一份提报单对应一个具体诉求，由提出人填写并说明背景和期望。收集表是多来源需求的归集载体，一行记录可能来自提报单，也可能来自一次会议或一条客户反馈，登记人负责把不同格式的信息整理成可比较的条目。两者都属于“进入环节”，处理的是需求还没有被正式接纳之前的事情；需求一旦评审通过进入需求池，后续的整理、合并、优先级排序和版本规划就属于需求池管理的范畴，不再由这两张表承担。
一句话结论：提报单解决“这一条说清楚了没有”，收集表解决“所有来源都进来了没有”，需求池条目解决“接下来做不做、先做哪个”。三者是前后衔接关系，不能互相替代。
同口径差异对照：字段、粒度与使用角色
把两张表放在同一组维度下比较，差异会更清楚。需要说明的是，两者的字段可以重叠，比如都包含诉求描述和提出人，但字段设置的目的不同：提报单的字段服务于完整描述单条诉求，收集表的字段服务于横向识别和去重。
| 对照维度 | 需求提报单 | 需求收集表 |
|---|---|---|
| 填写主体 | 需求提出人，通常是业务方、客户对接人或内部使用者 | 需求登记人，通常是产品经理、需求管理员或业务接口人 |
| 记录粒度 | 一条记录对应一个具体诉求，描述要求完整 | 一条记录对应一个来源条目，允许多条并列、来源各异 |
| 字段重点 | 诉求描述、业务场景、期望时间、影响范围、提出人联系方式 | 来源渠道、登记人、登记时间、初判结论、关联提报单编号 |
| 使用频率 | 按需提交，提出人有诉求时填写一次 | 周期性维护，登记人持续补充和更新状态 |
| 产出物 | 一份可评审的申请单据 | 一份可流转、可筛选的来源清单 |
| 与需求池的衔接方式 | 作为评审输入，评审通过后转为需求池条目 | 作为归集台账，逐条推动评审，评审通过的条目进入需求池 |
从表中可以看出，提报单偏纵向，把一个诉求讲深讲透；收集表偏横向，把多个来源摆在一起看全貌。实际工作中常见的情况是：收集表里的某一行信息不足，需要回溯到对应的提报单补充细节；提报单提交后如果没有进入收集表，就容易在评审排期时被遗漏。两者配合使用，才能同时保证单条质量和整体覆盖。
常见误用：把收集表当提报单，或把提报单当需求池
两类混淆都会在需求进入环节留下问题，且后果不同。
- 用收集表直接替代提报单。登记人凭自己的理解把需求压缩成一行，提出人没有机会完整描述业务场景和期望时间。结果是评审时信息缺失，评审人无法判断价值，需求被反复退回补充，进入周期被拉长。
- 把提报单当作需求池条目。提报单一提交就被视为“已受理”，跳过了归并和评审。同一诉求被多个部门分别提报时，会形成多条重复记录；优先级也没有经过统一比较，排期时容易出现先到先得而非按价值排序。
- 收集表只登记不流转。表越记越长，状态字段长期不更新，登记人无法判断哪些条目已经评审、哪些还在等待，收集表退化成一份静态台账。
- 两张表各记一套。提报单和收集表分别维护，编号不互通，追溯时对不上，重复录入增加了登记人的负担。
需要区分边界的是：服务请求的受理归服务台和入口建设负责，已入池需求的整理、优先级排序与版本规划归需求池管理负责，本文讨论的范围限定在需求进入环节的这两张表。
如何组合使用：从提报单到收集表再到需求池
组合使用的核心是让两张表各司其职，并通过编号建立追溯关系。可以按以下步骤落地：
- 设计提报单的必填字段。至少保留诉求描述、提出人、业务场景、期望时间四项。诉求描述要求写清现状和期望的差异；业务场景说明在什么流程、什么角色身上发生；期望时间用于后续排期参考，不作为承诺。
- 在收集表中增加归集字段。除承接提报单的核心信息外，补充来源渠道、登记人、登记时间、初判结论、关联提报单编号。初判结论可以由登记人给出“待评审、需补充、重复合并”等状态，便于筛选。
- 统一登记口径。明确所有来源最终都汇入同一张收集表，提报单提交后由登记人录入或自动关联，避免两张表各自维护。
- 按评审节奏推进。收集表中的条目按周期进入评审，评审通过的转为需求池条目，未通过的标注原因并保留记录。
- 保留追溯链接。需求池条目上保留原始提报单编号或链接，后续需要了解背景、联系提出人时有据可查。
在工具层面，这套流程可以通过工单与需求池的衔接来承载。ONES 支持使用工单收集和整理来自各方的反馈，处理后将工单转化为需求并整理出产品 Backlog；同时提供统一的业务需求池、产品需求池与工单系统，把业务反馈与产品开发串联起来。工作流可以按实际场景自定义，用于规范需求从登记到评审的流转。对于需要区分业务视角和产品视角的团队，还可以通过需求池、工单与任务看板同步状态，让提出人看到自己提交的诉求当前处于登记、评审还是已排期阶段。具体表单字段和流转配置以产品实际界面为准。
适配场景与选择建议
选择哪种方式，取决于需求来源的数量和复杂度，而不是团队规模或行业属性。
- 来源单一、量小时，可以只用提报单加简单登记。例如需求主要来自内部几个固定部门，提报单本身格式统一，登记工作用一张共享表格即可完成。此时引入完整的收集表字段反而增加维护成本。
- 来源多、渠道杂时，以收集表做统一入口。客户反馈、销售转达、客服工单、内部会议都可能产生需求，格式差异大，需要一张收集表先把所有来源接住，再逐条判断。提报单作为标准提交模板，供提出人按统一格式填写，减少登记人的整理工作量。
- 两者并用时，明确唯一登记口径。约定收集表是唯一的需求台账，提报单是它的上游输入，任何来源的需求都必须落到收集表中才算进入流程。这样可以避免同一诉求在两张表里重复出现，也便于统计需求来源分布。
如果团队已经在使用工单系统承接反馈，可以把工单作为提报单的载体，把收集表作为工单汇总和初判的视图，评审通过后再转入需求池。这样既保留了单条诉求的完整记录，也保证了多来源的统一归集，追溯链路从工单编号一直延伸到需求池条目。
常见问题
需求提报单提交后，还需要再填一遍需求收集表吗？
不需要重复填写，但需要完成登记动作。常见做法是提报单提交后，由登记人把核心信息录入收集表，并记录关联的提报单编号；如果工具支持自动关联，也可以由系统把提报单信息带入收集表。这样提出人只填一次，收集表承担归集和状态跟踪的职责，追溯时通过编号回到原始提报单。
需求来源只有内部几个部门，还需要单独做收集表吗？
可以简化。来源固定、格式统一、数量不大时，提报单本身就能承担登记功能，用一张共享表格做简单汇总即可。收集表的价值主要体现在来源多、渠道杂、格式差异大的场景，此时需要一张表先把所有来源接住，再逐条判断。判断标准是来源数量和格式差异，与团队规模没有直接关系。
收集表里的条目评审没通过，应该删除还是保留？
建议保留并标注原因。未通过的条目记录了曾经提出的诉求和当时的判断依据，后续业务条件变化时可能重新被提起，保留记录可以避免重复讨论。可以在收集表中增加状态字段，区分“待评审、需补充、重复合并、暂不采纳”等情况，便于按状态筛选和定期回看。
用ONES承接这套流程时，提报单和收集表分别对应什么？
ONES 支持使用工单收集和整理来自各方的反馈，处理后将工单转化为需求并整理出产品 Backlog，同时提供统一的业务需求池、产品需求池与工单系统，把业务反馈与产品开发串联起来。在实际配置中，工单可以承载单条诉求的提交，需求池承担归集与评审后的管理；工作流可按实际场景自定义，用于规范从登记到评审的流转。具体表单字段和流转配置以产品实际界面为准。
服务请求和需求是不是走同一套表单？
通常分开处理。服务请求的受理归服务台和入口建设负责，关注的是响应时效和处理流程；需求进入机制关注的是诉求是否被完整记录、是否值得进入产品规划。两者在工具上可以共用底层能力，但在表单字段、流转规则和考核口径上建议分开设计，避免把服务响应和产品需求混在一张表里统计。
