需求提报规范要解决的是需求从提出到被受理这一段的质量问题：谁在什么情况下提、填哪些字段、走哪个入口、由谁在多长时间内给出受理结论。本文给出可直接套用的文档骨架、字段表、角色分工和检查清单，范围到需求被受理入池为止，服务请求受理与需求池内的排序拆分不在本文展开。在ONES中，需求提报可以承载为需求管理工作项，通过字段配置和状态流转落实本文的规则。
要点总览（TL;DR）
- 需求提报规范要写清四件事：谁在什么情况下提、填哪些字段、走哪个入口、由谁在多长时间内给出受理结论。
- 先用判定表划清边界：改变产品功能、业务规则、工具形态的事项走需求提报，账号开通、故障报修等一次性事务走服务台，已入池需求的排序拆分归需求池管理。
- 字段设计以“受理人无需追问即可判断”为标准，现状与问题、期望结果、影响范围为必填，期望时间标注为参考而非承诺。
- 受理环节要写明受理、退回补充、转服务台三种结论及各自时限和责任人，退回时注明缺什么、补什么，避免提报单在入口处悬置。
- 规范发布后通过退回率和补充次数做运行检查，据此修订字段与填写指引，形成迭代闭环。
先划边界：哪些事项走需求提报
需求提报规范的第一页应当写清适用范围。判断标准是这件事改变的对象：改变产品功能、业务规则、内部工具形态的，属于需求类事项，走需求提报；解决一次性事务的，属于服务请求，走服务台入口。边界不清会让需求入口被大量事务性工单淹没，受理人难以识别真正的产品改进信号。
需求提报规范覆盖的典型对象包括：产品功能改进与新增、业务规则调整（如审批条件、计算口径）、内部工具或报表的新增与改造、影响多个岗位的流程变更。服务请求则包括账号开通与权限申请、故障报修、设备领用、数据导出等一次性事务，这类事项有明确的完成标准，处理完即结束，不进入需求池。
还有一类事项容易混入：已经受理入池的需求，后续的整理、排序、拆分和排期属于需求池管理的工作，不在提报规范范围内。提报规范只保证需求以合格的状态进入受理环节，入池之后由另一套机制接管。
落地时可以把下面的判定表放在规范开头，供提报人自查：
| 事项类型 | 判断问句 | 走哪个入口 |
|---|---|---|
| 产品功能改进或新增 | 这件事是否改变产品本身的能力？ | 需求提报 |
| 业务规则调整 | 调整后是否长期影响一类业务的处理方式？ | 需求提报 |
| 内部工具、报表新增或改造 | 是否需要开发或配置投入才能完成？ | 需求提报 |
| 账号开通、权限申请 | 是否按既有规则执行一次即可完成？ | 服务台 |
| 故障报修、设备领用 | 是否属于恢复或满足一次性事务？ | 服务台 |
| 已入池需求的排序与拆分 | 该需求是否已被受理？ | 需求池管理 |
判定表的作用是让提报人在提交前完成一次自检，减少受理人反复转办的工作量。规范中应写明：走错入口的事项由受理人转交对应渠道，并在原提报单上留下转办记录。
核心答案与操作步骤：规范怎么写、怎么跑
一份可执行的需求提报规范，内容由五部分组成：入口方案、字段集、受理与分级规则、补充与退回规则、发布与切换安排。下面按编写顺序给出每一步的输入、动作、输出和完成标志，编写者可以据此逐项推进。
第一步：盘点现有渠道，确定统一入口
输入是当前所有需求提报渠道的清单，包括邮件、群聊、口头转达、各类表单和已有系统。动作是逐个记录渠道的使用者、提报量和典型内容，识别重复与遗漏。输出是一份入口方案，明确唯一主入口的形式：结构化表单、系统中的需求工作项类型，或指定的接收人与接收邮箱。完成标志是所有现存渠道都能在方案中找到归宿——关闭、跳转或保留为辅助说明。
第二步：设计必填字段集
输入是过往需求提报中反复出现的沟通问题，例如信息不全、描述模糊、无法判断影响面。动作是据此确定字段清单和填写要求，至少覆盖提报人、业务场景、问题描述、期望结果、影响范围、期望时间和关联对象。输出是字段表（下一节给出完整版本）。完成标志是每个字段都能回答“缺了它受理人会卡在哪一步”，没有用途的字段不进必填。
第三步：定义受理与分级规则
输入是受理人的岗位设置和团队对响应速度的约定。动作是写明谁负责受理、在几个工作日内给出结论，以及分级依据——通常按影响范围、紧急程度和业务价值划分。输出是受理规则条款，包含受理、退回补充、转服务台三种结论及各自的触发条件。完成标志是每条规则都能对应到一个具体责任人和一个时限。
第四步：规定补充与退回的处理方式
退回不是终点。规范应写明：退回时须注明缺什么、补什么；提报人在约定时间内补充后，需求回到受理队列；超时未补充的提报单如何处置（如标记为关闭并说明原因）。这一步的输出是退回与补充的处理条款，完成标志是任何一张提报单都不会在入口处无限期悬置。
第五步：发布规范并切换旧渠道
输入是前四步形成的完整文档。动作是确定生效日期，同步旧渠道的关闭或跳转方式，并对提报人和受理人各做一次简短说明。输出是发布通知与生效日期。完成标志是生效日之后新提交的需求全部从主入口进入，旧渠道不再产生新的提报。
必填字段怎么设计：一张提报字段表
字段设计的目标是让受理人在不追问的情况下做出受理判断。字段过多会降低提报意愿，过少则无法分级。下表给出可直接复用的字段集，团队可按业务复杂度增减选填项。
| 字段名 | 是否必填 | 填写要求 | 用途 |
|---|---|---|---|
| 提报人 | 必填 | 真实姓名与所属部门 | 后续补充信息的联系人 |
| 提报日期 | 必填 | 系统自动记录 | 计算受理时效 |
| 需求类型 | 必填 | 从预设选项中选择，如功能新增、规则调整、工具改造 | 分流与统计 |
| 业务场景 | 必填 | 说明在什么业务环节、哪类角色遇到该问题 | 需求池归类与后续方案设计 |
| 现状与问题 | 必填 | 用业务语言描述当前做法和具体困难，给出发生频率或案例 | 判断问题真实性 |
| 期望结果 | 必填 | 描述希望达到的业务效果，而非指定技术方案 | 判断需求价值与可行方向 |
| 影响范围 | 必填 | 涉及哪些部门、岗位或流程环节，影响人数或单据量 | 分级的主要依据 |
| 期望时间 | 选填 | 标注为参考时间，说明时间约束的来源（如监管节点、业务旺季） | 辅助排期参考，不构成承诺 |
| 关联系统或流程 | 选填 | 填写涉及的系统名称、流程编号或相关需求编号 | 识别重复需求与依赖关系 |
| 附件 | 选填 | 截图、现有表单样例、数据说明 | 辅助理解现状 |
填写要求里有两条需要单独强调。其一，现状与期望必须用业务语言，写清“谁在什么环节、现在怎么做、卡在哪里”，只写“优化一下”“不好用”的提报单应被退回。其二，期望时间标注为参考而非承诺，避免提报人把填写的时间当成交付日期，也避免受理人因时间字段产生不必要的压力。
字段用途决定了它在流程中的位置：影响范围直接进入分级判断，业务场景进入需求池的归类维度，关联对象用于查重。规范中应说明这些字段在受理后被谁读取、用于什么决策，让提报人理解填写的意义。
角色与交付物：谁提、谁收、谁定
需求提报链条上有四个角色。规范必须为每个角色写明职责、时限和交付物，否则入口会出现“有人提、无人收”的空档。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提报人 | 按字段表完整提交，在约定时间内配合补充信息 | 合格的需求提报单 |
| 需求受理人（产品经理或需求管理员） | 在规定时限内完成受理判断，给出受理、退回或转服务台的结论 | 受理结论与分级结果 |
| 业务负责人 | 确认需求背后的业务优先级与影响范围 | 优先级意见 |
| 需求池管理员 | 接收已受理需求，纳入池内管理 | 入池记录 |
受理人是整个链条的关键节点。规范应明确受理时限，例如三个工作日内给出结论，并说明超时未处理的提报单如何升级。业务负责人的优先级意见用于受理后的排序参考，不替代受理人的受理判断。需求池管理员的入池记录应包含受理结论、分级结果和业务负责人意见，形成可追溯的交接凭证。
小团队中同一人可能兼任受理人与需求池管理员，甚至兼任提报人。角色合并可以接受，但受理结论仍须在提报单上留痕，写明判断依据和时间。留痕的作用是在后续复盘时能回答“这条需求当时为什么被受理或被退回”。
在ONES中，这套分工可以落到需求管理工作项上：提报人通过工作项表单提交，受理人通过状态流转给出受理结论，字段与状态变更自动留痕，业务负责人的优先级意见可作为字段记录在同一工作项中，减少线下传递。
示例：一条需求从提报到受理的完整走法
以下为演示情景，用于说明规范各环节如何衔接。某业务部门的合同专员提出：“合同审批流程希望支持按金额自动分流。”
提报环节：提报人从主入口提交，需求类型选择“规则调整”，业务场景填写“合同审批，合同专员与部门负责人”，现状与问题写明“目前所有合同不分金额走同一审批链，小额合同也要经过三级审批，每月约两百份合同中有六成是五十万以下”，期望结果写明“按金额区间配置审批层级，小额合同减少审批节点”，影响范围填写“合同专员、部门负责人、法务，涉及全部合同审批”，期望时间标注“下季度预算审批前”，并附上现行审批流程图。
受理环节：受理人在两个工作日内读取提报单，判断属于需求类事项，依据影响范围定为中优先级，给出受理结论并注明“与现有合同系统改造需求可能重叠，受理后由需求池查重”。若提报单缺少影响范围，受理人退回并注明需补充的内容，提报人补充后重新进入队列。
交接环节：受理后的需求连同受理结论、分级结果和业务负责人意见进入需求池，由需求池管理员登记入池记录，后续的排序与拆分由需求池管理接管。
这个例子体现的规律是：字段完整度直接决定受理速度。影响范围和现状描述齐全的提报单，受理人一次阅读即可判断；缺字段的提报单要经历退回与补充，周期被拉长。
完成检查：规范是否真的可执行
规范发布前做一轮静态检查，发布后做一轮运行检查。检查项、通过标准和责任人对比如下：
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 入口检查 | 只有一个主入口，旧渠道已关闭或设置跳转说明 | 规范编写者 |
| 字段检查 | 必填字段均能被提报人理解并填写，无长期空置字段 | 需求受理人 |
| 时限检查 | 受理结论的时限已写明，且对应到具体责任人 | 规范编写者 |
| 边界检查 | 服务请求与已入池需求整理已明确排除在流程外 | 需求受理人 |
| 运行检查 | 试运行后统计退回率与平均补充次数，据此调整字段设计 | 需求池管理员 |
运行检查是判断规范是否可执行的关键。试运行一段时间后，统计退回率和补充次数：退回率过高，说明字段要求与提报人的表达能力不匹配，需要简化字段或增加填写示例；补充次数集中在某几个字段，说明这些字段的填写说明不够清楚。检查结果应反馈到字段表和填写指引的修订中，形成规范的迭代闭环。
边界检查容易被忽略。规范发布后，服务台入口和需求池管理若没有同步说明，提报人仍可能把事务性请求提交到需求入口。发布时应同时更新相邻流程的说明文档，让两个入口的边界在提报人一侧也清晰可见。
常见问题
需求提报规范发布后，旧渠道怎么处理才不会出现两套入口并行？
发布规范时同步确定生效日期，并对每个旧渠道给出明确归宿：关闭、跳转到主入口，或保留为辅助说明渠道。生效日之后，旧渠道不再产生新的提报，这一点需要在发布通知中写清。若旧渠道仍有使用者，可在原渠道设置自动回复或跳转提示，引导提报人从主入口提交。切换期内可由受理人对走错渠道的提报做一次转办并留痕，作为过渡手段，不作为长期做法。
提报人坚持填写期望时间，并把它当作交付承诺，受理人怎么处理？
规范中应把期望时间定义为参考信息，填写要求里说明时间约束的来源，例如监管节点、业务旺季或预算审批周期。受理人在受理结论中可引用该时间作为排期参考，同时说明排期需经需求池排序后确定。若提报人把期望时间理解为承诺，受理人可在退回或受理回复中重申字段定义，并引导其补充时间约束的业务背景，让时间信息回到辅助判断的位置。
小团队里提报人、受理人、需求池管理员由同一人兼任，规范还有必要写角色分工吗？
有必要，但可以简化。角色合并时，规范的重点从“谁做”转向“留下什么记录”。受理结论、分级结果、退回原因和补充记录仍需在提报单上留痕，写明判断依据和时间。留痕的价值在于后续复盘时能回答这条需求当时为什么被受理或被退回，也便于角色增加或人员变动时交接。小团队可以把角色对照表压缩为一段说明，保留交付物和留痕要求即可。
试运行后发现退回率很高，应该先改字段还是先改填写指引？
先看退回原因集中在哪。若退回集中在某几个字段，通常是填写说明不够清楚，优先补充填写示例和反例，例如把“优化一下”这类描述列为不合格示例。若退回分散在多个字段，说明必填项整体偏多或要求超出提报人的表达能力，应考虑减少必填字段、把部分字段改为选填，或由受理人在沟通中补齐。调整后继续统计退回率和平均补充次数，观察是否下降，再决定是否进入下一轮修订。
服务请求被误提到需求入口，受理人应该直接关闭还是转办？
建议转办而非直接关闭。受理人判断属于服务请求后，将提报转交服务台入口，并在原提报单上留下转办记录，注明转办理由和目标渠道。直接关闭会让提报人重复提交，也丢失了误提报的统计信息。转办记录积累一段时间后，可用于判断是否需要加强入口处的引导说明，例如在需求提报表单顶部增加服务请求的跳转提示。
