技术债怎么量化、怎么排进迭代

一句话速记

技术债不能靠”感觉应该重构了”去说服 PM 和老板——必须量化成它正在吃掉多少生产力。三个量化维度：① 时间债——“每次改这个模块比正常多花 X 小时”；② 风险债——“这个旧版本有已知 CVE，不修一次事故的预期损失是 Y”；③ 机会债——“因为这个模块没法复用，每次新项目多花 Z 周”。排进迭代的规则：每个 sprint 固定 15-20% 的容量用于还技术债，不讨论做不做，只讨论优先还哪笔。

通俗解释（5 分钟版）

技术债不是"代码不够漂亮"（那叫审美债）。
技术债是"因为过去做的选择，今天和未来都要反复付利息"。

利息的计算方式：
  1. 时间利息：
     每次有人改到这块代码，都要多花时间理解、绕坑、手动回归。
     你发现一个模块每次 MR review 都要花 3 倍时间？
     这是债务在收利息。

  2. 风险利息：
     一个旧框架没人维护了、有已知安全漏洞。
     现在没出事，但每过一天 "发生事故的概率" 都在累积。
     这是债务本金。

  3. 机会利息：
     因为你不敢动这块代码，新需求只能用更绕的方式实现，
     每次新需求都多花时间——这是债务让你丧失了自由度。

关键细节

怎么量化技术债

方法 1：时间债——用”额外耗时”量化：

记录团队在某模块上的痛感数据：

"每次改订单状态机，需要：
   - 理解旧逻辑的人帮忙看（30 分钟 × 2 人）
   - 测试手动回归 6 个相关场景（2 小时）
   - review 时来回改 3 轮（比正常多 1.5 小时）
   正常修改一个逻辑 2 小时够了，这个模块每次要 5 小时。
   多出的 3 小时就是利息。"

如果你一个月要改这个模块 4 次：
  每月利息 = 3 × 4 = 12 人时
  重构预计需要 40 人时
  → 3.3 个月回本，第 4 个月开始全是赚的
  
这个数字摆在 PM 面前，比"太乱了想重构"有效 10 倍。

方法 2：风险债——用”预期损失”量化：

已知漏洞的风险债：
  框架 X 版本有 CVE，我们还在用旧版本。
  过去类似级别的漏洞，行业里平均 18 个月发生一次被攻击事件。
  一次事件的影响：
    - 线上停机 2 小时
    - 用户数据泄露风险
    - 合规罚款可能
  预估总损失：几十万到几百万。

升级框架需要：2 周开发 + 1 周测试 = 大概 X 万的人力成本。
→ 这是一份保险：花 X 万，规避 Y 倍于 X 的损失。

显然应该修。但你要把这个账算出来，老板才会签字。

方法 3：机会债——用”延迟的新功能价值”量化：

因为你不敢重构搜索模块，每次新的搜索需求都是
"用旧的方式在外面包一层新逻辑"。

Q1 搜索需求花了 3 周。如果模块是干净的只需 1.5 周。
Q2 搜索需求也会是同样的问题。
半年内如果重构了，后面每个需求都省 1.5 周。

量化：
  未来半年预计有 4 个搜索需求
  不重构：4 × 3 周 = 12 周
  重构后：1 周重构 + 4 × 1.5 周 = 7 周
  重构净收益：12 - 7 = 5 周
  
5 周的人力值多少钱？这就是机会债。

怎么排进迭代

固定比例法（最可行）：

每个 sprint 固定拿出一部分容量还技术债：

  容量比例参考：
    团队状态     技术债比例
    新团队       10%（债少，主要在建立规范）
    成熟团队     20%（持续还债不积累）
    老旧项目     30%（债务高企，先止血再开发）

规则：
  - 这个比例是底限不是上限——如果这 sprint 新功能
    恰好少，可以多还一点
  - 还债任务也在 sprint planning 里排，和功能开发
    一样估时、一样 track
  - 还债成果在 sprint review 里展示——"这周我们重构了
    订单查询，之前改一行要 3 小时，现在 30 分钟"

还债优先级排序：

每次规划还债任务时，排优先级：

1. 风险债最高优：
   有安全漏洞、依赖已 EOL 的库、数据库版本快不支持了
   → 不管功能排得多满也要修

2. 高频改动区的债：
   每周都被改的模块 → 利息每天都在滚
   → 优先还

3. 即将要改的债：
   下个月计划要大改的模块 → 先重构再开发
   （在干净地基上盖楼，不要在上一个烂尾楼上接着盖）

4. 沉没债：
   一年没改过的模块，没有安全风险
   → 不去动它。不是所有的旧代码都是技术债。
     没人在改的旧代码不产生利息。

如何跟老板/PM 沟通技术债

✗ "这模块太烂了，我们需要重构。"（主观意见）
✗ "这是历史遗留问题"（这句话的意思是"我没法量化"）

✓ 用收入而非成本的语言：
  "这次重构能让我们下个季度的开发速度提升 40%"
  "不修这个依赖，下次它出漏洞时我们的修复成本是现在的 5 倍"
  "重构完以后，我们第一次能在一个地方改规则而不是 4 个地方"

延伸追问

• Q：怎么防止重写完又产生新的技术债？ → 不是”不借债”，是”借债要有记录”。明确规定：任何走捷径的决策（“先 hardcode 一下以后再说”、“这个 TODO 下个迭代补”）必须① 在代码里标注 TODO + JIRA 号 ② 在下次 sprint planning 时讨论是否排进去。如果永远是”下个迭代补”但从没排过，就不要写这个 TODO。
• Q：如果团队从来不做技术债，全在堆功能怎么办？ → 记录下来。每次因为技术债导致的事故/延期/返工，你都在周报/复盘里写：根因是 X 模块未重构。这个记录积累 3 次，你去找老板要求 20% 的还债时间，就有数据支持了。
• Q：重写 vs 渐进式重构，怎么选？ → 大多数情况选渐进式。重写的成功率只有约 30%（你会在重写到一半时发现漏掉了旧系统的边界 case），同时新功能也停了。除非旧系统完全没法改了（技术栈完全古旧没法招人），否则别走重写。

我的记法

• 三种债：时间债（反复多花时间）、风险债（不出事但要命）、机会债（不敢动所以绕路）
• 量化核心：把”多花了多少时间”算成数字——这个数字是你说服 PM 的唯一货币
• 固定比例还债：每个 sprint 15-20% 容量，不讨论还不还，只讨论先还哪个
• 一句话：「不量化的技术债等于不存在——只有当你能说出’每个月浪费了多少天’时，还债才进得了排期」

状态

• 已背速记
• 能讲通俗版
• 能答追问