技术债治理预算要经得起评审，关键在三个动作：先划定纳入治理的债务范围与时间跨度，再统一人天单价、币种、税费等计价口径，最后用“债务项工作量×单价+固定投入”的公式组装成可复算的年度预算。本文按范围、成本项、口径、模型、敏感因素、取数六步展开，示例金额均为假设，与现价分开标注。
要点总览（TL;DR）
- 技术债治理预算按“范围—成本项—口径—模型—敏感因素—取数”六步测算，先划定纳入治理的债务类型与时间跨度，再逐项折算成金额。
- 成本科目至少覆盖人力、外部服务、环境与工具、机会成本四类；机会成本单独列示，不并入直接预算。
- 核心公式为年度预算=Σ（债务项工作量×人天单价）+固定投入+外部服务费，并按季度给出投入分布。
- 人天单价、币种、税费、计费周期需统一口径；示例假设与现价分开标注，没有采购记录的价格标为待询价。
- 对单价、范围规模、返工率、依赖升级复杂度做乐观、基准、保守三档测算，并写明缓冲额度的触发条件。
预算测算先划定范围与时间跨度
技术债治理预算失真的常见原因，是范围在编制过程中不断扩张：原本只算架构改造，评审时又把功能缺陷修复、日常运维一并塞进来，总额自然对不上。因此第一步是把“哪些债纳入本次预算”写成清单，作为后续所有测算的边界。
纳入项建议按债务类型分类列出，便于分别估算工作量：
- 架构类：模块耦合拆分、服务边界调整、数据模型重构；
- 代码质量类：重复代码清理、圈复杂度治理、静态扫描高优先级问题修复；
- 测试与文档类：补齐自动化测试、更新过期的接口文档与部署说明；
- 依赖升级类：框架版本升级、第三方库安全补丁、运行时版本迁移。
排除项同样要写明。已经确认的功能缺陷归缺陷管理流程处理，不计入技术债治理预算；计划内的新功能开发、常规运维值班也不纳入。排除项写清楚，评审时才能解释“为什么这笔钱不在预算里”。
时间跨度上，年度预算需要给出总额，同时拆到季度或迭代。建议按季度分配，因为技术债治理通常与业务需求争抢同一批研发人力，季度粒度既能体现节奏，又便于在季度复盘中调整。预算单元可以按系统、模块或团队切分：系统维度适合架构级债务，模块维度适合代码质量类债务，团队维度适合把预算落到具体执行人。三种切分方式可以叠加使用，但同一笔工作量只能归集一次，避免重复计算。
本步的交付物是一份预算范围清单，字段包括：债务项名称、类型、所属系统或模块、纳入或排除、计划治理季度、初步工作量区间。这份清单是后续成本拆解和公式计算的输入。
技术债治理的成本和资源项拆解
范围确定后，把每一项治理活动折算成可计价、可归集的成本科目。技术债治理的投入以人力为主，但只算人力会漏掉外部服务、环境资源和机会成本，导致预算申请时被质疑“算少了”。
| 成本科目 | 包含内容 | 计量单位 | 归集口径 |
|---|---|---|---|
| 人力成本 | 研发改造、测试验证、架构评审投入的人天 | 人天 | 按债务项归集，区分角色 |
| 外部成本 | 外包改造、专项工具或服务采购 | 合同金额或人天 | 按合同或采购单归集 |
| 环境与工具成本 | 测试环境、构建资源、监控与静态扫描工具 | 席位、资源规格或订阅周期 | 按项目分摊或全额计入 |
| 机会成本 | 治理期间让出的业务需求产能 | 人天折算 | 单独列示，不并入直接成本 |
人力成本是主体。研发人天按改造工作量估算，测试人天按验证范围估算，架构评审人天按评审次数和参与人数估算。三类人天可以合并为“总人天”，但建议在预算表中保留角色拆分，便于后续按单价差异计算。
外部成本适用于团队内部缺少特定技能的场景，例如老旧框架升级需要外部顾问，或专项静态扫描服务按年采购。这类成本按合同金额直接计入，不需要再乘人天单价。
环境与工具成本容易被忽略。治理期间往往需要额外的测试环境、更长的构建资源占用，以及监控和扫描工具的席位。席位类工具按订阅周期折算到年度，资源类按实际使用规格估算。
机会成本的处理方式是单独列示、不并入直接预算。治理投入占用的研发人力，本可以用于业务需求交付，这部分产出损失可以用人天折算成金额，作为决策参考。把它混入直接成本会让预算总额虚高，单独列示则能在评审时说明“这笔投入换来了什么”。
口径与假设：让预算可复算
同一份预算，换一个人用不同单价重算，结果可能差出一大截。口径的作用是让任何人拿到预算表都能复算出相同结果。需要统一的至少包括四项：人天单价、币种与汇率、税费、计费周期。
人天单价的来源有两种：内部核算价和外部市场参考价。内部核算价由财务按人力成本分摊得出，适合内部预算审批；市场参考价用于外包或外部服务比价。两种单价不能混用在同一张表里，否则总额没有意义。单价是否含税要明确标注，含税价和不含税价在汇总时不能直接相加。
币种方面，如果涉及海外工具订阅或外部服务，需要写明结算币种和折算汇率，并注明汇率取值日期。汇率波动较大的年份，可以在敏感性分析中单独设一档。
席位或订阅类工具按计费周期折算：月付按12个月折算年费，年付直接取年费，多年合同按年度分摊。折算时注明是否包含折扣、是否含实施服务费。
示例假设与现价必须分开标注。例如“假设内部研发人天单价为某一示例值”，这类数字只用于演示计算过程，不代表任何企业的实际价格；工具订阅价格、外包报价属于时效性信息，没有采购记录支撑时，在预算表中标注为“待询价”，不填入具体金额。评审时，现价数据附采购记录或报价单，示例假设单独成列，两者不混算。
计算模型与年度预算框架
口径统一后，用一条公式把范围、成本项和单价组装起来：
年度预算 = Σ（债务项工作量 × 人天单价）+ 固定投入 + 外部服务费
其中固定投入指不随工作量变化的支出，如工具年费、环境资源年费；外部服务费按合同金额计入。机会成本不进入公式，在预算表下方单独列示。
投入节奏有两种排法。固定比例预留适合治理目标明确、债务项优先级差异不大的情况，例如每季度预留研发总人天的固定比例用于技术债治理，全年均匀投入。按优先级排期适合债务项之间依赖关系强的情况，先治理影响发布稳定性的架构问题，再处理代码质量类债务，季度投入前低后高。两种排法都要在预算表中体现季度分布，而不是只给年度总额。
预期回报的量化，用治理前后的指标对比来折算。常用指标包括缺陷率、发布周期、变更失败率。做法是先记录基线值，再设定治理后的目标值，用差值乘以业务口径折算成收益。例如变更失败率下降带来的返工人天减少，可以按人天单价折算成金额。需要说明的是，这类折算依赖基线数据的准确性，基线采集方式要在预算表中注明，避免把估算收益写成确定收益。
预算表建议包含以下字段：债务项、所属系统或模块、工作量（人天）、人天单价、金额、季度分布、负责人、数据来源。字段齐全的预算表可以直接提交评审，也便于执行阶段逐项跟踪。
在预算执行阶段，技术债项登记、工作量估算和实际投入跟踪需要落在同一套研发管理流程里。ONES 可以承载技术债项作为工作项的登记与状态流转，把估算人天和实际投入记录在同一处，预算表与实际执行数据能够对照，季度复盘时直接取数，减少手工汇总。具体能力以官方资料为准。
敏感因素与预算弹性
基准预算算出来后，还要回答“如果条件变了，预算会偏多少”。技术债治理预算对四类变量最敏感：人天单价、范围规模、返工率、依赖升级复杂度。
人天单价受人力成本调整和外包市场价格影响；范围规模取决于治理过程中新发现的债务项数量；返工率反映改造后验证不通过、需要二次修改的比例；依赖升级复杂度在老旧系统上往往被低估，升级一个底层框架可能牵动多个模块。
建议按乐观、基准、保守三档测算：
| 情景 | 假设条件 | 预算用途 |
|---|---|---|
| 乐观 | 范围不扩张，返工率低，单价不变 | 预算下限，用于争取立项 |
| 基准 | 按当前估算范围和单价计算 | 提交评审的主预算 |
| 保守 | 范围上浮一定比例，返工率上升，单价按上限 | 申请缓冲额度的依据 |
缓冲比例不宜拍脑袋，可以按保守档与基准档的差额确定，并在预算中说明触发调整的条件：例如季度复盘中新发现债务项超过一定数量，或返工率连续两个迭代高于阈值，则启用缓冲额度。触发条件写清楚，缓冲才不会被当成“预留的余量”随意消耗。
取数方法与数据来源
预算评审时，评委最常问的是“这个数字从哪来”。每一项数据都应能追溯到来源，并标注置信度。
工作量估算有三个来源：历史工单记录同类改造的实际耗时；代码扫描结果给出问题数量和分布，作为范围依据；团队评估用于扫描工具覆盖不到的部分，如架构调整。三种来源可以交叉验证，历史工单和团队评估偏差较大时，取区间而非单点。
单价与采购价来自财务核算口径和采购记录。内部人天单价由财务提供，外部服务价以报价单或合同为准。没有采购记录的价格，标注为待询价，不填估算值。
指标基线与改善目标的数据采集方式要写明：缺陷率取自缺陷管理系统，发布周期取自发布记录，变更失败率取自变更与回滚记录。采集周期和统计口径一并注明，避免治理前后口径不一致导致收益虚高。
数据缺失时，用替代估算并标注方法。例如缺少历史工单时，用同类项目的团队评估值替代，置信度标为低；扫描工具未覆盖的模块，按已覆盖模块的平均问题密度推算，并注明推算假设。置信度建议分三档：有历史数据支撑为高，有部分数据加团队评估为中，纯估算为低。预算表中每项金额对应一个置信度，评审时优先复核低置信度项。
六步走完，预算表、口径说明、情景区间和取数登记表构成一套完整材料。年度预算编制中，这套材料既能回答“要多少钱”，也能回答“钱怎么花、偏了怎么办、数字可不可信”。
常见问题
技术债治理预算和缺陷修复预算怎么分开算？
在范围清单阶段就写明排除项：已经确认的功能缺陷归缺陷管理流程，其修复人力不计入技术债治理预算。技术债治理预算只覆盖架构调整、代码质量、测试与文档补齐、依赖升级这几类主动治理活动。如果某次改造同时涉及缺陷修复，按工作量拆分归集，同一笔人天只计入一个科目，避免两边重复申报。
团队没有历史工单数据，工作量估算怎么做？
可以先用代码扫描结果给出问题数量和分布，作为范围依据；扫描覆盖不到的架构调整部分，由团队评估给出区间而非单点。缺少同类项目历史记录时，用团队评估值替代，并在预算表中把该项置信度标为低，评审时优先复核。治理启动后，把实际投入人天回填到预算表，下一轮编制就有基线可用。
预算批下来后，季度执行超支了怎么处理？
先在编制阶段设定触发条件，例如季度复盘中新发现债务项超过约定数量，或返工率连续两个迭代高于阈值，才启用保守档与基准档之间的缓冲额度。超支原因属于范围扩张的，补充债务项登记并重新排期；属于单价或外部报价变化的，更新口径说明后按新价格重算剩余季度。缓冲额度没有触发条件支撑时，不随意消耗。
预期回报的收益折算能不能直接写进预算申请？
可以写，但要标注为估算收益并说明基线来源。做法是记录治理前的缺陷率、发布周期、变更失败率基线值，设定目标值，用差值按人天单价折算成金额。基线采集系统和统计口径要一并注明，避免治理前后口径不一致导致收益虚高。评审材料中把估算收益与确定成本分列，便于评委判断投入产出。
技术债项和预算执行数据放在哪里跟踪比较合适？
技术债项登记、工作量估算和实际投入跟踪放在同一套研发管理流程里，季度复盘时可以直接取数。ONES 可以承载技术债项作为工作项的登记与状态流转，把估算人天和实际投入记录在同一处，与预算表对照。具体能力以官方资料为准。
