需求分解颗粒度指一条需求被拆到哪一层、每层承载多少信息与验收责任。评估颗粒度是否合适，需要把“拆得太粗还是太细”的主观感受转成可复算的指标：先明确业务需求—产品需求—系统需求—子需求的层级关系，再统一分母、时间窗与单位，计算子需求数量分布、单条规模、验收标准覆盖数、跨层变更回流率与拆分后返工比例，并结合评审记录中的拆分理由判断。指标反映的是分解结构特征，用于调整分解规则，不能单独作为质量或绩效结论。
要点总览（TL;DR）
- 颗粒度评估的对象是业务需求—产品需求—系统需求—子需求之间的父子结构，评估结论用于调整分解规则，不直接用于个人考核。
- 核心指标包括子需求数量分布、单条需求规模、验收标准覆盖数、跨层变更回流率与拆分后返工比例，每个指标都要写清分子、分母、时间窗和单位。
- 计算时统一以“近3个月进入开发的父需求”为分母，剔除取消与合并项，按团队、需求类型和层级分组统计，保证结果可复算。
- 判断顺序从结构到证据：先看子需求数量分布，再看规模区间、验收标准覆盖与回流返工，四项指向同一层级时调整建议更可信。
- 指标只反映分解结构特征，不设通用达标线，需结合评审记录中的拆分理由与验收可行性说明解读，调整后按同一口径持续跟踪。
评估目标：颗粒度要回答哪几个问题
颗粒度评估的对象是需求层级结构，即父需求与子需求之间的父子关系，以及每一层承载的信息量和验收责任。评估不针对某个人的拆分速度或产出数量，而是看这套层级关系是否支撑了后续的设计、开发、测试与验收。把评估对象限定在结构上，结论才能落到分解规则，而不是变成对个人的评价。
具体评估要回答四类问题。第一，子需求能否被独立验收：每条子需求是否有明确的验收标准，验收时是否依赖其他子需求同时完成。第二，规模是否可控：单条子需求的规模是否落在团队一个迭代或一个短周期内可完成的区间。第三，变更是否回流：需求变更主要发生在低层级子需求上，还是反复回到父需求甚至业务需求层重新定义。第四，验收标准是否可对应：父需求的验收标准能否被其子需求的验收标准覆盖，拆完之后是否出现父需求有标准、子需求无对应的情况。
评估结果的使用边界需要提前说清。这套指标用于发现哪一层分解过粗或过细、哪类需求的拆分规则需要调整，例如修改需求模板中的验收标准字段、调整评审时的拆分检查项。指标不直接用于个人考核，因为子需求数量受需求类型、业务复杂度影响很大，同一团队不同季度的可比性也有限。把结构指标当成绩效分数，容易诱导为了凑数量而机械拆分。
指标与范围：层级模型和统计口径
层级模型采用四级父子关系：业务需求描述业务目标与价值，产品需求描述产品层面的解决方案，系统需求描述具体系统或模块需要提供的能力，子需求是可独立进入开发与验收的最小需求单元。上一层是下一层的父项，一条父需求可以对应多条子需求。统计时以父需求为归集单位，向下统计其子需求，避免把不同层级混在同一张表里比较。
指标定义需要同时给出公式、分子、分母、时间窗、单位和缺失值规则，保证不同人复算得到同一结果。下表给出一组可直接套用的定义，时间窗默认取近3个月，团队可按迭代节奏调整并保持前后一致。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 单位 | 缺失值规则 |
|---|---|---|---|---|---|---|
| 子需求数量 | 父需求下的子需求条数 | 该父需求关联的子需求数 | 不适用（按父需求逐条统计） | 近3个月进入开发的父需求 | 条/父需求 | 无子需求的父需求记为0，单独列出 |
| 单条需求规模 | 子需求规模之和÷子需求条数 | 子需求故事点或人日估算之和 | 参与估算的子需求条数 | 同上 | 点/条或人日/条 | 未估算的子需求剔除，并记录剔除条数 |
| 验收标准覆盖数 | 子需求中带验收标准的条数÷子需求总条数 | 有明确验收标准的子需求条数 | 子需求总条数 | 同上 | 百分比 | 验收标准字段为空按“无”计，不推断 |
| 跨层变更回流率 | 发生向上回流的父需求数÷父需求总数 | 变更后回到父需求或更高层重新定义的父需求数 | 统计范围内的父需求总数 | 同上 | 百分比 | 变更记录缺失的父需求标记为不可判定，不计入分子分母 |
| 拆分后返工比例 | 拆分后返工的子需求数÷子需求总数 | 因拆分不合理而重新合并或重拆的子需求数 | 子需求总数 | 同上 | 百分比 | 无返工记录按0计，需说明记录来源 |
分母的选择直接决定指标含义。以“近3个月进入开发的父需求”为分母，统计的是已进入执行阶段的需求结构，排除了仍在需求池中反复讨论、尚未定稿的条目，避免把探索期的不稳定结构混入评估。按层级分别统计时，业务需求层与产品需求层的子需求数量天然不同，不应合并成一个平均数。
数据口径与证据：从哪里取数、如何保证可比
取数依赖几类字段：需求层级标识、父子关联关系、状态流转时间、验收标准条目、变更记录。层级标识用于区分业务需求、产品需求、系统需求与子需求；父子关联用于把子需求归集到父需求；状态流转时间用于确定需求何时进入开发、在哪个层级停留最久；验收标准条目用于计算覆盖数；变更记录用于识别回流与返工。这些字段需要在同一套需求管理工具中保持关联，否则跨表拼接会丢失父子关系。
可比性处理有三条规则。第一，按团队与需求类型分组统计，新功能、优化类、缺陷转需求三类分开看，因为它们的拆分深度本来就不同。第二，统一时间窗，所有指标取同一段起止日期，不因某个团队迭代周期长就单独放宽。第三，剔除取消与合并的需求：被取消的父需求不计入分母，被合并的子需求不计入子需求总数，并在统计说明中记录剔除条数，保证分子分母来自同一集合。
定量指标之外还需要定性证据。评审记录中关于拆分理由的说明、验收可行性讨论的结论，是判断指标含义的关键材料。例如子需求数量偏少但每条都带清晰验收标准，可能说明分解得当；子需求数量多但验收标准普遍缺失，则提示拆分停留在形式层面。定性证据与指标并列呈现，才能支撑“哪一层需要调整”的结论。
在工具承载上，需求层级与父子关联需要有稳定的数据基础。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，功能复杂的需求可用子工作项拆解并关联研发和测试任务，使需求、研发、测试环节保持串联。这些结构为按父需求归集子需求、按层级统计提供了数据来源；具体的颗粒度指标仍需按本文口径自行统计。
计算与评估步骤：从原始记录到判断
计算按五步推进，每步产出可核对的结果。第一步，确定统计范围：选定时间窗、团队与需求类型，列出纳入统计的父需求清单。第二步，按层级归集：把每条子需求挂到对应父需求下，标注其所属层级，形成“父需求—子需求”对照表。第三步，逐指标计算：按上表公式分别算出子需求数量分布、单条规模、验收标准覆盖数、跨层变更回流率与拆分后返工比例，保留分子分母原始数值。第四步，分组对比：按团队、需求类型、层级分别看结果，找出偏离整体分布的组。第五步，结合定性证据判断：调取评审记录，核对指标异常组的拆分理由与验收讨论，形成调整建议。
异常情况需要预设处理规则。分母为零时，该指标标记为“不适用”，不按零分计入任何汇总或平均，例如某季度没有发生跨层变更，回流率应记为不适用而非0%。数据不可比时，优先拆分分组或延长观察窗口，而不是强行合并：两个团队迭代周期差异大，可以各自按自身周期统计后再比较分布形态；样本量过小，可以延长到两个季度再看。缺失字段按上表规则处理，并在结果中注明缺失比例，缺失比例过高时该指标只作参考。
判断顺序建议从结构到证据：先看子需求数量分布是否存在大量“一条父需求对应一条子需求”的情况，这通常提示分解过粗；再看单条规模是否集中在团队可完成区间的上沿或超出区间；然后看验收标准覆盖数是否明显偏低；最后看回流率与返工比例是否集中在某一层级。四项指向同一层级时，调整建议的可信度较高；指向分散时，优先处理验收标准覆盖与回流这两项，因为它们直接影响后续验收与变更成本。
例子：一个季度的颗粒度评估演算
以下为一组演示用假设数据，用于展示公式代入过程，不代表任何真实团队。某团队近3个月进入开发的父需求共40条，其中新功能类25条、优化类15条；子需求合计120条；子需求中有明确验收标准的84条；发生跨层变更回流的父需求6条；因拆分不合理而重新合并或重拆的子需求9条；参与估算的子需求100条，估算合计300点。
| 指标 | 代入计算 | 结果 | 读法 |
|---|---|---|---|
| 子需求数量 | 120÷40 | 平均3条/父需求 | 需看分布：若多数父需求只有1条子需求，平均被少数大需求拉高 |
| 单条需求规模 | 300÷100 | 3点/条 | 与团队单迭代可完成区间对照，判断是否偏大 |
| 验收标准覆盖数 | 84÷120 | 70% | 三成子需求缺少可验收依据，拆分未落到验收责任 |
| 跨层变更回流率 | 6÷40 | 15% | 回流集中在产品需求层时，提示该层定义不清 |
| 拆分后返工比例 | 9÷120 | 7.5% | 返工子需求集中在少数父需求时，检查其拆分方式 |
假设进一步分组后发现：新功能类父需求平均4.2条子需求，优化类平均1.1条；回流6条中有4条来自优化类，且都发生在产品需求层；返工9条中有6条来自同两条父需求。据此可以形成调整方向：优化类需求分解偏粗，产品需求层的定义需要补充验收标准与边界说明；两条返工集中的父需求应回看其拆分理由，确认是否按可独立验收的单元拆分；验收标准覆盖数70%是优先改进项，可在需求评审中把“子需求是否带验收标准”列为通过条件。调整后再按同一口径统计一个季度，对比覆盖数与回流率的变化。
解读与限制：指标说明什么、不能说明什么
这些指标反映的是需求层级结构的形态，不能单独证明质量高低或团队绩效。子需求数量多不等于分解充分，数量少也不等于分解粗糙，关键要看每条子需求能否独立验收、规模是否可控、变更是否在低层级消化。把子需求数量当作拆分质量的替代指标，容易得到与实际情况相反的结论。
跨层变更回流率与拆分后返工比例更接近结构问题的信号，但同样受需求类型影响。探索性强的新功能在开发中回到产品需求层重新定义，可能是正常的认知迭代；成熟业务的优化类需求频繁回流，则更可能指向分解时边界没划清。解读时应把指标放回需求类型与团队成熟度的语境，不设通用达标线，也不把某一季度的数值直接当作长期水平。
评估结论需要与评审证据结合使用。指标给出“哪一层可能有问题”的线索，评审记录中的拆分理由与验收可行性说明提供“为什么”的解释，两者一致时调整建议才站得住。指标本身不构成因果结论，调整分解规则后应继续按同一口径跟踪，观察覆盖数、回流率与返工比例是否朝预期方向变化，再决定是否固化新的拆分规则。
常见问题
团队刚建立需求层级，历史数据不完整，颗粒度评估还能做吗？
可以做，但要先缩小评估范围。建议从最近一个完整迭代或一个季度开始，只统计层级标识和父子关联都齐全的父需求，把字段缺失的条目单独列出并注明缺失比例。验收标准覆盖数、跨层变更回流率这类依赖特定字段的指标，缺失比例过高时只作参考，不进入汇总对比。等层级数据积累两个周期后，再扩大统计范围并比较前后变化。
子需求数量少，是不是说明需求分解得太粗？
不能单凭数量下结论。子需求数量受需求类型影响很大，优化类需求本身可能只需要一两条子需求就能独立验收。判断是否过粗，要同时看单条规模是否超出团队可完成区间、验收标准是否覆盖完整、变更是否频繁回到父需求层。数量少且验收标准清晰、规模可控，通常说明分解得当；数量少但规模偏大、验收标准缺失，才提示分解过粗。
跨层变更回流率高，应该先改拆分规则还是先改评审流程？
先定位回流发生在哪一层。如果回流集中在产品需求层，说明该层的边界与验收标准在拆分时没有定清，优先在需求评审中补充边界说明和验收标准检查项；如果回流分散在多个层级，且与需求类型强相关，则更适合按需求类型分别调整拆分规则。两种动作可以并行，但调整后要按同一口径再统计一个周期，观察回流率是否下降，避免只改流程不验证效果。
不同团队的迭代周期不一样，颗粒度指标还能横向比较吗？
直接合并计算会失真，建议各自按自身迭代周期统计后比较分布形态，而不是比较单一平均值。例如看子需求数量的分布区间、单条规模落在可完成区间内的比例，这类结构特征受周期长度影响较小。样本量过小时，可以延长到两个季度再看。确实需要合并时，先按团队和需求类型分组，再在组内比较，不把不同口径的数据强行平均。
需求层级和父子关联数据在工具里怎么承载，才能支撑这类统计？
需要工具在同一套数据中保留层级标识、父子关联、状态流转时间、验收标准条目和变更记录。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，功能复杂的需求可用子工作项拆解并关联研发和测试任务，使需求、研发、测试环节保持串联。这些结构为按父需求归集子需求、按层级统计提供了数据来源；具体的颗粒度指标仍需按本文口径自行统计。
