技术债务管理流程：从登记到偿还的完整闭环
技术债务这东西，说白了就是代码里的「欠账」。你今天图快写了一段烂代码，明天就得花时间还债。我在好几个项目里都见过这种情况——团队只顾着赶功能，结果债务越滚越大，最后连加个小功能都要改三天。
那怎么管？不能靠脑子记，得有一套流程。我习惯把技术债务管理分成三个环节：登记追踪 → 可视化看板 → 优先级排序。今天咱们就聊聊这套流程怎么落地。
一、技术债务登记与追踪：别让债务「隐身」
技术债务最大的问题是什么？是它看不见。业务需求有Jira ticket，bug有bug tracker，但技术债务往往只存在于几个老员工的脑子里。这不行。
我个人习惯用Jira或Notion来登记技术债务。选哪个？看团队习惯。
- Jira：适合研发团队，可以和 sprint 联动，方便追踪
- Notion：适合文档驱动型团队，灵活度高，可以嵌入代码片段
登记的时候，我建议至少包含这几个字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 债务描述 | 清晰说明问题 | 用户模块的SQL查询没有加索引，数据量超过10万行后响应时间超过5秒 |
| 发现时间 | 记录发现日期 | 2024-03-15 |
| 影响范围 | 哪些功能/模块受影响 | 用户列表页、搜索功能 |
| 预估修复成本 | 人天或故事点 | 3人天 |
| 责任人 | 谁发现的/谁负责跟进 | 张三 |
| 状态 | 待评估/已排期/修复中/已关闭 | 待评估 |
二、技术债务看板：让债务「可视化」
登记完了，怎么让团队看到？看板。我习惯在Jira或Notion里建一个技术债务看板，和需求看板分开，但放在同一个项目里。
看板的列我建议这样设：
- 待评估：新登记的债务，需要确认是否真的需要修
- 已确认：确认是债务，等待排期
- 已排期：已经安排到某个sprint里
- 修复中：正在改
- 验证中：改完了，需要Code Review或测试验证
- 已关闭：债务已偿还
嗯，这里要注意：看板不是摆设。我建议每周的站会上花5分钟过一下技术债务看板，看看有没有「卡住」的债务。如果一张ticket在「待评估」里躺了两周，说明团队在逃避问题。
三、债务偿还优先级矩阵：Quadrant模型
债务这么多，先修哪个？不能拍脑袋。我推荐用Quadrant模型，也就是四象限法。
横轴是影响程度（低→高），纵轴是修复成本（低→高）。这样分成四个象限：
- 第一象限（高影响，低成本）：立刻修。这种债务性价比最高，修完立竿见影。
- 第二象限（高影响，高成本）：计划修。影响大但成本也高，需要专门排期，可能还要做技术方案评审。
- 第三象限（低影响，低成本）：顺手修。比如一个变量命名不规范，看到了就改掉，别专门建ticket。
- 第四象限（低影响，高成本）：暂时不管。这种债务修了也没人感知到，不如把精力放在更有价值的地方。
我举个例子。之前有个项目，登录接口每次都要查一次用户角色表，其实可以缓存。这个问题的影响程度高（每次登录都慢），但修复成本低（加个缓存就搞定）。这就是典型的第一象限债务，我当天就修了。
反过来，有个老模块的代码用了过时的框架，要重构得花两周。但那个模块只有管理员偶尔用，影响不大。这就是第四象限，先放着。
四、知识体系总览
下面这张图把整个流程串起来了。你可以看到，从登记到追踪，再到看板可视化，最后用Quadrant模型排优先级，形成一个闭环。
你看，整个流程其实不复杂。关键是养成习惯——发现债务就登记，登记了就进看板，看板里的债务用Quadrant模型排优先级，然后按优先级去修。闭环跑起来，技术债务就不会失控。
公众号:蓝海资料掘金营，微信deep3321