评估需求分解颗粒度，要回答的是“层级深度和单条需求的信息量是否匹配团队决策与交付需要”。做法是先用可复算指标刻画现状，再结合团队基线设定目标区间，用一段时间的样本数据计算对照，最后用返工、评审耗时等结果指标解释。本文给出指标定义、取数口径、计算步骤和解读边界，示例数据均为演示情景。
要点总览（TL;DR）
- 评估需求分解颗粒度，先界定对象：需求层级深度与单条需求的信息量，任务拆解方法不在评估范围内。
- 用四个指标刻画现状：层级深度分布、单条需求信息量、拆分比、跨层变更回流率，每个指标只回答一个侧面。
- 计算前先定口径：逐指标写明分子、分母、时间窗、状态过滤与缺失值规则，草稿和作废需求不计入分母。
- 通过标准取自团队历史基线，按需求类型分组设定区间，不套用外部通用达标线。
- 指标反映结构特征，需与返工率、评审耗时交叉验证，结论用于规范调整和评审把关，不宜直接作为个人考核依据。
评估目标：颗粒度要回答哪几个问题
颗粒度评估的对象是需求层级和单条需求的信息量，任务拆解的具体方法不在本篇范围内。把“颗粒度是否合适”这个模糊判断转成可评估的问题，评估才有落点。建议在动手取数前，先写出一份评估问题清单，明确三件事：评什么、判断什么、结果用来做什么。
评估对象包含两个层面。层级层面看需求从顶层到最细层有几层、各层需求数量如何分布；信息量层面看单条需求描述是否完整、验收条件是否写清、一条需求承载的工作是否过大或过碎。这两个层面共同决定一条需求能否被独立评审、独立排期、独立验收。
需要回答的判断问题通常有三类：层级是否过深或过浅，即是否存在为了拆分而拆分、或顶层需求长期不往下拆的情况；单条需求是否过大或过碎，即一条需求是否包含多个可独立交付的目标，或细到无法独立验收；拆分是否稳定，即同一类需求在不同批次、不同人手里的拆分方式是否一致。
评估结果的使用场景决定指标的取舍。用于制定需求规范时，关注信息量指标的分布和典型偏离样本；用于评审把关时，关注单条需求是否达到最低信息量要求；用于流程调整时，关注跨层变更回流率和拆分比的变化趋势。先明确用途，再决定统计范围和精度，可以避免算出一堆用不上的数字。
指标与范围：用哪几个指标刻画颗粒度
刻画颗粒度不需要很多指标，四个指标分别覆盖层级结构、信息量、拆分行为和拆分稳定性，基本够用。每个指标只回答一个侧面，组合起来才能形成判断。
| 指标 | 含义与计算方式 | 衡量的侧面 | 适用范围 |
|---|---|---|---|
| 层级深度分布 | 统计每条顶层需求到最细层需求的层数，输出各层数的需求占比 | 层级是否过深或过浅 | 有明确父子层级结构的需求类型 |
| 单条需求信息量 | 单条需求的验收条件数、描述字数区间、必填字段完整率 | 需求是否过大、描述是否足以支撑评审与验收 | 所有进入评审的需求 |
| 拆分比 | 一个父需求平均拆出的子需求或工作项数量 | 拆分是否充分、是否过度拆分 | 存在父子关系的需求 |
| 跨层变更回流率 | 因拆分不当导致回退修改的需求数 ÷ 同期已拆分需求数 | 拆分结果是否稳定、是否经得起下游检验 | 有变更日志可追溯的需求 |
层级深度分布适合发现结构性问题，例如大部分需求只有一层，说明拆分不足；层数普遍达到四五层，则要检查中间层是否只是传递信息、没有独立价值。单条需求信息量适合做评审门槛，验收条件数是其中最容易核验的一项。拆分比适合观察趋势，同一类需求拆分比突然升高，往往意味着上游需求描述变粗。跨层变更回流率适合验证拆分质量，它把颗粒度问题和下游返工联系起来。
样本范围要在计算前固定：时间窗取多长、纳入哪些需求类型、覆盖哪些团队。新功能、缺陷修复、体验优化的拆分习惯差异明显，混在一起统计会互相干扰，建议按需求类型分组呈现。团队范围同理，跨团队汇总前先确认各团队的层级定义一致。
数据口径与证据：分母、时间窗和缺失值怎么定
口径不统一，指标就不可比。每个指标都要写清分子、分母、时间窗、状态过滤和缺失值规则，形成一份口径说明表，后续换人计算也能复现。
| 指标 | 分子 | 分母 | 时间窗与状态过滤 | 缺失值规则 |
|---|---|---|---|---|
| 层级深度分布 | 各层数对应的顶层需求数 | 同期全部顶层需求数 | 按需求创建时间归集，取已评审及之后状态 | 无子项的需求记为深度1，单独标注 |
| 单条需求信息量 | 验收条件数、描述字数 | 按需求条数逐条统计，不设汇总分母 | 取进入评审时的快照，避免评审后补写干扰 | 无验收条件记为0并计入分布，不剔除 |
| 拆分比 | 子需求或工作项总数 | 有子项的父需求数 | 按父需求关闭时间归集，统计周期建议不少于一个完整迭代批次 | 无子项的父需求不进入分母，单独统计占比 |
| 跨层变更回流率 | 因拆分不当回退修改的需求数 | 同期已拆分需求数 | 按变更发生时间归集，需能关联变更原因 | 变更原因未填写的记录单列，不默认计入分子 |
时间窗的选择影响结论稳定性。按创建时间归集适合观察“进入系统的需求长什么样”，按关闭时间归集适合观察“最终交付的需求怎么拆”。两者不要混用，同一份报告内保持一种归集方式，并在口径表中注明。统计周期过短会放大偶然波动，建议至少覆盖一个完整迭代批次，样本量偏小时只做趋势观察、不下达标结论。
状态口径要明确哪些需求计入。草稿状态的需求描述往往不完整，计入会拉低信息量指标；作废需求不应进入任何分母。建议只统计已评审及之后状态的需求，草稿和作废单独计数备查。缺失值处理的原则是“如实记录、单独标注”，无验收条件的需求记为0并保留在分布中，这样指标才能反映真实情况；把缺失值剔除会让结果虚高。
证据来源主要是需求管理系统的字段数据、评审记录和变更日志。层级关系、验收条件、描述内容来自需求条目本身；评审时间与结论来自评审记录；回退修改来自变更日志中的状态流转和原因字段。取数前先确认这些字段在各团队是否统一填写，字段缺失严重的团队，其指标只作参考。使用 ONES 时，复杂需求可通过子工作项拆解并关联研发与测试任务，需求、任务、测试在同一系统内串联，层级关系和变更记录可以直接作为取数来源，减少跨系统核对的工作量。
计算与评估步骤：从取数到判定通过
计算过程按五步执行，每一步都留下可复算的记录，结论才能被团队接受和复核。
第一步，确定样本范围并导出数据。写明时间窗、需求类型、团队范围和状态过滤条件，导出需求条目的层级关系、验收条件数、描述字数、创建与关闭时间、变更记录。导出时保留需求编号，便于后续定位样本。
第二步，按口径逐指标计算。每个指标记录公式、分子分母数值和中间结果，层级深度分布同时给出各层占比。计算脚本或表格公式一并留存，换人复算应得到相同结果。
第三步，设定目标区间或通过标准。标准来自团队自身历史基线，例如取过去若干批次的中位数作为参考区间，再结合当前业务复杂度调整。不要套用外部通用达标线，不同产品、不同阶段对颗粒度的合理要求本来就不同。通过标准可以写成区间形式，例如“验收条件数中位数不低于3条、层级深度集中在2至3层”。
第四步，对照结果并标注偏离项。把本期数值与目标区间比较，标出超出区间的指标，再下钻到具体需求样本，看是哪些需求拉高了或拉低了指标。偏离项要能对应到需求编号，讨论才有对象。
第五步，复核异常值。异常可能来自口径问题，例如某团队未按规范填写验收条件；也可能来自真实的颗粒度问题，例如某类需求确实拆得过粗。先排除口径原因，再确认是否为真实问题，避免用错误数据推动流程调整。
例子：一个迭代批次的实际计算
以下数据为演示情景，用于说明计算过程，不代表任何真实团队的结果。假设某批次纳入已评审需求40条，其中顶层需求10条，需求类型限定为新功能。
层级深度分布：10条顶层需求中，深度为1层的有2条，2层的有5条，3层的有3条。按顶层需求数计算占比，分别为20%、50%、30%。解读上，2至3层占八成，结构基本合理；深度为1层的2条需求需要抽查，确认是本身足够简单，还是拆分不足。
单条需求信息量：40条需求的验收条件数中位数为2条，其中8条验收条件为0，12条为1条。描述字数中位数为180字。若团队基线为验收条件中位数3条，则本期偏低，且8条无验收条件的需求是主要偏离来源，应逐条核对是否在评审时遗漏。
拆分比：10条顶层需求中，8条有子项，共拆出子需求26条，拆分比为26÷8≈3.25。另有2条无子项，占顶层需求的20%，单独统计而不进入分母，避免分母为零或虚增拆分比。若某条父需求确实无需拆分，这20%属于正常情况；若集中在某一类需求上，则需检查该类需求的描述是否过粗。
跨层变更回流率：同期已拆分需求32条，变更日志中因拆分不当回退修改的有4条，回流率为4÷32=12.5%。若历史基线在8%左右，本期偏高，可结合变更原因字段定位到具体需求，判断是拆分粒度过粗导致下游反复澄清，还是需求本身发生了合理变更。
综合看，本批次的偏离集中在信息量指标：验收条件不足是主要问题，层级结构和拆分比处于可接受范围。改进动作应优先落在评审环节的验收条件把关，而不是全面调整拆分规则。
解读与限制：指标能说明什么、不能说明什么
颗粒度指标反映的是需求的结构特征，与需求质量、交付结果之间是相关关系，不能当作因果结论。层级分布合理，不代表需求写得清楚；拆分比正常，也不保证下游不再返工。指标的价值在于把讨论聚焦到具体样本，而不是给出一个总分。
不同需求类型不宜用同一区间比较。新功能需求通常需要多层级拆解和较多验收条件，缺陷修复可能一条需求就足够，体验优化介于两者之间。分组统计、分组设标准，结论才站得住。跨团队比较前，还要确认各团队对“一层”的定义一致，否则层级深度没有可比性。
样本量小或周期短时，结论不稳定。一个批次只有十几条需求，中位数容易被个别样本拉动，此时更适合看具体样本而非汇总数字。建议连续观察多个批次，看趋势是否持续，再决定是否调整规范。
指标需要与结果指标交叉验证。把颗粒度指标与返工率、评审耗时、需求变更次数放在一起看：如果验收条件数提升后返工率同步下降，说明信息量确实是瓶颈；如果两者没有明显关联，就要重新审视指标是否抓对了问题。交叉验证的目的是解释指标，而不是用结果指标替代颗粒度评估。
最后，这套指标用于团队改进讨论，不宜直接作为个人考核依据。颗粒度受需求本身复杂度、业务节奏影响很大，把它和绩效挂钩容易导致为了达标而机械拆分或堆砌验收条件，反而偏离评估初衷。评估结论落地为规范调整和评审检查项，才能持续改善需求分解质量。
常见问题
团队第一次做颗粒度评估，应该从哪个指标入手？
建议从单条需求信息量入手，尤其是验收条件数。它取数简单，评审时就能核对，团队对“一条需求该写几条验收条件”也容易形成共识。先统计一个批次的验收条件数分布，标出无验收条件的需求，再讨论这些需求是评审遗漏还是本身不需要验收条件。层级深度分布和拆分比可以随后补充，用来解释信息量偏离背后的结构原因。
需求类型混杂时，颗粒度指标还能直接汇总比较吗？
不建议直接汇总。新功能需求通常需要多层级拆解和较多验收条件，缺陷修复可能一条需求就足够，体验优化介于两者之间，混在一起统计会互相干扰。做法是按需求类型分组计算，分组设定目标区间，汇总时只呈现各组结果和占比。如果团队需求类型划分本身不清晰，先统一分类口径，再谈颗粒度比较。
没有历史基线，怎么设定颗粒度的通过标准？
可以先用当前数据建立基线：连续统计两到三个完整迭代批次，取各指标的中位数和分布区间作为参考，再结合业务复杂度做小幅调整。第一轮评估的重点是看清现状和典型偏离样本，通过标准可以写得宽一些，例如只规定验收条件数下限和层级深度的常见范围。运行几个批次后，再根据返工率、评审耗时的变化收窄区间。
评估发现验收条件普遍不足，应该先改流程还是先改工具？
先确认问题出在哪个环节。如果评审记录显示验收条件在评审时就没有被检查，优先在评审检查项中加入验收条件要求，并明确无验收条件的需求不进入开发。如果团队有意愿填写但字段分散、难以汇总，再考虑在需求管理系统中统一字段和模板。ONES 支持将复杂需求通过子工作项拆解并关联研发与测试任务，需求、任务、测试在同一系统内串联，层级关系和变更记录可作为取数来源，减少跨系统核对的工作量。
颗粒度指标可以用于个人绩效考核吗？
不建议。颗粒度受需求本身复杂度、业务节奏影响很大，与个人绩效挂钩容易导致为了达标而机械拆分或堆砌验收条件，反而偏离评估初衷。更合适的用法是把评估结论落地为需求规范调整和评审检查项，在团队层面跟踪趋势。个人层面的讨论可以结合具体需求样本，聚焦“这条需求为什么拆得这么细或这么粗”，而不是给每个人算一个颗粒度分数。
