技术债准入记录用于在技术债进入待办前完成一次明确决策：这笔债从哪里来、影响什么、偿还大概要多少成本、是否准入、由谁负责。本文提供一张可直接复制的空白表格，并逐字段说明填写口径、划分必填与选填、给出一条完整填写示例，最后说明模板上线后的调整与维护方法。文中不展开具体重构实现，已确认的功能 Bug 归缺陷管理处理。
要点总览（TL;DR）
- 技术债准入记录按“表头信息—债务描述—影响与风险—成本与收益—准入决策—跟踪”六个区域组织，空白表格可直接复制填写。
- 来源类型、风险等级、准入结论建议使用有限可选值，风险等级按影响用户范围、故障概率、恢复难度三个维度判断，结论不一致时按最高维度定级。
- 最小可评审字段集包括记录编号、债务名称、来源类型、产生原因、影响范围、风险等级、预估偿还工作量、准入结论、决策人与状态；准入结论与决策人必须成对填写。
- 填写示例展示了一条赶工期债务从登记到准入待排期的完整记录，偿还工作量用人天区间并注明估算依据，便于与需求排期比较成本。
- 模板先试用一到两个迭代再调整字段，变更保留版本记录，按复查日期跟踪已准入记录，已偿还的债务核实后关闭。
可复制空白模板：技术债准入记录表
下表按“表头信息—债务描述—影响与风险—成本与收益—准入决策—跟踪”六个区域组织，可直接复制到文档或表格工具中填写。空白单元格保留字段名，填写时逐项替换。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 表头信息 | 记录编号 | |
| 登记日期 | ||
| 登记人 | ||
| 所属系统/模块 | ||
| 债务描述 | 债务名称 | |
| 来源类型 | ||
| 产生原因 | ||
| 涉及代码或组件范围 | ||
| 影响与风险评估 | 影响范围 | |
| 风险等级 | ||
| 触发条件 | ||
| 成本与收益 | 预估偿还工作量 | |
| 偿还方式 | ||
| 不偿还的后果 | ||
| 准入决策 | 准入结论 | |
| 优先级 | ||
| 计划处理窗口 | ||
| 决策人 | ||
| 决策日期 | ||
| 跟踪 | 状态 | |
| 复查日期 | ||
| 关联需求或缺陷编号 | ||
| 备注 |
表格结构本身不解释填写口径，下一节逐字段说明每个格子应该填什么、依据什么判断。记录编号建议采用“系统缩写-年份-序号”的形式，便于跨系统检索；所属系统/模块写到团队内可识别的粒度即可，过细会增加登记负担。
字段说明：每个字段填什么、怎么判断
字段口径统一是这张表能否被复用的前提。同一字段由不同人填写时含义漂移，后续统计和排序就失去意义。以下按区域给出填写口径与判断标准。
来源类型与债务描述
来源类型建议使用有限可选值，避免自由填写导致无法归类统计。常用可选值包括：架构妥协（为满足当前需求在结构上做出的让步）、赶工期（为按时交付跳过必要设计或测试）、技术选型遗留（早期选型已不适配当前规模）、外部依赖升级（第三方组件或接口版本落后）、代码质量累积（重复代码、缺少测试、命名混乱等长期积累）。产生原因写具体事件或决策背景，例如“大促前两周为上线临时改为同步调用”，比“历史原因”更有复查价值。
风险等级判断口径
风险等级按影响用户范围、故障发生概率、恢复难度三个维度综合判断，并给出文字口径，避免只贴高/中/低标签。
| 等级 | 影响用户范围 | 故障概率 | 恢复难度 |
|---|---|---|---|
| 高 | 核心链路，影响全部或大部分用户 | 已有线上征兆或同类问题近期发生过 | 需要停机或跨团队协同才能恢复 |
| 中 | 部分用户或非核心功能 | 在特定流量或数据条件下可能触发 | 可在数小时内定位并回滚 |
| 低 | 内部使用或边缘场景 | 目前无触发迹象，属潜在隐患 | 影响可局部隔离，恢复路径清晰 |
三个维度结论不一致时，按最高维度定级，并在备注中写明理由。触发条件写清楚“什么情况下这笔债会变成故障”，例如“单日订单量超过十万时同步调用超时”。
成本与收益字段
预估偿还工作量使用人天区间，例如“3–5 人天”，并注明估算依据和估算人。区间估算表达的是量级判断，不宜写成精确承诺。偿还方式写动作类型，例如“拆分同步调用为异步消息”“补充集成测试并替换过期依赖”。不偿还的后果写可观察的影响，例如“每次大促需人工值守扩容”“新功能接入需额外适配层”。
准入结论与状态流转
准入结论使用四个可选值：准入待排期（认可债务存在，进入待办等待窗口）、准入立即处理（风险已接近触发，需当期处理）、暂不准入（当前收益不足以支撑成本，保留记录）、转缺陷管理（已确认的功能缺陷，移交缺陷流程跟踪）。状态按“待评审—已准入—处理中—已偿还—已关闭”流转，暂不准入的记录保留在待评审或单独归档，复查日期到期后重新评估。
必填与选填：哪些字段缺失就不能进入评审
最小可评审字段集决定一张记录能否进入评审会。字段缺失时，评审无法判断风险与成本，讨论会退化为信息补充。建议将以下字段设为必填：记录编号、登记日期、登记人、所属系统/模块、债务名称、来源类型、产生原因、影响范围、风险等级、预估偿还工作量、准入结论、决策人、决策日期、状态。
| 字段类别 | 字段 | 缺失后果或适用场景 |
|---|---|---|
| 必填 | 记录编号、登记日期、登记人、所属系统/模块 | 无法定位与追溯，记录无法进入台账 |
| 必填 | 债务名称、来源类型、产生原因 | 评审无法判断债务性质，归类统计失效 |
| 必填 | 影响范围、风险等级 | 无法排序，评审失去决策依据 |
| 必填 | 预估偿还工作量 | 无法与需求排期比较成本 |
| 必填 | 准入结论、决策人、决策日期 | 结论与决策人必须成对填写，缺少决策人的结论视为无效记录 |
| 必填 | 状态 | 记录无法进入跟踪流程 |
| 选填 | 涉及代码或组件范围 | 债务范围明确时填写，跨多个模块时可先写主要组件 |
| 选填 | 触发条件 | 风险等级为中或高时建议填写，低风险可省略 |
| 选填 | 偿还方式、不偿还的后果 | 准入待排期或立即处理时建议填写，暂不准入时可简写 |
| 选填 | 优先级、计划处理窗口 | 准入结论为待排期或立即处理时填写 |
| 选填 | 复查日期、关联需求或缺陷编号、备注 | 暂不准入或转缺陷管理时填写关联编号 |
不同来源类型对字段的要求可以略有差异。外部依赖升级类记录建议必填涉及组件范围与触发条件，因为版本落后往往有明确的安全或兼容窗口；代码质量累积类记录可放宽触发条件，但影响范围与偿还工作量仍需完整。转缺陷管理的记录只需保留来源、影响范围与转交编号，后续跟踪在缺陷流程中完成。
填写示例：一条完整的技术债准入记录
以下示例为演示情景：某订单服务为赶版本上线，将库存扣减改为同步调用，版本上线后该方案保留至今。示例按模板字段逐项填写，展示字段之间的对应关系。
| 字段 | 填写内容 |
|---|---|
| 记录编号 | ORDER-2025-014 |
| 登记日期 | 2025-03-10 |
| 登记人 | 订单服务后端负责人 |
| 所属系统/模块 | 订单服务 / 下单链路 |
| 债务名称 | 下单链路库存扣减采用同步调用 |
| 来源类型 | 赶工期 |
| 产生原因 | 版本上线前两周为缩短联调时间，将原计划的异步消息改为同步调用，上线后未回改 |
| 涉及代码或组件范围 | 下单接口、库存服务客户端、超时与重试配置 |
| 影响范围 | 核心下单链路，影响全部下单用户；库存服务抖动时下单失败率上升 |
| 风险等级 | 高 |
| 触发条件 | 库存服务响应超过 800ms 或大促流量峰值时，同步调用超时导致下单失败 |
| 预估偿还工作量 | 4–6 人天（含消息改造、补偿逻辑与回归测试），估算人：订单服务后端负责人 |
| 偿还方式 | 改为异步消息扣减，增加失败补偿与对账任务 |
| 不偿还的后果 | 大促期间需人工值守扩容，库存服务每次发布都可能引发下单失败 |
| 准入结论 | 准入待排期 |
| 优先级 | 高 |
| 计划处理窗口 | 下个大促前一个迭代 |
| 决策人 | 订单域技术负责人 |
| 决策日期 | 2025-03-14 |
| 状态 | 已准入 |
| 复查日期 | 2025-04-15 |
| 关联需求或缺陷编号 | 需求 ORDER-1187（下单链路异步化改造） |
| 备注 | 若大促时间提前，需重新评估是否当期处理 |
这条记录的取舍理由体现在三处：风险等级定为高，因为影响核心链路且已有超时征兆；准入结论为待排期而非立即处理，因为当前有值守手段兜底，而下个大促前存在明确窗口；偿还工作量给区间并注明估算依据，便于与需求排期比较。复查日期设在计划窗口前，用于确认排期是否落实。
调整与维护方法：让模板随团队演进而可用
模板上线后先试用一到两个迭代再调整字段，避免在填写习惯尚未形成时频繁改动。调整时遵循以下规则。
- 字段增删原则：新增字段需说明它支撑哪个决策动作，连续两个迭代无人填写的字段考虑删除或转为选填；必填字段只增不减需评审确认。
- 版本记录：每次字段变更在模板顶部记录版本号、变更日期、变更内容与原因，历史记录保留原字段口径，避免新旧记录无法比较。
- 定期复查：按复查日期检查已准入记录的处理进展，已偿还的债务核实后关闭记录，长期暂不准入的记录重新评估风险是否变化。
- 关联维护：记录与需求、缺陷、迭代计划保持编号关联，需求拆分或缺陷转交时同步更新关联字段，避免记录成为孤立台账。
- 控制膨胀：字段总数控制在可在一屏内填完的范围，评审会只检查必填字段与风险等级，选填字段按需补充，防止模板退化为形式化填表。
当记录数量增长后，准入记录需要承载为可跟踪的工作项或文档，才能与迭代计划、需求状态联动。以 ONES 为例，可以将每条准入记录建为工作项，用自定义字段承载来源类型、风险等级、准入结论与复查日期，状态流转对应“待评审—已准入—处理中—已偿还—已关闭”，关联需求与缺陷通过工作项关联关系维护。这样复查日期到期、状态变更都能在系统中被检索和提醒，模板字段口径与系统字段保持一致即可减少重复登记。具体字段配置与权限设置可按团队流程在工具中调整。
常见问题
技术债准入记录和缺陷单有什么区别，什么情况应该转缺陷管理？
技术债准入记录面向尚未进入待办的债务做决策登记，关注来源、影响、偿还成本与是否准入；缺陷单跟踪已确认的功能异常及其修复过程。判断标准是问题是否已经表现为可复现的功能错误：如果用户看到的行为与预期不符、可以定位到具体功能缺陷，就转缺陷管理，准入记录中只保留来源、影响范围与转交编号，后续跟踪在缺陷流程中完成。如果问题是结构或实现方式带来的长期隐患，尚未表现为功能错误，则留在技术债记录中评估。
团队规模较小，必填字段可以再精简吗？
可以。必填字段的作用是保证记录能进入评审并支撑排序，团队规模小、评审人数少时，可以合并部分字段，例如把登记人与决策人合并为同一角色，或把优先级并入计划处理窗口。精简时保留三类信息即可：这笔债是什么与从哪来（债务名称、来源类型、产生原因）、影响多大（影响范围、风险等级）、是否处理与谁负责（准入结论、决策人、状态）。记录编号与登记日期用于追溯，建议保留。精简后的字段口径应在团队内统一，避免不同人填写含义不一致。
预估偿还工作量估不准怎么办？
准入阶段的估算用于量级比较，不承担精确承诺的作用。建议给出人天区间并注明估算依据和估算人，例如“4–6 人天，含改造、补偿逻辑与回归测试”。如果连区间都难以给出，可以先按“小于一个迭代 / 一个迭代左右 / 跨多个迭代”三档粗估，在准入结论中标注需要细化估算，并把细化估算作为排期前的动作。复查时对比实际投入与当初估算，积累几轮后团队的估算口径会逐渐稳定。
暂不准入的记录应该怎么处理，会不会变成无人过问的台账？
暂不准入表示当前收益不足以支撑偿还成本，记录本身仍有保留价值。处理方式是为这类记录设置复查日期，到期后重新评估风险是否变化、成本是否下降、是否有新的触发事件。复查可以由登记人或所属模块负责人发起，结论更新为继续暂缓、转为准入待排期或关闭。如果连续多轮复查结论都是暂缓且风险等级没有上升，可以考虑归档，减少台账中的无效条目。
准入记录数量变多以后，怎么和迭代计划衔接？
衔接的关键是让记录具备可检索的状态与关联编号。每条记录保留关联需求或缺陷编号，准入待排期的记录在排期时把编号带入迭代计划，状态随之更新为处理中；处理完成后核实偿还结果再关闭。记录数量增长后，可以按所属系统、风险等级、复查日期做分组查看，优先处理高风险且复查日期临近的条目。若使用工具承载，可将记录建为工作项，用自定义字段保存来源类型、风险等级与准入结论，状态流转与模板保持一致，减少重复登记。
