制定需求提报规范，核心是把“谁在什么情况下、通过哪个入口、提交哪些信息、由谁在多久内给出受理结论”写成可执行的规则。落地顺序是：先划清需求与相邻事项的边界，再设计统一入口和提报字段，明确角色分工与受理时限，最后用示例和检查项验证规范是否可执行。下文按这一顺序给出可直接引用的范围说明、字段表、角色职责表、文档框架、示例记录和上线检查清单。
要点总览（TL;DR）
- 先划定需求提报的边界：改变产品或系统现有能力、需要进入排期评估的事项走需求提报入口，故障报修、账号开通、使用咨询走各自通道。
- 统一入口应收敛为一个，按来源或业务线在入口内分类；必填字段以“缺少该信息接口人无法判断是否受理”为标准，其余设为选填。
- 受理流程要形成闭环：提报人提交前自查，接口人在三个工作日内给出受理、补充、转通道或不予受理的结论，退回和合并都要写明原因并留痕。
- 规范文档用可判断的条件替代笼统要求，标注版本、生效日期和修订记录，通过入口页面提示和过渡期逐条说明完成宣贯。
- 上线前按入口、字段、角色、时限四类检查项核对，试运行两到四周，用提报完整率、退回率和平均受理时长观察执行效果并触发修订。
先划清需求提报的边界与适用范围
规范的第一项动作是划定边界：哪些事项必须走需求提报入口，哪些事项走其他通道。边界不清，统一入口就会混入故障报修、账号开通、日常咨询等事项，需求接口人被迫做分流，提报人也会因为“提了没人管”而绕开入口。范围说明的完成标志是：任意一名员工拿到这份说明，能判断自己手上的事项该走哪个入口。
纳入与排除事项的划分方法
划分时用两个判断维度：事项是否改变产品或系统的现有能力，以及是否需要进入排期评估。两个维度都成立的事项纳入需求提报；只涉及恢复、配置或答疑的事项走对应通道。下表给出常见事项的归属示例，组织可据此增删。
| 事项类型 | 是否走需求提报入口 | 对应去向 |
|---|---|---|
| 新增业务功能、调整现有流程规则 | 是 | 需求提报入口，进入受理与评估 |
| 系统故障、报错、性能异常 | 否 | 故障报修通道 |
| 账号权限开通、环境配置 | 否 | 服务请求通道 |
| 使用咨询、操作答疑 | 否 | 支持渠道或知识库 |
| 合规要求引发的系统改造 | 是 | 需求提报入口，标注合规来源 |
| 内部效率改进设想，尚未明确范围 | 是（可标为预研类） | 需求提报入口，受理时判定是否立项 |
按需求来源分类
来源分类决定后续的对接人和优先级参考。常见分类包括：业务方提出的业务需求、客户或外部用户反馈的需求、内部团队提出的改进需求、合规与审计驱动的需求。分类不必过细，四到五类即可覆盖多数组织；每类指定一名对接人，提报人在入口中选择来源后，系统或接口人据此分派。
适用组织范围与生效方式
范围说明要写明适用的部门、团队和系统边界，以及生效日期。若组织内已有部分团队在用的旧流程，需写明新旧流程的切换时间和过渡期处理方式。生效方式建议采用“发布即生效、设置一个月过渡期、过渡期内旧通道提交的事项由接口人代为转入”，避免切换当天出现无人受理的空档。
设计统一入口与提报字段
统一入口解决“从哪提”，字段设计解决“提什么”。两者共同的目标是让提报人一次提交完整信息，让接口人无需反复追问即可做出受理判断。入口数量应尽量收敛为一个，按来源或业务线在入口内做分类，而不是为每类需求单开一个入口。
统一入口的形式与承载位置
入口形式可选在线表单、需求管理工具中的提报页面，或两者结合：表单负责结构化采集，工具负责记录状态和流转。承载位置应满足三个条件：提报人容易找到（放在常用办公入口或工具首页）、提交后有可查询的单据编号、状态变化对提报人可见。若使用需求管理工具承载，ONES 的需求收集与工作项状态跟踪可以承担入口记录、字段留存和受理状态更新，使提报人随时看到自己的需求处于待受理、补充中还是已受理。
必填字段与选填字段的划分
必填字段的判断标准是：缺少该信息，接口人无法做出受理与否的判断。其余信息设为选填，避免表单过长导致提报人敷衍填写。下表给出字段表模板，组织可按业务调整字段名和示例。
| 字段名 | 是否必填 | 填写说明 | 示例 |
|---|---|---|---|
| 需求标题 | 必填 | 一句话说明要解决的问题，不超过30字 | 报销单支持按项目维度汇总导出 |
| 需求来源 | 必填 | 从下拉项中选择：业务方/客户/内部改进/合规 | 业务方 |
| 提出人及所属部门 | 必填 | 填写真实姓名与部门，便于回访 | 张明，财务部 |
| 现状与问题 | 必填 | 描述当前做法、遇到的困难及影响范围 | 每月手工汇总报销数据约需2人日，易出错 |
| 期望结果 | 必填 | 描述希望达到的效果，不限定实现方式 | 系统内按项目一键导出汇总表 |
| 期望时间与紧迫性理由 | 必填 | 填写期望上线时间，并说明该时间的约束来源 | 季度结账前，否则影响报表出具 |
| 影响范围 | 选填 | 涉及的用户群体、部门或系统 | 财务部及8个项目部 |
| 参考材料 | 选填 | 截图、现有表格、同类产品参考等 | 附当前汇总表模板一份 |
字段填写口径与示例
每个必填字段都要给出填写口径，说明“写什么、不写什么”。例如“期望结果”字段要求描述效果而非指定技术方案，避免提报人直接写“加一个按钮”而掩盖真实问题；“期望时间”要求附约束来源，防止所有需求都填“尽快”。口径写进表单的字段提示文字中，比写在规范文档里更有效。
附件与补充材料的要求
附件规则要明确三点：允许的格式与大小上限、哪些材料属于必需（如涉及报表的需求需附现有报表样例）、敏感数据的处理方式（如客户信息需脱敏）。附件不是必填项，但规范可约定“涉及现有流程变更的需求，应附当前流程说明”，把材料要求与需求类型挂钩。
明确角色分工与受理流程
提交之后由谁处理、多久反馈，是规范能否被信任的关键。流程设计要形成闭环：提报人提交并自查，接口人在约定时限内初筛并给出受理结论，评审角色对进入评估的需求给出意见，结论反馈给提报人并记录状态。
提报人的责任与提交前自查
提报人对信息真实性负责，提交前按三项自查：问题描述是否能让不了解背景的人看懂、期望结果是否写清、是否已确认该事项不属于故障或服务请求。自查项以勾选形式放在表单末尾，完成标志是提报人确认提交并收到单据编号。
需求接口人的初筛动作与受理时限
接口人收到需求后做初筛：判断是否属于需求范围、信息是否完整、是否与已有需求重复。建议约定三个工作日内的首次反馈时限，反馈内容至少包含“已受理待评估”“需补充信息”“转其他通道”“不予受理”四种结论之一。时限从提交时刻起算，遇节假日顺延的规则需写明。
评审角色与退回、补充、合并的处理规则
退回指信息不足或不属于需求范围，退回时须写明原因和需补充的内容，提报人补充后重新进入初筛，计时重新开始。合并指与已有需求实质相同，接口人将新需求关联到原需求并通知提报人，提报人保留关注权。评审角色由业务负责人、产品负责人和技术负责人组成，对已受理需求给出是否进入排期的意见，评审意见记录在需求单据上。
角色职责表与受理流程
| 角色 | 主要动作 | 时限 | 输出 |
|---|---|---|---|
| 提报人 | 填写字段、完成自查、提交 | 提交前 | 完整需求单据 |
| 需求接口人 | 初筛、判定范围与完整性、处理重复 | 提交后3个工作日内 | 受理结论及理由 |
| 评审角色 | 评估价值与可行性，给出排期意见 | 受理后按评审周期 | 评审意见与去向 |
| 提报人 | 补充信息、确认结论 | 收到退回后5个工作日内 | 补充后的需求单据 |
受理结论的反馈方式应与入口一致：通过工具提交的，状态变更即通知提报人；通过表单提交的，由接口人以邮件或消息回复并抄送提报人所属部门负责人。所有结论都要留痕，便于后续统计退回率和受理时长。
写一份可执行的需求提报规范文档
规则内容确定后，需要写成一份正式文档发布。文档的价值在于让未参与制定的人也能照做，因此条款要写成可判断的条件，而不是原则性表述。
文档章节结构建议
建议包含以下章节：目的与适用范围、术语定义、需求范围与排除事项、统一入口说明、提报字段与填写口径、角色职责、受理流程与时限、退回与合并规则、附则（版本、生效日期、解释部门）。字段表和角色表以附录形式附在文末，正文引用即可，避免正文过长。
条款写法：用可判断的条件替代笼统要求
对比两种写法：“提报人应认真填写需求信息”无法判断是否做到；“需求标题不超过30字，现状与问题字段需写明当前做法和影响范围，缺少任一项接口人可退回”则可以逐条核对。规范中的每个“应”字句，尽量配一个可观察的判断标准或后果说明。
版本、生效日期与修订记录
文档首页标注版本号、生效日期、制定部门和解释人。文末设修订记录表，记录每次修改的日期、版本、修改内容和修改人。修订记录的作用是让执行者知道规则何时变过，避免用旧版本要求新流程。
发布与宣贯方式
发布渠道包括内部知识库、办公系统公告和入口页面的说明链接。宣贯不必开大会，可采取三种轻量方式：在提报表单顶部放置三行填写要点、对接口人和评审角色做一次流程说明、在过渡期内对退回的需求逐条说明原因。完成标志是目标人群能在入口页面直接看到规范链接和填写要点。
示例：一条需求从提报到受理的完整记录
以下为演示情景，用于展示各字段和角色动作如何衔接，不代表真实业务数据。
示例需求的背景与提报信息
财务部张明发现每月报销数据需手工汇总，耗时约2人日且易出错，希望在季度结账前实现系统内按项目导出。他通过统一入口提交：标题“报销单支持按项目维度汇总导出”；来源选“业务方”；现状与问题写明手工汇总的做法、耗时和出错情况；期望结果写“系统内按项目一键导出汇总表”，未指定具体实现方式；期望时间填“季度结账前”，理由为报表出具时间约束；附件上传当前汇总表模板。
接口人初筛与补充沟通
接口人在第二个工作日完成初筛：确认该事项属于需求范围，字段完整，但与已有需求“报销数据导出优化”部分重叠。接口人将两条需求关联，并向张明说明合并情况，询问其导出维度是否与已有需求一致。张明补充说明需按项目维度而非部门维度，接口人据此在单据上补充说明，保留两条需求的关联关系。
受理结论与后续去向
接口人给出“已受理待评估”的结论，通知张明并记录受理时间。评审会上，评审角色确认该需求与已有导出优化需求可合并实施，给出进入下一排期周期的意见。张明在工具中看到状态从“待受理”变为“已受理”，再到“已排期”，无需反复询问进度。
示例中体现的字段填写口径
该示例体现了三条口径：期望结果描述效果而非方案，使评审能判断合并可行性；期望时间附约束来源，使紧迫性可被评估；附件提供现有材料，减少接口人追问。这三条口径可直接写入字段提示文字。
上线前的完成检查与持续维护
规范发布前，用一份检查清单逐项核对，判断其是否具备执行条件。清单按入口、字段、角色、时限四类组织，每项都应有明确的通过标准。
四类上线检查项
| 类别 | 检查项 | 通过标准 |
|---|---|---|
| 入口 | 入口是否唯一且易找到 | 目标人群能在两次点击内到达提报页面 |
| 入口 | 排除事项是否有明确去向 | 范围说明中每类排除事项都标注了对应通道 |
| 字段 | 必填字段是否都有填写说明和示例 | 表单中每个必填项都有提示文字 |
| 字段 | 字段能否支撑受理判断 | 接口人仅凭单据即可给出四种结论之一 |
| 角色 | 每个角色是否明确到岗位 | 职责表中无“相关人员”等模糊表述 |
| 角色 | 退回与合并规则是否可执行 | 退回须填原因，合并须关联原需求并通知提报人 |
| 时限 | 受理时限是否写明起算点和顺延规则 | 时限条款无歧义，节假日规则明确 |
| 时限 | 结论反馈方式是否与入口一致 | 提报人能在入口处看到状态变化 |
试运行与反馈收集
建议选择一个业务线试运行两到四周，期间记录三类问题：提报人卡在哪个字段、接口人退回的主要原因、时限是否被突破。反馈收集用简短问卷加接口人访谈即可，重点问“哪条规则最难执行”，而不是泛泛询问满意度。
规范修订的触发条件
出现以下情况时启动修订：退回率连续两个月偏高且集中在同一字段、受理时限频繁被突破、组织调整导致角色变化、入口承载工具更换。修订不必大改，可先更新字段提示文字或时限规则，再按版本记录留痕。
用提报完整率、退回率等观察执行效果
执行效果用几个可统计的指标观察：提报完整率（首次提交即满足必填要求的比例）、退回率（因信息不足被退回的比例）、平均受理时长（从提交到给出结论的时间）、合并率（与已有需求重复的比例）。这些指标按月统计，用于判断规范是否需要调整，而不是用于考核提报人。指标改善的方向应是退回率下降、受理时长稳定在约定时限内。
常见问题
需求提报规范制定后，业务方仍然绕过入口直接找产品经理提需求，怎么处理？
先判断绕行的原因，再对应处理。常见原因有三类：入口不好找、提了没有反馈、不知道自己的事项该走哪个入口。入口不好找的，把提报页面放到常用办公入口或工具首页，并在页面顶部放三行填写要点；提了没有反馈的，检查受理时限是否被突破，状态变化是否对提报人可见；分不清入口的，把范围说明中的纳入与排除事项做成对照表，附在入口页面。
对已经发生的绕行，接口人可以代为补录到统一入口，并告知提报人后续从入口提交。过渡期内逐条说明补录原因，比直接拒绝更有效。
需求提报的必填字段应该设几个，字段太多提报人不愿意填怎么办？
必填字段的数量由受理判断需要决定，不以表单完整度为目标。判断标准是：缺少该信息，接口人能否给出受理、补充、转通道或不予受理的结论。通常标题、来源、提出人、现状与问题、期望结果、期望时间六项即可支撑初筛，其余信息设为选填。
字段多导致敷衍填写时，优先压缩必填项，再为每个必填项配一句填写口径和示例，把口径写进表单提示文字。涉及现有流程变更的需求，可通过附件规则补充材料要求，不必把材料清单全部变成必填字段。
接口人三个工作日内给不出受理结论，时限规则怎么调整？
先区分是规则问题还是资源问题。若接口人同时承担其他职责、初筛工作量超出预期，可把初筛拆成两步：一个工作日内先确认收到并判断是否属于需求范围，三个工作日内给出完整结论。若需求集中提交导致积压，可在入口页面公示当前受理排队情况，让提报人对等待时间有预期。
时限调整要同步更新规范文档和修订记录，并写明新的起算点和节假日顺延规则。时限放宽后，仍应保留“超时未反馈时提报人可向接口人上级升级”的条款，避免时限形同虚设。
需求被判定为与已有需求重复而合并，提报人的诉求会不会被忽略？
合并规则要保证提报人的信息进入原需求，而不是简单关闭新单据。接口人合并时应做三件事：把新需求的补充信息（如不同的导出维度、使用场景）追加到原需求记录上，将新单据关联到原需求，并通知提报人合并去向。提报人保留对原需求的关注权，能看到后续状态变化。
若提报人认为自己的需求与原需求实质不同，可提出复核，由评审角色判断是否拆分。合并率和复核结果按月统计，用于发现字段口径或分类规则中容易造成误判的地方。
规范试运行期间，用哪些数据判断它可以正式发布？
试运行两到四周后，看三类数据：提报完整率，即首次提交即满足必填要求的比例；退回率，以及退回原因是否集中在同一两个字段；平均受理时长，是否稳定在约定时限内。退回集中在某个字段，说明该字段的填写口径或提示文字需要修改；受理时长频繁超限，说明时限规则或接口人配置需要调整。
这些数据用于判断规范是否可执行，不用于考核提报人。试运行结束时的通过标准可设为：退回原因分散、受理时长在时限内、接口人仅凭单据即可给出结论。达到标准后正式发布，并保留按月统计的做法用于后续修订。
