需求提报人提交需求时，需要写清三组信息：业务背景、需求内容和验收信息。背景说明谁在什么场景下遇到什么问题、当前怎么处理、影响多大，回答“为什么值得做”；需求内容说明期望达成什么结果、范围到哪里；验收信息说明用什么结果或数据判断需求已完成、由谁确认，回答“做到什么程度算完成”。背景与验收信息缺一，需求进入评审后就容易反复澄清，交付后也容易在验收环节产生分歧。下面按字段清单、写法、流程、角色分工、完整示例和检查清单依次展开。
要点总览（TL;DR）
- 需求提报人需要写清三组信息：业务背景（谁在什么场景下遇到什么问题、当前怎么处理、影响多大）、需求内容（期望达成什么结果、范围到哪里）、验收信息（用什么结果或数据判断需求已完成、由谁确认）。
- 背景信息建议按业务场景与角色、现状做法与痛点、影响范围与频次、期望结果与范围边界四组字段填写，让评审方判断需求为什么值得做。
- 验收条件写成可观察的结果或数据，区分功能验收与业务效果验收，验收人写到岗位并明确确认方式；无法量化时给出可核对的替代依据。
- 提报与受理按“提交前自查—提交—受理初审—退回补充或进入评审—评审通过后进入需求池”推进，每步明确输入、动作、输出和完成标志。
- 提交前用检查清单逐项核对，阻断项缺失即退回，非阻断项可在初审意见中提示补充。
提报时先写清哪几项背景信息
背景信息的作用是让没有参与一线业务的评审方，在几分钟内理解问题的来龙去脉，并判断这件事是否值得投入。建议按四组字段填写，每组都落到具体的人、动作和数字上。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 业务场景与角色 | 写明哪个岗位、在哪个业务环节、执行什么动作时遇到问题 | 区域销售助理在每月初汇总各门店回款时，需要手工从三个表格中核对数据 |
| 现状做法与痛点 | 描述目前怎么处理、耗时多少、容易出什么错、代价是什么 | 目前用Excel手工比对，单次约4小时，上月出现两笔回款漏记，导致对账返工 |
| 影响范围与频次 | 涉及哪些岗位和人数、多久发生一次、影响多少业务量 | 涉及6名销售助理和2名财务人员，每月发生一次，覆盖约300家门店 |
| 期望结果与不做什么 | 写清希望达到的状态，同时明确本次不涉及的范围 | 希望回款数据自动汇总并与门店台账核对；本次不涉及发票开具和税务申报 |
填写时有三个常见问题值得注意。第一，场景写到部门层级就停住，例如只写“财务部对账效率低”，评审方无法判断问题出在哪个环节。第二，痛点只写感受不写代价，“很麻烦”“很不方便”无法支撑优先级判断，换成耗时、差错次数、返工工时更有说服力。第三，范围只写做什么、不写不做什么，评审时容易把相邻诉求一并塞进来，导致需求边界不断扩张。
影响范围与频次这一项，数据不确定时可以给区间并注明来源，例如“每月约200至300笔，依据上季度台账估算”，比留空或写“很多”更便于评审。期望结果应描述业务上要达成的状态，避免直接写成某个功能，例如写“回款数据能按门店自动汇总”，而不是写“增加一个导出按钮”，后者属于解决方案层面的讨论。
验收信息怎么写才可判断
验收信息回答的是“凭什么说这件事做完了”。可判断的验收条件具备两个特征：有明确的观察对象，有明确的通过标准。写成“操作更便捷”“体验更好”“效率明显提升”，任何人都可以给出不同解读，验收时只能靠反复沟通收场。
验收条件建议写成“在什么条件下，执行什么操作或经过多长时间，观察到什么结果”。同时区分两类验收：功能验收关注功能是否按约定可用，通常在提测或上线前判定；业务效果验收关注上线后业务指标是否改善，需要经过一段观察期。两类验收的判定时点和责任人不同，提报时应分别写明。
| 类型 | 模糊写法 | 可判断写法 |
|---|---|---|
| 功能验收 | 回款汇总功能好用 | 选择指定月份和门店范围后，系统在1分钟内生成汇总结果，金额与财务台账逐条一致；异常数据有明确提示 |
| 业务效果验收 | 对账效率提升 | 上线后连续两个月，月度回款汇总的人工耗时从4小时降至1小时以内，漏记笔数为0 |
验收人应写到岗位而非泛称，例如“财务共享中心对账岗确认金额准确性，销售运营负责人确认流程可用”，并写明确认方式：在需求工作项中确认、在验收会议上确认，或以书面意见回复。确认方式写清楚，验收环节就不会出现“我以为已经通过了”的情况。
确实无法量化时，可以给出可核对的替代依据：明确的业务规则（例如“按合同约定的账期计算逾期”）、可复现的操作路径（例如“从订单列表进入详情页，三步内完成状态变更”），或相关方的书面确认。替代依据同样要写清由谁核对、核对什么，避免退回到主观描述。
从提报到受理的操作步骤
提报与受理是一条连续链路，每一步都有明确的输入、动作、输出和完成标志。按下面的顺序推进，可以减少来回补充的次数。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交前自查 | 已填写的背景与验收草稿 | 对照检查清单逐项核对，补齐缺失字段 | 完整的提报内容 | 阻断项全部满足 |
| 2. 提交 | 完整提报内容 | 在需求入口填写必填项并提交 | 一条待受理的需求记录 | 系统生成需求编号，状态为待受理 |
| 3. 受理初审 | 待受理需求 | 受理人检查背景、范围、验收条件是否齐全可判断 | 初审意见 | 给出“通过初审”或“退回补充”的明确结论 |
| 4. 退回补充 | 初审意见 | 提报人按意见补充信息后重新提交 | 更新后的需求记录 | 补充内容回应了全部退回意见 |
| 5. 进入评审 | 通过初审的需求 | 业务负责人确认优先级与验收口径，参与评审 | 评审结论 | 评审记录中写明通过、暂缓或否决 |
| 6. 进入需求池 | 评审通过的需求 | 受理人将需求纳入需求池并标注状态 | 需求池中的待规划需求 | 状态由待受理变为已入池 |
退回补充应有明确规则，避免变成无限循环。可以约定：退回意见必须逐条对应具体字段，说明缺什么、补到什么程度；同一需求退回不超过两轮，两轮后仍不满足的，由业务负责人协调补充或判定暂不受理。这样既保证信息质量，也让提报人知道改进方向。
在工具层面，这类流转可以依托需求工作项承载。ONES 支持通过工单收集和整理来自各方的反馈，处理工单并快速转化为需求，整理出产品 Backlog，并可根据实际场景自定义工作流，促进需求规范化流转。提报信息填写在需求工作项中，受理、退回与入池对应状态变化，评审通过后的需求与后续研发、测试任务串联，业务团队可跟踪处理进度。具体字段结构和状态配置需按团队实际情况设置。
角色分工与各自交付物
提报信息之所以经常不完整，往往不是提报人不愿意写，而是没人说清每一段由谁负责。把三个角色的职责和交付物定下来，交接时点也就清楚了。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 提报人 | 提供业务场景、现状痛点、影响范围、期望结果与范围边界，给出初步验收条件 | 填写完整的需求提报，含背景四组字段与验收条件草案 | 提交前完成自查，提交后响应退回意见 |
| 业务负责人 | 确认需求优先级，确认验收口径与验收人，对范围边界背书 | 优先级结论、确认后的验收条件、验收人名单 | 评审前完成确认，评审会上给出结论 |
| 受理人 | 检查提报完整性，判断验收条件是否可核对，执行退回或放行 | 初审意见、需求池入池记录 | 收到需求后完成初审，评审通过后完成入池 |
三个角色的交接有两个关键时点。一是提交前的自查，提报人对信息完整性负第一责任，不能把补全工作留给受理人。二是评审前的确认，业务负责人需要在评审会上带着明确的优先级和验收口径出现，否则评审容易变成现场讨论背景，效率很低。受理人的职责是判断信息是否达到受理标准，业务判断仍由业务负责人作出。
一个完整提报示例
以下为演示情景，用于说明填写方式，不代表真实业务数据。
背景段落：区域销售助理在每月初汇总各门店回款时，需要从订单系统、银行流水和门店台账三个来源手工核对数据。目前用Excel逐条比对，单次约4小时，上月出现两笔回款漏记，导致对账返工约半天。该工作涉及6名销售助理和2名财务人员，每月发生一次，覆盖约300家门店。期望回款数据能按门店自动汇总并与台账核对，减少手工比对和漏记；本次范围不涉及发票开具、税务申报和账龄分析。
验收条件：功能验收方面，选择指定月份和门店范围后，系统在1分钟内生成汇总结果，金额与财务台账逐条一致，异常数据有明确提示，由财务共享中心对账岗在工作项中确认。业务效果验收方面，上线后连续两个月，月度回款汇总人工耗时降至1小时以内，漏记笔数为0，由销售运营负责人确认。
受理人检查过程：受理人先看背景四组字段是否齐全，确认场景、痛点、影响范围和范围边界都有具体描述；再看验收条件是否可核对，确认功能验收有观察对象和通过标准、业务效果验收有指标和观察期、验收人写到岗位；最后检查范围边界是否排除了相邻诉求。三项均满足，初审通过，进入评审；评审中业务负责人确认优先级为高，验收口径无调整，需求入池。
提交前的完成检查
提交前用下面这份清单逐项核对，可以显著减少退回次数。清单由提报人自查，受理人在初审时按同一份清单复核。
| 类别 | 检查项 | 是否阻断 |
|---|---|---|
| 背景 | 写明了具体岗位、业务环节和触发动作 | 是 |
| 背景 | 写明了现状做法及其代价（耗时、差错、返工等） | 是 |
| 背景 | 写明了影响范围与发生频次，数据不确定时注明估算依据 | 否 |
| 背景 | 写明了期望结果，并列出本次不做的范围 | 是 |
| 验收 | 功能验收有观察对象和通过标准 | 是 |
| 验收 | 涉及业务效果时，写明指标、观察期和判定时点 | 否 |
| 验收 | 验收人写到岗位，确认方式明确 | 是 |
| 验收 | 无法量化处给出了可核对的替代依据 | 否 |
阻断项缺失即退回，非阻断项缺失可在初审意见中提示补充。检查时点为提交前由提报人自查，提交后由受理人在初审时复核。把这份清单固定为提报入口的必填提示，团队对“什么样的提报算合格”就有了共同标准，评审和验收也能围绕同一套信息展开。
常见问题
提报人无法量化业务效果时，验收信息怎么写才不流于主观？
无法量化时，可以给出可核对的替代依据，例如明确的业务规则（如“按合同约定的账期计算逾期”）、可复现的操作路径（如“从订单列表进入详情页，三步内完成状态变更”），或相关方的书面确认。替代依据同样要写清由谁核对、核对什么，避免退回到“体验更好”这类主观描述。
需求被退回补充后，提报人应该怎么处理才能避免反复退回？
退回意见应逐条对应具体字段，说明缺什么、补到什么程度。提报人按意见逐条补充后重新提交，确保补充内容回应了全部退回意见。团队可以约定同一需求退回不超过两轮，两轮后仍不满足的，由业务负责人协调补充或判定暂不受理，避免无限循环。
业务负责人和受理人在验收口径确认上分别承担什么责任？
业务负责人负责确认验收口径与验收人，对范围边界背书，并在评审会上给出明确的优先级和验收结论。受理人负责检查提报完整性、判断验收条件是否可核对，执行退回或放行。业务判断由业务负责人作出，受理人聚焦信息是否达到受理标准。
提报信息在ONES中如何承载和流转？
ONES 支持通过工单收集和整理来自各方的反馈，处理工单并快速转化为需求，整理出产品 Backlog，并可根据实际场景自定义工作流，促进需求规范化流转。提报信息填写在需求工作项中，受理、退回与入池对应状态变化，评审通过后的需求可与后续研发、测试任务串联，业务团队可跟踪处理进度。具体字段结构和状态配置需按团队实际情况设置。
