技术债治理的核心，是把“要不要还、先还哪一笔、谁来还、还到什么程度”变成一套可重复的决策机制。起步阶段先建立统一的技术债台账，用业务影响与偿还成本形成排序口径，再通过固定的评审入口决定偿还、暂缓或转为约束，最后用可观察的指标验证效果。本文围绕台账字段、排序决策、角色分工、流转示例和验证检查展开，治理对象是技术债的决策与跟踪，具体重构写法不在讨论范围；已确认的功能缺陷按缺陷管理流程处理。
要点总览（TL;DR）
- 技术债治理从统一台账开始：固定债务描述、涉及模块、产生原因、影响范围、当前风险、偿还预估工作量和责任人七项必填字段，并按设计、代码、测试、文档、依赖与基础设施五类归档。
- 排序用业务影响、故障风险、变更阻碍程度、偿还成本四个维度打分，评审并入需求排期或迭代规划会，每个条目必须给出立即偿还、纳入计划偿还或暂缓并设复查条件三种结论之一。
- 开发与测试负责登记，技术负责人评估风险与成本，产品与业务负责人判断业务影响，研发管理者主持评审并确认容量，各环节产出物形成台账条目到偿还任务的闭环。
- 偿还节奏可选按比例预留容量或按风险阈值触发，两种方式需在评审记录中写明当前采用哪种，避免执行时互相挤占。
- 验证同时看过程指标（台账条目变化、评审覆盖率、按期偿还比例）和结果指标（变更失败率、缺陷密度、发布周期变化），暂缓债务按季度复查。
技术债治理先建什么：台账字段与分类口径
治理技术债的第一步是让每一笔债务都能被看见、被比较。台账承担这个作用：它把分散在开发人员记忆、代码注释和口头讨论中的问题，转成结构一致的记录。字段不必多，但必须覆盖后续排序和评审所需的全部输入。
台账必填字段
下表给出一份建议字段结构，团队可以按自身规模增减，但建议保持“债务描述、涉及模块、产生原因、影响范围、当前风险、偿还预估工作量、责任人”七项为必填，缺一项就退回补充。
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 债务描述 | 一句话说明现状与问题，例如“订单模块状态判断分散在五处，修改易遗漏” | 统一认知，避免条目含糊 |
| 涉及模块 | 标注服务、模块或代码目录 | 定位影响面，便于分配评估人 |
| 产生原因 | 赶工期临时方案、需求变更、依赖升级滞后等 | 判断是否可预防同类债务 |
| 影响范围 | 受影响的业务功能、调用方、团队 | 评估业务影响的基础 |
| 当前风险 | 故障可能性、变更阻碍程度、安全或合规隐患 | 排序的核心输入 |
| 偿还预估工作量 | 以人天或故事点给出区间，注明估算依据 | 计算投入产出比 |
| 责任人 | 对该债务最熟悉的开发或技术负责人 | 保证条目持续更新 |
按类型分类
分类的作用是让评审时能按类别批量判断，也便于观察债务集中在哪一类。建议分为五类：设计债指架构或模块划分不合理；代码债指重复、耦合、命名混乱等实现问题；测试债指缺少自动化测试或测试覆盖不足；文档债指接口、部署、运维文档缺失或过期；依赖与基础设施债指第三方库版本滞后、构建与部署环境陈旧。一笔债务可以带多个标签，但主类型只选一个，避免分类失去区分度。
与功能缺陷分开记录
已确认的功能缺陷有明确的错误表现和修复预期，走缺陷管理流程，有独立的优先级和验收标准。技术债描述的是“当前可用但会持续增加成本”的结构性问题。两类事项混在同一张表里，会让缺陷的紧急程度稀释债务的排序信号，也会让债务条目被当作待修 Bug 处理。登记时先判断：这是用户可感知的错误，还是影响后续改动效率的隐患，前者进缺陷库，后者进台账。
登记入口与更新频率
登记入口建议设在两个位置：日常开发中发现问题时随手提交，以及迭代回顾时集中补充。更新频率与评审节奏对齐，至少每次评审前由责任人确认条目状态，已偿还的关闭，风险变化的更新描述。台账长期不更新，排序就会基于过期信息，评审结论也随之失真。
如何排序与决策：评审入口和偿还节奏
台账解决“有什么”，排序和评审解决“先做哪个、做不做”。这一步的关键是建立统一口径，让技术判断和业务判断在同一张桌上比较，而不是各自按偏好推动。
四个排序维度
建议从业务影响、故障风险、变更阻碍程度、偿还成本四个维度评估，每个维度用高、中、低三档打分。业务影响看债务是否拖慢关键需求交付；故障风险看是否可能引发线上问题；变更阻碍程度看修改相关代码时需要多少额外验证和沟通；偿还成本看预估工作量。前三个维度高、成本低的条目优先处理；影响大但成本高的条目拆分成阶段任务；四个维度都低的条目可以暂缓。单看技术偏好容易过度投入低影响债务，单看业务压力则会让高风险债务长期积压。
与排期合并的评审入口
评审不必单独设会。把技术债评审并入需求排期会或迭代规划会，每次留出固定时段处理台账中待决策的条目。这样做的原因是参与人已经在场，业务与技术信息同步，决策可以直接进入排期，减少一次会议和一轮信息传递。评审频率与迭代周期一致即可，条目多时可只评审新增和高风险条目。
三种处置结论
每个进入评审的条目必须给出一个结论，不允许“再看看”这类模糊状态：
- 立即偿还：风险高、成本可控，在当前或下一个迭代安排任务。
- 纳入计划偿还：影响明确但需要排期，指定目标迭代或时间窗口。
- 暂缓并设定复查条件：当前影响有限，写明什么条件下重新评估，例如“该模块下次有需求变更时”“依赖版本停止维护时”。
偿还节奏的两种安排
按比例预留容量适合债务分布较散、需要持续投入的团队，例如每个迭代预留百分之十到二十的工时用于偿还任务，具体比例按债务集中度和交付压力调整。按风险阈值触发适合债务集中在少数高风险模块的情况，设定触发条件，如某模块变更失败次数超过约定值或关键依赖临近停止维护，即启动专项偿还。两种方式可以并用，但需要在评审记录中写明当前采用哪种，避免执行时互相挤占。
决策留痕
每次评审记录条目、结论、依据和责任人，与台账条目关联。复查时先看记录再判断是否需要调整，避免同一笔债务反复讨论却得不出新结论。
角色与交付物：谁登记、谁评估、谁决策
治理机制能否运转，取决于每个环节是否有人负责、有产出物可交接。角色划分不必复杂，但要避免“大家都觉得该还、没人真正推动”的局面。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 开发与测试人员 | 发现债务并登记，提供影响描述和复现或观察依据 | 台账条目 |
| 技术负责人 | 评估风险与偿还成本，给出技术判断和拆分建议 | 评估结论 |
| 产品与业务负责人 | 判断业务影响，确认优先级与排期窗口 | 优先级意见 |
| 研发管理者 | 主持评审，确认容量与偿还节奏，跟踪闭环 | 评审记录、偿还任务 |
开发与测试是登记的主要来源，登记质量直接影响后续评估，因此影响描述要写到“哪个功能、哪类改动会受影响”，而不是只写“代码乱”。技术负责人对成本和风险的判断负责，评估时给出估算依据，便于评审时被质疑和修正。产品与业务负责人不需要判断技术方案，但要说明债务对交付节奏和用户体验的实际影响。研发管理者负责让评审按期发生、结论被执行，并在容量冲突时做出取舍。
各环节的交付物形成一条链：台账条目进入评估，评估结论进入评审，评审记录产生偿还任务，任务完成后回写台账状态。任一环节缺少产出物，链条就断了，治理会退回到口头推动。
一个治理示例：从登记到偿还完成
以下为演示情景，用于说明流转过程，不代表特定团队的真实案例。
背景：某订单模块为赶一次大促上线，采用临时方案拼接状态判断逻辑，上线后每次调整订单状态都需要在多个位置同步修改，近两个迭代中因此产生过两次回归问题。
登记：负责该模块的开发提交台账条目，描述为“订单状态判断分散在五处，修改需同步调整”，涉及模块为订单服务，产生原因为赶工期临时方案，影响范围为订单创建、取消、退款三条流程，当前风险标注为变更阻碍程度高、故障风险中，偿还预估五到八人天，责任人为该开发。
评估与评审：技术负责人评估后确认成本估算，建议先抽取统一状态机再逐步替换调用点，拆成两个阶段。产品负责人确认该模块下个季度有退款流程改造需求，债务不还会直接拖慢改造。评审结论为纳入下个迭代偿还第一阶段，第二阶段随退款改造一并安排。
偿还：第一阶段拆成三个可交付任务，每个任务关联原台账条目，任务描述中写明验收标准，例如“状态判断集中到单一入口，原有调用点全部替换并通过回归测试”。
关闭与复查：任务完成后，责任人验证回归测试通过、后续两次小改动未再出现同步遗漏，更新台账状态为已偿还并记录验证依据。第二阶段保留为待办，复查条件为退款改造启动。
这个示例说明两点：债务条目要能追溯到具体任务，偿还效果要有可验证的依据，而不是任务完成即视为关闭。
治理效果怎么验证：指标与完成检查
机制建立后，需要判断它是否真的在运转，而不是只在初期热闹一阵。验证分过程指标和结果指标两类，前者看机制执行，后者看实际改善。
过程指标
- 台账条目数量变化：持续增长说明登记入口有效；长期不增长可能是登记意愿不足或入口太隐蔽。
- 评审覆盖率：进入评审的条目占新增条目的比例，偏低说明评审入口没有覆盖全部来源。
- 按期偿还比例：纳入计划的条目在约定窗口内完成的比例，反映结论是否被执行。
结果指标
结果指标需要结合基线观察，例如变更失败率、缺陷密度、发布周期变化。这些信号受需求波动、人员变动影响，建议按季度对比而非逐迭代判断。指标改善只能作为佐证，不能单独证明某一笔债务的偿还效果，具体条目仍以任务验收标准为准。
复查机制
暂缓的债务要定期回看，复查频率可与季度规划对齐，逐条确认复查条件是否触发。触发即重新进入评审，未触发则更新风险描述后继续暂缓。缺少复查，暂缓就会变成遗忘。
完成检查清单
- 台账是否统一：字段齐全、分类口径一致、与缺陷库分开记录。
- 评审是否固定：有固定入口和频率，每次评审有明确结论。
- 结论是否留痕：评审记录与台账条目关联，可追溯依据。
- 偿还任务是否闭环：任务关联原条目，完成后有验证依据并回写状态。
- 暂缓条目是否复查：复查条件明确，到期有人回看。
当台账、评审记录和偿还任务分散在不同工具中时，跟踪成本会明显上升。ONES 可用于承载技术债台账条目、评审记录与偿还任务，让条目状态、结论和任务进度在同一处关联更新，减少人工汇总；具体使用方式按团队现有的研发管理流程配置。检查清单逐项通过，说明治理机制已经形成可重复的循环，后续只需按节奏维护和调整排序口径。
常见问题
技术债台账和缺陷库能不能合并成一张表管理？
不建议合并。已确认的功能缺陷有明确的错误表现和修复预期，走缺陷管理流程，有独立的优先级和验收标准；技术债描述的是当前可用但会持续增加成本的结构性问题。两类事项混在一起，缺陷的紧急程度会稀释债务的排序信号，债务条目也容易被当作待修 Bug 处理。登记时先判断：用户可感知的错误进缺陷库，影响后续改动效率的隐患进台账。
团队规模小、债务条目不多，还需要单独设评审会吗？
不需要单独设会。评审可以并入已有的需求排期会或迭代规划会，每次留出固定时段处理待决策条目即可。条目少的时候，可以只评审新增条目和高风险条目，其余条目按季度集中回看。关键是评审有固定入口和频率，结论有记录，而不是依赖临时讨论。
暂缓的债务长期没人回看，怎么避免变成遗忘？
暂缓条目在登记时就要写明复查条件，例如“该模块下次有需求变更时”“依赖版本停止维护时”，并把复查频率与季度规划对齐。每次复查逐条确认条件是否触发：触发即重新进入评审，未触发则更新风险描述后继续暂缓。复查动作本身也要留痕，否则无法判断是条件未触发还是没人执行。
按比例预留容量和按风险阈值触发，应该选哪一种？
取决于债务分布。债务分散、需要持续投入的团队适合按比例预留容量，例如每个迭代预留百分之十到二十的工时，具体比例按债务集中度和交付压力调整；债务集中在少数高风险模块的团队适合按风险阈值触发，设定变更失败次数或依赖停止维护等条件后启动专项偿还。两种方式可以并用，但要在评审记录中写明当前采用哪种，避免执行时互相挤占。
偿还任务完成后，怎么判断这笔债务真的关闭了？
以任务验收标准为准，而不是任务状态变为完成即视为关闭。验收标准在拆分任务时写明，例如“状态判断集中到单一入口，原有调用点全部替换并通过回归测试”。任务完成后由责任人验证效果，确认后续若干次改动未再出现同类问题，再更新台账状态并记录验证依据。结果指标如变更失败率的变化可以作为佐证，但受需求波动影响，不宜单独用来判断单笔债务的偿还效果。
