需求分解颗粒度没有通用达标线，判断它是否合适，要看分解结果能否支撑排期、验收和变更定位。本文把“颗粒度是否合适”转成可计算的问题：用层级深度、叶子需求规模分布、可独立验收比例、变更回流率四项指标，在固定时间窗和统一下钻口径下统计，再结合评审与变更证据解释结果。评估对象限于需求层级与叶子需求，执行任务拆解不在本文范围内。
要点总览（TL;DR）
- 颗粒度评估的对象是需求层级与叶子需求，判断标准是分解结果能否支撑排期、验收和变更定位，不设通用达标线。
- 用四项指标衡量：层级深度（层）、叶子需求规模分布（百分比）、可独立验收比例（百分比）、变更回流率（百分比），每项都需固定分母与时间窗。
- 缺失值单列、不默认合格：未填规模与未写验收条件的叶子需求单独统计，比例反映全部叶子需求的真实状态。
- 按五步执行：圈定范围导出层级数据、代入公式计算、按需求类型分组找异常、结合评审与变更证据解释、设定复评时点验证调整效果。
- 指标只反映分解结果的结构特征，不直接等于交付质量；层级深度不宜设统一达标线，样本过少时只报条数不报比例。
评估目标：颗粒度要回答哪几个判断
颗粒度评估的起点是明确要回答什么，而不是先收集数据。评估对象是需求层级结构和叶子需求，结论用于调整分解规范，不用于考核个人。把“颗粒度合适吗”拆成以下四个判断问题，每个问题对应后续的一项或一组指标。
| 判断问题 | 具体含义 | 评估结论的用途 |
|---|---|---|
| 层级是否过深或过浅 | 从顶层需求到叶子需求经过多少层，是否存在为拆而拆的中间层，或顶层需求直接落到过大的叶子需求 | 调整层级规范，明确哪些需求类型允许三层以上 |
| 叶子需求能否独立验收 | 叶子需求是否带有明确、可判定的验收条件，能否单独提测和关闭 | 补充验收条件模板，规定叶子需求的完成定义 |
| 变更能否定位到单条需求 | 需求变更发生时，能否落到具体叶子需求并评估影响范围 | 修正分解边界，减少跨层级连带变更 |
| 规模分布是否集中 | 叶子需求按规模分档后是否集中在少数档位，是否存在明显偏大的条目 | 设定叶子需求的规模参考区间 |
这四个问题共同构成评估目标清单。层级深度回答结构问题，可独立验收比例回答交付问题，变更回流率回答稳定性问题，规模分布回答拆分均衡问题。四项都指向同一件事：分解结果是否让排期、验收和变更定位变得可操作。
指标与范围：用哪几个指标衡量颗粒度
四项指标各有明确的公式、单位和对应判断。统计前先固定需求类型、时间窗和纳入排除规则，否则不同批次的数据无法比较。
| 指标 | 公式 | 单位 | 时间窗 | 对应判断 |
|---|---|---|---|---|
| 层级深度 | 从顶层需求到叶子需求经过的层数，统计最大值与中位数 | 层 | 取评估时点的存量需求结构 | 层级是否过深或过浅 |
| 叶子需求规模分布 | 各规模档位的叶子需求条数 ÷ 叶子需求总条数 | 百分比 | 与评估周期一致，如一个季度 | 规模分布是否集中 |
| 可独立验收比例 | 具备明确验收条件的叶子需求条数 ÷ 叶子需求总条数 | 百分比 | 同上 | 叶子需求能否独立验收 |
| 变更回流率 | 时间窗内发生跨层级变更的需求条数 ÷ 需求总条数 | 百分比 | 固定窗口，如近90天 | 变更能否定位到单条需求 |
规模分档需要事先约定依据。常用做法是按故事点分为1、2、3、5、8及以上几档，没有故事点估算的团队可按人天分为半天以内、半天到一天、一天到三天、三天以上。分档依据写入评估说明，中途不调整，否则分布占比失去可比性。
统计范围包括三项约定：纳入哪些需求类型，例如只统计产品需求和业务需求，排除缺陷与纯技术任务；时间窗的起止日期；排除规则，例如已取消、已合并或测试性质的需求不计入分母。范围一旦确定，本次评估内保持一致。
数据口径与证据：分母、缺失值和定性材料
指标能否复算，取决于分母是否固定、缺失值是否单列。建议以叶子需求条数作为规模分布和可独立验收比例的分母，以需求总条数作为变更回流率的分母，并在报告中同时标注分母数值和缺失条数。
缺失值处理遵循“单列、不默认合格”的原则。未填写规模估算的叶子需求，单独计入“规模未填”一栏，不归入任何规模档位，也不从分母中剔除；未写明验收条件的叶子需求，计入“验收条件缺失”，不计入可独立验收的分子。这样比例反映的是全部叶子需求的真实状态，而不是只对填写完整的条目计算。
定量指标需要定性材料解释。需求评审记录用来说明层级划分的决策依据，验收条件文本用来核对“明确验收条件”的判定是否一致，变更单用来追溯跨层级变更的触发原因。三类材料在评估时抽样调取，与指标异常点对应。
数据不可比的情形主要有两类：不同需求类型的分解习惯不同，例如平台类需求天然层级更深；不同团队对规模分档的理解不一致，同样标为3个故事点的需求实际工作量差异较大。遇到这两类情况，按需求类型和团队分组分别统计，组间只做趋势对照，不直接合并计算总体比例。
计算与评估步骤：从取数到结论的操作顺序
一次完整的颗粒度评估按以下五步执行，每步都有明确输入和产出，便于他人复算。
- 确定范围与时间窗，导出层级数据。输入是需求管理中的层级关系、规模字段、验收条件字段和变更记录；动作是圈定需求类型与起止日期，导出每条需求的层级路径；产出是一张包含需求编号、层级、父级、规模、验收条件、变更标记的明细表。
- 按公式计算四项指标。动作是逐项代入公式，同时记录每个指标的分子、分母和缺失条数；产出是指标计算表，任何一项比例都能从明细表复算出来。
- 按需求类型分组对比，识别异常层级。动作是把指标按需求类型拆分，找出层级深度明显偏大或偏小的分组，以及规模分布集中在最大档位的分组；产出是异常清单，标注具体需求编号。
- 结合评审与变更证据解释结果。动作是抽取异常需求对应的评审记录和变更单，判断层级过深是流程要求还是拆分习惯，变更回流是需求边界不清还是外部条件变化；产出是原因说明和调整建议。
- 设定复评时点，验证调整效果。动作是在分解规范调整后约定复评日期，通常间隔一个完整迭代周期或一个季度，用同一口径重新计算四项指标；产出是前后对比，确认调整是否带来预期变化。
在工具层面，需求层级和验收条件需要有稳定的承载位置，指标才取得出来。ONES 支持用子工作项对功能复杂的需求进行拆解，并关联研发和测试任务；迭代规划时，团队就需求与验收标准达成一致后再拆分，测试人员依据验收标准编写和执行用例。这些动作让层级路径和验收条件在系统中留有记录，为上述取数提供基础。层级深度的统计报表、规模字段的分布统计等具体取数方式，需按团队实际配置确认。
例子：一次颗粒度评估的算例
以下为演示数据，用于说明计算过程，不代表任何真实团队的水平。
某季度纳入统计的需求共120条，其中叶子需求80条。层级分布为：两层结构30条，三层结构70条，四层结构20条，最大层级深度4层，中位层级深度3层。规模方面，80条叶子需求中填写了故事点的65条，未填写15条；已填条目中，1点8条、2点20条、3点22条、5点10条、8点及以上5条。验收条件方面，80条叶子需求中写明可判定验收条件的52条，缺失28条。变更方面，近90天内120条需求中有18条发生跨层级变更。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 层级深度 | 最大值4层；中位数3层 | 最大4层，中位3层 |
| 叶子需求规模分布 | 以80条为分母：1点8÷80=10.0%；2点20÷80=25.0%；3点22÷80=27.5%；5点10÷80=12.5%；8点及以上5÷80=6.3%；未填15÷80=18.8% | 3点档占比最高，未填占18.8% |
| 可独立验收比例 | 52÷80=65.0% | 65.0%，缺失28条 |
| 变更回流率 | 18÷120=15.0% | 15.0% |
解读这组结果：规模分布集中在2点和3点两档，合计52.5%，说明多数叶子需求的拆分尺度较为一致；8点及以上占6.3%，可抽查这几条是否应继续拆分。未填规模占18.8%，比例偏高，应先补齐字段再判断分布。可独立验收比例65.0%，意味着约三分之一的叶子需求缺少可判定验收条件，这是本次评估最需要处理的问题。变更回流率15.0%，需结合变更单判断跨层级变更是否集中在少数几条需求上。
分母为零或样本过少时单独处理。若某需求类型在本时间窗内只有3条叶子需求，规模分布百分比的分母过小，单条变动就会造成十几个百分点的波动，此时只报告条数，不报告比例，或将该类型并入相邻类型统计并注明。若某类型没有任何叶子需求，可独立验收比例的分母为零，结论记为“无样本”，不记为0%。
据此可形成的调整方向包括：为叶子需求补充验收条件模板，要求关闭前必须填写；对8点及以上的叶子需求组织一次拆分复核；把规模字段设为必填。这些调整的局限在于，它们改善的是记录完整性和拆分尺度，交付周期是否缩短还受排期、依赖和资源影响，不能由本次指标直接推出。
解读与限制：指标能说明什么、不能说明什么
四项指标反映的是需求分解结果的结构特征，包括层级形态、规模集中度、验收条件覆盖和变更分布。它们能帮助团队发现层级异常、验收条件缺口和变更集中点，但不能直接等同于交付质量。可独立验收比例高，说明叶子需求的完成定义清楚；交付是否按时，还取决于估算准确性和依赖管理。
层级深度与团队习惯、需求类型密切相关。平台型、合规型需求往往需要更多层级承载约束条件，创新探索型需求可能两层就足够。因此不宜为层级深度设定统一达标线，更合理的做法是按需求类型分别观察历史区间，把明显偏离自身历史水平的分组列为复核对象。
样本量小或时间窗过短时，结论不稳定。变更回流率在只有十几条需求的窗口内，一两条变更就能让比例大幅跳动。建议时间窗至少覆盖一个完整迭代周期，需求条数较少时延长窗口或合并相邻周期统计，并在报告中注明样本量。
评估结论应转化为分解规范的调整，例如验收条件必填、规模分档定义、层级审批要求，并设定复评时点验证效果。指标本身不构成对个人的评价依据，也不应作为唯一的流程改进依据。把一次评估的结果与后续复评对比，才能判断调整是否真正改变了分解行为。
常见问题
需求层级深度有没有一个通用的合理层数？
没有通用层数标准。层级深度与需求类型和团队习惯相关：平台型、合规型需求往往需要更多层级承载约束条件，创新探索型需求可能两层就足够。更可行的做法是按需求类型分别观察自身历史区间，把明显偏离历史水平的分组列为复核对象，而不是给所有需求设同一个层数上限。
团队还没有故事点估算，规模分布怎么统计？
可以改用工作量分档，例如半天以内、半天到一天、一天到三天、三天以上，按人天记录后计算各档占比。关键是分档依据在评估前写入说明，评估中途不调整，否则不同批次的分布占比失去可比性。未填写规模的叶子需求单独计入“规模未填”，不归入任何档位。
某个需求类型只有几条叶子需求，比例还能用吗？
样本过少时比例波动很大，单条变动就可能造成十几个百分点的变化。此时只报告条数，不报告比例，或将该类型并入相邻类型统计并注明合并原因。若某类型没有任何叶子需求，可独立验收比例的分母为零，结论记为“无样本”，不记为0%。
评估发现问题后，怎么确认调整真的有效？
在分解规范调整后约定复评日期，通常间隔一个完整迭代周期或一个季度，用同一口径、同一分母定义重新计算四项指标，做前后对比。对比时注意样本量是否可比，若时间窗内需求条数差异较大，应延长窗口或合并相邻周期，并在报告中注明。指标变化只能说明分解行为是否改变，交付周期是否缩短还需结合排期与依赖情况判断。
需求层级和验收条件在工具里怎么承载，才能取到数？
层级路径和验收条件需要有稳定的记录位置，指标才取得出来。以 ONES 为例，功能复杂的需求可用子工作项拆解并关联研发和测试任务；迭代规划时团队就需求与验收标准达成一致后再拆分，测试人员依据验收标准编写和执行用例，这些动作会在系统中留下层级与验收记录。层级深度统计报表、规模字段分布统计等具体取数方式，需按团队实际配置确认。
