需求细化是把需求池里一条粗粒度需求拆成可开发、可验收条目的过程。具体做法是：先确认需求边界与来源，再按用户场景或业务规则拆成子项，为每个子项补齐背景、验收标准、约束与依赖，标注优先级和就绪状态，经评审确认后进入可开发队列。关键产物是一份字段完整、可逐条验收的需求条目清单。本文按操作顺序展开字段标准、五步流程、角色分工、完整示例和自检清单，迭代排期与需求价值评分不在讨论范围内。ONES 可用于承载需求条目、状态流转与评审记录，文中在相应环节说明衔接方式。
要点总览（TL;DR）
- 需求细化的产物是字段完整、可逐条验收的需求条目清单，判断标准是研发能估算、测试能写用例，篇幅长短不构成标准。
- 操作按五步推进：确认边界与来源、选择拆分方式、补齐验收标准与依赖、标注优先级与就绪状态、评审确认并更新需求池状态。
- 需求负责人主导细化，提出人提供背景与澄清，研发评估可行性与依赖，测试检查验收标准可验证性，交接以评审记录为准。
- 拆分先按角色分界、再按动作分条，每个子项对应一个可独立交付和验收的结果；粒度过粗继续拆，过细则合并。
- 细化只回答“是什么、做到什么程度算完成”，优先级评估与迭代排期分别处理，排期压力不改变已评审的验收标准。
需求细化要产出什么：条目字段与完成标准
细化的目标形态是一条条结构一致的需求条目，每条都能被研发直接认领、被测试逐项验证。判断细化是否完成，看的是条目字段是否齐全、验收标准是否可执行，篇幅长短不构成标准。一条需求写了两千字但验收标准仍是“功能正常”，说明细化尚未完成。
单条需求应包含的字段
| 字段 | 填写要求 | 缺失时的后果 |
|---|---|---|
| 需求标题 | 用“对象+动作+结果”描述，能与其他条目区分 | 评审时无法快速定位，条目易混淆 |
| 背景与目标 | 说明为什么做、要解决谁的什么问题、期望达成什么结果 | 研发只能照字面实现，遇到取舍无从判断 |
| 用户场景 | 谁在什么条件下、执行什么操作、期望看到什么 | 边界情况遗漏，测试无法设计用例 |
| 验收标准 | 可观察、可判断通过与否的条件，逐条列出 | “做完了”没有共识，返工概率上升 |
| 约束与依赖 | 技术限制、合规要求、上下游系统或团队依赖 | 开发中途才发现阻塞，排期被动 |
| 优先级 | 按团队约定口径标注，并写明判断依据 | 排期时反复争论，条目积压 |
| 就绪状态 | 如“待澄清、已细化、已评审、可开发”，状态与实际情况一致 | 研发误领未就绪条目，进度失真 |
| 来源与提出人 | 记录需求来自哪个渠道、谁提出、谁负责跟进 | 澄清时找不到人，信息断链 |
“可开发”的完成标准
一条需求达到可开发状态，通常同时满足以下条件：研发读完后能估算工作量，不需要再向产品追问核心逻辑；测试能依据验收标准写出至少一组正向用例和一组异常用例；约束与依赖已明确，或已标注为待确认并指定了确认人；优先级与就绪状态已填写，且经过评审确认。四项中任何一项不满足，条目应停留在“已细化待评审”或“待澄清”，不进入可开发队列。
粗需求与细化后条目对照
| 对比项 | 粗需求 | 细化后条目 |
|---|---|---|
| 描述 | “导出功能要支持大数据量” | “订单列表支持按当前筛选条件导出 Excel，单次上限 5 万行，超出时提示缩小时间范围” |
| 验收标准 | 无 | “筛选 3 个月数据导出，文件行数与列表总数一致；超过 5 万行时出现提示且不生成文件” |
| 依赖 | 无 | “依赖报表服务提供异步导出接口，接口未就绪前该条目保持待澄清” |
| 可操作性 | 研发需反复询问 | 可直接估算、开发、验收 |
需求细化的操作步骤：从入池到就绪
细化按固定顺序推进，每一步都有明确输入、动作和输出，完成标志是输出物可以交给下一环节。五步走完，一条需求从池中的粗条目变成可开发条目。
第一步：确认需求边界与来源
输入是需求池中的原始条目。动作是核对提出人、提出场景和期望结果，判断这条需求是否属于本需求池的受理范围，是否与已有条目重复。输出是一句边界说明，例如“本次只处理 PC 端导出，移动端另立条目”。完成标志是需求负责人能说清这条需求解决什么问题、不解决什么问题。范围不清的条目直接标记待澄清，不进入拆分。
第二步：选择拆分方式，拆成子项
输入是确认过边界的需求。动作是根据需求性质选择拆分维度：以用户操作为主的需求按场景拆，例如“新用户首次下单”和“老用户重复下单”分开；规则复杂的需求按业务规则拆，例如不同退款原因对应不同审批路径；涉及多类数据的需求按数据对象拆，例如订单、发票、物流分别成条。输出是一组子项，每个子项有独立标题和一句话说明。完成标志是每个子项都能单独交付、单独验收，且子项合起来覆盖原需求范围。拆分后子项数量明显多于预期时，回到第一步检查边界是否划得过大。
第三步：补齐验收标准与约束依赖
输入是拆分后的子项。动作是逐条补写验收标准，每条标准写成“在什么条件下执行什么操作，看到什么结果”；同时记录技术约束、合规要求和上下游依赖，依赖未落实的写明对接人和预计确认时间。输出是字段基本完整的条目。完成标志是测试人员仅凭条目内容就能设计用例，研发能指出主要技术风险点。
第四步：标注优先级与就绪状态
输入是字段完整的条目。动作是按团队既定口径标注优先级，并把每条需求的状态更新为“待澄清”“已细化”或“可开发”之一；存在未决问题的条目单独列出待澄清清单，写明问题和期望回复时间。输出是带状态标记的条目集合和一份待澄清清单。完成标志是需求池中每条细化条目都有明确状态，待澄清项都有责任人和时限。
第五步：评审确认并更新需求池状态
输入是待评审的条目集合。动作是组织需求提出人、研发、测试进行评审，逐条确认范围、验收标准和依赖，记录评审结论与修改意见；评审通过后把状态更新为“可开发”，未通过的退回补充。输出是评审记录和更新后的需求池。完成标志是评审结论有记录、修改意见已回填、状态与实际一致。在 ONES 中，需求池条目可自定义状态与多种属性，评审后的状态更新和负责人分配可以在同一条目上完成，便于后续追溯。
谁来做、交付什么：角色分工与交接物
细化由需求负责人主导，提出人、研发和测试在不同节点参与，各自交付可被下游直接使用的材料。分工不清时，细化容易停留在个人笔记里，其他人无法接手。
| 角色 | 主要职责 | 交付物 | 参与时点 |
|---|---|---|---|
| 需求提出人 | 说明业务背景、使用场景和期望结果，回答澄清问题 | 原始需求说明、澄清回复 | 入池时、待澄清阶段 |
| 需求负责人（产品角色） | 确认边界、组织拆分、补写验收标准、维护状态 | 细化条目、验收标准、待澄清清单 | 全流程 |
| 研发角色 | 评估技术可行性，指出约束与依赖，参与工作量估算 | 技术可行性意见、依赖说明 | 第三步、评审 |
| 测试角色 | 检查验收标准是否可验证，补充异常场景 | 验收标准修订意见、用例设计反馈 | 第三步、评审 |
交接发生在两个时点：一是条目从“待澄清”转为“已细化”时，需求负责人把条目和待澄清清单交给研发与测试预审；二是评审通过后，条目连同验收标准交给研发认领。确认方式以评审记录为准，口头确认需回填到条目中。待澄清问题集中记录在一份清单上，写明问题、提出人、责任人、期望回复时间和当前结论，每次评审先过一遍清单，未闭环的问题不随条目进入开发。ONES 提供业务、产品经理与研发团队三个视角，需求来源、规划与交付状态在同一套需求池和任务看板中同步，待澄清项和评审结论可以随条目一起被相关角色查看。
示例：一条粗需求如何细化成可开发条目
以下为演示情景，用于说明拆分与补字段的过程，不代表真实项目。
原始描述
“客户希望后台能管理优惠券，运营自己就能发券和停券。”这条描述包含多个动作和多个使用角色，直接开发会导致范围失控。
按场景拆出的子项
| 子项 | 验收标准（节选） | 约束与依赖 |
|---|---|---|
| 运营创建优惠券 | 填写面额、有效期、适用商品范围后可保存；必填项为空时保存失败并提示具体字段 | 依赖商品中心提供范围选择接口 |
| 运营发放优惠券 | 按用户名单发放，发放结果逐条显示成功或失败原因；重复发放同一用户时提示已领取 | 单次名单上限待确认 |
| 运营停止优惠券 | 停止后新用户无法领取，已领取用户仍可使用至有效期结束 | 需与财务确认已发放券的核销口径 |
| 用户查看与使用优惠券 | 用户端展示可用券及失效时间；下单时自动匹配可用券并显示抵扣金额 | 依赖订单结算流程改造 |
待澄清项标注
示例中至少有三项需要澄清：单次发放名单上限、停止发放后已领券的核销规则、优惠券与现有促销活动叠加时的优先级。每项写明责任人和期望回复时间，在结论明确前，相关子项状态保持“待澄清”。
可迁移的拆分规律
这条需求按“谁在做什么”拆成运营侧管理和用户侧使用两类，再按动作细分为创建、发放、停止、使用。拆分时先按角色分界，再按动作分条，每个子项对应一个可独立验收的结果。遇到包含多个角色的粗需求，可以沿用这个顺序：先分角色，再分动作，最后检查子项是否覆盖原描述中的每个期望。
细化过程中的常见问题与处理
细化卡住通常集中在四类情况，处理原则是让问题显性化并指定责任人和时限，避免条目长期悬置。
- 信息不足。把条目状态改为“待澄清”，在清单中写明缺什么信息、向谁要、何时回复。超过约定时限未回复的，由需求负责人在评审中升级处理，或先按假设细化并标注假设条件，待信息到位后复核。
- 粒度过粗。判断信号是研发无法估算、测试无法写用例、一个子项包含多个可独立交付的结果。处理方式是继续按场景或动作拆分，直到每个子项能对应一组验收标准。
- 粒度过细。判断信号是子项单独交付没有业务价值，或多个子项必须同时上线才有意义。处理方式是把它们合并为一条，验收标准中分条列出，避免条目数量膨胀、管理成本超过收益。
- 业务重复。发现两条需求解决同一问题时，保留描述更完整的一条作为主条目，另一条关联到主条目并注明来源，避免重复开发和重复验收。
- 与优先级、排期的边界。细化只回答“这条需求是什么、做到什么程度算完成”，优先级评估回答“先做哪条”，迭代排期回答“什么时候做”。细化阶段可以标注优先级，但不以排期结论倒推拆分粒度；排期变化时回到需求池调整状态，不改动已评审的验收标准。
完成检查：细化结果的自检清单
本轮细化结束前，由需求负责人逐项核对，评审时抽查。任一项不通过，条目退回补充，不进入可开发队列。
| 检查类别 | 检查项 | 不通过时的动作 |
|---|---|---|
| 字段完整性 | 标题、背景与目标、用户场景、验收标准、约束与依赖、优先级、就绪状态、来源与提出人均已填写 | 退回需求负责人补齐，缺验收标准的不得提交评审 |
| 验收标准可验证性 | 每条标准包含条件、操作和可观察结果；测试能据此写出正向与异常用例 | 由测试提出修订意见，需求负责人改写后复审 |
| 依赖与待澄清闭环 | 依赖已确认或已指定对接人和时间；待澄清清单中无超期未回复项 | 超期项升级到评审处理，相关条目保持待澄清 |
| 就绪状态与评审记录 | 状态与实际一致；评审结论、修改意见和确认人均有记录 | 补录评审记录，状态回退到“已细化待评审” |
检查通过后，条目状态更新为“可开发”，进入研发认领环节。ONES 中需求条目可规划至迭代并分配负责人，细化完成后的条目与后续任务在同一处衔接，状态变化可追溯。需要说明的是，细化解决的是条目质量问题，条目何时进入迭代仍由排期环节决定，两者分开管理可以避免因排期压力降低验收标准。
常见问题
需求细化做到一半发现原始需求本身方向有问题，应该退回还是继续细化？
退回需求池重新确认边界，不继续在错误方向上补字段。具体做法是把条目状态改回“待澄清”，在待澄清清单中写明疑点和需要提出人回答的问题，由需求负责人与提出人重新确认目标与范围后再决定是否拆分。已经写好的验收标准可以保留在条目备注中，作为后续参考，但不作为评审依据。
验收标准写到什么程度，研发和测试才算有共识？
可操作的判断是：测试仅凭条目内容就能写出至少一组正向用例和一组异常用例，研发读完后能指出主要技术风险点，不需要再追问核心逻辑。验收标准建议写成“在什么条件下执行什么操作，看到什么结果”，避免“正常”“合理”“友好”这类无法判断通过与否的表述。评审时由测试逐条确认，有争议的当场改写。
需求提出人迟迟不回复澄清问题，条目一直卡在待澄清怎么办？
先按约定时限升级：由需求负责人在评审中提出，明确回复时间和不回复的后果。若业务上必须推进，可以按假设条件先细化，并在条目中标注假设内容与复核时点，信息到位后复核验收标准。超期未闭环的条目保留在待澄清清单中，不随其他条目进入开发，避免带着未确认的前提开工。
细化后的条目在评审中被要求改拆分粒度，应该改条目还是新开条目？
看改动是否改变交付范围。若只是把一条拆成两条、范围不变，直接在原条目下拆分并保留关联关系，原条目关闭或转为父级；若评审发现原需求范围本身划得过大，回到第一步重新确认边界，新拆出的子项单独建条并注明来源。无论哪种情况，已评审通过的验收标准需要同步更新，避免条目与标准不一致。
团队刚开始做需求细化，字段一次填不全，是否可以先简化字段？
可以按阶段简化，但验收标准、约束与依赖、就绪状态三项建议保留。起步阶段可先固定标题、背景与目标、验收标准、就绪状态四个字段，运行一两个评审周期后再补充用户场景、优先级依据等字段。简化的是字段数量，不是判断标准：验收标准仍要可验证，状态仍要与实际一致，否则细化会退回到写长文档的状态。
