产品进入多版本并行维护阶段后，补丁维护评估需要同时回答两个问题：维护负担有多大，补丁质量是否稳定。规模指标反映资源占用和发布节奏，质量指标反映补丁是否可靠、遗留缺陷是否收敛。两类指标只有固定版本范围、时间窗和分母口径，才能跨版本、跨月份比较；单看补丁数量容易得出错误结论。
要点总览（TL;DR）
- 补丁维护评估分规模与质量两条线：规模看维护版本数、补丁发布次数、补丁承载条目数和维护人力投入；质量看补丁回退率、补丁引入新缺陷比例、遗留缺陷存量与账龄、发布后缺陷逃逸数。
- 每个指标都要固定版本范围、时间窗和分母口径：回退率以同期补丁版本总数为分母，引入新缺陷比例以同期补丁承载缺陷总数为分母，分母为零记“不适用”。
- 解读顺序是先规模后质量：规模判断维护负担是否可持续，质量判断补丁是否稳定、遗留缺陷是否收敛，单看补丁数量不能得出质量结论。
- 回退率偏低可能来自回退记录不全，遗留缺陷账龄受分级标准影响，指标适合用于改进方向和资源安排，不宜直接作为个人考核结论。
- 补丁版本、缺陷和回退事件作为可查询记录留存，按版本分组、按时间窗汇总的取数才能复算。
评估目标：规模与质量分别回答什么问题
补丁维护的规模与质量是两条独立的评估线，各自回答不同问题，不能互相替代。
规模线回答“维护负担与资源占用”：当前有多少个已交付版本仍在维护、统计窗口内发布了多少次补丁、这些补丁承载了多少缺陷与需求条目、投入了多少维护人力。规模指标用于判断维护工作是否可持续、资源是否够用、是否需要推动版本收敛或停止维护。
质量线回答“补丁是否稳定、遗留缺陷是否收敛”：补丁发布后是否被回退、是否引入新缺陷、遗留缺陷存量与账龄是否下降、发布后是否有缺陷逃逸到客户侧。质量指标用于判断补丁交付过程是否可靠、遗留问题是否在收敛。
两类指标的组合解读原则是：先看规模判断负担是否可持续，再看质量判断补丁是否稳定。规模大而质量稳定，说明维护投入有效；规模大且质量波动，说明维护过程需要改进；规模小但质量差，说明少量补丁仍存在交付风险。补丁数量多本身不能直接得出质量差的结论，需要结合维护版本数和缺陷结构一起看。
指标与范围：维护版本、时间窗与统计对象
多版本并行时，统计范围不固定就无法复算。开始取数前，先把以下四项写成书面约定。
纳入统计的版本清单与排除规则
列出当前处于维护状态的已交付版本，明确每个版本的维护起止时间。排除规则需要事先写明，例如：已宣布停止维护的版本不计入；仅做安全修复、不发布常规补丁的版本是否计入需单独约定；内部测试版本不计入已交付维护版本。版本清单应在统计窗口内保持不变，中途新增或退出维护的版本单独标注。
统计时间窗
时间窗可选自然月或发布周期，同一组指标在连续多个窗口内应使用同一种时间窗。自然月便于与人力投入、财务周期对齐；发布周期便于与补丁发布节奏对齐。跨窗口的补丁以补丁版本发布日期归属窗口，缺陷以创建日期或关闭日期归属窗口，两种归属方式需在口径表中写明并保持一致。
统计对象
统计对象包括四类：补丁版本（每次补丁发布记为一个补丁版本）、缺陷单（补丁承载的缺陷与补丁引入的新缺陷）、回退事件（补丁被回退的记录）、人力投入（维护人力的人日或人时）。每类对象都要有唯一标识，便于按版本和时间窗汇总。
多版本并行的分组方式
先按版本分组计算，再汇总到产品线。分组维度至少包括：维护版本、时间窗、缺陷严重级别。汇总时区分“各版本合计”和“产品线整体”，避免大版本的量掩盖小版本的质量问题。
| 统计要素 | 定义 | 记录要求 |
|---|---|---|
| 维护版本清单 | 统计窗口内处于维护状态的已交付版本 | 版本号、维护起止时间、排除原因 |
| 时间窗 | 自然月或发布周期，全组指标统一 | 起止日期、归属规则 |
| 补丁版本 | 每次补丁发布记录一条 | 版本号、发布日期、关联缺陷与需求 |
| 缺陷单 | 补丁承载缺陷与补丁引入缺陷 | 创建时间、严重级别、关联补丁 |
| 回退事件 | 补丁被回退的记录 | 回退时间、原因、关联补丁 |
| 人力投入 | 维护人力的人日或人时 | 统计口径、是否含测试与发布支持 |
数据口径：每个指标的公式、分母与缺失值处理
以下口径表给出规模与质量指标的公式、分子分母、单位和缺失值规则。所有比率指标的分母为零时记为“不适用”，不做补零或补一处理。
规模指标
| 指标 | 公式 | 单位 | 说明 |
|---|---|---|---|
| 维护版本数 | 统计窗口内处于维护状态的已交付版本计数 | 个 | 按版本清单逐一点数，中途退出维护的版本按窗口内实际维护天数折算或单独标注 |
| 补丁发布次数 | 统计窗口内发布的补丁版本数 | 次 | 以补丁版本发布日期归属窗口 |
| 补丁承载条目数 | 补丁关联的缺陷数与需求数之和 | 条 | 缺陷与需求分别统计，可再按严重级别或优先级拆分 |
| 维护人力投入 | 统计窗口内投入维护的人日或人时之和 | 人日/人时 | 口径需写明是否含测试、发布支持与客户支持 |
质量指标
| 指标 | 公式 | 分母 | 缺失值处理 |
|---|---|---|---|
| 补丁回退率 | 被回退的补丁版本数 ÷ 同期发布的补丁版本总数 | 同期补丁版本总数 | 分母为零记“不适用”；回退记录缺失时先补记录，不按零回退计算 |
| 补丁引入新缺陷比例 | 补丁发布后确认由该补丁引发的新缺陷数 ÷ 同期补丁承载缺陷总数 | 同期补丁承载缺陷总数 | 分母为零记“不适用”；归因未确认的缺陷不计入分子，单独列示待确认数 |
| 遗留缺陷存量 | 统计截止日仍未关闭的缺陷数 | 不适用（计数指标） | 按严重级别分组呈现 |
| 遗留缺陷账龄 | 统计截止日减缺陷创建时间 | 不适用（天数指标） | 按账龄分档统计数量，分档阈值事先约定 |
| 发布后缺陷逃逸数 | 补丁发布后由客户或线上环境发现、且应在本补丁中解决的缺陷数 | 不适用（计数指标） | 需明确“应在本补丁中解决”的判定依据 |
单位与统计粒度约定：比率指标以百分比表示，保留一位小数；计数指标以“个/次/条”表示；账龄以天为单位。统计粒度统一到“版本×时间窗”，汇总时先分组后合计。账龄分档阈值（例如7天、30天、90天）需在组织内事先约定，不同分级标准下的账龄分布不可直接横向比较。
计算与评估步骤：从取数到结论的流程
按以下步骤执行，可以从原始记录得到可复核的评估结论。
- 固定范围。确认维护版本清单、时间窗和统计对象，写入口径表并由维护负责人确认。
- 取数。从版本记录取补丁版本与发布日期，从缺陷记录取缺陷创建时间、严重级别、关联补丁和关闭状态，从回退记录取回退事件，从工时记录取人力投入。
- 核对。抽查补丁版本与缺陷的关联是否完整，核对回退记录是否有遗漏，确认人力投入口径与约定一致。记录不完整的先补记录，再进入计算。
- 按版本分组计算。对每个维护版本分别计算规模指标和质量指标，分母为零的指标标记“不适用”。
- 汇总。将各版本结果汇总到产品线，同时保留分组明细，避免合计值掩盖单版本问题。
- 联合判读。先看规模判断负担是否可持续，再看质量判断补丁是否稳定，最后对照遗留缺陷账龄分布判断遗留问题是否收敛。
- 形成结论并复核。结论写明数据范围、时间窗、异常项和待确认项，由维护负责人复核后归档，作为下一窗口的对比基线。
示例：三个维护版本一个月的指标计算
以下为演示情景，数据为假设值，用于说明公式代入过程。
某产品有V1、V2、V3三个已交付版本处于维护状态，统计窗口为一个自然月。当月共发布补丁12次，其中2次被回退；补丁承载缺陷60个，发布后确认由补丁引入新缺陷6个；遗留缺陷按账龄分档统计如下。
| 版本 | 补丁发布次数 | 被回退次数 | 承载缺陷数 | 引入新缺陷数 | 遗留缺陷（≤30天） | 遗留缺陷（31–90天） | 遗留缺陷（>90天） |
|---|---|---|---|---|---|---|---|
| V1 | 3 | 0 | 12 | 1 | 8 | 5 | 2 |
| V2 | 4 | 1 | 20 | 2 | 10 | 6 | 3 |
| V3 | 5 | 1 | 28 | 3 | 12 | 9 | 6 |
| 合计 | 12 | 2 | 60 | 6 | 30 | 20 | 11 |
补丁回退率＝2 ÷ 12 ≈ 16.7%。补丁引入新缺陷比例＝6 ÷ 60＝10%。分版本看，V1回退率为0，V2和V3各为25%和20%，V3的引入新缺陷比例为3 ÷ 28 ≈ 10.7%，与整体接近，但V3的补丁发布次数和遗留缺陷存量都最高。
规模与质量对照：三个版本合计发布补丁12次、承载缺陷60条，维护负担集中在V3；整体回退率16.7%、引入新缺陷比例10%，质量处于可观测状态。遗留缺陷中账龄超过90天的有11个，其中V3占6个，说明V3的遗留问题收敛较慢。判断结论是：V3需要优先安排遗留缺陷清理和补丁发布前验证，V1维护负担相对轻、质量稳定。该结论仅适用于本演示数据，不作为达标线。
解读与限制：指标不能证明什么
指标用于改进方向和资源安排，解读时需要守住以下边界。
- 补丁数量多不等于质量差。补丁数量与维护版本数、缺陷结构相关，版本多、缺陷基数大时补丁自然多，需结合维护版本数和缺陷严重级别一起看。
- 回退率低可能源于记录不全。回退流程未留痕或回退记录缺失时，回退率会偏低，解读前先核对记录完整性。
- 遗留缺陷账龄受分级标准影响。不同严重级别的缺陷处理时限不同，账龄分布需按级别分组呈现，跨团队比较前先统一分级标准。
- 指标不构成因果保证。指标变化可能来自版本结构、客户反馈量或统计口径调整，不能直接归因于某个改进动作。
- 指标用于改进而非个人考核结论。把补丁数量或回退率直接作为个人绩效依据，容易导致少报回退、延迟记录等行为，扭曲数据。
- 达标线需自行设定。回退率、引入新缺陷比例等指标没有通用达标线，应基于组织历史基线设定观察阈值，并在口径表中注明。
用工作项与版本记录承载指标取数
上述指标能否复算，取决于补丁版本、缺陷和回退事件是否作为可查询的记录留存。把这三类对象纳入同一套工作项与版本记录体系，取数才有稳定来源。
具体管理动作包括：每次补丁发布建立一个补丁版本记录，关联本次承载的缺陷与需求工作项；缺陷工作项记录创建时间、严重级别、关联补丁和关闭状态；补丁被回退时建立回退事件记录并关联原补丁版本；维护人力投入按版本和时间窗登记。这样，按版本分组、按时间窗汇总的取数路径可以直接从记录中生成，遗留缺陷存量和账龄也能按截止日查询。
ONES 支持以工作项承载缺陷与需求、以版本记录组织发布内容，并可按版本、时间、状态等条件筛选和汇总工作项，适合作为补丁维护指标的取数基础。具体字段配置和报表形式需结合团队现有流程确定，本文不展开产品功能细节。
常见问题
维护中的版本中途退出维护，规模指标怎么算？
在版本清单里标注该版本的维护起止时间，按窗口内实际维护天数折算，或单独列示并在汇总时说明。关键是同一口径在连续窗口内保持一致，中途变化的版本单独标注，避免与全程维护的版本直接相加后失真。
回退率算出来很低，是否说明补丁质量好？
先核对回退记录是否完整。回退流程未留痕、回退事件没有关联到原补丁版本时，回退率会偏低。确认记录完整后，再结合补丁引入新缺陷比例和发布后缺陷逃逸数一起看，单一回退率不足以判断补丁质量。
遗留缺陷账龄的分档阈值应该怎么定？
按缺陷严重级别分别设定处理时限，再据此划分账龄档位，例如按7天、30天、90天分档。阈值需在组织内事先约定并写入口径表，不同分级标准下的账龄分布不能直接横向比较。分档确定后，连续多个窗口沿用同一套阈值，才能观察遗留缺陷是否收敛。
维护人力投入统计到哪一步，测试和发布支持算不算？
口径由组织自行约定，但必须在指标表中写明。常见做法是分别记录开发修复、测试验证和发布支持的人日或人时，再决定是否合并为维护人力总投入。口径一旦确定，跨窗口比较时保持一致；口径调整时在结论中注明，避免与历史数据直接对比。
这些指标可以直接用于个人绩效考核吗？
不建议。补丁数量、回退率等指标受版本结构、缺陷基数和记录完整度影响，直接与个人绩效挂钩容易导致少报回退、延迟记录等行为，反而扭曲数据。更合适的用法是作为团队改进方向和资源安排的依据，个人层面的评价结合具体工作内容判断。
