无实现关联的需求占比，指统计期内进入统计范围的需求中，没有关联到任何实现记录的需求数占需求总数的比例。计算时先固定需求范围与时间窗，再逐条判定是否存在有效实现关联，用“无实现关联需求数 ÷ 统计范围内需求总数 × 100%”得出结果。本文给出可直接复算的口径、取数规则、计算步骤与解读限制，并配套说明反向指标“有实现无需求关联的变更占比”。
要点总览（TL;DR）
- 无实现关联的需求占比 = 统计范围内无有效实现关联的需求数 ÷ 需求总数 × 100%；先固定需求状态范围、时间窗和归集口径，结果才可跨期比较。
- 有效关联以系统记录为准：关联字段非空且指向统计范围内的有效需求；关联为空、指向已取消或已合并需求，均计为无实现关联。
- 配套统计反向指标“有实现无需求关联的变更占比”，用未关联有效需求的实现记录数 ÷ 实现记录总数 × 100%，发现绕过需求的工作。
- 分母为零时报告写“本期无可统计对象”，不输出 0%；百分比与分子分母同时呈现，便于复算。
- 指标只反映关联完整性，解读要结合趋势和明细，不设统一达标线，也不单独作为绩效结论。
这个指标要回答什么问题
这个指标服务于一个具体判断：在需求到实现的链路上，有多少需求没有留下任何实现痕迹。它把“需求是否被真正落到开发动作上”变成可以定期检查的数字，帮助团队在版本推进过程中尽早发现被遗漏、被搁置或只在口头流转的需求。
评估对象是需求记录与实现记录之间的关联关系。所谓实现记录，通常包括代码提交、合并请求、构建项、发布项等能证明需求进入开发交付环节的凭证。指标只检查这条关联是否存在，不评价需求写得是否清楚、实现方案是否合理、测试是否充分。
需要明确指标的边界。占比高低不能说明需求价值大小，也不能说明交付质量好坏。一个需求没有实现关联，可能是尚未排期、被拆分到其他需求、通过配置或数据操作完成，也可能是关联动作没有登记。指标提供的是排查线索，最终结论要回到明细逐条确认。
指标定义、统计范围与分母口径
建议同时统计两个方向相反的指标，配套使用才能看清链路全貌。正向指标看需求是否都有实现，反向指标看实现是否都来自需求。两者的口径需要在同一份文档中固定下来，并在多个统计周期内保持一致，否则跨期比较会失真。
| 指标名 | 分子 | 分母 | 时间窗 | 单位 | 排除项 |
|---|---|---|---|---|---|
| 无实现关联的需求占比 | 统计范围内无有效实现关联的需求数 | 统计范围内需求总数 | 与分母同一时间窗，按需求创建时间或完成时间归集，口径固定后不随意切换 | 百分比，保留一位小数，同时保留分子分母原始数值 | 已取消、重复、已合并到其他需求的需求 |
| 有实现无需求关联的变更占比 | 统计范围内未关联任何有效需求的实现记录数 | 统计范围内实现记录总数 | 与分子同一时间窗，按实现记录的提交或合入时间归集 | 百分比，保留一位小数，同时保留分子分母原始数值 | 纯配置调整、依赖升级、回滚等无业务需求来源的变更，需在口径中列明 |
需求状态范围要事先写清楚。常见做法是只纳入“已进入开发”及之后状态的需求，例如开发中、待测试、已上线；处于草稿、待评审、已搁置状态的需求不进入分母，因为它们尚未承诺进入实现环节。如果团队希望观察积压情况，可以另设一个“未排期需求占比”，与本文指标分开统计，避免口径混杂。
时间窗的选择取决于检查目的。按周或按迭代统计，适合在版本节奏中及时发现遗漏；按月或按季度统计，样本量更大，趋势更稳定。归集时间建议二选一并长期沿用：按需求创建时间归集，反映当期新增需求的实现覆盖；按需求完成时间归集，反映当期交付需求的关联完整度。两种口径的结果不可直接比较，切换时要在报告中注明。
排除项要逐类说明处理方式。已取消的需求从分母中剔除；重复需求若已合并到主需求，只保留主需求；被拆分的长需求，子需求各自作为独立统计对象，父需求若不再单独实现，应在口径中约定按子需求汇总或整体剔除。所有排除动作都要留下记录，便于复核。
数据从哪里取、关联怎么判定
需求侧需要导出四类字段：需求编号、当前状态、创建时间、完成时间。如果需求有父子层级或所属版本，也一并导出，便于后续按版本或模块切片分析。实现侧需要导出：提交或合并请求的标识、提交时间或合入时间、关联的需求标识。若使用构建或发布项作为实现凭证，则导出构建号、发布时间及关联需求字段。
有效关联的判定标准可以归纳为三条同时成立：关联字段存在且非空；关联字段指向的需求在统计范围内且状态有效；一条实现记录至少关联一个有效需求，或一个需求至少关联一条有效实现记录。判定以系统记录为准，口头说明、聊天记录、会议纪要都不作为关联证据。
常见的数据情形需要分别处理。关联字段为空，计为无关联；关联指向已取消或已合并的需求，按无效关联处理，需求侧计入无实现关联，变更侧计入无需求关联；一条实现记录关联多个需求时，只要其中任一需求有效，该记录即视为有需求关联，需求侧则各自独立判定；一个需求关联多条实现记录时，只要存在一条有效记录，该需求即视为有实现关联。多对多关系不影响判定方向，只影响明细的展开方式。
当两个系统的数据无法直接比对时，例如需求编号规则不一致、实现记录缺少需求字段，应在报告中说明数据不可比的原因和影响范围，并给出替代取证方式，例如按分支命名规范或提交信息中的需求号做辅助匹配，同时标注匹配的可靠性。数据缺口本身也是改进线索，可以推动团队补齐关联字段。
在工具层面，需求与实现记录的关联需要落在同一套工作项体系中才便于统计。ONES 的 ALM 研发管理方案以数字线程贯通需求、开发、测试、变更与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯。团队可以在需求工作项上按状态与时间筛选出统计范围内的需求清单，再沿关联关系核对是否存在对应的开发与交付记录，把本文的取数与判定动作落到具体的工作项和关联字段上。具体可关联的对象类型与字段形式以实际产品配置为准。
计算步骤与公式
整个计算可以拆成五步，每一步都留下可复核的中间产物，便于他人按同样口径复算。
- 确定统计期与需求清单。写明起止日期、归集时间口径、纳入的状态范围，导出需求明细表，逐条标注是否属于排除项，得到分母。
- 匹配实现记录并标记关联状态。将实现记录按需求标识与需求清单做匹配，为每条需求标注“有有效关联”或“无有效关联”，形成判定明细表。
- 按公式计算两个占比。无实现关联的需求占比 = 无有效关联需求数 ÷ 需求总数 × 100%；有实现无需求关联的变更占比 = 未关联有效需求的实现记录数 ÷ 实现记录总数 × 100%。
- 处理分母为零的情况。当期没有纳入统计的需求或实现记录时，报告写“本期无可统计对象”，不输出百分比，也不写 0%，避免把“没有数据”误读为“表现良好”。
- 抽样复核与交叉验证。随机抽取若干条判定为“无关联”的需求，回到系统核对是否确实没有实现记录；同时用反向指标交叉检查，若正向指标很低而反向指标很高，说明关联登记可能集中在少数需求上，需要进一步看明细。
公式本身简单，容易出错的地方在分母和判定。建议在明细表中保留需求编号、状态、关联记录数、判定结果四列，汇总数字由明细直接得出，不做手工调整。报告中的百分比与分子分母同时呈现，读者可以自行验算。
一个可复算的例子
以下为演示情景，数据为假设值，仅用于说明计算过程。
假设某统计月按需求创建时间归集，纳入“开发中”及之后状态的需求共 120 条，剔除已取消 6 条、重复合并 4 条后，分母为 110 条。逐条匹配实现记录后，有 18 条需求没有任何有效实现关联，其余 92 条至少关联一条有效实现记录。
同一统计月内，实现记录共 260 条，其中 26 条未关联任何有效需求，其余 234 条关联到有效需求。
| 指标 | 分子 | 分母 | 占比 |
|---|---|---|---|
| 无实现关联的需求占比 | 18 | 110 | 16.4% |
| 有实现无需求关联的变更占比 | 26 | 260 | 10.0% |
复算过程：18 ÷ 110 × 100% ≈ 16.4%，26 ÷ 260 × 100% = 10.0%。两个数字放在一起看，说明当期既有需求未落到实现，也有实现未挂到需求，两条链路都需要排查。若下期分母变为 0，例如统计期内没有新需求进入开发，则报告写“本期无可统计对象”。
结果怎么解读、有哪些限制
占比偏高时，先区分成因再决定动作。流程缺失表现为需求评审通过后没有拆解开发任务；关联习惯不足表现为开发做了但没在系统里登记关联；统计口径问题表现为把尚未排期的需求纳入了分母，或实现记录的时间窗与需求错位。三类成因对应的改进动作不同，前者补流程节点，中者补登记规范，后者修口径。
解读应结合趋势和明细，单期数值的信息量有限。连续几个周期观察同一口径下的变化，再抽取无关联需求逐条查看状态和备注，往往能发现具体卡点，例如某类需求长期停留在开发中、某个模块的实现记录普遍缺少需求字段。趋势稳定下降说明关联习惯在改善，突然上升则要检查是否发生了口径调整或系统迁移。
指标的限制需要写进报告。它只反映关联完整性，与需求质量、实现质量、测试充分性没有直接因果关系；关联齐全不代表交付正确，关联缺失也不必然意味着工作没做。这个指标不适合单独作为团队或个人绩效结论，也不建议设置统一的达标线，不同团队的需求粒度、开发方式和工具使用习惯差异较大，合理区间应由团队在若干周期内自行观察形成。
把两个指标配套使用，并保留明细和口径说明，这个度量就能成为定期检查需求到实现链路的稳定工具。ONES 在需求、开发、测试、变更与发布之间建立关联关系，需求发生变化时可沿关联分析受影响的任务、测试和交付内容，并保留过程追踪依据，为这类定期检查提供可回溯的记录基础；统计视图的具体形式以实际产品配置为准。
常见问题
需求被拆分或合并后，统计时怎么处理才不重复计数？
拆分和合并要在口径中事先约定，并留下处理记录。常见做法是：被拆分的长需求若不再单独实现，父需求整体剔除，只统计各子需求；若父需求仍保留独立实现，则父子各自作为统计对象。重复需求合并到主需求后，只保留主需求，被合并的需求从分母中剔除。无论采用哪种方式，都要在明细表中标注处理原因，保证同一口径下不重复计数，也便于他人复核。
需求通过配置、数据修正或外部系统完成，没有代码提交，算不算无实现关联？
按本文口径，这类需求在系统里没有关联到任何实现记录，会计入无实现关联。但这不等于工作没有做，而是说明实现凭证的形式与代码提交不同。处理方式有两种：一是在口径中把配置单、数据变更单等纳入实现记录范围，并确保它们能关联到需求；二是在报告中单列这类需求，说明其完成方式。两种方式都需要在统计前固定下来，避免同一类需求在不同周期被归入不同类别。
两个指标一个很低、一个很高，说明什么问题？
正向指标低说明多数需求都有实现关联，反向指标高说明不少实现记录没有挂到需求上。两者同时出现，通常意味着关联登记集中在少数需求上，或者存在绕过需求直接开发的情况。此时应抽取无需求关联的实现记录，查看提交信息、分支命名和变更内容，判断是登记遗漏还是需求外工作。若确认是登记习惯问题，改进动作是补关联规范；若确认是流程外工作，则需要回到需求受理环节排查。
统计周期内需求数量很少，指标波动很大，还能用吗？
样本量小时，单期百分比容易被个别需求放大，例如 10 条需求中 1 条无关联就是 10%。这种情况下建议拉长统计窗口，按月或按季度统计，或者把连续几个周期的分子分母合并计算，而不是只看单期百分比。同时保留明细，说明当期样本量。样本过少时，指标更适合作为排查线索，不宜直接用于横向比较。
用 ONES 做这类统计，需要提前准备什么？
核心是让需求与实现记录在同一套工作项体系中建立可查询的关联。ONES 的 ALM 研发管理方案以数字线程贯通需求、开发、测试、变更与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯。团队可以先在需求工作项上按状态和时间筛选出统计范围内的需求清单，再沿关联关系核对开发与交付记录。具体可关联的对象类型、字段形式和统计视图以实际产品配置为准，建议在正式统计前先用一个小周期试跑，确认取数字段与判定规则一致。
