债务预算是什么
债务预算是把技术债偿还当作有配额的常规工作，而不是等攒够了再立项。做法是每个迭代固定拿出产能的一部分用于偿还与工程改进，配额由团队持有并写进排期，与功能同列同估点。它解决的问题是默认排序：在没有约束的情况下，功能永远优先，偿还永远排在最后。
机制要点
| 配额 | 每迭代固定比例产能，常见 10% 到 20% |
|---|---|
| 选题 | 从债务台账按利息排序，取前几项 |
| 排期 | 与功能同列同估点，不藏在功能估算里 |
| 验收 | 必须给出利息下降的可验证证据 |
| 滚动 | 本期未用完说明原因并结转到下期 |
典型使用场景
- 迭代节奏稳定的团队：固定留出偿还配额，避免长期只做功能导致维护成本缓慢上升
- 债务台账积压：用配额逐项消化，而不是一次性大专项带来的排期冲击
- 新模块上线后清偿：把上线时的临时兼容层与开关纳入下一期预算
- 故障复盘后：把根因改进项直接排进下一期预算，而不是只写进文档
- 多团队协作的公共模块：由使用方按比例共同承担偿还投入
迭代排期示例
迭代排期示例
# 迭代总产能 10 人日
- 功能开发：8 人日
- 债务偿还：2 人日（本期选题：报表模块入口收敛起步）
# 本期验收标准
- 报表入口从 3 处收敛到 1 处，旧入口加弃用告警
- 新增一处门禁：禁止新代码直接引用旧入口
# 结转规则
- 若被紧急需求占用，须在复盘写明原因，下期补回配额执行对照
| 情形 | 表现 | 处理方式 |
|---|---|---|
| 配额被功能挤占 | 连续两个迭代未投入 | 列为流程问题，在复盘提出并追回配额 |
| 花了时间但利息未降 | 只做了重构没有度量前后差异 | 要求偿还任务带可验证的验收指标 |
| 选题过大做不完 | 单期完不成、下期被迫继续 | 拆成可单期交付的最小改进项 |
| 配额长期用不完 | 团队不认为有值得做的事 | 重新审视台账排序与利息数据是否失真 |
| 只还债不交付 | 配额被当默认工作量 | 配额是上限不是目标，功能价值仍是主线 |
配额的正当性来自利息数据：改动耗时对比、缺陷集中区、门禁红项数量。没有这些数据，预算讨论会退化为「要不要投入」的立场之争；有数据，讨论才落在「投入哪一项收益最大」。
与冻结式维护配合使用：利息可控且改动频率低的模块不必占用配额，直接冻结新增、只修缺陷，把配额留给高频热点模块。判断依据是变更频率与影响面，不是代码看起来有多糟。
落地检查清单
- 配额比例写进了排期规则，而不是口头共识
- 每个偿还项都有可验证的验收指标与前后对比
- 债务台账按利息排序，并且定期更新
- 未用完的配额有结转记录与原因说明