技术债务治理要解决的是决策问题：哪些债值得记、先还哪一笔、什么时候还、由谁拍板。把这些判断从个人经验变成团队流程，债务才不会长期停留在讨论里。本文按登记口径、分级决策、迭代排期、执行示例和效果验证五个环节展开，给出可直接套用的字段表、规则和检查清单。债务项与需求、缺陷、版本的关联和状态流转，可以在ONES的工作项与文档中承载，具体配置按团队实际流程设定。
要点总览（TL;DR）
- 技术债治理从统一登记口径开始：同时满足偏离合理设计、持续产生成本、可被记录追踪三个条件才计入债务台账，已确认功能Bug走缺陷管理。
- 分级按业务影响面、故障或变更风险、偿还成本、成本放大速度四个维度判断，挂账项必须写明触发式偿还条件，决策记录保留依据与审批人。
- 偿还进入迭代需要固定配额和检查节点，需求评审、技术方案评审、迭代计划、发布前检查各设债务检查动作，产品、研发、架构、测试按输入输出分工。
- 效果验证分过程与结果两类指标：登记覆盖率、分级完成率、偿还计划达成率，以及重复故障次数、模块改动耗时、变更失败情况，按季度复盘调整规则。
- 机制失效的典型信号是台账长期不更新、偿还任务只停留在文档、同类债务反复出现却未触发偿还，对应收紧触发条件或前移检查节点。
技术债务治理先定口径：什么算债、记在哪里
治理的第一步是统一判定条件。建议采用三个条件同时满足的口径：当前实现偏离了合理设计；这种偏离会持续产生维护、理解或变更成本；它可以被具体记录和追踪。只满足其中一条的，多数属于普通需求、优化建议或已确认缺陷，不应进入债务台账。口径统一后，团队讨论“这笔债该不该还”时才有共同前提。
技术债与已确认功能Bug的边界需要写清楚：已经表现为功能错误、数据错误或用户可感知故障的问题，进入缺陷管理流程，按缺陷的严重程度和修复时限处理；技术债登记的是尚未表现为功能故障、但在后续改动中持续消耗成本的实现问题，例如重复逻辑、过时依赖、缺少自动化验证的关键路径、耦合过深的模块边界。普通需求变更也不计入债务，除非变更本身留下了需要持续维护的临时方案。
登记表是治理的基础设施，字段不宜多，但要能支撑后续分级和排期。建议包含以下核心字段：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 位置 | 模块、服务或代码目录，精确到可定位的范围 | 关联改动、估算成本 |
| 类型 | 设计债、代码债、测试债、依赖债、文档债等 | 归类统计与复盘 |
| 成因 | 赶工期、需求变更、技术选型遗留、人员交接等 | 识别源头，防止同类新增 |
| 影响面 | 受影响的业务功能、团队和使用方 | 分级时判断业务影响 |
| 利息表现 | 当前已经造成的具体成本，如改动耗时增加、重复故障、发布等待 | 证明偿还价值 |
| 触发条件 | 什么情况下必须处理，如再次改动该模块、临近大版本 | 支撑挂账管理 |
| 责任人 | 对该模块最熟悉的研发人员或架构角色 | 保证信息更新 |
| 状态 | 待评估、已挂账、已排期、偿还中、已关闭 | 跟踪流转 |
登记入口建议放在两个位置：技术方案评审时由评审人提出，日常开发中由改动该模块的研发人员补充。更新频率与迭代节奏对齐，每个迭代结束时由责任人复核自己名下债务项的利息表现和触发条件，避免台账变成一次性文档。
分级与决策：哪些债先还、哪些先挂账
分级的目的不是给债务排一个绝对顺序，而是让“先还”和“先挂账”都有可解释的依据。建议从四个维度评估：业务影响面，即债务所在模块支撑多少业务和用户；故障或变更风险，即该处出问题或需要改动时的影响范围；偿还成本，包括人力和回归验证投入；随时间放大的速度，即拖延后成本增长快慢。四个维度分别给出高、中、低判断，再综合形成优先级，避免只用“技术上看不顺眼”一个维度决定顺序。
决策规则可以按优先级分档：高影响、高风险且放大速度快的债务，进入当前或下一迭代；影响中等但触发条件明确的，挂账并写明触发式偿还条件；影响低且成本高的，记录在案，按季度复核。挂账不等于不处理，必须写清触发条件，常见的有三类：再次改动该模块时强制纳入偿还；临近重要版本发布前做专项检查；同一位置出现重复故障时升级处理。
审批角色要与决策影响匹配。业务影响判断由产品负责人确认，偿还成本估算由研发负责人给出，技术方案和风险判断由架构角色把关。高优先级债务的排期需要产品与研发共同确认，避免单方面插入打乱迭代承诺；挂账项由模块责任人维护，架构角色定期抽查触发条件是否仍然成立。决策记录至少保留：评估结论与依据、选择偿还或挂账的理由、触发条件、审批人和决策日期。这些信息在季度复盘时是判断规则是否有效的直接材料。
把偿还排进迭代：配额、节点与角色分工
债务偿还只有进入迭代计划才算真正排期。常见做法是每个迭代预留一定比例的工作量用于债务偿还，比例根据债务存量和团队容量确定，不设统一数字；当出现重大风险或版本压力时允许临时调整，但调整需要在迭代计划中记录原因，避免配额被静默挤占。配额之外，触发式偿还项应优先占用这部分容量。
债务检查应嵌入现有研发节点，而不是另设一套流程：
- 需求评审：判断需求是否触及已知债务区域，触及则关联对应债务项，评估是否顺带偿还。
- 技术方案评审：评审人检查方案是否新增债务，新增的当场登记；涉及既有债务的，明确本次是否处理。
- 迭代计划：研发负责人汇总候选债务项，结合配额确定本迭代偿还清单，产品负责人确认业务影响判断。
- 发布前检查：核对本版本涉及的债务项状态，触发条件已满足但未处理的，说明原因并记录。
角色分工按输入和交付物界定：产品负责人提供业务影响判断和优先级确认；研发负责人负责成本估算、排期和容量协调；架构角色负责技术判断、方案把关和分级复核；测试提供故障信号和回归风险，帮助判断债务是否已转化为缺陷。每个角色的输出都落到具体记录上，而不是停留在会议口头结论。
债务项需要与需求、缺陷、版本建立关联：偿还任务作为独立工作项排入迭代，关联触发它的需求或故障记录，并标注目标版本。这样在版本发布和季度复盘时，可以按版本统计偿还完成情况，也能看出哪些债务反复被触发却一直未处理。在ONES中，这类关联可以通过工作项之间的关联关系和版本字段承载，使债务项与需求、缺陷处于同一跟踪视图，减少台账与研发实际状态脱节。
示例：一个支付模块的债务治理走一遍
以下为演示情景，用于说明字段填写和决策过程，不代表真实项目数据。
某团队的支付模块在多次促销需求后，出现三套并行的优惠计算逻辑，新需求每次都要改三处。研发人员在改动时登记了一笔债务：位置为支付模块优惠计算；类型为设计债；成因为连续赶工期叠加需求变更；影响面为所有使用优惠券的订单；利息表现为每次优惠相关需求平均需要改动三个文件并做三轮回归；触发条件为下次涉及优惠规则的需求；责任人为该模块研发负责人；状态为待评估。
分级评估时，业务影响面为高，因为优惠覆盖大部分订单；变更风险为高，三套逻辑容易不一致；偿还成本为中，需要合并逻辑并补充回归用例；放大速度为快，需求越密集成本越高。结论是进入下一迭代偿还，由研发负责人估算工作量，产品负责人确认不影响当期需求承诺，架构角色评审合并方案。决策记录写明选择偿还的理由和审批人。
排期后，偿还任务作为独立工作项进入迭代，关联触发它的促销需求，并标注目标版本。执行中测试补充了优惠组合的回归用例，发布前检查确认三套逻辑已合并为一套、旧入口已下线。偿还完成后，责任人把状态更新为已关闭，并在记录中写明验证结果：优惠相关需求的改动范围缩小，回归用例纳入常规测试集。下一季度复盘时，这笔债务作为“需求密集区域优先偿还”的正面例子，用于校准同类债务的分级判断。
治理效果怎么验证：指标与完成检查
机制是否运转，要看过程指标和结果指标两类数据。过程指标反映流程执行情况：登记覆盖率，即技术方案评审和日常改动中提出的债务是否都被记录；分级完成率，即登记债务是否在规定时间内完成评估；偿还计划达成率，即排入迭代的债务项是否按计划关闭。结果指标反映债务的实际成本变化：同一模块重复故障次数、改动该模块的平均耗时、变更失败情况。结果指标需要团队积累基线，初期看趋势而非绝对值。
季度复盘建议逐项检查规则有效性：分级维度是否仍能区分优先级，是否出现大量债务集中在同一档；挂账项的触发条件是否被实际执行，有没有长期挂账且从未触发的条目；迭代配额是否被稳定执行，临时调整是否都有记录；角色分工是否落地，产品、研发、架构、测试的输出是否齐全；登记口径是否出现混入缺陷或普通需求的情况。检查结果用于调整规则，而不是追究单笔债务。
机制失效的常见信号包括：台账登记后长期无人更新；债务项与迭代计划脱节，偿还任务只存在于文档；同一模块反复出现同类债务却未触发偿还；配额每个迭代都被挤占且无记录。对应的调整方向是收紧触发条件、把债务检查前移到方案评审、或重新校准配额与分级权重。以下检查清单可用于季度自评：
- 本季度新增债务是否都有位置、成因、影响面和责任人。
- 登记债务是否在约定时限内完成分级，挂账项是否写明触发条件。
- 排入迭代的债务项是否按计划关闭，未关闭项是否有原因记录。
- 重复故障次数和模块改动耗时是否呈下降或稳定趋势。
- 产品、研发、架构、测试在债务决策中的输出是否可查。
- 配额执行情况和临时调整是否在迭代记录中可追溯。
把这套检查结果与下一季度的分级规则和配额调整挂钩，技术债治理就形成了从登记到复盘的闭环，债务决策也从个人判断转为团队可持续执行的机制。
常见问题
技术债登记后长期没人更新，台账变成一次性文档怎么办？
这通常说明登记动作与研发节奏脱节。可以把复核责任落到模块责任人身上，与迭代节奏对齐：每个迭代结束时复核自己名下债务项的利息表现和触发条件，更新状态。同时把登记入口前移到技术方案评审，让新增债务在产生时就被记录，减少事后补录。台账字段保持精简，只保留支撑分级和排期所需的信息，维护成本过高本身会削弱更新意愿。
迭代配额总被业务需求挤占，偿还计划无法执行怎么处理？
先确认挤占是否有记录。允许在版本压力或重大风险时临时调整配额，但调整原因要写进迭代计划，便于季度复盘判断是偶发还是常态。如果连续多个迭代配额都被挤占，需要重新校准配额比例与分级权重，并把高影响、高风险的债务项在计划阶段就与产品负责人确认排期，避免在迭代中途被动让位。触发式偿还项应优先占用配额容量，减少与其他需求争抢。
技术债和已确认的功能Bug在流程上如何避免混在一起？
按表现划分：已经表现为功能错误、数据错误或用户可感知故障的问题进入缺陷管理流程，按缺陷严重程度和修复时限处理；技术债登记的是尚未表现为功能故障、但在后续改动中持续消耗维护成本的实现问题。两者可以在工作项上建立关联，例如某笔债务因重复故障被升级处理时，关联对应的缺陷记录，但状态流转和时限规则各自独立，避免用缺陷流程管理债务，也避免债务台账混入待修复缺陷。
团队规模较小、没有专职架构角色时，分级审批怎么安排？
审批角色可以合并，但判断依据要分开保留。业务影响判断仍由产品负责人确认，偿还成本估算由研发负责人给出，技术判断可由团队内最熟悉该模块的资深研发承担，并在决策记录中写明评估依据。关键是每笔高优先级债务的排期都有产品与研发的共同确认，挂账项写明触发条件并定期抽查。角色合并时更容易出现单方面决定，决策记录中的理由和审批人信息就更需要完整。
结果指标初期没有基线，怎么判断治理是否有效？
初期看趋势而非绝对值。先记录重复故障次数、改动该模块的平均耗时、变更失败情况等指标的当前水平，按季度对比变化方向。同时重点看过程指标是否稳定：登记覆盖率、分级完成率、偿还计划达成率能否持续达成。过程指标先达标，结果指标的改善通常滞后出现；如果过程指标正常而结果指标长期无变化，需要检查分级规则是否把资源投向了真正高成本的债务。
