制定需求工具应用规范，核心是把“需求在工具里怎么走”写成可执行、可检查的约定。建议按“对象与字段—五环节操作—角色职责—示例验证—发布前检查”的顺序推进，并在试点团队运行一轮后修订发布。规范最终要落到工具的工作项配置上，ONES 的需求池、自定义状态与属性、多层级权限可以作为承载方式，具体配置以实际版本为准。
要点总览（TL;DR）
- 规范的核心骨架是需求对象模型：先定需求类型与层级、状态流转、必填字段和编号规则，再写操作步骤。
- 执行层按录入、评审、排期、变更、关闭五个环节展开，每步写清输入、动作、输出和可核验的完成标志。
- 角色职责按交接点划分，需求提出人、需求负责人、评审组、开发负责人、测试人员各自有交付物，权限遵循最小必要原则。
- 用一条演示需求走完全流程，验证规则是否冲突或缺失，再按发布前检查清单逐项核对。
- 规范先在试点团队运行一轮，修订后发布并约定复审周期；工具承载时把类型、状态、字段和权限映射到工作项配置。
规范先定哪几件事：需求对象、状态与字段
规范的第一部分要回答“需求在工具里是什么”。如果对象类型、状态和字段没有先定下来，后面的操作步骤和角色分工就会各自解释，评审时也缺少共同依据。建议先产出一张需求对象与字段定义表，作为整份规范的骨架。
需求类型划分与层级关系
先列出团队实际会录入工具的需求类型，并说明它们之间的关系。常见划分包括业务需求、用户故事、缺陷和变更请求。类型不宜过多，能覆盖来源、颗粒度和处理路径的差异即可。层级上要写清父子关系：业务需求可以拆成若干用户故事，用户故事下挂开发任务和测试用例；缺陷和变更请求可以关联到原需求，但不作为原需求的子项改变其验收口径。
类型划分确定后，为每类需求指定默认负责人角色和默认状态集。例如业务需求由产品负责人接收，用户故事由需求负责人跟进，缺陷由测试或值班人员登记。这样录入人不需要每次询问“这条该找谁”。
状态流转定义
状态要覆盖从提出到关闭的完整路径，并逐条列出允许的跳转。一个可用的最小状态集是：待评审、已评审、已排期、开发中、待验收、已关闭，另设“已拒绝”和“已挂起”两个旁路状态。规范中要写明每个状态的含义、进入条件和允许的下一状态，特别要避免出现没有出口的孤立状态。
跳转规则要写具体。例如“待评审”只能由评审通过进入“已评审”，评审否决进入“已拒绝”；“开发中”回到“已评审”表示需求内容发生实质变化，需要重新确认。状态回退是否允许、由谁操作，也要在表中注明。
必填字段清单
必填字段以“能支撑评审和追溯”为下限，不必把所有想收集的信息都设为必填。建议的最小必填集包括：标题、描述、优先级、来源、验收标准、负责人。选填字段可以包括目标版本、关联需求、预估工作量、截止日期等，由团队按需启用。
每个字段要写清填写要求和示例。标题采用“对象+动作+结果”的短句；描述说明背景、问题和期望；验收标准写成可判断是否满足的条目；来源记录提出人、渠道或关联的客户反馈。字段定义表建议包含字段名、是否必填、填写人、填写时机和校验规则五列。
编号与命名规则
编号用于检索和跨文档引用，规则要稳定且不依赖人工记忆。可以采用“项目前缀-类型缩写-流水号”的形式，由工具自动生成，规范中只约定前缀和类型缩写。命名规则针对标题，约定长度范围、避免使用的模糊词（如“优化一下”“看看”），并要求同一需求下的子项标题带统一前缀，便于按父项聚合查看。
| 需求类型 | 层级关系 | 必填字段 | 命名规则 |
|---|---|---|---|
| 业务需求 | 顶层，可拆分用户故事 | 标题、描述、优先级、来源、验收标准、负责人 | 项目前缀-BR-流水号；标题含业务对象与目标 |
| 用户故事 | 业务需求子项，下挂任务 | 标题、描述、优先级、验收标准、负责人 | 项目前缀-US-流水号；标题采用“角色+动作+价值” |
| 缺陷 | 关联需求或独立登记 | 标题、复现描述、严重程度、来源、负责人 | 项目前缀-BG-流水号；标题含现象与影响范围 |
| 变更请求 | 关联原需求 | 标题、变更内容、变更原因、影响范围、负责人 | 项目前缀-CR-流水号；标题注明原需求编号 |
按环节写操作步骤：录入、评审、排期、变更、关闭
对象和字段确定后，规范进入执行层。每个环节都要写清输入、动作、输出和完成标志，完成标志是判断这一步是否结束的客观依据，避免“已经沟通过了”这类无法核验的描述。以下五环节清单可以直接作为规范正文的操作章节。
录入：谁提、填什么、提交后去哪
输入是需求线索或原始诉求，动作是提出人按必填字段创建需求单并选择类型，输出是一条处于“待评审”状态的需求记录。完成标志是必填字段齐全、编号已生成、负责人已指定。规范要写明提出人可以是业务方、产品人员或测试人员，但每条需求必须有且只有一名需求负责人，负责后续补充信息和推动评审。
评审：评审人、依据与结论处理
输入是待评审需求单，动作是评审组按约定周期集中评审，依据包括业务价值、与当前目标的一致性、验收标准是否可判断、工作量是否可接受。输出是评审记录和结论：通过则进入“已评审”，否决则进入“已拒绝”并写明原因，需要补充信息则退回“待评审”并指定补充人和期限。完成标志是评审结论已记录在需求单上，且每条被否决的需求都有可查的原因。
排期与拆分：进入迭代或版本
输入是已评审需求，动作是需求负责人与开发负责人共同确认优先级，将需求规划到迭代或版本，必要时拆分为用户故事和任务并建立关联。输出是带目标迭代、负责人和工作量估算的需求及其子项。完成标志是需求已出现在某个迭代或版本的范围内，子项与原需求的关联关系完整，且没有未分配负责人的子项。
变更：内容或优先级变化怎么处理
输入是变更请求或开发过程中发现的需求调整，动作是提出人记录变更内容、原因和影响范围，由需求负责人判断是否影响验收标准或排期。影响验收标准或范围的，回到评审环节再确认；仅调整优先级或排期的，由需求负责人和开发负责人确认后更新记录。输出是变更记录和更新后的需求单。完成标志是变更前后内容可对比，再评审结论已记录，受影响的迭代范围已同步调整。
关闭与归档：完成判定与证据
输入是待验收需求，动作是需求负责人组织验收，按验收标准逐条核对，测试人员提供测试结论，必要时附上截图、日志或验收记录。输出是验收结论和关闭后的需求记录。完成标志是验收标准全部有结论、验收证据已关联到需求单、需求状态变为“已关闭”。未通过验收的需求退回“开发中”并记录未通过项，不直接关闭。
角色与交付物：谁在什么节点负责什么
流程步骤写完后，要把每一步落到具体角色上。职责划分的原则是每个交接点都有明确的交出方、接收方和交付物，避免出现“大家都觉得对方在跟”的悬空状态。下表可作为角色职责与交付物对照表的初稿。
| 角色 | 主要职责 | 关键交接点 | 交付物 |
|---|---|---|---|
| 需求提出人 | 提供背景与原始诉求，配合补充信息 | 录入完成移交需求负责人 | 需求单（含来源与描述） |
| 需求负责人 | 维护需求内容与优先级，推动评审、排期和验收 | 评审前、排期前、验收前 | 完整需求单、验收结论 |
| 评审组 | 按依据给出通过、否决或补充结论 | 评审会结束 | 评审记录与结论 |
| 开发负责人 | 确认工作量、拆分任务、反馈变更影响 | 排期确认、变更评估 | 任务拆分结果、变更影响说明 |
| 测试人员 | 依据验收标准验证并给出测试结论 | 验收前 | 测试结论与证据 |
权限设置遵循最小必要原则，并在规范中逐项写明：谁能创建需求、谁能修改必填字段、谁能变更状态、谁能关闭需求。通常需求负责人可以修改内容字段和推进状态，评审组可以给出评审结论，关闭权限归需求负责人并需附验收证据。权限要按项目角色分配，人员变动时通过调整角色完成交接，避免逐条改权限。
例外路径要单独成条。超期未评审的需求，由需求负责人升级至产品负责人，约定新的评审时限；跨团队需求由主责团队的需求负责人牵头，关联团队指定接口人参与评审；紧急插入需求允许先进入开发，但须在约定时限内补评审并记录原因。每条例外都要写明触发条件、处置人和时限，否则规范在真实场景中容易被绕过。
示例：一条需求在工具中的完整流转
以下为演示情景，用于说明规范如何被执行，不代表真实项目数据。假设某团队收到一条来自客服的诉求：希望订单列表支持按支付状态筛选。
提出与填写。客服人员作为提出人创建业务需求，标题为“订单列表支持按支付状态筛选”，描述中写明当前客服核对订单需逐条打开、平均耗时较长，来源填写“客服反馈-工单编号”，优先级暂定中，验收标准写成三条：列表页出现支付状态筛选条件；筛选结果与订单实际状态一致；无结果时显示空状态提示。需求负责人指定为产品经理，需求进入“待评审”。
评审与排期。评审组在周度评审会上确认该需求与当前版本目标一致，验收标准可判断，结论为通过，需求进入“已评审”。产品经理与开发负责人确认工作量后，将需求规划到下一迭代，拆分为“筛选组件开发”“接口参数支持”“联调与测试”三个任务并关联到原需求，各任务分配负责人，需求进入“已排期”。
开发中的变更。开发过程中发现支付状态字段存在历史数据口径不一致，产品经理提交变更请求，记录变更内容为“筛选范围限定为近两年订单”，原因和影响范围一并写明。该变更影响验收标准，需求回到评审确认，评审通过后更新验收标准并同步测试人员，需求继续开发。
验收与关闭。开发完成后需求进入“待验收”，测试人员按更新后的验收标准逐条验证，附上测试结论和筛选结果截图。产品经理核对证据后确认验收通过，需求状态变为“已关闭”，变更记录和验收证据均保留在需求单上，后续可按编号检索追溯。
完成检查：规范发布前要核对的清单
规范写完后，先别急着全员发布。用下面这份清单逐项核对，确认规范本身可执行，再安排试点和正式发布。每项检查都应有明确的通过标准和核对人。
| 检查项 | 通过标准 | 核对人 |
|---|---|---|
| 字段与状态覆盖 | 五环节均有对应状态，每个状态有进入条件和出口，无孤立状态；必填字段能支撑评审与追溯 | 需求负责人 |
| 环节责任明确 | 每个环节有负责人和完成标志，完成标志可客观核验 | 产品负责人 |
| 权限与例外路径 | 改状态、改字段、关闭需求的权限逐项写明；超期、跨团队、紧急需求均有处置人和时限 | 项目管理者 |
| 示例可走通 | 用一条真实或模拟需求按规范走完全流程，未出现规则冲突或缺失步骤 | 试点团队 |
| 试点与修订记录 | 试点运行一轮，收集字段冗余、状态卡点等问题并修订；发布方式、生效日期和复审周期已约定 | 规范维护人 |
试点阶段重点观察三类问题：必填字段是否造成录入负担、状态跳转是否在实际协作中卡住、例外路径是否被频繁触发。修订完成后记录变更内容和生效日期，并约定复审周期，例如每季度或每次流程调整后复审一次。规范发布后，新成员入职和工具配置调整都应以当前版本为准，避免口头约定与书面规范并行。
在工具承载层面，规范中的需求类型、状态、字段和权限需要映射到工作项配置中。ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，需求和相关任务可规划至迭代并分配负责人，其产品、项目、任务多层级权限可按组织架构、用户组和项目角色分配，适合作为上述规范的落地载体；评审记录、变更历史等环节的具体配置方式，建议在试点前结合实际版本确认。
常见问题
规范里的必填字段定多少合适，字段太多团队不愿填怎么办？
必填字段以“能支撑评审和追溯”为下限，建议先保留标题、描述、优先级、来源、验收标准、负责人六项，其余字段设为选填，由团队按需启用。字段过多会抬高录入成本，提出人容易用一句话敷衍描述，反而降低需求质量。
试点阶段重点观察哪些必填项在实际录入中被反复跳过或随意填写，这类字段要么简化填写要求，要么降为选填。字段调整应记录在规范修订记录中，避免不同团队各按各的版本执行。
紧急插入的需求来不及评审，规范应该怎么规定？
紧急需求可以允许先进入开发，但要在规范中写明触发条件、审批人和补评审时限。常见做法是由产品负责人确认紧急理由，需求负责人记录插入原因和影响范围，并在约定时限内补做评审；补评审未通过时，需评估是否回退或调整范围。
例外条款要单独成条，写清谁有权认定紧急、补评审的最晚时间、以及未按时补评审的升级路径。例外被频繁触发时，说明常规评审节奏需要调整，应在复审时一并修订。
跨团队的需求在工具里由谁负责，状态怎么统一？
跨团队需求由主责团队的需求负责人牵头，关联团队指定接口人参与评审和排期。规范中要写明主责团队与配合团队的边界：需求单由主责方维护，子任务可由各团队在自己的项目中承接，并通过关联关系回到原需求。
状态统一的关键是约定以主责团队的状态集为准，配合团队只更新自己承接任务的进度。若两个团队的状态定义差异较大，可在规范中列出状态映射关系，避免同一需求在不同视图里显示为互相矛盾的进度。
规范发布后，工具配置调整了，规范要不要跟着改？
要改。规范中的需求类型、状态、字段和权限最终映射到工具的工作项配置上，配置变化会让书面规范与实际执行脱节。建议约定复审周期，例如每季度一次，并在工具配置发生调整时同步触发规范修订。
修订时记录变更内容、生效日期和影响范围，新成员入职和工具配置调整都以当前版本为准。口头约定与书面规范并行，是规范失效最常见的原因。
ONES 能否承载规范中的状态流转和权限要求？
ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，需求和相关任务可规划至迭代并分配负责人；其产品、项目、任务多层级权限可按组织架构、用户组和项目角色分配。这些能力可以作为规范中对象、状态、字段与权限的落地载体。
评审记录、变更历史等环节的具体配置方式，建议在试点前结合实际版本确认，再写入规范的工具操作说明。
