需求拆分评审最容易陷入两种争论：有人觉得拆得太粗，有人觉得拆得太细，最后往往靠职级或嗓门定结论。这份清单把“颗粒度是否合适”转成可逐项判断的检查表，按准备、拆分、评审、收口四个阶段列出检查项、通过标准、证据和负责人，供产品负责人、需求分析人员、研发负责人和测试负责人在需求进入开发前的拆分评审会上使用。清单只判断需求层级与颗粒度，执行任务拆解和跨研发对象的需求追溯不在其中。
要点总览（TL;DR）
- 清单按准备、拆分、评审、收口四个阶段组织，每项给出通过标准、证据和负责人，供需求进入开发前的拆分评审会逐项使用。
- 颗粒度判断收敛为五个维度：可验收、可归属、可估算、可排期、可追溯，任一维度不通过即列为阻断项。
- 拆分过程重点识别五类问题：子项无独立价值、子项重叠或遗漏、粒度与迭代节奏脱节、层级混拆、验收口径丢失。
- 阻断项包括无法验收、无负责人、层级混拆、验收口径丢失；清单关闭需阻断项全部关闭、评审纪要完整、子项进入待排期。
- 证据按类别分工留存：产品负责人管目标与验收口径，需求分析人员管拆分记录，研发负责人管估算与排期，测试负责人管可验收判断。
谁在什么时点用这份清单
这份清单服务于需求拆分评审会，而不是日常任务分配。使用对象和职责分工先明确，评审时才能快速找到对应证据的提供者。
| 角色 | 在清单中的职责 | 主要参与的时点 |
|---|---|---|
| 产品负责人 | 确认原始需求目标、验收口径和层级归属，主持拆分评审 | 需求进入开发前的拆分评审会；迭代规划前的复核 |
| 需求分析人员 | 提供拆分记录，说明每个子项对应的用户价值或业务动作 | 拆分评审会 |
| 研发负责人 | 判断子项是否可估算、可排期，识别技术依赖和拆分遗漏 | 拆分评审会；迭代规划前复核 |
| 测试负责人 | 判断每个子项是否具备可验收的完成定义，核对验收口径是否随拆分保留 | 拆分评审会；提测前抽查 |
使用时点有两个。第一个是需求进入开发前的拆分评审会，逐项过完整张表并形成结论；第二个是迭代规划前的复核，重点看上次评审的修改意见是否落实、阻断项是否关闭。范围边界需要说清楚：本清单判断需求层级与颗粒度，执行层面的任务拆解与组织、跨研发对象的需求追溯与覆盖管理由相应流程处理，不在这张表里讨论，避免评审会跑题。
拆分前的准备检查项
颗粒度讨论的前提是输入信息齐备。原始需求目标含糊、层级定义各说各话时，评审会很容易变成对需求本身的重新讨论。准备阶段先过以下四项，任何一项不通过，拆分评审应推迟而不是勉强进行。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 原始需求目标与验收口径 | 需求文档中写明要解决的业务问题、目标用户和可验证的验收条件，验收条件能对应到具体场景 | 需求文档中的目标与验收标准段落 | 产品负责人 |
| 需求层级定义统一 | 团队对史诗、特性、用户故事等层级的含义有书面约定，评审人对当前需求处于哪一层没有分歧 | 团队需求管理约定或需求模板说明 | 产品负责人 |
| 拆分责任人与评审参与人确定 | 拆分执行人、评审主持人、必须到场的研发与测试代表已明确，评审会时间已通知 | 评审会议通知或参与人名单 | 产品负责人 |
| 约束条件记录 | 时间窗口、外部依赖、合规或安全要求已写入需求说明，拆分时能据此判断哪些子项必须优先或合并 | 需求文档中的约束说明、依赖清单 | 需求分析人员 |
准备阶段的判断标准是“评审人能否在不追问背景的情况下理解需求”。如果评审会上仍需花大量时间澄清目标，说明准备检查没有通过，应先补充信息再安排拆分评审。
拆分过程中的颗粒度检查项
拆分动作本身有五类常见问题：子项没有独立价值、子项之间重叠或遗漏、粒度与迭代节奏脱节、层级混拆、验收口径在拆分中丢失。下表给出每项的判断方法和示例，供拆分执行人自检、评审人复核。
| 检查项 | 通过标准 | 判断示例 |
|---|---|---|
| 单一价值或业务动作 | 每个子项能用一句话描述它为用户或业务带来的变化，且这句话不含“以及”“同时”连接的多个目标 | “支持按手机号找回密码”通过；“优化登录体验并重构账号体系”不通过，应继续拆 |
| 子项之间无重叠、无遗漏 | 把全部子项合起来能覆盖原始需求的验收口径，任意两个子项的工作内容不重复 | 两个子项都包含“修改用户表结构”，属于重叠，需合并或明确归属 |
| 粒度与迭代周期匹配 | 子项规模落在团队常规迭代可完成的范围内，团队能按既有估算方式给出工作量判断 | 一个子项预估超过一个迭代，通常说明还可再拆；半天以内且无独立验收价值的子项，考虑合并 |
| 层级清晰 | 上层条目描述目标与范围，下层条目描述可交付内容，同一层内不混放目标型与交付型条目 | 特性层写“提升下单转化”，其下用户故事写“支持优惠券在结算页自动匹配”，层级清楚 |
| 验收口径可回溯 | 每个子项标注其对应的原始需求验收条件，拆分后原始验收口径仍能逐条找到承接子项 | 原始需求有3条验收条件，拆分记录中每条都能指向至少一个子项 |
颗粒度没有绝对标准，判断依据是团队的管理节奏。两周迭代的团队与按月发布的团队，对同一需求的合理拆分深度不同；评审时应以团队已约定的层级定义和迭代周期为基准，而不是套用其他团队的做法。
评审会上的逐项通过标准
评审会需要当场给出通过或不通过的结论，因此检查项要收敛为五个可判断的维度：可验收、可归属、可估算、可排期、可追溯。任一维度不通过，该子项即列为阻断项，不进入待排期状态。
| 维度 | 通过标准 | 证据 | 负责人 | 结论 |
|---|---|---|---|---|
| 可验收 | 子项有明确的完成定义，测试人员能据此写出至少一条测试用例 | 子项描述中的完成定义、验收条件 | 测试负责人 | 通过 / 不通过 |
| 可归属 | 每个子项有唯一负责人，不存在两个子项由同一人负责却无法区分交付边界的情况 | 拆分记录中的负责人字段 | 产品负责人 | 通过 / 不通过 |
| 可估算 | 研发负责人能当场给出工作量区间或故事点，无需会后补充调研才能判断规模 | 评审会估算记录 | 研发负责人 | 通过 / 不通过 |
| 可排期 | 子项能放入某个迭代或发布计划，前置依赖已识别并记录 | 迭代规划草案、依赖清单 | 研发负责人 | 通过 / 不通过 |
| 可追溯 | 子项与上层需求、原始验收口径的对应关系在拆分记录中可见 | 拆分记录中的关联关系 | 需求分析人员 | 通过 / 不通过 |
五个维度中，可验收与可追溯最容易在评审会上被跳过。建议评审主持人按固定顺序逐项过表，每个子项停留时间大致均衡，避免在个别争议子项上耗尽会议时间而草率通过其余子项。对争议子项，记录分歧点和待补证据，按阻断项处理，留到下次评审。
在工具层面，ONES 支持对功能复杂的需求利用子工作项进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；产品负责人可将待办列表中的需求按优先级规划至对应迭代，在迭代计划会议上与团队共同评审。这类结构能让“子项—负责人—验收条件”的对应关系在评审时有据可查，减少口头确认带来的遗漏。
证据留存与负责人分工
评审结论要能复核，前提是每类检查项都有明确的证据提供者和存放位置。下表按检查项类别给出建议分工，团队可结合现有工具调整，不必照搬。
| 检查项类别 | 证据内容 | 提供者 | 留存位置 |
|---|---|---|---|
| 需求目标与验收口径 | 需求文档、验收条件清单 | 产品负责人 | 需求文档库中对应需求条目下 |
| 层级定义与拆分记录 | 层级约定说明、子项清单及关联关系 | 需求分析人员 | 需求管理空间中的拆分记录 |
| 可估算与可排期判断 | 估算结果、迭代归属、依赖清单 | 研发负责人 | 迭代规划记录、依赖登记表 |
| 可验收判断 | 完成定义、测试用例初稿或验收场景 | 测试负责人 | 测试用例库或需求条目的验收说明 |
| 评审结论与修改意见 | 评审纪要，含逐项结论、阻断项清单、整改责任人和期限 | 评审主持人（通常为产品负责人） | 评审纪要文档，与需求条目关联 |
评审纪要建议采用固定结构：子项名称、五个维度的结论、阻断原因、整改责任人、整改期限。这样下次复核时可以直接对照纪要检查整改情况，而不必重新翻找聊天记录。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，研发团队通过任务和工单完成开发、测试与修复，形成需求—任务—测试—缺陷的闭环；测试工程师可依据迭代需求与验收标准编写并执行测试用例。评审结论和整改记录与需求条目放在同一处，复核时能顺着需求看到拆分、任务和测试的对应关系。
阻断项与完成条件
并非所有问题都需要当场整改。区分阻断项与非阻断项，能让评审会聚焦在影响开发启动的问题上，其余问题进入后续优化。
| 类别 | 具体情形 | 处理方式 |
|---|---|---|
| 阻断项 | 子项无法验收，测试人员无法写出测试用例 | 退回拆分，补充完成定义后重新评审 |
| 阻断项 | 子项无负责人，或负责人无法唯一确定 | 明确归属后再进入待排期 |
| 阻断项 | 层级混拆，目标型条目与交付型条目混在同一层 | 调整层级结构，重新确认上下层对应关系 |
| 阻断项 | 原始验收口径在拆分后丢失，无法逐条找到承接子项 | 补齐追溯关系，缺失部分补充子项或调整拆分 |
| 非阻断项 | 子项命名不规范、描述措辞可优化 | 记录修改意见，由负责人在排期前修正 |
| 非阻断项 | 非关键子项的估算区间偏宽 | 迭代规划时细化，不阻塞本次评审 |
清单关闭需要同时满足三个条件：所有阻断项已关闭并有整改记录；评审纪要完整记录了逐项结论和修改意见；通过评审的子项已进入待排期状态，且负责人、验收条件和迭代归属均已填写。三个条件缺一不可，只关闭阻断项而未记录结论，下次复核时无法判断当时的分歧是否已解决。
复核时按同一张表再走一遍，重点检查上次的非阻断项是否已修正、阻断项整改是否引入新的层级问题。颗粒度判断是迭代规划前的常规动作，把这份清单固定为评审会的议程模板，能让每次拆分评审的结论口径保持一致，也便于团队在几个迭代后回看哪些检查项反复不通过，据此调整需求模板或拆分约定。
常见问题
团队迭代周期不同，颗粒度标准要不要跟着改？
要改，但改的是判断基准，不是检查项本身。五个评审维度保持不变，粒度与迭代周期匹配这一项的通过标准应换成团队自己的节奏：两周迭代的团队可以把“一个子项能在一个迭代内完成”作为参考线，按月发布的团队则允许子项规模更大。评审前把当前迭代周期和估算方式写进清单说明，评审人按同一基准判断，避免拿其他团队的做法当标准。
评审会上争议子项迟迟达不成一致，怎么处理？
把争议子项按阻断项处理，记录分歧点和待补证据，留到下次评审，其余子项照常给出结论。这样做的目的是避免在个别子项上耗尽会议时间、草率通过其他子项。评审纪要中写明争议原因、需要谁补充什么材料、下次评审的时间，复核时先看这一条是否已解决。
非阻断项记录后一直没人改，清单还能关闭吗？
可以关闭，但要在评审纪要中写明非阻断项的整改责任人和期限，并在迭代规划前复核时逐条检查。如果同一类非阻断项在多个迭代反复出现，例如子项命名长期不规范，说明需求模板或拆分约定需要调整，此时应把这类问题升级为流程改进事项，而不是继续留在清单里循环记录。
拆分记录和评审结论放在不同工具里，复核时怎么对上？
关键是让评审纪要与需求条目保持关联，纪要中记录子项名称和对应需求编号，复核时从需求条目就能找到当次评审结论。ONES 支持对功能复杂的需求利用子工作项进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；评审结论与需求条目放在同一处，复核时能顺着需求看到拆分、任务和测试的对应关系。团队也可以沿用现有工具，只要保证纪要和需求条目之间有一条稳定的关联路径即可。
需求层级定义还没统一，能先开始拆分评审吗？
不建议。层级定义不统一时，评审人对同一需求处于哪一层会有分歧，颗粒度讨论就失去共同基准。准备阶段应先把史诗、特性、用户故事等层级的含义写成书面约定，并明确当前需求所处层级，再安排拆分评审。层级定义属于团队约定，可以结合团队规模和发布节奏简化，不必照搬其他团队的分层方式。
