设计需求收集表，目标是让每条需求进入时具备可判断、可分流、可追踪的最小信息集。做法是先划定表格的用途边界，再按提交人信息、需求描述、业务价值、影响范围、时间期望、附件证据六层设置字段，区分必填与选填，配套提交入口、受理角色和状态流转，最后用填写示例和上线前检查表验证可用性。本文覆盖需求进入环节，服务请求受理与已入池需求的整理排序不在范围内。
要点总览（TL;DR）
- 需求收集表只承接需求进入环节，服务请求、故障报修和已入池需求的整理排序应走各自渠道，避免字段被迫兼容两类信息。
- 字段按提交人与归属、需求描述与场景、业务价值与优先级、影响范围与关联系统、时间期望与约束、附件与证据六层组织，总数控制在15至20个。
- 必填字段以是否直接影响受理决策为准，期望完成时间建议必填，并区分硬性节点与期望时间。
- 状态设置草稿、待受理、待补充、已受理、已关闭五个节点，每个状态明确下一步动作与负责人。
- 上线前用3至5名真实提交人试填，重点观察填写耗时与因信息缺失被退回的比例，并约定定期复盘机制。
需求收集表先定边界：承接什么、不承接什么
需求收集表只负责一件事：把一条需求完整、可判断地送进需求池。它记录需求从哪里来、要解决什么问题、对谁有价值、大概什么时候要，供受理人做出“受理、退回补充、转其他渠道”的判断。表格在需求被受理后即完成主要使命，后续的拆解、排期、版本规划由需求池和规划流程承担。
把服务请求和故障报修混进同一张表，是常见的设计失误。服务请求有明确的处理时限和标准动作，故障报修需要即时响应，两者的受理规则、考核口径与需求完全不同。如果共用一张表，受理人就要在大量“开通权限”“页面报错”的记录中筛选真正的需求，字段也会被迫兼容两类信息而变得臃肿。建议在入口层面就分开：需求走需求收集表，服务请求走服务台工单，故障走报修通道。
需求来源类型较多时，不必为每类来源建一张表，可以用“来源类型”字段加分区的做法。例如内部业务部门提报、客户反馈、销售转达、产品自研构想，共用同一套核心字段，再针对来源补充少量专属字段。这样既保持字段口径统一，又避免表格数量失控。下表可作为用途边界说明的模板。
| 事项 | 是否由本表承接 | 说明 |
|---|---|---|
| 新功能、功能改进、体验优化诉求 | 承接 | 填写完整字段后进入受理环节 |
| 来自客户、销售、业务部门的反馈转化 | 承接 | 通过来源类型字段区分，附原始反馈记录 |
| 账号开通、权限申请、数据导出等服务请求 | 不承接 | 走服务台工单，按服务目录受理 |
| 系统故障、页面报错 | 不承接 | 走报修通道，按故障等级响应 |
| 已入池需求的优先级调整、版本归属 | 不承接 | 在需求池内维护，不回填收集表 |
核心答案：一张需求收集表的字段结构
字段按六层组织，每层回答受理人做判断时的一个问题。层与层之间有先后关系：先知道谁提的、提的什么，再判断值不值得做、影响多大、什么时候要，最后用附件支撑上述判断。字段总数建议控制在15至20个，超出这个范围，提交人的填写负担会明显上升，反而降低信息质量。
六层字段清单
| 层级 | 字段名 | 填写要求 | 必填/选填 |
|---|---|---|---|
| 提交人与归属 | 提交人姓名与部门 | 自动带出或手动填写 | 必填 |
| 提交人与归属 | 需求来源类型 | 下拉选择：内部业务、客户、销售转达、产品构想等 | 必填 |
| 提交人与归属 | 期望对接的产品/业务线 | 下拉选择 | 必填 |
| 需求描述与场景 | 需求标题 | 一句话概括，不超过30字 | 必填 |
| 需求描述与场景 | 问题与使用场景 | 描述谁在什么情况下遇到什么问题 | 必填 |
| 需求描述与场景 | 期望的解决方式 | 提交人的初步想法，允许不完整 | 选填 |
| 业务价值与优先级 | 业务价值说明 | 影响的收入、成本、效率或合规要求 | 必填 |
| 业务价值与优先级 | 提交人建议优先级 | 高/中/低，附一句理由 | 必填 |
| 业务价值与优先级 | 影响用户或部门范围 | 涉及的人数、部门或客户数量 | 必填 |
| 影响范围与关联系统 | 关联系统或模块 | 涉及哪些现有系统、接口或数据 | 选填 |
| 影响范围与关联系统 | 是否涉及合规或安全要求 | 是/否，选“是”时补充说明 | 必填 |
| 时间期望与约束 | 期望完成时间 | 日期，说明是硬性节点还是期望 | 必填 |
| 时间期望与约束 | 时间约束原因 | 如合同约定、监管期限、活动排期 | 选填 |
| 附件与证据 | 相关截图、文档或数据 | 支持判断的原始材料 | 选填 |
| 附件与证据 | 补充说明 | 其他需要受理人知道的信息 | 选填 |
必填与选填的划分原则
判断一个字段是否必填，看它是否直接影响受理决策。缺少它，受理人无法判断需求是否成立、是否紧急、是否与其他需求重复，这类字段设为必填。仅用于丰富背景、帮助后续理解的字段设为选填，例如期望的解决方式、附件材料。必填项过多会让提交人草率填写，必填项过少则受理人频繁退回，两种结果都拖慢流程。
“期望完成时间”是容易被误设为选填的字段。缺少时间信息，受理人无法判断需求的紧迫程度，也无法在多个需求之间做排序。建议设为必填，同时明确区分“硬性节点”和“期望时间”，避免所有需求都被写成“尽快”。
从提交到受理：操作步骤与状态流转
表格嵌入流程后，每个动作都要有明确的输入、做法、输出和完成标志。下表给出从提交到受理通过的完整步骤，受理通过即视为需求进入需求池，本表流程结束。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 获取入口 | 需求线索 | 提交人通过统一入口打开表单，按来源类型选择对应分区 | 空白表单 | 表单正确加载对应分区字段 | 提交人 |
| 2. 填写与自检 | 空白表单 | 逐项填写，对照自检提示确认必填项完整、描述可读 | 已填写的表单 | 必填项无空缺，场景描述包含人物、情境、问题 | 提交人 |
| 3. 提交 | 已填写的表单 | 点击提交，系统记录提交时间与提交人 | 待受理记录 | 状态变为“待受理” | 提交人 |
| 4. 初筛 | 待受理记录 | 受理人核对字段完整性，判断是否属于需求、是否重复、信息是否足够 | 初筛结论 | 给出受理、退回补充或转其他渠道的结论 | 受理人 |
| 5. 退回补充 | 初筛结论为退回 | 在表单中注明缺失项与补充要求，退回提交人 | 补充通知 | 状态变为“待补充”，提交人收到通知 | 受理人 |
| 6. 受理通过 | 初筛结论为受理 | 补充受理备注，将需求转入需求池并指定需求负责人 | 入池需求记录 | 状态变为“已受理”，需求负责人明确 | 受理人 |
状态字段建议设置五个节点：草稿、待受理、待补充、已受理、已关闭。草稿用于提交人暂存未完成的内容；待受理是提交后的默认状态；待补充对应退回动作；已受理表示需求已进入需求池；已关闭用于处理重复提交、撤回或经判断不属于需求的情况。状态流转规则要写进表单说明，让提交人知道自己的需求现在处于哪一步、下一步由谁处理。
在工具承载层面，ONES 的工单可用于收集和整理来自各方的反馈，处理后可转化为需求并整理出产品 Backlog，并支持按实际场景自定义工作流来规范需求流转（依据 F3）。这意味着上述状态节点和退回规则可以在工单与需求池之间衔接落地，受理人不必在表格与需求池之间手工搬运信息。对于同时存在固定交付项目与持续演进产品的组织，ONES 也支持项目制与产品制并行管理（依据 F5），需求进入后的归属可以按场景选择。
角色与交付物分工
需求收集表涉及三类角色，各自的责任边界要清晰，避免出现“表填了但没人管”或“受理人替提交人补信息”的情况。提交人对信息完整度负责，受理人对判断结论负责，需求负责人对入池后的需求质量负责。
| 角色 | 职责 | 交付物 | 完成标准 |
|---|---|---|---|
| 提交人 | 按字段要求填写需求，提供场景、价值与时间信息，配合补充 | 填写完整的收集表记录 | 必填项无空缺，场景描述可被第三方理解 |
| 受理人 | 初筛需求，判断归属与完整性，执行退回或受理，指定需求负责人 | 初筛结论与受理备注 | 每条待受理记录在约定时限内给出结论 |
| 需求负责人 | 受理后补充业务细节，确认价值判断，参与后续优先级讨论 | 需求补充说明与确认记录 | 入池需求的关键信息经确认无歧义 |
受理人通常由产品经理或需求管理岗担任，需要具备判断需求归属和识别重复需求的能力。当组织内需求量大、来源分散时，可以按产品线设置多个受理人，各自负责对应分区的初筛，但初筛标准要保持一致，否则同一类需求在不同受理人手里会得到不同结论。需求负责人的指定应在受理通过时完成，避免需求入池后长期无人认领。
填写示例：一条需求如何完整填表
以下为演示情景，用于说明字段填写方式与受理判断过程，不对应真实客户案例。
背景：某零售企业的门店运营部门发现，店员在盘点时需要手工汇总多个表格，耗时较长且容易出错，运营主管希望通过系统支持简化这一过程。
| 字段 | 填写内容 |
|---|---|
| 提交人姓名与部门 | 门店运营部 王主管 |
| 需求来源类型 | 内部业务部门 |
| 期望对接的产品/业务线 | 门店管理系统 |
| 需求标题 | 盘点数据自动汇总，减少手工表格 |
| 问题与使用场景 | 每月末盘点时，店员需从三个系统导出数据，手工合并到汇总表，单店耗时约4小时，合并过程出现过数量对不上的情况 |
| 期望的解决方式 | 系统内直接生成盘点汇总结果，支持导出 |
| 业务价值说明 | 覆盖120家门店，每月可减少约480小时的汇总工作量，降低数据差错带来的返工 |
| 提交人建议优先级 | 高，理由是下季度将扩大盘点频次 |
| 影响用户或部门范围 | 120家门店的店长与店员，约600人 |
| 关联系统或模块 | 门店管理系统、库存系统、财务导出模块 |
| 是否涉及合规或安全要求 | 否 |
| 期望完成时间 | 下季度末前，属于期望时间，非合同硬性节点 |
| 时间约束原因 | 下季度盘点频次提升，手工方式压力增大 |
| 附件与证据 | 现行汇总表模板、一次盘点耗时记录截图 |
| 补充说明 | 财务侧对汇总口径有固定要求，需与其确认 |
受理人的初筛判断：该需求属于功能改进类需求，场景描述包含人物、情境和具体问题，业务价值有量化依据，影响范围明确，字段完整，予以受理。受理备注中注明两点：一是需与财务确认汇总口径，二是关联库存系统的数据接口需评估。随后指定需求负责人，状态变为“已受理”。
从这个示例可以提炼出可迁移的填写规律：场景描述要写到“谁、在什么情况下、遇到什么问题、造成什么后果”；业务价值尽量给出可核对的数字或明确的影响对象；时间期望要说明是硬性节点还是期望，并给出原因。满足这三点，受理人通常能在一轮内做出判断。
完成检查：表格上线前的核对项
表格设计完成后，用一份检查清单逐项核对，全部通过再正式启用。检查不通过的项目要回到对应章节调整，不要带着问题上线后再补。
| 检查类别 | 核对项 | 通过标准 |
|---|---|---|
| 字段完整性 | 六层字段是否齐全，必填项是否覆盖受理决策所需信息 | 受理人仅凭表单内容即可做出受理、退回或转渠道的判断 |
| 字段合理性 | 必填项数量是否适中，是否存在长期无人填写的字段 | 必填项控制在10项左右，试填时无明显卡顿 |
| 边界检查 | 是否混入服务请求、故障报修或池内整理事项 | 表单说明中明确不承接事项，并给出对应渠道指引 |
| 流程检查 | 状态节点是否覆盖提交、退回、受理、关闭，每个状态是否有明确责任人 | 任一状态下的记录都能找到下一步动作和负责人 |
| 角色检查 | 提交人、受理人、需求负责人是否均已明确，职责无重叠 | 每个环节有且仅有一个角色负责推进 |
| 试用验证 | 邀请3至5名真实提交人试填，观察填写耗时与退回率 | 试填记录中因信息缺失被退回的比例可接受，填写说明无需口头解释即可理解 |
| 调整机制 | 是否约定表格的复盘周期与修改权限 | 明确每季度或每半年复盘一次，字段调整有指定负责人 |
试用验证是判断表格是否可用的关键一步。设计者熟悉字段含义，容易高估提交人的理解程度。让不熟悉背景的同事试填，能暴露字段命名含糊、说明缺失、必填项过多等问题。试填后收集两类反馈：哪些字段不知道该怎么填，哪些字段觉得没必要填。前者补充填写说明或调整字段表述，后者考虑改为选填或删除。表格上线后保持定期复盘，随着需求来源和业务变化调整字段，避免表格逐渐与实际判断需求脱节。
常见问题
需求收集表的必填项控制在多少比较合适？
正文建议必填项控制在10项左右，字段总数15至20个。判断标准是受理人能否仅凭表单内容做出受理、退回或转渠道的结论：缺少后无法判断需求是否成立、是否紧急、是否重复的字段设为必填，仅用于丰富背景的设为选填。必填过多会让提交人草率填写，必填过少则受理人频繁退回，两种情况都会拖慢流程。试填阶段可以观察退回率，据此微调必填范围。
提交人写不清需求场景时，受理人应该退回还是代为补充？
建议退回补充，并在表单中注明缺失项与补充要求，状态改为“待补充”。场景描述是判断需求是否成立的核心依据，受理人代为补充容易带入自己的理解，后续难以追溯原始诉求。退回时给出具体的补充提示，例如要求写明“谁、在什么情况下、遇到什么问题、造成什么后果”，能减少反复退回的次数。若提交人确实无法描述清楚，可由需求负责人在受理后与其当面确认，再回填记录。
需求来源很多时，是建多张表还是用一张表加字段区分？
优先用一张表加“来源类型”字段，再按来源设置分区或补充少量专属字段。多张表会让字段口径分散，同一类需求在不同表里的填写标准不一致，汇总和比较都变困难。分区方式可以保持核心字段统一，同时让客户反馈类需求附带原始记录、销售转达类需求附带客户信息。只有当某类来源的受理规则、考核口径与需求完全不同时，才考虑单独建表。
表格上线后，字段需要多久复盘一次？
正文建议每季度或每半年复盘一次，并指定字段调整的负责人。复盘时重点看两类信号：一是长期无人填写的字段，考虑改为选填或删除；二是退回记录中反复出现的缺失项，考虑补充填写说明或调整为必填。业务来源和判断标准变化较快时，复盘周期可以缩短。复盘结论要同步给提交人，避免表格改了但填写习惯没跟上。
用工具承载需求收集表时，需要关注哪些衔接点？
重点看三个衔接点：提交入口能否按来源类型分发到对应表单；状态节点能否覆盖待受理、待补充、已受理等环节并支持退回；受理通过后能否直接转入需求池并指定负责人，避免手工搬运。ONES 的工单可用于收集和整理来自各方的反馈，处理后可转化为需求并整理出产品 Backlog，并支持按实际场景自定义工作流来规范需求流转（依据 F3）。具体表单字段的自定义与校验能力，建议在选型时结合实际场景确认。
