需求工具应用规范要解决的是需求进出有序：一条需求从提出到关闭，字段填什么、状态怎么走、谁审谁改、变更如何留痕，都有统一约定。本文按对象与字段、状态与流转、角色与权限、评审与变更、检查与度量五块展开，给出可直接填写的字段字典、状态流转表、角色权限表和执行检查清单。规范最终要落到工具配置上，ONES Project 可作为承载需求字段、状态与迭代规划的工具之一，文中在相应环节说明衔接方式。
要点总览（TL;DR）
- 需求工具应用规范由四类内容组成：对象与字段、状态与流转、角色与权限、评审与变更，分别对应工具中的工作项类型与自定义字段、状态集、项目角色、评审记录与变更申请。
- 落地顺序建议为：先定需求类型与字段字典，再设计状态流转与准入准出条件，然后把动作分配到角色并配置权限，最后用抽样检查和度量验证执行情况。
- 字段字典逐字段写明字段名、含义、取值规则、是否必填、维护人；必填项控制在八到十个，确需但非每次适用的信息设为条件必填。
- 状态集全局唯一、由一人维护，每个状态绑定一个责任人和明确的准入准出条件，禁止用标签或标题前缀模拟状态。
- 规范每季度复审一次，依据字段完整率、状态停留时长、变更次数、回退率等指标和抽样检查结果判断偏差来自执行还是规范本身。
一套可执行的需求工具应用规范包含哪些内容
需求工具应用规范的内容可以归为四类，每类都对应工具中的具体配置落点。判断一份规范是否可执行，看它能否回答四个问题：需求以什么形态进入工具、在工具中如何流转、由谁操作、在哪些节点被评审和变更。
| 内容类别 | 解决的问题 | 工具配置落点 | 交付物 |
|---|---|---|---|
| 对象与字段 | 需求以什么类型、带哪些信息进入系统 | 工作项类型、自定义字段、必填校验、取值枚举 | 需求字段字典 |
| 状态与流转 | 需求生命周期如何推进、何时可进可出 | 需求状态集、状态流转规则、关联的评审与验收动作 | 需求状态流转表 |
| 角色与权限 | 谁提、谁审、谁改、谁关 | 项目角色、用户组、字段与操作权限 | 角色职责与权限对照表 |
| 评审与变更 | 哪些节点必须评审、变更走什么路径 | 评审记录载体、变更申请单、审批流转 | 评审节奏说明与变更流程 |
这四类内容与PRD文档规范分工不同。PRD规范管单份需求文档写什么、写到什么颗粒度；工具应用规范管需求作为一条工作项在系统中如何被创建、推进和关闭。两者衔接点在字段：PRD中的关键信息（如目标用户、验收标准、优先级依据）应映射为工具字段，避免文档写完后再手工摘录。PRD写作模板本身不在本文展开。
规范文档建议控制在一份可读完的长度，四类内容各占一节，附上字段字典和状态流转表两张核心表格。文档版本与工具配置版本保持同步，配置调整时同步修订文档，避免规范与实际系统脱节。
第一步：定义需求对象与字段字典
这一步的输入是团队现有的需求来源和协作习惯，动作是确定需求类型划分与字段清单，输出是一份字段字典，完成标志是每个字段都能在工具中找到对应配置项，且必填字段在提交时能被校验。
需求类型怎么划分
类型划分的目的是让不同来源、不同颗粒度的需求走各自合适的流程，而不是把所有内容塞进一个类型。常见划分方式：
- 业务需求：来自业务方或客户，描述业务目标与期望结果，颗粒度较粗，通常需要再拆解。
- 用户故事：面向具体使用场景的功能描述，带验收标准，可直接进入开发。
- 缺陷衍生需求：由缺陷分析引出的改进项，需关联原缺陷记录，便于追溯。
- 技术或合规需求：由架构升级、安全合规等内部要求产生，评审人侧重技术角色。
类型数量控制在三到五类。类型过多会导致提交人选择困难、统计口径分散；类型过少则无法区分流程差异。每类需求在工具中对应一个工作项类型或一个类型字段，并绑定各自的必填字段集。
必填与选填的取舍原则
必填字段的判断标准是：缺少该信息会导致下游无法决策或无法验收。按此标准，通常必填的有：需求标题、需求描述、提出人、需求负责人、优先级、目标版本或期望时间、验收标准。选填的通常是：关联文档链接、竞品参考、预估工作量、依赖项。
必填项不宜超过八到十个。字段越多，提交门槛越高，实践中容易出现随意填写或绕过工具线下沟通的情况。对确有必要但非每次都适用的信息，设为条件必填：例如状态推进到“待开发”时，验收标准字段变为必填。
字段字典的写法
字段字典逐字段写明五项信息，形成可配置、可交接的表格：
| 字段名 | 含义 | 取值规则 | 是否必填 | 维护人 |
|---|---|---|---|---|
| 需求标题 | 一句话说明需求要解决的问题 | 文本，不超过50字，以动词开头 | 是 | 提出人 |
| 需求类型 | 区分需求来源与流程 | 枚举：业务需求/用户故事/缺陷衍生/技术合规 | 是 | 产品负责人 |
| 优先级 | 排期依据 | 枚举：P0/P1/P2/P3，附判定说明 | 是 | 需求负责人 |
| 验收标准 | 判定需求完成的依据 | 文本，逐条列出可验证的结果 | 条件必填（进入待开发时） | 需求负责人 |
| 目标版本 | 计划交付的迭代或版本 | 关联迭代或版本对象 | 是 | 项目经理 |
| 关联文档 | PRD或设计稿地址 | 链接 | 否 | 提出人 |
取值规则要写到可判定的程度。“优先级P0”应附一句判定说明，例如“影响核心流程可用性或存在数据风险”，避免全员都填P0。枚举字段的选项由维护人统一增删，普通成员只有选择权。
在工具配置上，ONES Project 支持编写需求并自定义需求状态与多种属性，字段字典中的类型、优先级、目标版本等可以对应到需求工作项的属性设置；需求池用于承接尚未排期的条目，规划迭代时再将需求和相关任务分配负责人。字段的必填校验粒度以实际配置为准，配置前建议先在测试项目中验证一遍提交体验。
第二步：设计状态流转与准入准出条件
这一步的输入是第一步确定的需求类型，动作是为每类需求画出状态序列并写明每个状态的进入与离开条件，输出是状态流转表，完成标志是任一需求在工具中的当前状态都能唯一对应一个责任人和下一步动作。
典型状态序列
一条需求的常见状态序列为：待评审 → 已确认 → 待开发 → 开发中 → 待验收 → 已验收 → 已关闭。可回退路径需要显式定义，例如“待开发”可退回“已确认”补充信息，“待验收”验收不通过退回“开发中”。回退不是异常，而是正常流程的一部分，关键是回退时记录原因。
| 状态 | 准入条件 | 准出条件 | 责任人 |
|---|---|---|---|
| 待评审 | 必填字段完整，已指定需求负责人 | 评审会给出通过、修改或拒绝结论并记录 | 需求负责人 |
| 已确认 | 评审通过，优先级与目标版本已定 | 验收标准补齐，拆解出开发任务 | 需求负责人 |
| 待开发 | 验收标准完整，已排入迭代 | 开发任务启动，负责人确认排期 | 项目经理 |
| 开发中 | 开发任务已分配 | 代码完成并提交测试 | 开发负责人 |
| 待验收 | 测试通过，具备验收环境 | 按验收标准逐条确认结果 | 需求负责人 |
| 已验收 | 验收标准全部满足 | 上线或交付完成，归档关联文档 | 需求负责人 |
| 已关闭 | 交付完成或评审决定终止 | — | 需求负责人 |
状态与动作的对应
每个状态应绑定一个明确的动作和产出：待评审对应评审会与评审记录，待开发对应迭代规划，待验收对应验收清单。状态本身不产生信息，状态变化时留下的记录才有价值。因此规范中要写明：状态推进时必须在工具中更新哪些字段、附上什么记录。
避免状态冗余与双轨
常见问题是同一含义出现两个状态，例如“评审中”和“待评审”并存，或者工具里一套状态、周报里另一套说法。做法是：状态集全局唯一，由一人维护；线下会议结论必须回写到工具状态；禁止用标签或标题前缀模拟状态。状态数量控制在七到九个，超过十个通常意味着把任务级动作混入了需求生命周期。
ONES Project 支持自定义需求状态，可将上述状态集配置为团队统一的状态选项；状态流转的自动化校验能力以实际配置为准，规范落地初期可先靠评审和抽查保证状态纪律。
第三步：明确角色分工、权限与评审节奏
这一步的输入是状态流转表，动作是把每个状态的推进动作分配到具体角色，并配置工具权限，输出是角色职责与权限对照表及评审变更流程说明，完成标志是任一成员都能说清自己在需求流程中负责哪几个动作。
角色职责
| 角色 | 主要职责 | 工具权限建议 |
|---|---|---|
| 需求提出人 | 提交需求，补充业务背景，参与验收确认 | 创建需求、编辑本人提交的字段、查看关联需求 |
| 需求负责人 | 维护需求内容与优先级，组织评审，推进状态，关闭需求 | 编辑需求全部字段、推进状态、关联迭代 |
| 评审组 | 在评审节点给出通过、修改或拒绝结论 | 查看需求、填写评审意见 |
| 开发负责人 | 评估工作量，拆解开发任务，推进开发中状态 | 编辑开发相关字段、创建关联任务 |
| 测试负责人 | 验证实现结果，提交测试结论 | 编辑测试结论字段、关联缺陷 |
权限设置遵循最小必要原则：字段编辑权按角色分配，状态推进权只给需求负责人，枚举选项和状态集的增删权只给规范维护人。ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，适合把上述角色映射为项目角色后统一授权。
评审节奏与记录
评审频率与团队节奏匹配即可，常见做法是每周一次需求评审会，参与人包括需求负责人、开发负责人、测试负责人和提出人代表。评审决议要当场记录在需求条目上，写明结论、修改意见和下次评审时间。决议记录写在工具里而非会议纪要文档里，才能与需求状态同步。
变更的触发与审批
以下情况触发变更申请：验收标准修改、目标版本调整、优先级升降、需求范围增减。变更申请写明变更内容、原因、影响范围（涉及的任务与排期），由需求负责人提交，评审组中至少一名开发负责人确认影响评估后生效。小范围文字修订可直接修改并留修改记录，不必走完整审批，避免流程过重。
示例：一条需求从提出到关闭的完整走查
以下为演示情景，用于说明规范各环节如何组合使用，不代表真实项目数据。
提出。运营同事提交一条业务需求，标题为“支持按客户标签筛选订单列表”。字段填写：需求类型为业务需求，优先级P1（判定说明：影响大客户日常对账效率），提出人为运营同事，关联文档为一份简要说明。此时状态为待评审，必填字段校验通过。
评审。周评审会上，需求负责人补充验收标准：“订单列表页可按至少三个客户标签组合筛选，筛选结果在2秒内返回”。评审组结论为通过，但要求补充标签来源说明。决议记录写在需求条目上，状态推进为已确认。
拆解与排期。需求负责人将需求拆为前端筛选组件、后端查询接口两个开发任务，关联到下一迭代，指定开发负责人，状态推进为待开发。
开发与变更。开发中发现标签数据存在两种口径，开发负责人发起变更申请，说明影响：查询接口需增加口径判断逻辑，预计增加一天工作量。需求负责人确认后更新验收标准，补充口径说明，变更记录保留在需求条目上。状态进入开发中。
验收与关闭。测试通过后状态推进为待验收，需求负责人按验收标准逐条确认，全部满足后推进为已验收，上线完成后关闭需求，关联文档归档。
这个走查可迁移的规律有三条：每个状态推进都伴随一条记录；变更发生在开发中而非事后补记；验收标准在评审阶段就写到可验证的程度。团队规模、需求类型不同，状态名称和评审频率可以调整，这三条保持不变。
规范落地后的检查与度量
规范写完不等于被执行。检查的目的是发现规范与实际操作的偏差，并判断偏差来自执行不力还是规范本身不合理。
可观察指标
| 指标 | 口径 | 参考信号 |
|---|---|---|
| 字段完整率 | 必填字段全部填写的需求数 / 当期新增需求数 | 持续低于90%说明必填项过多或校验未生效 |
| 状态停留时长 | 需求在各状态的平均停留天数 | 某状态长期积压，检查该状态的责任人是否明确 |
| 变更次数 | 每条需求在开发启动后的变更申请数 | 偏高说明评审阶段信息不足；为零且频繁返工说明变更未走流程 |
| 回退率 | 从待验收退回开发中的需求占比 | 偏高说明验收标准不清晰或测试介入过晚 |
抽样检查
建议每月抽样一次，样本覆盖各需求类型和各个需求负责人，每类抽取五到十条。检查项包括：必填字段是否完整、状态是否与实际进展一致、评审决议是否有记录、变更是否留痕。检查结果按问题类型汇总，反馈给规范维护人，而非逐条追责个人。
常见失效信号与纠正
- 需求在工具外流转：群里讨论定稿、工具里只补记录。纠正动作是明确“未在工具中登记的需求不进入排期”。
- 状态长期不动：需求实际已完成但状态停在开发中。纠正动作是把状态更新纳入验收动作，验收时同步关闭。
- 字段敷衍填写：验收标准写成“功能正常”。纠正动作是给出正反示例，评审时把验收标准作为必查项。
- 规范与配置脱节：文档改了状态名，工具里没改。纠正动作是规范维护人与工具管理员由同一人担任，或建立变更同步机制。
规范本身的复审
规范每季度复审一次，复审依据是上季度的检查数据和团队反馈。复审内容包括：必填字段是否仍必要、状态是否可合并、评审频率是否合适。每次修订记录版本号和修订说明，旧版本归档。规范修订后，工具配置同步调整，并在下一次评审会上向团队说明变化点。
当需求条目数量增长、跨团队协作增多时，字段和状态的统一价值会更明显。ONES Project 的需求池、迭代规划与多层级权限可以承接本文所述的字段、状态和角色配置；ONES Assistant 可在已使用 ONES Project、ONES Wiki 的环境中，按自然语言指令将 PRD 拆解为需求和任务并分配负责人，拆解结果仍需人工复核后进入评审。规范的核心始终是团队对需求进出规则的共同约定，工具负责让约定可见、可查、可追溯。
常见问题
团队规模很小，是否也需要完整的字段字典和状态流转表？
可以按比例简化，但两类内容建议保留。字段字典至少写明必填字段和取值规则，状态流转表至少写明每个状态的责任人。小团队的简化空间主要在评审节奏和变更审批层级：评审可以并入每周例会，变更可由需求负责人与开发负责人两人确认后生效。判断简化是否过度的标准是，新成员能否只看这两张表就独立提交一条合格需求。
需求已经在工具里登记，但状态长期不更新，规范该怎么调整？
先区分原因再决定动作。如果是验收环节没有把状态更新纳入动作，就把“验收时同步关闭需求”写进验收清单；如果是状态太多、推进一次要改好几处，就合并含义相近的状态。检查时可用状态停留时长指标定位积压环节，再针对该环节明确责任人和推进动作。状态纪律在规范落地初期主要靠评审和抽查维持，工具配置只能起到辅助作用。
需求评审的决议应该记在会议纪要里还是工具里？
建议记在需求条目上，会议纪要只保留议程和参会人。决议写在工具里才能与需求状态同步，后续查看一条需求时能直接看到评审结论、修改意见和下次评审时间。如果团队已有纪要文档习惯，可以在纪要中列出决议摘要，并在每条需求上回写完整结论，避免同一结论出现两个版本。
变更审批会不会让流程变得太重，影响交付节奏？
关键在分级。验收标准修改、目标版本调整、优先级升降、需求范围增减这类影响排期的变更走申请与确认；文字表述修订、补充背景说明这类不影响交付内容的修改直接编辑并保留修改记录。审批人也不必是完整评审组，通常由需求负责人提交、一名开发负责人确认影响评估即可。变更次数指标偏高时，应回头检查评审阶段的信息是否给足，而不是继续加审批环节。
规范文档和工具配置由不同人维护，怎样避免两边脱节？
最直接的做法是规范维护人与工具管理员由同一人担任。如果必须分开，就建立同步机制：状态集、枚举选项、必填字段的任何调整，先改规范文档并记录版本号，再由管理员按版本修改配置，配置完成后在文档中标注生效日期。季度复审时对照文档与系统实际配置逐项核对，把差异列为复审问题处理。
