技术债治理计划的价值在于把散落在代码评审、事故复盘和个人经验里的技术债，转成有记录、有评估、有排期、有验收的管理对象。本文按“定范围—建台账—做分级—进迭代—验收复盘”的顺序给出可执行步骤，并说明每一步的输入、动作与产出，适用于需要从零建立治理机制的研发团队。
要点总览（TL;DR）
- 技术债治理计划的核心是把技术债变成有记录、有评估、有排期、有验收的管理对象，关键产物是台账、分级排序表、迭代排期表和验收记录。
- 先划定纳入范围与排除项：架构腐化、重复代码、测试缺失、依赖过期、文档缺失纳入治理，已确认功能缺陷归缺陷管理。
- 分级排序围绕业务影响、故障风险、变更阻碍程度和偿还成本四个维度打分或做矩阵分类，信息不足的条目先做小范围评估再排期。
- 治理项要拆到迭代可交付粒度并预留固定容量，明确技术负责人、架构师、开发、测试、产品经理的职责与评审节点。
- 计划是否成立看两件事：台账有人定期维护、排期有容量保障；效果用治理项完成率和相关故障或变更耗时变化来观察。
技术债治理计划先定什么：范围、口径与产出
技术债治理计划是一份约定“哪些债纳入管理、按什么标准评估、如何进入迭代、由谁验收”的工作机制。它的目标是把偿还动作从个人临时决定变成团队可预期的安排，让技术债的规模、优先级和进展在团队内可见。制定计划的第一步是划定范围，避免把缺陷修复、需求开发和代码教学混入同一套流程。
纳入范围通常包括以下几类：架构层面的耦合与腐化，例如模块边界模糊、服务间依赖混乱；重复代码与复制粘贴式实现；测试缺失或测试长期失效；依赖库与运行时版本过期；关键设计文档缺失或与实现脱节。这些条目的共同点是：它们不直接表现为功能错误，但会持续增加变更成本和故障概率。
排除项需要提前写清楚。已确认的功能缺陷应进入缺陷管理流程，按缺陷的严重程度和修复时限处理，不占用技术债治理的评估口径；具体的重构代码教程、设计模式讲解属于工程实践内容，不作为治理计划的组成部分。把这两类内容排除在外，可以让台账条目保持同质，便于横向比较优先级。
计划的核心产物有四份：技术债台账，记录每一条债的位置、类型、影响和状态；分级排序表，给出优先级和排序依据；迭代排期表，说明治理项进入哪个迭代、由谁负责；验收记录，记录完成情况和效果观察。这四份产物相互衔接，构成计划执行的主线。台账和排期表需要有固定的承载位置，ONES 的工作项与文档可以分别承载条目跟踪和计划说明，具体字段配置按团队实际流程设定。
第一步：建立技术债台账与统一登记字段
台账的作用是让技术债有唯一入口。条目来源主要有四类：代码评审中发现的重复实现或临时绕过；架构评审中识别出的耦合与扩展瓶颈；线上事故复盘时定位到的脆弱环节；研发人员在日常开发中自评记录的改进点。四类来源的登记口径应保持一致，否则台账很快会出现重复条目或描述含糊的条目。
台账字段建议按下表设置，字段数量以能支撑后续分级为准，不必追求大而全。
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 编号 | 按团队规则生成，全局唯一 | 引用与状态追踪 |
| 位置 | 模块、服务或文件路径 | 定位与影响分析 |
| 类型 | 架构腐化、重复代码、测试缺失、依赖过期、文档缺失等 | 分类统计与治理方式选择 |
| 影响范围 | 受影响的业务功能、团队或调用方 | 业务影响评估 |
| 发现时间 | 首次登记的日期 | 账龄分析与积压观察 |
| 责任人 | 对该条目跟进的技术负责人 | 推动状态更新 |
| 当前状态 | 待评估、已分级、已排期、治理中、已验收、暂缓 | 进度跟踪 |
登记动作的输入是评审记录、复盘结论或自评描述；做法是由发现人按字段填写条目，由模块技术负责人确认位置和影响范围；输出是一条状态为“待评估”的台账记录。完成标志是该条目能被另一位工程师读懂并定位，不需要额外口头解释。
台账最常见的失效方式是建成后无人更新。应对办法是设定固定的巡检节奏，例如每两周由各模块负责人检查一次本人负责条目的状态，把已完成项改为“已验收”，把不再适用的条目改为“暂缓”并写明原因。巡检结果在团队例会上简要同步，让台账保持可信。
第二步：用业务影响与偿还成本做分级排序
分级排序解决“先还哪一笔”的问题。建议从四个维度评估：业务影响，指该条目影响的功能重要程度和用户范围；故障风险，指它引发线上问题的可能性和后果；变更阻碍程度，指它让新需求开发变慢或变复杂的程度；偿还成本，指修复所需的人力和时间。前三个维度越高越优先，偿还成本越高则越需要拆分或延后。
打分可以采用简单量表，例如每个维度按 1 至 5 分评估，业务影响、故障风险、变更阻碍三项加权求和，再结合偿还成本做矩阵分类。也可以直接用二维矩阵：横轴为影响程度，纵轴为偿还成本，落在“高影响、低成本”区域的条目优先处理，“高影响、高成本”的条目拆分为多个阶段，“低影响、高成本”的条目暂缓或仅做监控。两种方式都要求评估人给出简短理由，避免分数成为拍脑袋的结果。
排序结果需要经过评审确认。评审参与人包括技术负责人、架构师和产品经理，重点确认高优先级条目是否与当前业务节奏冲突、成本估算是否合理。评审输出是一份带优先级和理由的队列，状态从“待评估”改为“已分级”。
对信息不足的条目，不要直接排进迭代。做法是先安排一次小范围评估，例如用半天时间做依赖分析或影响面梳理，补齐信息后再进入分级。这样能避免把不确定的条目排进迭代后反复调整，消耗团队对计划的信任。
第三步：把治理项排进迭代并分配角色
治理项进入迭代前需要拆到可交付的粒度。判断标准是：一项任务能在一个迭代内完成，有明确的完成标志，例如“将某模块的重复实现合并为公共组件并通过回归测试”“为某核心服务补齐关键路径的单元测试，覆盖率从当前水平提升到约定目标”。粒度过大的条目应拆成多个任务，分别排期。
迭代容量需要预留。常见做法是在每个迭代中划出固定比例用于技术债治理，比例根据团队当前债务压力和业务排期确定，并在迭代计划会上明确写入。预留容量的意义在于让治理项与需求项一样参与排期竞争，而不是等“有空再做”。如果某个迭代业务压力过大，可以降低比例，但应在计划中记录原因，避免连续多个迭代归零。
角色分工建议按下表明确，具体职责可按团队规模调整。
| 角色 | 主要职责 |
|---|---|
| 技术负责人 | 维护台账口径，组织分级评审，确认排期优先级 |
| 架构师 | 评估架构类条目的影响与方案，参与高优先级条目评审 |
| 开发工程师 | 登记条目、执行治理任务、回写状态与验收材料 |
| 测试工程师 | 确认治理后的回归范围，验证测试补齐类条目的效果 |
| 产品经理 | 参与业务影响评估，协调治理排期与需求排期的冲突 |
评审与交接节点有三个：立项评审，确认条目进入迭代前的方案和范围；完成验收，由责任人和测试共同确认完成标志达成；状态回写，把台账条目更新为“已验收”并附上验收记录。三个节点都应有记录，便于后续复盘时追溯。在 ONES 中，治理任务可以作为工作项进入迭代，验收结论和方案说明通过文档关联到对应条目，使排期与记录保持在同一处。
示例：一个中等规模研发团队的技术债治理计划片段
以下为演示情景，背景假设为：一个约三十人的研发团队，维护三个业务服务和一个公共组件库，采用两周一个迭代，当前没有正式的技术债台账。示例中的条目、分值和排期均为说明方法而设，不代表真实项目结论。
台账条目示例：编号 TD-001，位置为订单服务，类型为架构腐化，影响范围为订单创建与查询链路，发现时间为第一季度架构评审，责任人为订单服务技术负责人，状态为已分级。编号 TD-002，位置为公共组件库，类型为重复代码，影响范围为三个业务服务的表单校验逻辑，来源为代码评审，状态为已排期。编号 TD-003，位置为支付回调模块，类型为测试缺失，影响范围为支付结果通知，来源为线上事故复盘，状态为待评估。
分级打分示例：TD-001 业务影响 4 分、故障风险 4 分、变更阻碍 5 分，偿还成本评估为高，结论为高优先级但需拆分为两个阶段；TD-002 业务影响 3 分、故障风险 2 分、变更阻碍 4 分，偿还成本低，结论为高优先级、优先执行；TD-003 信息不足，先安排半天做影响面梳理，暂不排期。
排期与角色示例：TD-002 拆为两个任务，分别进入下一个迭代和再下一个迭代，由公共组件库维护人负责，测试工程师确认三个业务服务的回归范围；TD-001 第一阶段进入下一个迭代，由订单服务技术负责人牵头，架构师参与方案评审。迭代计划会上明确本迭代预留约两成容量用于治理任务。该示例的适用边界是团队已有基本的需求迭代节奏；如果团队尚未形成固定迭代，可先按月设定治理窗口，再逐步过渡到迭代排期。
完成检查：计划是否可执行、可验证
计划落地前，用一份检查清单确认执行条件是否具备。清单中的每一项都应有明确答案，而不是笼统的“已安排”。
- 台账是否覆盖了约定的条目来源，字段是否填写完整，是否存在长期未更新的条目；
- 分级是否有评分或矩阵依据，高优先级条目是否附有理由，信息不足的条目是否安排了补充评估；
- 治理任务是否已拆到迭代可交付粒度，是否进入具体迭代并有负责人；
- 迭代容量是否明确预留，预留比例是否在计划会上确认；
- 角色职责是否落到具体人员，立项评审、完成验收、状态回写三个节点是否有记录位置。
效果验证可以观察两类指标：治理项完成率，即已验收条目占已排期条目的比例，用于判断执行是否跟得上计划；相关故障或变更耗时变化，例如治理涉及的模块在后续一段时间内的故障次数、需求交付周期是否出现改善。指标观察应结合治理范围解读，避免把业务波动直接归因于治理动作。
复盘节奏建议与迭代节奏对齐，每个季度做一次较完整的回顾，检查优先级队列是否仍符合业务现状、预留容量是否被持续挤占、台账口径是否需要调整。复盘输出应包含对计划的修改项，例如调整分级权重、更换巡检频率或重新划分治理范围。
有两类情况会直接导致计划不成立：台账长期无人维护，条目状态与实际脱节，分级和排期就失去依据；排期没有容量保障，治理任务持续被需求挤占，计划会退化为一份文档。出现这两类情况时，应先修复机制本身，再讨论具体条目的偿还顺序。
常见问题
技术债台账建好后很快没人更新，怎么维持？
台账失效通常源于更新动作没有嵌入既有节奏。可以把状态检查挂到每两周一次的模块巡检上，由各模块技术负责人核对本人负责的条目，把已完成项改为“已验收”，把不再适用的条目改为“暂缓”并写明原因。巡检结果在团队例会上简要同步，让台账状态与团队认知保持一致。另一个有效做法是把状态回写设为治理任务的完成条件之一，任务关闭时同步更新台账，避免两套记录脱节。
业务排期很满，技术债治理的迭代容量应该怎么定？
容量比例没有统一标准，取决于团队当前的债务压力和业务节奏。常见做法是在每个迭代划出固定比例用于治理，并在迭代计划会上明确写入，让治理项与需求项一样参与排期竞争。业务压力特别大的迭代可以下调比例，但应在计划中记录原因，避免连续多个迭代归零。如果团队尚未形成固定迭代节奏，可以先按月设定治理窗口，再逐步过渡到迭代排期。
信息不足的技术债条目，是直接排期还是先评估？
建议先做小范围评估再决定是否排期。信息不足时直接排进迭代，容易在执行中反复调整范围，消耗团队对计划的信任。可以安排半天到一天做依赖分析或影响面梳理，补齐业务影响、故障风险和偿还成本的基本判断，再进入分级评审。评估后确认影响小、成本高的条目可以暂缓或仅做监控，不必占用迭代容量。
技术债治理和缺陷管理如何划清边界？
划分依据是问题是否已经表现为功能错误。已确认的功能缺陷进入缺陷管理流程，按严重程度和修复时限处理；技术债指不直接表现为功能错误、但持续增加变更成本和故障概率的问题，例如架构耦合、重复代码、测试缺失、依赖过期和文档缺失。边界写清楚后，台账条目保持同质，分级排序才有可比性。线上事故复盘中发现的技术债条目，可以在缺陷修复完成后单独登记进台账。
治理效果怎么验证，避免只看到任务完成数？
完成率只能说明执行进度，还需要观察治理带来的实际变化。可以选取治理涉及的模块，跟踪后续一段时间内的故障次数、需求交付周期或变更耗时，与治理前的情况做对比。解读指标时要结合治理范围和业务波动，避免把无关变化归因于治理动作。复盘节奏建议与迭代对齐，每季度做一次较完整的回顾，输出对分级权重、巡检频率或治理范围的调整项。
