季度技术债复盘要回答三个问题：存量有多大、增长有多快，对业务造成了哪些可观测影响，哪些债应当先治。本文给出一套可复算的评估方法：存量侧用台账条目、涉及代码规模和预估偿还工时计量，累积速度用季度新增与偿还工时之比观察；业务影响侧用受影响需求的交付周期、变更失败率、故障时长和受影响用户或订单量折算。两组指标按同一时间窗对齐后，用“影响×紧迫度”排序，形成下一季度的治理顺序。
要点总览（TL;DR）
- 存量用三层指标计量：技术债台账条目数、涉及代码规模、预估偿还工时（人日），单看条目数会把大小债混为一谈。
- 累积速度用季度新增工时÷季度偿还工时观察，比值大于1说明存量扩大，配合季度净变化看绝对量。
- 业务影响用受影响需求交付周期延长、变更失败率、故障时长、受影响用户或订单量折算，归因口径需在复盘前约定。
- 紧迫度用影响分×紧迫度分排序，再结合预估偿还工时取舍，排序分只决定先后，不直接当绩效依据。
- 指标反映相关性与趋势，口径变更或数据缺失时跨季度不可比，需如实标注并记录变更原因。
季度复盘要回答的三个评估问题
技术债评估的价值在于把“这块代码很烂、早晚要还”这类主观判断，转成可比较、可排序的治理决策输入。季度复盘不需要给技术债下一个精确的总价，而需要支撑三类决策，每类决策对应一组问题。
| 决策类型 | 要回答的问题 | 需要的指标组 | 产出 |
|---|---|---|---|
| 规模判断 | 存量有多大、本季度增长多快 | 存量指标、累积速度指标 | 存量总量、季度净变化、趋势方向 |
| 影响判断 | 技术债对业务造成了哪些可观测影响 | 业务影响指标 | 延迟天数、失败率、故障时长、受影响用户或订单量 |
| 排序判断 | 哪些债先治、依据是什么 | 影响分与紧迫度分的合成结果 | 治理优先级列表与建议动作 |
三类决策有先后依赖：先确认存量与速度，才能判断治理是在追赶还是在补漏；先建立业务影响的归因口径，排序才有业务依据；最后才谈优先级。复盘会前应把这三类问题写成议程，避免会上直接跳到“先重构哪个模块”的争论。
存量与累积速度的指标与统计范围
存量建议分三层计量，三层结合使用。单看条目数容易把大小债混为一谈：一条涉及三个文件的重复代码和一条横跨支付链路的架构缺陷，条目数都记1，但偿还成本相差一个数量级。
| 指标 | 定义与公式 | 单位 | 统计时间窗 | 数据来源 |
|---|---|---|---|---|
| 技术债条目数 | 台账中状态为“已确认、未偿还”的条目计数，按模块、类型、严重度分组 | 条 | 季度末快照 | 技术债台账 |
| 涉及代码规模 | 各条目关联的代码行数或文件数之和，按语言与模块统计；同一文件被多条债务关联时只计一次 | 行 / 个 | 季度末快照 | 代码库统计 + 台账关联字段 |
| 预估偿还工时 | 各条目预估偿还人日之和；由提出人与模块负责人共同估算，并在台账中记录估算依据 | 人日 | 季度末快照 | 台账估算字段 |
| 季度新增工时 | 本季度新登记条目的预估偿还工时之和 | 人日 | 本季度 | 台账登记时间 |
| 季度偿还工时 | 本季度关闭条目在登记时记录的预估偿还工时之和 | 人日 | 本季度 | 台账关闭时间 |
| 累积速度比 | 季度新增工时 ÷ 季度偿还工时 | 比值 | 本季度 | 由上行两项计算 |
| 季度净变化 | 季度新增工时 − 季度偿还工时 | 人日 | 本季度 | 由上行两项计算 |
累积速度比大于1说明存量在扩大，小于1说明在收敛，等于1说明新增与偿还持平。比值适合看方向，净变化适合看绝对量，两者一起看：一个团队比值0.8但基数很大，另一个团队比值1.5但基数很小，治理策略并不相同。偿还工时统一使用条目登记时的预估值，避免实际投入与预估口径混用导致跨季度不可比。
纳入范围需要事先约定。建议纳入：已确认的设计缺陷、重复代码、缺失的自动化测试、过期依赖、已知的性能瓶颈、文档缺失等由技术负责人确认的条目。建议排除：已确认的功能Bug归缺陷管理流程单独统计，不重复计入技术债存量，否则会高估存量并扭曲累积速度；纯代码风格问题若已由静态检查自动约束，可不单独立条。纳入与排除规则写入台账说明，季度间保持一致。
业务影响的指标与数据口径
业务影响侧的目标是建立技术债与业务结果之间可核验的对应关系，而不是证明因果。指标选取遵循两条原则：可归因到具体条目或模块，可复算且分母明确。
| 指标 | 公式 | 分母 | 缺失值处理 |
|---|---|---|---|
| 受影响需求交付周期延长 | 受影响需求的实际上线日期 − 原计划上线日期，取受影响需求的中位数与总和 | 本季度受技术债影响的需求数 | 无受影响需求时记为“不适用”，不记0 |
| 变更失败率 | 失败变更数 ÷ 变更总数 | 本季度变更总数 | 变更总数为0时记为“不适用” |
| 故障总时长 | 归因于技术债的故障持续时长之和 | 不涉及比率，按季度累计 | 未确认归因的故障单列，不并入 |
| 平均恢复时长 | 归因故障总时长 ÷ 归因故障次数 | 归因故障次数 | 次数为0时记为“不适用” |
| 受影响用户数 | 归因故障或性能问题影响到的去重用户数 | 不涉及比率，按事件累计 | 无法统计时标注“未采集” |
| 受影响订单量 | 归因事件期间失败或延迟的订单数 | 不涉及比率，按事件累计 | 同上 |
归因口径必须在复盘前约定，否则季度会上容易陷入“这次故障到底算不算技术债”的争论。建议做法：由需求负责人或值班工程师在事件记录中标注疑似技术债原因，季度复盘时由技术负责人复核确认；未确认归因的数据单列展示，不并入技术债影响统计。归因记录应写明关联的台账条目编号，使影响数据可以回溯到具体债务。
分母与缺失值处理直接影响可比性。比率类指标在分母为零时记为“不适用”而非零，否则会把“没有发生变更”误读为“变更质量完美”。受影响用户数、订单量这类绝对量指标，若某季度未采集，应标注“未采集”并在趋势图中留空，不用相邻季度插值填充。
计算步骤：从台账到紧迫度排序
评估流程按固定顺序执行，保证结果可复算、跨季度可比。
- 统一时间窗与数据来源。确定季度起止日期，存量指标取季度末快照，速度与影响指标取整个季度区间。台账、需求管理系统、变更记录、故障记录使用同一时间窗导出，导出时间与口径写入复盘记录。
- 计算存量指标。按模块汇总条目数、涉及代码规模、预估偿还工时，形成存量基线。
- 计算累积速度。统计季度新增工时与偿还工时，计算速度比与净变化，判断存量处于扩大还是收敛状态。
- 计算业务影响指标。按归因规则筛选确认条目，计算交付周期延长、变更失败率、故障时长、受影响用户或订单量。
- 归一化并合成紧迫度分。影响分取业务影响指标的加权归一化结果，紧迫度分取存量规模与累积速度的加权结果，两者相乘得到排序分。
- 排序并结合偿还成本取舍。按排序分从高到低排列，再结合预估偿还工时判断投入产出，形成下一季度治理清单。
归一化建议采用季度内相对排名或极值缩放，权重在复盘会上固定并跨季度保持一致，否则排序结果不可比。排序分只用于决定先后，不直接等同于绩效评价。分母为零的比率指标记为“不适用”，不参与加权；数据不可比时（如口径变更），该指标本季度不纳入排序，并在复盘记录中说明原因。
台账、工时估算与需求交付、故障数据需要落在同一套工作项和报表里，评估才不必每季度手工拼接。在ONES中，技术债条目可以作为工作项登记模块、类型、严重度和预估工时，需求交付与故障记录同样以工作项承载，季度复盘时按同一时间窗筛选并汇总，归因字段保留条目编号以便回溯。这样存量、速度与影响三组数据来自同一数据源，口径变更也有记录可查。
一个季度的算例
以下为演示情景，数字用于说明计算过程，不代表任何真实团队。
某团队第一季度末技术债台账共42条，涉及代码约18600行，预估偿还工时合计310人日。本季度新增条目11条、预估工时合计96人日；关闭条目7条、登记时预估工时合计64人日。业务侧：本季度受技术债影响的需求6个，实际上线日期比原计划平均延后9天，合计延后54天；变更总数120次，失败14次；归因于技术债的故障3次，总时长7.5小时，影响用户约2.3万人，受影响订单约1400单。
| 指标 | 计算 | 结果 |
|---|---|---|
| 累积速度比 | 96 ÷ 64 | 1.5，存量在扩大 |
| 季度净变化 | 96 − 64 | +32人日 |
| 变更失败率 | 14 ÷ 120 | 11.7% |
| 平均恢复时长 | 7.5 ÷ 3 | 2.5小时 |
| 受影响需求平均延后 | 54 ÷ 6 | 9天 |
假设两条重点债务的归一化打分如下：债务A为支付链路的重试逻辑缺陷，影响分0.9、紧迫度分0.8，排序分0.72，预估偿还12人日；债务B为报表模块的重复代码，影响分0.3、紧迫度分0.9，排序分0.27，预估偿还20人日。排序结果指向先治债务A：它以更低的偿还成本覆盖了更高的业务影响。债务B存量规模大但业务影响有限，可排入后续季度或与报表改版合并处理。这个例子说明排序分的作用：它把“存量最大”和“最该先治”区分开。
结果解读与使用限制
这套指标能说明存量的规模与趋势、业务影响的可观测部分，以及治理顺序的相对依据。它不能说明的同样需要明确。
- 相关性不等于因果。指标反映的是技术债与业务结果之间的相关性和趋势，不能单独证明某项债务导致了某次业务损失。归因记录和复核的作用是提高可信度，而非建立因果保证。
- 单指标不能替代全部判断。条目数少不代表风险低，速度比低也不代表治理到位；排序分高只说明在本季度口径下优先级靠前，仍需结合架构演进方向和业务规划做取舍。
- 口径变化影响可比性。纳入范围、归因规则、打分权重任何一项调整，都会改变跨季度对比的结果。变更需在台账中记录时间与原因，跨口径数据不直接比较。
- 数据缺失要如实标注。未采集的指标留空并注明，不用估算值填充，否则趋势图会给出虚假的稳定感。
复盘结论的用法是进入下一季度治理计划：把排序靠前的条目转为带负责人和预估工时的治理工作项，设定季度偿还目标，并在下季度复盘时对照速度比是否回落、业务影响指标是否改善。指标改善本身也需要多个季度观察，单季度波动不宜直接作为治理成效的结论。
常见问题
技术债条目和已确认的功能Bug如何划分，避免存量重复计算？
建议在台账说明中事先写清纳入与排除规则：已确认的功能Bug归缺陷管理流程单独统计，不重复计入技术债存量。技术债条目聚焦设计缺陷、重复代码、缺失的自动化测试、过期依赖、已知性能瓶颈、文档缺失等由技术负责人确认的问题。若某条Bug的根因是技术债，可在缺陷记录中关联台账条目编号，影响统计时按归因规则处理，存量侧仍只计一次。
季度新增与偿还工时用预估值还是实际投入，跨季度怎么保持可比？
偿还工时统一使用条目登记时的预估工时，新增工时同样取登记时的预估值，这样分子分母口径一致，跨季度可以比较。实际投入工时可另行记录用于校准估算准确度，但不混入速度比计算，否则会出现预估与实际口径交错、趋势失真的情况。若团队决定改用实际工时，需在台账中记录切换时间和原因，切换前后的季度不直接对比。
某季度没有发生归因故障，故障时长和恢复时长该怎么记？
比率类指标在分母为零时记为“不适用”，不记0。平均恢复时长的分母是归因故障次数，次数为0时该指标不参与加权和排序，并在复盘记录中注明原因。故障总时长按季度累计，没有归因故障时记0是合理的，因为它本身是绝对量而非比率。受影响用户数、订单量若未采集，标注“未采集”并留空，不用相邻季度插值填充。
排序分靠前的债务一定先做吗，还需要考虑什么？
排序分决定的是本季度口径下的相对先后，不是唯一依据。排完序后还要结合预估偿还工时看投入产出：影响分高但偿还成本极大的条目，可能需要拆分成多个治理工作项分季度推进；影响分中等但偿还成本很低的条目，可以顺手清理。此外还要对齐架构演进方向和业务规划，例如某模块下季度计划整体替换，相关债务就不必单独投入。排序结果是讨论起点，最终清单由复盘会确认。
第一次做这套评估，历史数据不全怎么办？
可以从当季度开始建立基线：先把现有技术债条目补登模块、类型、严重度和预估工时，业务影响侧只统计本季度能确认归因的事件，缺失的指标如实标注“未采集”。第一个季度的结果主要用于建立口径和基线，不急于做跨季度趋势判断。后续季度保持同一时间窗、同一归因规则和同一打分权重，数据积累两到三个季度后再看速度比和影响指标的变化方向。
