第11章 技术债务量化管理

技术债务不是一个新话题，但在研发绩效体系里，它经常被忽视或简化。前面的体系提到了技术债要被看见、被记录、被评估、被偿还，但缺少具体的操作方法。

这一章我们讨论：如何量化技术债？如何管理偿还计划？如何让技术债进入绩效评价？

技术债务的本质

技术债务不是"代码写得不好"这么简单。更准确地说：

技术债务是我们为了短期目标，有意识或无意识地接受的长期成本。

技术债务可以分为三类：

绩效体系不应该惩罚所有技术债，但必须惩罚不可见、不可控、不可偿还的技术债。

技术债务量化评分卡

要管理技术债，首先要能评估它。用下面的评分卡可以把技术债从"感觉"变成"可量化的指标"。

评分维度

综合评分

把每个维度的分数加起来，得到技术债的综合评分：

评分示例

示例 1：一个命名不规范但不影响功能的模块

• 影响范围：2分（一个模块）
• 修复成本：2分（几小时重命名）
• 业务风险：1分（无风险）
• 扩散速度：1分（不会扩散）
• 可见性：1分（显而易见）
• 综合评分：7分（低优先级）

示例 2：核心支付模块缺少重试机制，偶发丢单

• 影响范围：5分（核心路径）
• 修复成本：3分（1人周）
• 业务风险：5分（资金损失、客户投诉）
• 扩散速度：3分（其他模块可能效仿）
• 可见性：3分（需要看日志才知道）
• 综合评分：19分（高优先级）

技术债务的管理流程

第一步：发现和记录

技术债不能只靠"感觉"，要有系统的发现机制：

记录时，每个技术债条目应该包含：

• 问题描述
• 评分（用上面的评分卡）
• 发现时间
• 发现人
• 计划修复时间
• 责任人

第二步：评估和分类

不是所有技术债都要立刻修。根据评分分类：

第三步：制定偿还计划

技术债偿还应该像功能开发一样，有明确的计划：

计划要素：

• 修复目标（要达到什么状态）
• 修复步骤（分几步完成）
• 时间安排（什么时候开始、什么时候完成）
• 责任人（谁负责）
• 验收标准（怎么算修完了）

示例计划：

技术债：支付模块缺少重试机制
评分：19分（高优先级）
目标：3个月内建立完善的重试和幂等机制
步骤：
  1. 第1个月：设计方案，加入幂等ID（2人周）
  2. 第2个月：实现重试逻辑，覆盖核心场景（2人周）
  3. 第3个月：灰度验证，全面上线（1人周）
责任人：张三
验收标准：重试覆盖率 100%，幂等逻辑通过压力测试

第四步：执行和跟踪

技术债偿还不能"说过就算"，必须跟踪进度：

• 把技术债偿还任务纳入迭代规划
• 定期（如每周）更新进展
• 遇到阻碍及时升级
• 完成后做验收和复盘

第五步：预防新债

偿还旧债的同时，不能产生更多新债：

• 建立代码规范和架构原则
• 加强代码评审
• 做架构评审，在设计阶段就避免问题
• 用自动化工具防止已知问题再次出现
• 把"不产生恶性技术债"作为绩效评价的一部分

技术债务相关的 KPI 设计

技术债不能只用定性描述，也要有定量指标观察趋势。

推荐 KPI

如何使用这些 KPI

不要用这些 KPI 机械地评价团队：

• 不要考核"技术债必须为 0"（这不现实）
• 不要因为团队上报技术债就惩罚他们（反而应该鼓励）
• 不要因为有技术债就否定团队的贡献

正确的使用方式：

• 观察趋势：技术债是在变好还是变坏？
• 发现问题：是否有某个模块或团队技术债快速增加？
• 分配资源：根据技术债的分布，合理安排资源
• 奖励进步：团队主动发现并偿还技术债，应该被认可

技术债务在绩效评价中的位置

技术债应该进入绩效评价，但要用正确的方式。

应该奖励的行为

不应该被奖励的行为

绩效评价时如何考虑技术债

评价时可以问这些问题：

• 团队是否主动发现和记录技术债？
• 高优先级技术债是否得到及时处理？
• 技术债整体趋势是变好还是变坏？
• 团队是否有意识地预防新债？
• 是否沉淀了防止技术债的机制？

不要因为有技术债就否定团队，但要关注：

• 技术债是否可见？
• 是否在可控范围内？
• 是否在被积极管理？

技术债务管理的常见误区

误区 1：技术债必须为 0

这不现实，也没有必要。为了赶时间窗口、验证方向，适当接受一些技术债是正常的。

正确做法：技术债不需要为 0，但必须可见、可控、有偿还计划。

误区 2：技术债只是"技术问题"

技术债不只是技术问题，也是业务问题。它会影响交付速度、质量、成本、团队士气。

正确做法：技术债需要业务方和技术方共同面对，一起决定偿还优先级和节奏。

误区 3：偿还技术债是"不务正业"

有些团队认为"先做功能，技术债以后再说"。但技术债会让以后的功能开发越来越慢，质量越来越差。

正确做法：每个迭代都应该安排一定比例的时间（如 20%）偿还技术债。

误区 4：用"重构"的名义制造更多技术债

有些团队为了"技术理想"，不考虑成本和风险，盲目重构，反而制造更多问题。

正确做法：重构要有明确目标、清晰计划、验收标准，不能为了重构而重构。

一套可落地的技术债管理模板

技术债登记表

技术债季度报告

内容包括：

1. 技术债存量变化（期初 vs 期末）
2. 技术债偿还情况（完成了哪些）
3. 新增技术债分析（为什么会产生，如何预防）
4. 高优先级技术债处理进展
5. 下季度计划

技术债验收清单

修复完成后，确认：

• 问题是否真正解决？
• 是否有测试覆盖？
• 是否有文档说明？
• 是否有防止复发的机制？
• 相关团队是否知道这个变化？

总结

技术债务管理的核心不是"消灭所有技术债"，而是：

1. 让技术债可见：不隐瞒、不回避
2. 量化评估：用评分卡替代感觉
3. 有计划管理：不是救火式地修，而是有节奏地还
4. 预防为主：从源头减少新债的产生
5. 进入绩效：但要用正确的方式，不机械考核

当团队真正把技术债管理起来，而不是把它当成"欠债"时，交付效率和质量都会持续提升。