技术债务治理的关键，是把“这块代码迟早要改”从个人判断变成团队可执行的决策机制：债务有统一登记口径，有分级和排期规则，有明确的责任人和验收标准，并能用存量、偿还周期和复发情况检验效果。本文按登记、分级排期、角色分工、完整示例和效果检查五步展开，帮助研发管理者或技术负责人搭建一套能持续运行的治理流程。
要点总览（TL;DR）
- 技术债务治理从一份统一台账开始：每条债务写清现象、成因、影响范围、偿还成本和触发条件，让评审有共同对象。
- 分级按业务影响、发生概率、偿还成本三个维度打分，并给每个迭代留出固定的债务偿还预算，满足立即处理条件的债务直接进入当前迭代。
- 产品负责人判断业务影响与排期冲突，技术负责人评估成本与风险并主持评审，开发团队执行偿还，测试与运维按事先写入的验收标准确认关闭。
- 治理是否有效看四项数据：债务存量、新增速度、平均偿还周期和同类问题复发率，再配合台账更新、评审按期、预算执行等机制检查项。
- 债务台账与缺陷管理分开：功能不符合预期的走缺陷流程，符合预期但实现方式带来持续成本的进债务台账。
治理从哪里起步：先建一份可决策的债务台账
治理技术债务的第一步是建立一份统一台账，把分散在个人经验里的问题写成可以评估、可以排期的条目。台账的价值在于让讨论有共同对象：评审时看的是同一条记录，而不是各自记忆中的“那块逻辑很乱”。
台账不需要一开始就做得很重。最小可用做法是选一个共享文档或工作项列表，先登记五到十条团队公认的债务，跑通一轮评估和排期，再逐步补充字段和流程。
台账需要记录哪些字段
每条债务至少写清以下五项信息，缺少任何一项都会让后续决策失去依据：
| 字段 | 记录内容 | 填写示例 |
|---|---|---|
| 现象 | 当前可观察到的具体表现，避免只写“代码烂” | 订单查询接口平均响应 1.8 秒，高峰期超时率约 3% |
| 成因 | 问题形成的技术或历史原因 | 早期为赶上线在查询层直接拼接 SQL，未做索引设计 |
| 影响范围 | 涉及模块、受影响的业务场景和用户规模 | 订单中心，影响全部下单用户，涉及三个下游服务 |
| 偿还成本 | 预估工作量、所需角色和依赖条件 | 约 8 人日，需要 DBA 配合，依赖订单表数据迁移完成 |
| 触发条件 | 什么情况下必须处理，什么情况下可以继续观察 | 超时率超过 5% 或大促前必须处理；平时进入观察清单 |
字段之外，建议补充登记人、登记日期和当前状态三项辅助信息，便于追溯条目来源和流转过程。
技术债与功能Bug的边界
台账要和缺陷管理划清边界。已确认的功能Bug走缺陷流程，按缺陷的严重程度和修复时限处理；技术债记录的是系统当前可用、但存在长期维护成本或风险的设计与实现问题。判断标准可以简化为一句：功能是否符合预期。不符合预期的进缺陷流程，符合预期但实现方式带来持续成本的进债务台账。
边界不清会带来两个后果：债务台账被大量Bug淹没，失去决策价值；或者真实缺陷被当作“技术债”长期搁置。登记时由登记人先做初判，技术负责人在评审时确认归类。
首批条目从哪里来
首批债务可以从四个来源收集：开发人员在日常工作中反复抱怨的模块；线上故障复盘中被认定为根因的设计问题；代码评审中反复出现的同类意见；新人上手时耗时最长的理解成本高的代码。每个来源先收集三到五条，合并重复项后形成首批台账，再进入分级环节。
债务条目登记和后续排期需要承载工具。ONES 提供工作项与文档能力，可以把债务条目作为工作项登记、关联所属模块和迭代，并把评估结论沉淀在文档中，便于团队在同一处查看和流转。
怎么分级和排期：把债务放进迭代决策
台账建立后，下一步是决定先还哪些、什么时候还。分级解决“轻重缓急”，排期解决“什么时候进迭代”，两者结合才能让债务真正进入团队的交付计划，而不是停留在清单上。
三个维度做分级
建议按业务影响、发生概率、偿还成本三个维度打分，每个维度分高、中、低三档：
| 维度 | 高 | 中 | 低 |
|---|---|---|---|
| 业务影响 | 影响核心交易链路或大面积用户 | 影响部分功能或特定场景 | 影响内部效率或可维护性 |
| 发生概率 | 已频繁触发或大促等高负载场景必现 | 特定条件下偶发 | 目前未触发，属于潜在风险 |
| 偿还成本 | 超过一个迭代的人力 | 数人日到十余人日 | 数人日以内可完成 |
组合规则可以这样定：业务影响高且发生概率高的债务列为紧急，优先安排；业务影响高但发生概率低的进入计划清单，在相关模块有变更时一并处理；业务影响低但偿还成本低的可以作为顺手项，随迭代搭车完成；三项都处于低位的放入观察清单，定期复核。
设定每迭代偿还预算
债务长期排不进迭代，通常是因为需求永远优先。解决办法是给偿还留出固定预算，常见做法是每个迭代拿出总人力的 10% 到 20% 用于债务偿还，具体比例根据债务存量和业务节奏确定。预算一旦确定，就按迭代执行，不因单个需求临时挤占；确需调整时由技术负责人和产品负责人共同确认，并记录原因。
预算之外还需要触发规则，明确哪些债务必须立即处理：已经造成线上故障或用户可感知性能下降的；阻塞当前需求开发的；存在安全或数据一致性风险的；影响即将到来的大促或关键交付节点的。满足任一条件即进入当前迭代，不占用常规预算排队。
排期结果要写回台账
分级和排期完成后，把结论写回台账：每条债务标注优先级、计划处理的迭代或触发条件、责任人。观察清单中的条目设定复核周期，例如每季度复核一次，避免长期无人问津。排期结果同步到团队的迭代计划中，让债务工作和需求工作在同一张计划表上可见。
角色怎么分工：谁登记、谁评估、谁验收
治理机制能否运行，取决于每个环节是否有人负责、有明确交付物。技术债务治理涉及四类角色，职责和交接物如下：
| 角色 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 产品负责人 | 债务条目的影响范围描述 | 判断业务影响，确认优先级和排期冲突 | 业务影响评级、排期确认意见 |
| 技术负责人 | 债务条目、团队技术判断 | 评估偿还成本与风险，确认分级，主持评审 | 分级结论、偿还方案、验收标准 |
| 开发团队 | 排期后的债务条目和偿还方案 | 执行偿还，记录过程与偏差 | 可验收的代码变更和说明 |
| 测试与运维 | 验收标准、变更内容 | 验证功能与性能指标，观察线上表现 | 验收结论、线上观察记录 |
关键交接点
流程中有三个交接点需要明确责任人。登记到评估的交接：登记人提交条目后，由技术负责人在固定评审会上确认字段完整性和归类，通常每周或每两周一次。评估到排期的交接：技术负责人给出分级建议，产品负责人确认业务影响和排期，双方对优先级不一致时由技术负责人牵头讨论，形成书面结论。偿还到验收的交接：开发完成后提交验收，测试与运维按事先约定的标准验证，验收人签字或记录结论后条目才能关闭。
验收责任人应在排期时确定，而不是偿还完成后再找人。验收标准在评估阶段写入条目，例如“接口平均响应降至 500 毫秒以内、高峰期超时率低于 0.5%”，让偿还工作有明确的完成标志。
一个完整例子：支付模块债务从登记到关闭
以下情景用于示范流程如何走完一轮，数据为演示设定。
登记
支付模块的开发人员在日常工作中发现，退款回调处理逻辑依赖一张历史遗留的中间表，多次出现重复回调导致对账差异。登记条目如下：现象为退款回调偶发重复处理，近三个月出现四次对账差异；成因为早期回调接口未做幂等设计，依赖中间表状态判断；影响范围为支付退款链路，涉及全部退款用户；偿还成本预估 6 人日，需要测试配合构造并发场景；触发条件为再次出现对账差异或退款量增长超过当前两倍时立即处理。
分级与排期
评审会上，技术负责人评估业务影响为高、发生概率为中、偿还成本为中，建议列入计划清单，在下个迭代安排。产品负责人确认退款对账差异会带来客服工单和财务核对成本，同意排入下个迭代，占用该迭代债务预算的 60%。验收标准同步写入条目：并发回调场景下不产生重复处理，对账差异为零。
偿还与验收
开发团队在迭代内完成幂等改造，提交变更说明和自测记录。测试按验收标准构造并发回调场景验证，运维在灰度环境观察一周，确认无重复处理和对账差异。验收人记录结论后，条目状态改为已关闭，并在台账中保留关闭日期和实际投入人日，供后续统计偿还周期使用。
怎么判断治理有效：检查项与完成标准
治理机制建立后，需要定期检查它是否真的在运行、是否产生了效果。检查分两层：一层看债务本身的变化，一层看机制是否被执行。
观察债务变化
建议每月或每季度统计三项数据：债务存量，即台账中未关闭条目的数量和预估总成本；新增速度，即统计周期内新登记条目的数量，与偿还数量对比，判断债务是在收敛还是扩张；平均偿还周期，即条目从登记到关闭的平均时长，周期过长说明排期机制没有真正生效。此外关注复发情况：同类问题是否在关闭后再次登记，复发率高说明偿还停留在表面修复，需要回到成因层面处理。
机制运行检查清单
以下检查项可用于定期自查，每项都有可核验的完成标志：
- 台账持续更新：最近一个月内有新增或状态变更的条目，说明登记渠道畅通。
- 评审按期进行：评审会记录完整，新条目在两周内完成分级，没有长期未评估的条目。
- 预算被执行：每个迭代的实际债务投入与计划预算偏差在合理范围内，挤占情况有书面记录。
- 触发规则生效：满足立即处理条件的债务在当迭代进入排期，没有积压。
- 验收有记录：关闭的条目都有验收结论和验收人，验收标准在评估阶段已写入。
- 观察清单有复核：观察清单中的条目按设定周期复核，复核结论有记录。
当债务存量趋于稳定或下降、新增速度低于偿还速度、平均偿还周期在团队可接受范围内、同类问题复发减少，并且上述检查项大部分持续满足时，可以认为治理机制已经进入正常运行状态。此时的重点从建立机制转向维持节奏，根据业务变化调整预算比例和分级规则。
常见问题
团队规模小、没有专职技术负责人，债务台账由谁维护？
可以由团队中承担技术决策职责的人兼管，例如资深开发或研发组长，关键是固定一个责任人而不是轮流登记。评审频率可以降低，例如每两周一次，与迭代计划会合并进行。台账维护的工作量主要在字段完整性和状态更新，登记人负责提交条目，责任人负责确认归类和排期结论，两项职责分开即可，不必设专职岗位。
债务偿还预算被紧急需求挤占时怎么处理？
预算被挤占本身可以接受，但需要留下记录：由技术负责人和产品负责人共同确认，写明挤占原因、被推迟的债务条目和补回的时间点。连续多个迭代被挤占时，说明预算比例或排期规则需要重新讨论，而不是继续默认执行。另一种做法是把预算拆小，例如每迭代固定安排两到三天，降低被整体挪走的概率。
已经造成线上故障的问题，应该登记为技术债还是缺陷？
先按缺陷流程处理，恢复功能和用户可用性；故障复盘确认根因属于设计或实现层面的长期问题时，再登记一条技术债，记录成因和防止复发的偿还方案。两条记录互相关联但不合并，避免债务台账承担故障跟踪的职责，也避免真实缺陷被长期搁置在债务清单里。
观察清单里的债务长期不处理，会不会变成新的遗留问题？
观察清单的作用是承认风险存在并设定复核节奏，而不是永久搁置。每条观察项要写明复核周期和触发条件，例如每季度复核一次，或相关模块发生较大变更时重新评估。复核时如果业务影响或发生概率上升，就调整分级进入排期；如果条件长期不变，保留在清单中并记录复核结论即可。
治理运行一段时间后，怎么判断可以降低投入？
当债务存量连续几个统计周期稳定或下降、新增速度低于偿还速度、平均偿还周期在团队可接受范围内，并且机制检查项大部分持续满足时，可以考虑下调每迭代的偿还预算比例。调整时保留触发规则和观察清单复核，避免存量反弹。预算比例的变化应记录在案，便于后续对照效果。
