技术债治理预算要能持续执行，需要把它做成一个循环：预算有明确来源和计量口径，债务项进入台账并按统一规则排序，申请与审批有准入标准，批准后的额度落到团队和时间窗口，执行中按固定节奏和触发条件滚动调整，复盘结果再进入下一轮分配。本文按这一循环给出可直接套用的字段、规则和示例。
要点总览（TL;DR）
- 先定预算池边界：从研发总人力比例预留、季度专项额度或业务项目计提三种来源中选定组合，统一用人力天数或故事点计量，并明确覆盖重构、架构优化、依赖升级，不含已确认功能缺陷。
- 分配依据来自技术债台账：登记影响范围、风险等级、预估成本、关联业务与阻塞情况，按业务影响、故障风险、维护成本、阻塞程度评分排序，形成待偿清单。
- 申请与审批固定三方面分工：技术负责人评估技术合理性，业务或产品负责人评估业务影响，预算归口人核定额度；准入需满足在台账内、达到风险阈值、有验收标准三条。
- 滚动调整靠固定复盘节奏加触发条件：月度核对消耗、季度完整复盘，风险升级、业务优先级变更、进度偏差超阈值或新增高优债务时，做追加、缩减、延期或重新排序，并记录变更原因。
- 机制是否可持续，用检查清单核对：预算口径是否明确、台账是否持续维护、审批是否有标准与记录、调整是否有触发依据、复盘结果是否进入下一轮分配。
预算从哪里来：技术债预算的资金与人力口径
技术债预算的第一步是确定预算池的边界：钱或人力从哪里出、用什么单位计量、覆盖哪些工作。边界不清，后续的申请和分配就会变成临时争取资源，难以形成稳定节奏。
常见来源有三种，可以单独使用，也可以组合使用：
- 按研发总人力比例预留。在每个规划周期从研发总人力中划出固定比例用于技术债，例如每季度预留总人力的10%—15%。比例高低取决于系统老化程度和故障频率，没有统一标准，建议先按一个可承受的比例试行一至两个季度，再根据实际消耗调整。
- 按季度专项额度申请。由技术负责人或架构负责人在季度规划时提交专项额度申请，说明拟处理的债务项和预期收益，由预算归口人核定。这种方式适合债务问题集中、需要一次性投入较大改造的场景。
- 从业务项目中按比例计提。在每个业务项目的工时或成本中计提一定比例用于偿还该项目触及的技术债，例如项目排期中固定留出部分容量。这种方式能让债务偿还与产生债务的工作保持关联。
计量单位建议统一为人力天数或故事点，二选一后全周期沿用。混用两种单位会让消耗核对和跨团队比较失去可比性。无论采用哪种来源，都应在预算说明中写清：预算总量、计量单位、覆盖范围、使用期限和归口负责人。
覆盖范围建议限定为重构、架构优化、依赖升级、测试与部署基础设施改善等技术债项。已确认的功能缺陷属于缺陷管理范畴，走缺陷修复流程，不占用技术债预算，避免两类工作互相挤占额度、责任也难以追溯。
本节产出是一份预算来源与计量口径说明，至少包含：来源方式、预算总量、计量单位、覆盖范围、使用期限、归口负责人。
建立技术债台账与优先级排序规则
台账是预算分配的输入。没有台账，申请就只能凭印象描述问题，审批也难以比较不同债务项的轻重。台账应保持一份主清单，所有申请都从台账中的条目发起。
建议的台账字段如下：
| 字段 | 填写要求 |
|---|---|
| 债务项描述 | 说明问题所在模块和具体表现，避免只写“代码质量差” |
| 影响范围 | 涉及的系统、服务、团队数量 |
| 风险等级 | 按故障概率与影响面分级，如高、中、低 |
| 预估偿还成本 | 以人力天数或故事点计 |
| 关联业务 | 受影响的业务线或产品 |
| 阻塞情况 | 是否阻碍新需求交付，阻碍程度 |
| 登记人与登记时间 | 便于追溯和更新 |
排序建议从四个维度评估：业务影响、故障风险、维护成本、阻塞新需求的程度。可以为每个维度设定三档分值，加权求和后形成总分，再按总分划分优先级。评分规则应事先写定并保持稳定，避免每次排序临时调整权重导致结果不可比。
台账需要明确维护责任人，通常由技术负责人或架构负责人担任，各团队指定一名对接人负责本团队条目的登记与更新。更新频率建议与复盘节奏一致，至少每季度全量复核一次，风险等级发生变化的条目随时更新。
本节产出是台账字段表与优先级评分规则，完成标志是所有待偿债务项都已登记并完成评分排序。
申请与审批流程：谁提、谁审、按什么标准批
申请与审批解决的是“哪些债务项可以动用预算”。流程应固定申请内容、审批角色和准入标准，使批准结果可解释、可追溯。
申请人提交的内容包括：对应的台账条目、预估偿还成本、预期收益（如故障率下降、交付周期缩短、维护工时减少）、不处理的后果。预期收益尽量写成可观察的结果，例如“该模块近半年故障工单占比明显偏高，改造后预计减少重复排查工时”，避免只写“提升质量”。
审批角色建议按三个方面分工：
- 技术负责人评估技术合理性：方案是否针对根因、成本估算是否合理、验收标准是否可检验。
- 业务或产品负责人评估业务影响：该债务项对当前业务目标的影响程度，以及排期是否与业务交付冲突。
- 预算归口人核定额度：在当期预算池内是否可容纳，是否需要与其他申请比较取舍。
准入标准建议至少包含三条：条目已在台账内并完成评分；风险等级或业务影响达到当期设定的阈值；有明确的验收标准。三条同时满足才进入审批，可以减少低价值申请占用审批精力。
审批结果分为全额批准、部分批准、延后、驳回四类，每类都记录理由。部分批准需写明缩减后的范围和额度；延后需写明重新评估的时间点；驳回需说明原因，便于申请人补充后再次提交。
本节产出是申请单模板与审批角色职责表，完成标志是每一笔预算支出都能对应一条审批记录。
预算分配：额度切分与执行排期
批准之后，预算需要落到具体债务项、责任团队和时间窗口，形成可执行的计划。分配表建议按季度编制，包含以下列：债务项、责任团队、分配额度、起止时间、验收标准、关联迭代或版本。
分配时按优先级从高到低切分额度，同时预留一定比例的机动额度，用于应对执行中出现的突发债务，例如线上故障暴露出的架构问题。机动额度比例根据系统稳定性设定，常见做法是预留总预算的10%—20%，具体数值按团队实际情况确定。
排期需要与迭代和版本计划对齐。技术债工作与业务交付争用同一批人力时，提前在排期中标注占用容量，比执行中临时抽调更容易保持进度。对于跨团队的重构或依赖升级，还应标注依赖关系和先后顺序，避免多个团队同时改动同一模块。
每项预算都应写明验收标准，例如“完成某模块的依赖升级并通过回归测试”“将某服务的重复代码合并，单元测试覆盖率提升到约定水平”。验收标准是后续核对消耗和判断偿还完成的依据。
本节产出是季度预算分配表，完成标志是所有批准额度都已分配到团队和时间窗口，且每项都有验收标准。
滚动调整：触发条件与调整节奏
预算执行中，风险等级、业务优先级和实际进度都会变化，滚动调整让预算跟随这些变化，而不是按季度初的计划机械执行到底。
固定复盘节奏建议按月核对消耗与偿还进度，按季度做一次完整复盘。月度核对关注额度消耗是否与计划一致、验收标准是否达成；季度复盘关注整体偿还效果和下季度预算需求。
调整触发条件建议明确为以下几类：
- 债务项风险等级上升，例如故障频次增加或影响面扩大；
- 业务优先级变更，原计划处理的债务项关联业务被调整；
- 进度偏差超过设定阈值，例如实际消耗超出计划一定比例或进度明显滞后；
- 出现新的高优先级债务项，需要从机动额度或重新排序中安排。
对应的调整动作包括追加额度、缩减范围、延期到下一周期、重新排序。每次调整都记录变更原因、调整前后的额度与时间窗口、批准人，形成变更记录表。记录的作用是让下一轮分配有据可依，也便于复盘时判断调整是否合理。
未用完额度的处理规则需要事先约定，常见做法有三种：结转到下一周期继续使用、由预算归口人回收进入统一池、重新分配给其他待偿债务项。规则应写进预算说明，避免周期末出现突击消耗或额度长期沉淀。
本节产出是滚动调整规则与变更记录表，完成标志是每次调整都有触发依据和记录。
角色分工与交付物清单
预算循环涉及四类角色，职责边界清晰才能减少推诿和重复沟通。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 预算归口人 | 确定预算来源与总量，核定额度，处理未用完额度 | 预算来源与计量口径说明、额度核定记录 |
| 技术负责人 | 维护台账与评分规则，评估技术合理性，组织复盘 | 技术债台账、优先级评分结果、复盘报告 |
| 业务或产品负责人 | 评估业务影响，确认排期与业务交付的协调 | 业务影响评估意见、排期确认 |
| 团队执行者 | 提交申请，执行偿还工作，更新进度与验收结果 | 申请单、进度更新、验收记录 |
各环节交付物汇总为：台账、申请单、审批记录、季度分配表、滚动调整变更记录、复盘报告。这些记录建议集中存放在同一处，与债务项条目关联，便于按季度检索和对比。
决策会议建议与复盘节奏合并：月度核对以团队为单位进行，季度复盘由技术负责人组织，预算归口人和业务负责人参加，输出下季度预算建议。会议结论写入复盘报告，作为下一轮分配和调整的依据。
当团队已经在使用项目协作工具管理工作项时，可以把债务项登记为工作项，用状态字段标记申请、审批、执行、验收各阶段，把审批意见和变更原因记录在对应条目下。ONES 的工作项与状态流转可以承载这类台账和审批记录，使预算循环中的条目、额度和变更历史保持在同一处可查。具体配置方式按团队现有流程设计。
示例：一个季度的技术债预算循环
以下示例用于演示完整一轮循环，数字仅作演示，不作为行业标准。
季度初。某研发团队共有20人，按总人力10%预留技术债预算，折合约200人天。技术负责人组织各团队更新台账，登记了12个债务项，按业务影响、故障风险、维护成本、阻塞程度评分排序。排名靠前的三项分别是：支付服务依赖版本过期（预估40人天）、订单模块重复代码合并（预估30人天）、日志采集链路重构（预估25人天）。三个团队分别提交申请，技术负责人确认方案与验收标准，业务负责人确认与版本排期不冲突，预算归口人在200人天额度内核定批准，并预留20人天作为机动额度。
季度中。月度核对时发现，支付服务依赖升级实际消耗超出预估，原因是升级牵连两个下游服务需要同步改造。进度偏差超过设定阈值，触发调整：从机动额度中追加15人天，同时将日志采集链路重构延后到下季度，释放的额度用于支付服务改造。调整原因、调整前后额度和批准人记入变更记录表。
季度末。复盘显示：支付服务依赖升级完成并通过回归测试，订单模块重复代码合并完成，日志采集链路重构未启动。实际消耗185人天，剩余15人天按事先约定结转到下季度。复盘报告记录了三项债务项的偿还结果、一次调整的原因和效果，并将未启动的债务项和新增的两条高优债务项列入下季度台账，作为下一轮排序和申请的输入。
完成检查：预算机制是否可持续执行
以下检查项用于判断预算机制是否真正建立并运转，可逐项核对：
- 预算来源、总量、计量单位和覆盖范围是否已写入预算说明，并有明确的归口负责人；
- 技术债台账是否持续维护，所有申请是否都从台账条目发起，评分规则是否稳定执行；
- 申请单是否包含成本、预期收益和不处理的后果，审批是否有明确准入标准和角色分工；
- 审批结果是否分类记录，部分批准、延后和驳回是否写明理由；
- 季度分配表是否包含责任团队、额度、时间窗口和验收标准，是否预留机动额度；
- 滚动调整是否有明确的触发条件，每次调整是否记录原因和批准人；
- 未用完额度的处理规则是否事先约定并实际执行；
- 复盘报告是否包含消耗与偿还结果，并作为下一轮分配和排序的输入。
如果上述条目中有多项无法确认，说明预算仍停留在一次性立项阶段，建议先补齐台账和审批记录，再逐步建立复盘与调整节奏。
常见问题
技术债预算按研发总人力比例预留，比例定多少合适？
没有统一标准，比例取决于系统老化程度、故障频率和业务交付压力。可行的做法是先按一个团队可承受的比例试行一至两个季度，例如从总人力的10%起步，观察实际消耗与偿还效果后再调整。比例过低会导致债务持续积压，过高则可能挤压业务交付，因此建议在季度复盘时把消耗率、未完成债务项数量和故障情况一起看，作为下一轮比例调整的依据。
预算执行到一半，业务优先级变了，已批准的债务项怎么处理？
这属于滚动调整的典型场景。处理方式取决于债务项与业务的关联程度：如果关联业务被调整、该债务项的紧迫性下降，可以缩减范围或延期到下一周期，释放的额度重新分配给其他待偿债务项；如果债务项本身的风险等级没有变化，只是排期冲突，优先考虑调整时间窗口而非取消。无论哪种处理，都应记录变更原因、调整前后的额度与时间窗口、批准人，让下一轮分配有据可依。
季度末预算没用完，应该结转还是回收？
规则需要事先约定，常见做法有三种：结转到下一周期继续使用、由预算归口人回收进入统一池、重新分配给其他待偿债务项。选择哪种取决于未用完的原因：如果是排期冲突导致执行延后，结转到下季度更合理；如果是债务项本身价值下降或已完成，回收或重新分配更合适。事先不约定规则，容易出现周期末突击消耗或额度长期沉淀，两种情况都会削弱预算的实际效果。
技术债台账由谁维护，多久更新一次？
台账通常由技术负责人或架构负责人担任维护责任人，各团队指定一名对接人负责本团队条目的登记与更新。更新频率建议与复盘节奏一致，至少每季度全量复核一次；风险等级发生变化、出现新的高优先级债务项时随时更新。台账只在季度初集中整理一次，执行中就会与实际情况脱节，申请和排序也会失去依据。
团队规模较小，是否也需要完整的申请审批流程？
流程的完整程度可以随团队规模调整，但几个关键要素建议保留：申请内容包含成本、预期收益和不处理的后果；审批有明确的准入标准和责任人；批准结果有记录。小团队可以把技术评估和业务影响评估合并由同一人完成，审批环节从简，但仍应保留台账条目作为申请起点，以及变更记录作为调整依据。缺少这些记录，预算循环在复盘时就无法判断哪些投入产生了效果。
