制定需求提报规范，核心是把“谁在什么情况下、通过什么入口、填哪些字段、交给谁判断”写成一份可执行的规则。本文只覆盖需求进入环节，依次给出范围清单、入口与字段表、分级评审规则、一份完整示例和上线后的检查清单，服务请求受理与已入池需求的整理不在本文展开。
要点总览（TL;DR）
- 先划定提报范围：用纳入、不纳入、待定三类清单区分需求、服务请求、缺陷和已入池事项，并写明与需求池管理、服务台受理的衔接。
- 入口以单一表单为主，例外通道只解决补录时点；最小必填字段控制在业务背景、目标用户、期望结果、紧急程度、提出人五项，其余选填或受理后补充。
- 受理侧设受理人、评审组、提出人三类角色，按影响范围、紧急程度、实现复杂度分三档，分别设定响应时限与评审方式，并写明退回与补充规则。
- 发布前用一两个真实需求走通提报、受理、分级、退回全流程，确认字段可填、角色到位、时限可执行。
- 上线后每周抽样核对字段完整率、首次响应时限和退回原因，按失效信号调整规则，并保留版本与变更记录。
规范先定边界：哪些事项走需求提报
需求提报规范的第一页应当回答“什么该提、什么不该提”。边界不清，入口再统一也会被各类事项挤满，受理人每天在做分诊而不是判断需求价值。划定边界的做法是先定义需求，再用清单把相邻事项排除出去。
可以把需求定义为：对产品或系统提出的、需要评估后可能改变功能、流程或体验的诉求。按这个口径，以下三类相邻事项需要单独区分：
- 服务请求：账号开通、权限申请、设备领用、故障报修等已有标准处理流程的事项，走服务台受理，不进入需求提报。
- 缺陷：现有功能未按预期工作，走缺陷流程，由测试或研发按缺陷规则处理。
- 已入池事项：已经进入需求池、正在排序或规划中的需求，后续变更走需求池管理的变更记录，不重复提报。
范围清单建议写成“纳入、不纳入、待定”三栏，每栏配一个判定示例，让提报人自己能对照判断。待定栏尤其重要，它承接那些一时说不清性质的事项，由受理人判断后再归类，避免提报人因为拿不准而放弃提报或强行归类。
| 类别 | 判定口径 | 示例 | 去向 |
|---|---|---|---|
| 纳入 | 可能改变功能、流程或体验的诉求 | 希望订单列表支持按客户分组查看 | 需求提报入口 |
| 不纳入 | 已有标准流程的服务事项 | 为新同事开通后台账号 | 服务台 |
| 不纳入 | 现有功能未按预期工作 | 导出按钮点击后无响应 | 缺陷流程 |
| 待定 | 性质不清或跨类事项 | 报表加载慢，希望优化并增加筛选条件 | 受理人判断后归类 |
清单末尾应写明衔接关系：服务请求由服务台受理，已入池需求的整理与排序由需求池管理承接，需求提报规范只约束“进入”这一环。这样三份规则各管一段，提报人遇到不同事项时知道该找哪个入口。
统一入口与提报字段怎么设计
入口收敛的目标是让所有需求从同一个地方进来，便于统计、分派和追溯。原则是单一入口为主、例外通道为辅：日常需求一律走统一表单；口头提出、会议中临时提出的需求，由提出人或对接人当天补录到同一入口，避免出现“只在聊天记录里存在”的需求。例外通道只解决录入时点问题，不改变入口的唯一性。
字段设计的关键是控制必填项数量。必填字段越多，提报人越容易敷衍填写或绕开表单。建议最小必填集控制在五项，其余作为选填或受理后补充：
| 字段 | 必填/选填 | 填写说明 | 对应评审判断 |
|---|---|---|---|
| 业务背景 | 必填 | 当前做法是什么、带来什么具体问题，一两句话说清场景 | 判断需求是否真实存在、影响范围多大 |
| 目标用户 | 必填 | 哪些角色、大约多少人受影响 | 判断受益面与优先级 |
| 期望结果 | 必填 | 希望达成什么效果，描述结果而非指定实现方案 | 判断价值与可行方向 |
| 紧急程度 | 必填 | 按规范给定的档位选择，并说明时间约束来源 | 判断响应时限与是否走加急通道 |
| 提出人 | 必填 | 姓名与所属团队，便于补充信息 | 确定沟通对象与责任归属 |
| 期望上线时间 | 选填 | 有明确业务节点时填写 | 辅助排期判断 |
| 参考资料 | 选填 | 截图、数据、相关文档 | 减少来回澄清 |
| 影响范围与频次 | 受理后补充 | 由受理人与提出人共同确认 | 用于分级与排序 |
选填字段和受理后补充字段要写明“由谁在什么时点补齐”。例如影响范围由受理人在初次沟通时确认，技术可行性由研发在评审时评估。字段与评审判断一一对应，评审人看表单就知道该关注哪几项，而不是拿到一段自由描述后重新问一遍。
入口和字段落到工具上时，需要表单、状态和分派机制配合。ONES 可通过工单收集和整理来自各方的反馈，处理后将工单转化为需求并整理出产品待办列表，并支持按实际场景自定义工作流，让提报、受理、评审各状态按规范流转；统一的业务需求池、产品需求池与工单系统也能把业务反馈与产品开发衔接起来。具体字段类型与状态配置需结合团队实际使用的版本确认。
分级评审与受理角色分工
需求进入后，规范要回答三个问题：谁来接、按什么分级、多久给答复。角色上建议设三类：受理人负责首次判断与分派，评审组负责对进入评审的需求做价值与可行性判断，提出人负责补充信息并确认理解一致。小团队可以由一人兼任受理人与评审组成员，但职责要分开写清。
分级维度不宜过多，建议用影响范围、紧急程度、实现复杂度三个维度组合成三档：
| 级别 | 判定特征 | 响应时限 | 评审方式 |
|---|---|---|---|
| 紧急 | 影响核心业务运行或有明确外部时间节点 | 1个工作日内响应 | 受理人当日上报，评审组临时评审 |
| 常规 | 影响部分角色效率，无硬性时间约束 | 3个工作日内响应 | 进入周期性需求评审会 |
| 观察 | 诉求合理但影响面小或时机不成熟 | 5个工作日内响应 | 记录入池，定期回看 |
时限设定要留出可执行的空间：响应时限指受理人给出“已受理、需补充、退回、转其他流程”四类结论之一的时间，不等于给出排期。评审时限指进入评审后给出结论的时间。两个时限分开写，避免提报人把“已受理”误认为“会做”。
退回规则同样要写进规范。退回只针对信息不足或不属于需求范围两种情况，退回时必须写明缺什么、由谁补、补完后回到哪个状态。提出人补充信息后，需求回到待受理状态重新计时，而不是在原时限上顺延。对于反复补充仍无法说清价值的需求，由受理人标记为观察并记录原因，避免无限往返。
在工具承载上，ONES 支持产品负责人按优先级将待办列表中的需求规划至对应迭代，并在迭代计划会议中与团队共同评审；对于功能复杂的需求，可用子工作项拆解并关联研发与测试任务，把需求、研发、测试环节串联起来。业务团队也能跟踪需求与缺陷的处理进度，便于提出人了解自己提报事项的状态。
完整示例：一份提报规范如何落地
以下为演示情景，用于说明规范从提报到受理的完整路径，不代表真实案例。某内部系统团队按上述规则发布提报规范，统一入口为需求提报表单，受理人为产品经理，评审组由产品、研发负责人组成。
提报内容：客服团队提出，处理退款时需要逐单打开三个页面核对信息，高峰期每人每天多花约一小时，希望在一个页面内完成核对。
按字段填写后的表单样例：
- 业务背景：退款核对需在订单、支付、售后三个页面之间切换，高峰期单量大，核对耗时明显。
- 目标用户：客服退款组，约12人。
- 期望结果：在一个页面内看到退款所需的订单、支付与售后信息，减少页面切换。
- 紧急程度：常规，无外部时间节点。
- 提出人：客服组主管，客服团队。
- 期望上线时间：选填，未填。
- 参考资料：选填，附一张当前操作路径截图。
受理判断与分级结果：受理人在第二个工作日完成首次判断，确认属于需求范围，信息基本完整，定为常规级，转入周期性评审。评审组判断影响面集中在客服退款组，价值明确、实现路径清晰，同意进入需求池等待排期。影响范围与频次由受理人与提出人沟通后补充为“每日约200单”。
处理路径：需求进入产品待办列表，由产品负责人按优先级规划至后续迭代，评审在迭代计划会议中完成。若该需求在受理时缺少目标用户或期望结果，受理人应退回并注明补充项，提出人补齐后重新进入待受理状态。整个过程中，提出人可在统一入口查看状态变化，不需要另行询问进度。
发布后的完成检查与迭代
规范发布前先做一轮检查，确认文档能被执行，而不是只被阅读。检查项建议包括：必填字段是否都能在表单中填写并校验；三类角色是否都已指定到人；响应与评审时限是否与团队实际会议节奏匹配；退回与补充的路径是否闭环；范围清单中的每个示例是否能对应到明确去向。
上线初期建议做抽样检查：每周抽取一定数量的提报记录，核对必填字段完整率、首次响应是否在时限内、退回原因是否写明、待定事项是否已归类。抽样不必追求大样本，重点是发现规则与实际操作之间的偏差，例如某个字段大家普遍填不出、某档时限总是超期。
常见失效信号及对应调整动作：
- 大量需求从聊天工具直接进入研发，说明入口不够方便或例外通道没有补录要求，应简化表单或明确补录责任。
- 必填字段普遍填写笼统，说明字段说明不够具体，应补充正反示例。
- 退回率持续偏高，说明提报指引不足或字段过多，应精简必填项并前置填写说明。
- 响应时限长期超期，说明受理人负载或时限设定不合理，应调整分派方式或时限档位。
规范本身要有版本号和变更记录，记录每次调整的日期、调整内容、原因和生效范围。调整前用一两个真实需求试跑新规则，确认可执行后再全量发布。规范只约束需求进入环节，服务请求受理与需求池整理分别由对应规则承接，三者之间的衔接处在每次迭代时一并核对，避免出现同一事项被两个入口重复受理。
常见问题
需求提报规范和服务台受理、需求池管理之间怎么划清界限？
三份规则各管一段：需求提报规范只约束“进入”环节，即什么事项走需求入口、填哪些字段、由谁首次判断。服务请求（账号开通、权限申请、故障报修等已有标准流程的事项）由服务台受理；已经进入需求池的需求，后续排序、变更和整理由需求池管理承接，不重复提报。规范里应写明这三者的衔接关系，并在范围清单的“去向”一栏直接标出对应入口，让提报人自己能对照判断。
团队规模小，受理人和评审组成员由同一人兼任，规范还需要分开写角色吗？
需要分开写职责，即使由同一人兼任。受理人的职责是首次判断、分派和给出四类结论（已受理、需补充、退回、转其他流程）；评审组的职责是对进入评审的需求做价值与可行性判断。两者时限也不同：响应时限不等于评审时限。把职责和时限分开写，团队扩大或人员变动时可以直接交接，不会因为“一个人全包”导致规则模糊。
退回后提出人补充信息，响应时限怎么计算？
建议在规范中写明：提出人补充信息后，需求回到待受理状态重新计时，不在原时限上顺延。退回时必须写明缺什么、由谁补、补完后回到哪个状态。对于反复补充仍无法说清价值的需求，由受理人标记为观察并记录原因，避免无限往返。这样时限对双方都是可预期的。
规范发布后，怎么判断它是否真的在被执行？
上线初期做小样本抽样即可：每周抽取一定数量的提报记录，核对必填字段完整率、首次响应是否在时限内、退回原因是否写明、待定事项是否已归类。重点不是追求大样本，而是发现规则与操作之间的偏差，例如某个字段大家普遍填不出、某档时限总是超期。发现偏差后按失效信号对应的调整动作修改规则，并用一两个真实需求试跑新规则后再全量发布。
用工具承载提报入口和流转时，需要关注哪些配置点？
主要关注三处：表单字段是否与规范中的必填、选填、受理后补充字段一一对应；状态流转是否覆盖提报、受理、评审、退回补充等环节；分派规则是否能把新提报自动交给受理人。ONES 可通过工单收集和整理来自各方的反馈，处理后将工单转化为需求并整理出产品待办列表，并支持按实际场景自定义工作流，让提报、受理、评审各状态按规范流转。具体字段类型与状态配置需结合团队实际使用的版本确认。
