技术债偿还预算是什么
技术债要真正被偿还，必须有可执行的预算机制：常见做法是固定容量比例（每个迭代留出一定人力处理债务项）或专项窗口（大版本前停功能集中治理），再结合风险数据排序，把有限的容量投到最可能引发故障或拖慢交付的地方。
怎么排优先级
用信号排序比用感觉排序有效：故障来源、改动频率高且易错的模块、维护工时长、即将失去官方支持的版本，都是可量化的依据。度量上跟踪债务项存量、修复率以及相关故障与工时是否下降；预留容量如果没有保护机制，会被需求一再挤占，等于没有。
基本信息
| 机制 | 固定容量比例、专项窗口或与项目捆绑 |
|---|---|
| 排序依据 | 风险与成本影响：故障源、改动频率、维护工时 |
| 度量 | 债务项数量、修复率、相关故障与工时趋势 |
| 保护 | 预留容量进入排期并对外可见，避免被需求挤占 |
典型使用场景
- 迭代排期：每个迭代固定额度处理高优债务项
- 大版本前：停功能一段时间集中重构与升级
- 故障复盘后：把根因相关的债务项并入跟踪清单
- 版本到期前：提前规划框架或数据库版本升级
- 交付速度下降：用改动频率与工时数据定位拖慢点
- 新人难上手：补齐缺失的文档与测试作为债务项处理
容量与跟踪示例
容量与跟踪示例
每个迭代预留 15%-20% 容量处理债务项 # 写进排期
高优债务与故障复盘行动合并跟踪，共用一份清单
每季度回顾：完成率、存量变化、相关事故是否下降
超期项：要么拆小再做，要么明确放弃并说明理由
# 度量口径固定，避免用“感觉好多了”替代结论排序信号
| 信号 | 含义 | 处理建议 |
|---|---|---|
| 故障高频来源 | 稳定性受直接威胁 | 优先处理，与故障复盘合并 |
| 改动频率高且易错 | 交付速度被拖慢 | 补测试与重构，控制单次改动量 |
| 依赖版本即将到期 | 安全与支持风险上升 | 提前排期升级并预留回滚 |
| 维护工时占比高 | 人力被持续消耗 | 评估重构或替换的整体收益 |
债务项要写成有明确完成条件的工作项（如“补上核心链路集成测试并纳入流水线”），模糊的“优化架构”无法验收，也无法排期。