技术债评估要先把“评什么、为什么评”定下来，再选择指标、固定口径和时间窗，让结果能够复算、跨期比较并支撑决策。常见做法是把债务落到债务条目、涉及代码范围、关联缺陷和维护工时上，用存量、新增率、债务密度、修复投入占比等指标回答不同问题。本文给出指标定义、计算公式、执行步骤和一个模块的演示算例，并说明结果解读的边界。
要点总览（TL;DR）
- 技术债评估先定决策目标：偿还优先级排序、偿还节奏与投入规划、治理效果验收，三类目标对应不同输出物和评估粒度。
- 常用指标包括债务条目存量与新增率、债务密度、修复投入占比、债务相关缺陷占比及平均修复时长，每个指标需写明统计对象和适用范围。
- 口径要固定公式、分子分母、单位、时间窗和缺失值规则；存量按时点取数，新增率按时间窗统计，分母为零记为不适用。
- 执行流程为确定范围与口径、登记核对债务条目、取数计算、交叉校验、形成结论，技术负责人、研发负责人和项目经理分工负责。
- 指标反映存量与投入关系，不能直接证明质量提升；范围调整、统计方式变化会导致跨期不可比，需重算历史数据或重建基线。
评估目标：技术债评估要回答哪几个决策问题
技术债评估的起点是决策问题，而非指标本身。同一批债务数据，用于排优先级、排投入节奏和验收治理效果时，需要的粒度、时间窗和输出物并不相同。先明确评估要支撑哪类决策，再决定统计范围和指标组合，可以避免收集了一堆数字却无法落到行动。
常见的三类目标及其输出物如下：
| 决策目标 | 要回答的问题 | 主要输出物 | 评估粒度 |
|---|---|---|---|
| 偿还优先级排序 | 先还哪些债务，哪些可以延后 | 按模块或债务条目排序的清单，附影响范围与关联缺陷 | 模块、债务条目 |
| 偿还节奏与投入规划 | 每个周期投入多少工时，节奏是否可持续 | 按迭代或季度拆分的投入计划，含偿还工时占比目标 | 团队、迭代、季度 |
| 治理效果验收 | 一段时间治理后，存量与投入关系是否改善 | 两期或多期对比的验收结论，含口径说明 | 系统、模块、季度 |
评估范围需要提前划清。本文讨论的是债务条目的识别、度量与治理决策；已经确认的功能缺陷走缺陷管理流程，按缺陷的严重程度、修复时限等规则处理，不纳入债务指标的计算。重构的具体手法、代码改造方案也不在评估范围内。范围边界写进评估说明，后续取数时才能保持一致。
债务条目、工时和缺陷数据通常分散在需求、任务、缺陷和代码库中。在研发管理工具里把债务登记为可追踪的工作项，并与模块、迭代、工时记录关联，可以让取数环节少一次人工汇总；具体字段和报表形式需要按团队现有工具配置核验。
指标与范围：技术债评估用哪些指标、统计边界怎么划
指标选择围绕三类问题展开：债务有多少、增长多快；债务集中在哪些范围；偿还投入和债务带来的缺陷影响有多大。每个指标都要写明统计对象和适用范围，否则同名指标在不同团队之间无法比较。
| 指标 | 统计对象 | 回答的问题 | 适用范围 |
|---|---|---|---|
| 债务条目存量 | 统计时点处于未关闭状态的债务条目数 | 当前待处理债务的规模 | 系统、模块、团队 |
| 债务新增率 | 时间窗内新增债务条目数÷期初存量 | 债务积累速度相对存量是否加快 | 按周、迭代或季度 |
| 债务密度 | 债务涉及代码行（或模块数）÷统计范围代码行（或模块数） | 债务在代码范围内的集中程度 | 模块、系统 |
| 修复投入占比 | 偿还债务工时÷总研发工时 | 团队有多少研发投入用于还债 | 团队、迭代、季度 |
| 债务相关缺陷占比 | 关联债务条目的缺陷数÷同期缺陷总数 | 债务对缺陷产生的关联影响 | 模块、系统、季度 |
| 债务相关缺陷平均修复时长 | 债务相关缺陷从创建到关闭的平均时长 | 债务相关问题的处理成本 | 模块、系统 |
统计范围按系统、模块或团队划分，三者选其一作为主口径，其他维度作为下钻。纳入规则要写明：哪些债务条目计入（例如已登记且标注所属模块的条目），哪些排除（例如已确认功能缺陷、重复登记条目、测试环境临时问题）。排除规则越具体，后续复核越容易执行。
债务密度有两种可选口径：按代码行或按模块数。代码行口径适合模块内部粒度较细的场景，模块数口径适合模块规模差异大、代码行统计不稳定的场景。同一份评估报告内只使用一种口径，并在报告中注明，避免混用导致结果不可比。
数据口径：分子分母、时间窗与缺失值怎么定
口径决定结果能否复算。每个指标需要固定公式、分子、分母、单位和时间窗，并约定分母为零、数据缺失和口径变更时的处理方式。下表给出常用口径，团队可按自身数据条件调整，但调整后要同步更新说明。
| 指标 | 公式 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|---|
| 债务条目存量 | 统计时点未关闭债务条目数 | 未关闭债务条目 | 无 | 条 | 时点值，按周末或迭代末取数 |
| 债务新增率 | 新增债务条目数÷期初存量 | 时间窗内新增条目 | 期初未关闭条目数 | 百分比 | 周、迭代或季度 |
| 债务密度 | 债务涉及代码行÷统计范围代码行 | 债务条目关联的代码行数 | 统计范围内代码总行数 | 百分比 | 与代码快照同一时点 |
| 修复投入占比 | 偿还债务工时÷总研发工时 | 登记为债务偿还的工时 | 同期总研发工时 | 百分比 | 迭代或季度 |
| 债务相关缺陷占比 | 债务相关缺陷数÷同期缺陷总数 | 关联债务条目的缺陷 | 同期全部缺陷 | 百分比 | 季度 |
| 债务相关缺陷平均修复时长 | 债务相关缺陷修复总时长÷缺陷数 | 各缺陷从创建到关闭的时长之和 | 同期关闭的债务相关缺陷数 | 小时或天 | 季度 |
时间窗要固定并与统计节奏一致。存量按时点取数，新增率按时间窗统计，两者分开计算，不能把期内存量与新增混在一个数字里。跨期比较时，两期使用相同的时间窗长度和相同的取数时点规则，例如都取迭代最后一个工作日的快照。
缺失值处理需要事先约定。工时未记录时，该条目不计入修复投入占比的分子，同时在报告中标注未记录条目的数量；模块未标注债务时，该条目计入存量但不计入按模块的债务密度，并列入待补录清单。分母为零时，该指标记为“不适用”并注明原因，不用零值参与排序或平均值计算。口径发生变更时，保留变更前后的对照数据，或在报告中说明变更点，跨期结论只使用同一口径下的数据。
计算与评估步骤：从取数到形成结论的流程
评估按固定流程执行，每一步都有明确的输入、动作和产出，便于复核和交接。以下步骤适用于单次评估，也适用于按季度重复执行的治理验收。
- 确定范围与口径。技术负责人确认本次评估的系统或模块范围、指标清单、时间窗和缺失值规则，形成一页口径说明。产出：评估口径说明。
- 登记与核对债务条目。研发负责人组织各模块负责人补录债务条目，标注所属模块、涉及代码范围和关联缺陷。产出：债务条目清单。
- 取数与计算。项目经理按口径从工时记录、缺陷记录和代码统计中取数，逐项计算指标。产出：指标计算表。
- 交叉校验。技术负责人抽样复核债务条目与代码范围的对应关系；项目经理对比两期数据，检查分母是否一致、异常值是否有合理解释。产出：校验记录。
- 形成结论。按决策目标输出排序清单、投入计划或验收结论，并附口径说明和校验记录。产出：评估报告。
角色分工上，技术负责人对债务条目的技术判断和范围划分负责，研发负责人对条目登记质量和模块归属负责，项目经理对取数、计算和报告一致性负责。校验方法包括：随机抽取一定比例的债务条目，核对关联代码行与模块标注；对比相邻两期的分母，确认统计范围没有悄然扩大或缩小；对明显偏离历史区间的指标逐条查原因，排除取数错误后再进入结论。
算例：一个模块的技术债评估怎么算出来
以下为演示情景，数据为假设值，用于说明计算过程，不代表任何真实项目结论。假设某系统有三个模块，统计时间窗为一个季度，代码行口径统计债务密度。
| 模块 | 代码行 | 债务涉及行数 | 债务偿还工时 | 总研发工时 | 债务相关缺陷数 | 缺陷总数 |
|---|---|---|---|---|---|---|
| 模块A | 40,000 | 6,000 | 320 | 1,600 | 12 | 40 |
| 模块B | 25,000 | 1,500 | 160 | 1,200 | 5 | 30 |
| 模块C | 60,000 | 2,400 | 200 | 2,000 | 6 | 50 |
逐项计算：
- 债务密度：模块A为6,000÷40,000=15.0%；模块B为1,500÷25,000=6.0%；模块C为2,400÷60,000=4.0%。
- 修复投入占比：模块A为320÷1,600=20.0%；模块B为160÷1,200=13.3%；模块C为200÷2,000=10.0%。
- 债务相关缺陷占比：模块A为12÷40=30.0%；模块B为5÷30=16.7%；模块C为6÷50=12.0%。
三个指标的方向一致：模块A的债务密度、修复投入占比和债务相关缺陷占比均最高，说明债务集中在较大比例的代码范围内，且已与较多缺陷关联，偿还投入也相对更高。按综合结果排序，模块A优先偿还，模块B次之，模块C可以按常规节奏处理。如果团队只按债务涉及行数绝对值排序，模块C的2,400行会排在模块B之前，但结合代码规模和缺陷影响，模块C的实际紧迫度低于模块B，这正是使用密度和占比指标的意义。
排序结论还需要结合业务影响确认。例如模块A若处于核心交易链路，优先级可以进一步提前；若模块A处于低频使用的后台功能，则可以与模块B合并排期。评估结果提供排序依据，最终排期由技术负责人和业务负责人共同确认。
解读与限制：结果怎么用、哪些结论不能下
指标反映的是债务存量、分布和投入之间的关系，不能直接证明质量提升。修复投入占比上升，可能说明治理力度加大，也可能说明债务问题集中爆发；债务密度下降，可能来自实际偿还，也可能来自统计范围扩大导致分母增加。解读时要回到分子分母的变化来源，结合缺陷趋势和业务影响判断。
以下情况会导致跨期不可比，需要在报告中说明或暂停跨期结论：统计范围调整，例如新增或移出模块；代码行统计方式变化，例如是否包含自动生成代码；工时记录规则变化，例如债务偿还工时的登记口径调整；缺陷关联规则变化，例如关联债务条目的判定标准放宽。出现这些变化时，可以用同一口径重算历史数据，或在新口径下重新建立基线，不直接拿新旧两期数字做升降判断。
单指标不构成全部绩效评价。债务条目存量高，可能说明登记充分而非问题严重；修复投入占比低，可能说明债务尚未进入偿还阶段。评估结论用于排序、排期和验收，个人或团队的绩效评价需要结合交付结果、缺陷处理和业务目标综合判断。建议每个季度复盘一次口径：检查缺失值比例是否下降、分母是否稳定、指标是否仍能区分模块差异，并根据复盘结果修正统计规则，修正记录与评估报告一并留存。
常见问题
技术债评估和缺陷管理怎么划清边界？
评估范围在开始取数前就要写进口径说明。已经确认的功能缺陷走缺陷管理流程，按缺陷的严重程度和修复时限处理，不计入债务条目存量和债务密度。技术债评估关注的是债务条目的识别、度量与治理决策，包括哪些债务先还、每期投入多少、治理后存量与投入关系是否改善。
实际操作中，一条问题可能先以缺陷形式出现，修复时发现根因是设计或结构问题，这时可以另建债务条目并关联该缺陷，缺陷本身仍按缺陷流程关闭。关联关系用于计算债务相关缺陷占比，不改变缺陷的处理路径。
团队刚开始做技术债评估，指标要不要一次全部上齐？
可以从两三个指标起步，优先选能直接支撑当前决策的。如果当前主要问题是排不出偿还顺序，先做债务条目存量、债务密度和债务相关缺陷占比；如果主要问题是投入节奏，先做修复投入占比和新增率。
指标增加会带来取数成本和口径维护成本，尤其是工时记录和代码行统计，需要团队形成稳定的登记习惯。建议先跑一个季度，检查缺失值比例和分母是否稳定，再决定是否补充平均修复时长等指标。指标清单调整时同步更新口径说明，保证前后两期可比。
工时没有单独记录债务偿还，修复投入占比还能算吗？
可以算，但要先约定缺失值规则。常见做法是要求债务条目在任务或工作项上单独登记工时，未登记的条目不计入分子，同时在报告中标注未记录条目的数量，让读者知道这个比例是下限而非全量。
如果长期缺失比例偏高，这个指标就失去区分度，此时可以改用替代口径，例如按债务条目的计划工时估算，或先只统计已完整登记的模块。替代口径同样要写进说明，并在跨期比较时保持一致，避免新旧口径混用。
债务密度按代码行算还是按模块数算，怎么选？
代码行口径适合模块内部代码规模差异不大、代码统计比较稳定的场景，能反映债务在代码范围内的集中程度。模块数口径适合模块规模差异大、代码行统计口径不统一的情况，例如部分模块包含大量自动生成代码。
两种口径不能在同一份报告里混用。选定一种后，在报告中注明统计方式和代码快照时点。如果后续要切换口径，用新口径重算历史数据或重新建立基线，不直接拿新旧两期数字比较升降。
评估结果能不能直接用于团队绩效考核？
不建议直接使用。债务条目存量高，可能说明登记充分，也可能说明问题确实多；修复投入占比低，可能说明债务尚未进入偿还阶段，也可能说明工时登记不完整。这些指标反映的是存量、分布和投入之间的关系，缺少业务影响和交付结果的上下文。
更合适的用法是把评估结果作为排期和复盘的输入：排序清单用于确定偿还顺序，投入计划用于安排迭代资源，验收结论用于判断治理方向是否有效。绩效评价需要结合交付结果、缺陷处理和业务目标综合判断，指标只作为其中一类参考信息。
