技术债治理计划要把“看不见的债”变成可评估、可排期、可复核的工作项，核心是一套决策机制：统一登记口径、按影响与紧迫度分级、纳入迭代容量、明确角色与验收。本文按范围规则、登记分级、排期、角色分工、季度示例、工具承载和完成检查七步展开，帮助研发负责人搭建可运转的治理流程。
要点总览（TL;DR）
- 技术债治理计划先定三件事：判定口径、纳入范围、决策权限，把“代码很乱”转成可比较、可排期的条目。
- 登记字段覆盖位置、成因、影响面、偿还成本与风险，用影响与紧迫度两维交叉定级，定级结论附判断依据。
- 每个迭代预留固定比例的技术债容量（常见百分之十到二十），与业务需求并列排期；大额债务拆成可独立验收的分批任务。
- 明确提出、评估、决策、执行、验收五类角色的交付物与交接节点，按月开治理评审会，结论关联到条目和迭代计划。
- 用存量与新增速率、高优先级条目关闭周期、债务引发的返工占比等指标按季度核对，连续两个季度无改善再调整策略。
技术债治理计划先定什么：范围、口径与决策规则
计划启动前先回答三个问题：什么算技术债、哪些进治理范围、谁有权决定做与不做。这三项定下来，后续登记和排期才有统一依据，否则每个团队各说各话，条目无法横向比较。
技术债的判定口径
建议用一条可操作的判定标准：当前实现能正常工作，但结构、依赖、测试覆盖或文档的欠缺会在未来增加修改成本、故障概率或交付周期，即视为技术债。判定时要求提出方写清“未来成本体现在哪里”，例如某模块每次改动需回归测试三天、某接口耦合导致新功能无法独立发布。写不出具体成本的，先不纳入治理队列。
与缺陷管理、需求变更的边界
已确认的功能缺陷走缺陷管理流程，按缺陷严重度和修复时限处理；技术债条目聚焦结构性、可维护性与长期成本问题。需求变更属于产品范围调整，也不进技术债队列。边界不清时按“是否影响当前功能正确性”判断：影响正确性的归缺陷，影响未来改动效率的归技术债。两类工作分队列管理，避免互相挤占容量，也避免用“技术债”名义夹带未排期的需求。
治理目标与决策权限
治理目标要写成可观察的状态，例如“核心服务模块的单次改动回归时间从三天降到一天”“季度内高优先级债务条目清零”。决策权限建议分两层：迭代内的技术债取舍由研发负责人与产品负责人共同确认，跨季度的大额债务（如架构调整）由技术委员会或架构评审会决策。权限写进计划文档，评审时按权限归属找对应决策人，减少反复讨论。
本节的交付物是一份技术债判定口径表与治理范围说明，包含判定标准、边界规则、目标表述和决策权限四项内容，作为后续所有条目的准入依据。
技术债如何登记与分级：字段与评估方法
登记的目的是把“代码很乱”这类模糊判断转成可比较的条目。字段设计围绕四个问题：在哪里、为什么形成、影响多大、偿还多贵。
登记必填字段
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 位置 | 模块、服务或文件路径，精确到可定位 | 订单服务-结算模块 |
| 成因 | 形成原因，如赶工期、技术选型过时、需求叠加 | 大促前临时硬编码规则 |
| 影响面 | 受影响的业务功能、团队和改动频率 | 影响三个下游服务，月均改动四次 |
| 偿还成本 | 预估人天与所需角色 | 约八人天，需后端两人 |
| 风险 | 不处理的潜在后果，如故障概率、安全暴露 | 规则冲突时可能产生错误账单 |
影响与紧迫度的分级维度
分级用两个维度交叉判断。影响维度看波及范围：影响核心交易链路为高，影响内部工具为低。紧迫度看时间压力：已有故障征兆或阻塞近期需求为高，仅增加维护成本为低。两维交叉后形成四档：高影响高紧迫优先排入近期迭代，高影响低紧迫进入季度计划，低影响高紧迫随相关需求顺带处理，低影响低紧迫进入观察列表、定期复核。分级结果要附判断依据，避免只写一个等级。
评估所需输入与产出
评估输入包括提出方的条目描述、相关模块的改动记录与故障记录、执行方对偿还成本的估算。评估产出是定级结论、建议处理窗口和是否需要拆分。评估由熟悉该模块的技术负责人完成，评估周期控制在一周内，避免条目在评估环节积压。本节交付物为技术债登记表字段清单与分级规则，可直接作为登记模板使用。
治理排期怎么落地：容量分配与优先级规则
排期解决“什么时候做”。技术债如果只靠空闲时间处理，通常永远排不上，需要在迭代规划阶段就预留明确容量。
每迭代技术债容量的确定方式
常见做法是按团队迭代总容量划出固定比例，例如每迭代预留百分之十到百分之二十用于技术债，具体比例根据债务存量和业务压力调整。比例一旦确定，在迭代规划会上作为独立容量项列出，与业务需求并列排入，而不是等业务排满后看剩余。存量较大时可阶段性提高比例，并设定退出条件，例如高优先级条目清零后回落。
与业务需求的优先级权衡规则
权衡规则建议写成三条：一是高影响高紧迫的技术债可以挤占业务容量，但需研发负责人与产品负责人共同确认；二是与当前业务需求直接相关的技术债，随该需求一并排期，作为需求的组成部分；三是低优先级债务不单独占用迭代容量，进入观察列表按季度复核。规则的作用是减少每次排期时的临时争论，把判断前置到分级环节。
大额债务的分批偿还与里程碑
超过单迭代容量的债务（如架构拆分、测试体系重建）要拆成可独立验收的分批任务，每批设定完成标志和里程碑日期。例如一次服务拆分拆为接口梳理、数据迁移、双写验证、流量切换四批，每批单独排期和验收。里程碑用于向管理层展示进展，也用于在业务压力增大时判断哪一批可以延后、哪一批不能中断。
角色与交付物：谁提出、谁评估、谁验收
治理链条上每个环节都要有明确的责任人和交付物，否则条目容易停在“已登记”状态无人推进。
| 角色 | 职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 提出方 | 发现并描述债务，写清位置、成因与影响 | 登记条目 | 提交至评估方 |
| 评估方 | 核实描述、估算成本、给出分级 | 定级结论与处理建议 | 提交至评审会 |
| 决策方 | 确认优先级、容量分配与是否拆分 | 排期结论 | 下发至执行方 |
| 执行方 | 按批次实施偿还，更新进展 | 完成说明与验证证据 | 提交至验收方 |
| 验收方 | 核对完成标志，确认条目关闭或退回 | 验收结论 | 归档并更新存量 |
评审会议建议按月召开一次治理评审会，议程固定为四项：新增条目定级确认、待排期条目优先级调整、在办条目进展与风险、已完条目验收结论。会议控制在半小时到一小时内，结论当场记录并同步到条目上。季度末增加一次复盘，核对治理目标完成情况和容量比例是否需要调整。本节交付物为角色职责表与评审议程模板。
完整示例：一个季度的技术债治理计划
以下为演示情景，用于展示结构，不代表真实项目数据。
某研发团队在季度初启动治理，债务条目来源有三类：日常开发中提出的登记条目、故障复盘中发现的结构性问题、架构评审列出的待改进项。季度初共登记二十条，评估后定级为高影响高紧迫三条、高影响低紧迫五条、低影响高紧迫四条、低影响低紧迫八条。
排期上，团队按每迭代百分之十五预留技术债容量。三条高优先级条目排入前两个迭代，其中一条涉及结算模块的规则硬编码，拆为规则梳理和配置化改造两批执行。五条高影响低紧迫条目进入季度计划，按模块集中安排在后两个迭代。低影响高紧迫条目随相关业务需求顺带处理，低影响低紧迫条目进入观察列表，季度末复核。
执行过程中，第二批改造因业务大促延期一个迭代，评审会确认里程碑顺延但保留容量，未取消条目。季度末验收：三条高优先级条目全部关闭，五条季度计划条目完成四条，剩余一条转入下季度；观察列表中两条因影响面扩大被重新定级并排入下季度。复盘结论是容量比例维持不变，但评估环节需增加对业务节奏的预判，避免大促期间安排大额改造。
治理过程如何承载：工作项、文档与状态流转
治理机制要落到日常协作工具里，条目才有稳定的载体和可追溯的记录。承载方式包括三部分：工作项类型与字段、状态流转、评审留痕。
工作项设置上，建议为技术债建立独立的工作项类型，与缺陷、需求区分开，字段对应登记表的必填项：位置、成因、影响面、偿还成本、风险、分级结果、目标迭代。独立类型便于按队列统计存量和新增速率，也避免与缺陷队列混排。
状态流转建议覆盖完整链条：待评估、已定级、已排期、进行中、待验收、已关闭，另设观察列表作为低优先级条目的停留状态。条目从登记到关闭的每次状态变更记录操作人和时间，验收结论附在条目上，形成可回溯的记录。
评审留痕上，每次治理评审会的结论应关联到对应条目和迭代计划，包括定级调整、排期变更和验收结论。这样季度复盘时可以直接按条目和迭代汇总，不必依赖会议纪要人工整理。ONES 支持工作项类型与字段配置、状态流转以及文档与工作项的关联，可用于承载上述条目管理和评审记录；具体配置方式以团队实际使用的版本和部署方式为准。本节交付物为技术债工作项配置与状态流转方案。
完成检查：治理计划是否真的在运转
计划是否落地，可以用一组可逐项核对的检查项判断，而不是看文档写得多完整。
各环节检查项
- 登记：本季度新增条目是否都有完整必填字段，是否存在长期停留在待评估状态的条目。
- 分级：定级结论是否附判断依据，分级结果与后续排期是否一致。
- 排期：每个迭代是否实际预留了技术债容量，预留容量是否被业务需求挤占且未记录原因。
- 验收：已完条目是否有验收结论和验证证据，关闭条目是否更新了存量统计。
- 评审：评审会是否按频率召开，结论是否关联到条目和迭代计划。
效果验证的观察指标
指标口径需在计划启动时确定。常用指标包括：债务条目存量与季度新增速率、高优先级条目的平均关闭周期、因债务引发的返工或故障占比、核心模块的改动回归时间。指标用于判断趋势，单季度波动不必过度解读，连续两个季度无改善才需要调整策略。
计划失效时的调整信号
出现以下信号说明计划需要调整：连续两个迭代技术债容量被完全挤占且无记录；新增条目速率持续高于关闭速率；评审会连续缺席或结论不落到条目；高优先级条目长期停留在已排期状态。调整方向包括重新校准分级标准、调整容量比例、收紧准入口径或更换决策人。本节交付物为治理计划完成检查清单，可按季度逐项核对。
常见问题
技术债和已确认的功能 Bug 怎么区分，能放在同一个队列里吗？
按“是否影响当前功能正确性”判断：已确认的功能缺陷走缺陷管理流程，按严重度和修复时限处理；技术债条目聚焦结构性、可维护性与长期成本问题。两类工作建议分队列管理，各自有独立的容量和统计口径，避免互相挤占，也避免用技术债名义夹带未排期的需求。边界不清的条目，在登记时要求提出方写清未来成本体现在哪里，写不出具体成本的先不纳入治理队列。
团队业务压力大，技术债容量经常被挤占，计划还要继续吗？
可以继续，但要把挤占变成显式决策而不是默认结果。规则上允许高影响高紧迫的技术债挤占业务容量，前提是研发负责人与产品负责人共同确认，并在条目或迭代计划上记录原因。如果连续两个迭代容量被完全挤占且没有记录，说明计划已经失效，需要重新校准分级标准或调整容量比例。大促等可预期的业务高峰，可以在季度计划阶段就预判，把大额改造避开这段时间。
大额技术债跨多个迭代，怎么避免做到一半失去推进？
把大额债务拆成可独立验收的分批任务，每批设定完成标志和里程碑日期，单独排期和验收。例如服务拆分拆为接口梳理、数据迁移、双写验证、流量切换四批。里程碑的作用有两个：向管理层展示进展，以及在业务压力增大时判断哪一批可以延后、哪一批不能中断。评审会上按批次核对进展，延期要记录原因并确认容量是否保留。
治理评审会应该多久开一次，议程怎么定才不流于形式？
建议按月召开一次，议程固定为四项：新增条目定级确认、待排期条目优先级调整、在办条目进展与风险、已完条目验收结论。会议控制在半小时到一小时内，结论当场记录并关联到对应条目和迭代计划，季度末增加一次复盘。如果评审会连续缺席，或结论不落到条目上，就是计划需要调整的信号。
技术债条目在协作工具里怎么承载，才能支撑季度复盘？
建议为技术债建立独立的工作项类型，与缺陷、需求区分开，字段对应登记表必填项，包括位置、成因、影响面、偿还成本、风险、分级结果和目标迭代。状态流转覆盖待评估、已定级、已排期、进行中、待验收、已关闭，另设观察列表停留低优先级条目。每次状态变更记录操作人和时间，评审结论关联到条目和迭代计划，季度复盘时可直接按条目和迭代汇总。ONES 支持工作项类型与字段配置、状态流转以及文档与工作项的关联，可用于承载上述管理动作，具体配置方式以团队实际使用的版本和部署方式为准。
