交付依赖升级跟踪记录模板由两张相互衔接的表组成：依赖登记清单负责把每条跨团队依赖登记清楚，升级跟踪记录负责记录依赖未落实后的每一次升级动作。两表通过依赖编号关联，状态字段统一取值，升级记录只追加不覆盖，形成从登记到关闭的可追溯链路。下面给出可直接复制的空白表、字段口径、必填规则、完整填写示例和维护方法。
要点总览（TL;DR）
- 模板由两张表组成：依赖登记清单负责登记每条跨团队依赖，升级跟踪记录负责记录依赖未落实后的每次升级动作，两表通过依赖编号关联。
- 依赖登记清单的核心字段是依赖编号、提出方、承接方、依赖内容、期望交付时间、当前状态和责任人；升级跟踪记录的核心字段是升级编号、关联依赖编号、触发条件、升级层级、升级对象、诉求与承诺和关闭结论。
- 状态与升级层级使用统一枚举取值，升级记录只追加不覆盖；必填字段缺失时退回补录，补录完成前不进入跟踪流程。
- 模板可按团队规模和依赖类型裁剪字段，但依赖编号、关联依赖编号、状态、责任人和关闭结论建议始终保留，并指定维护责任人记录变更。
- 把依赖登记清单作为交付计划评审的输入、升级跟踪记录作为例会固定议题，只讨论受阻和已升级的依赖，模板才能长期用下去。
可复制空白模板：依赖登记清单与升级跟踪记录表
先把两张表复制到文档或表格工具中，再按“先登记、后升级”的顺序使用。依赖登记清单每条依赖占一行，升级跟踪记录每次升级动作占一行，两表通过“依赖编号—关联依赖编号”建立一对多关系：一条依赖可以对应零条或多条升级记录，但每条升级记录必须指向一条已登记的依赖。
表一：依赖登记清单
| 依赖编号 | 提出方 | 承接方 | 依赖内容 | 期望交付时间 | 影响范围 | 当前状态 | 责任人 |
|---|---|---|---|---|---|---|---|
| DEP-001 |
表二：升级跟踪记录
| 升级编号 | 关联依赖编号 | 升级触发条件 | 升级层级 | 升级对象 | 升级时间 | 诉求与承诺 | 下次跟进时间 | 关闭结论 |
|---|---|---|---|---|---|---|---|---|
| ESC-001 |
使用顺序分三步：第一步，在依赖登记清单中登记依赖，填写提出方、承接方、依赖内容、期望交付时间和责任人，状态置为“已登记”；第二步，依赖推进过程中更新状态，出现逾期或受阻时按触发条件在升级跟踪记录中新增一行；第三步，依赖落实或确认无法落实后，在登记清单更新最终状态，并在升级跟踪记录中填写关闭结论。升级记录只追加，不修改历史行，保证每次升级动作都能回看。
字段说明：每个字段记录什么、怎么填
字段口径统一，模板才能被不同团队一致使用。下面按两张表逐字段说明含义、填写方式和常见填错情形。
依赖登记清单字段
| 字段 | 记录什么 | 填写口径 | 常见填错 |
|---|---|---|---|
| 依赖编号 | 该条依赖的唯一标识 | 按“DEP-三位流水号”编码，全表唯一，登记后不再变更 | 重复编号；用依赖内容代替编号 |
| 提出方 | 需要这项依赖的团队或角色 | 写到团队名加具体接口人，如“订单团队-张三” | 只写部门名，找不到具体对接人 |
| 承接方 | 负责提供依赖的团队或角色 | 同样写到团队名加接口人 | 写“相关团队”等模糊表述 |
| 依赖内容 | 需要对方交付的具体事项 | 写清交付物、接口或数据范围，可验收 | 写成“支持一下”“配合联调” |
| 期望交付时间 | 提出方需要拿到依赖的时间 | 写具体日期，并注明该时间对应的下游节点 | 只写“尽快”“本月底” |
| 影响范围 | 依赖未落实会波及的对象 | 写受影响的版本、功能、客户或里程碑 | 留空或写“无”，实际有影响 |
| 当前状态 | 依赖所处的推进阶段 | 从统一枚举中取值，见下文 | 各团队自造状态名 |
| 责任人 | 负责跟进这条依赖的人 | 写提出方一侧的跟进人，负责发起升级 | 填成承接方接口人，无人推动 |
升级跟踪记录字段
| 字段 | 记录什么 | 填写口径 | 常见填错 |
|---|---|---|---|
| 升级编号 | 本次升级动作的唯一标识 | 按“ESC-三位流水号”编码，全表唯一 | 与依赖编号混用 |
| 关联依赖编号 | 本次升级对应的依赖 | 必须填写已存在的依赖编号 | 填写不存在的编号或留空 |
| 升级触发条件 | 为什么发起这次升级 | 写具体事实，如“超过期望交付时间3个工作日未回复” | 写“对方不配合”等主观判断 |
| 升级层级 | 本次升级到达的组织层级 | 从统一枚举中取值，见下文 | 层级跳级且无记录 |
| 升级对象 | 本次升级对接的人或会议 | 写具体人名、角色或会议名称 | 只写“领导” |
| 升级时间 | 发起升级的日期 | 写具体日期 | 补记时写成计划日期 |
| 诉求与承诺 | 提出方要什么、对方答应什么 | 分两句写：诉求一句，承诺一句，承诺带时间和交付物 | 只写“已沟通”，没有承诺内容 |
| 下次跟进时间 | 下一次检查承诺兑现的日期 | 写具体日期，通常为承诺时间后1至2个工作日 | 留空，升级后无人跟进 |
| 关闭结论 | 本次升级的收口结果 | 写“已解决”“转为风险”“继续升级”等结论并附一句依据 | 未兑现就写“已解决” |
枚举取值与编码规则
状态和升级层级是两张表能否对齐的关键，建议在模板中固定取值，不允许各团队自行扩展：
- 当前状态取值：已登记、推进中、受阻、已升级、已交付、已关闭。其中“已升级”表示已存在至少一条升级记录，“已关闭”表示依赖落实或确认终止。
- 升级层级取值：接口人级、团队负责人级、项目/交付负责人级、管理层级。层级逐级上升，跳级时需在触发条件中写明原因。
- 依赖编号规则：DEP-加三位流水号，按登记顺序递增，作废依赖保留编号并置为“已关闭”，编号不复用。
- 升级编号规则：ESC-加三位流水号，全局递增，与依赖编号分开编号，便于统计升级次数。
必填与选填：哪些字段缺失就不能进入跟踪
必填字段的作用是保证每条依赖都能找到人、找到时间、找到状态。必填缺失时不允许进入跟踪流程，应退回登记人补录后再提交。
| 表 | 必填字段 | 选填字段 | 划分理由 |
|---|---|---|---|
| 依赖登记清单 | 依赖编号、提出方、承接方、依赖内容、期望交付时间、当前状态、责任人 | 影响范围 | 前七项缺任何一项，依赖都无法被跟进或升级；影响范围用于评估优先级，可在登记后补充 |
| 升级跟踪记录 | 升级编号、关联依赖编号、升级触发条件、升级层级、升级对象、升级时间、诉求与承诺 | 下次跟进时间、关闭结论 | 前七项构成一次升级动作的完整事实；下次跟进时间在承诺明确后填写，关闭结论在收口时填写 |
缺失处理规则建议写进模板说明：登记清单缺少必填字段时，退回提出方补录，补录完成前状态停留在“已登记”；升级记录缺少必填字段时，该次升级不计入升级次数统计，由责任人当日补全。关闭结论虽为选填，但依赖进入“已关闭”状态时必须填写，否则状态更新视为无效。
填写示例：一条依赖从登记到升级关闭的完整记录
以下为演示情景，用于说明两表如何配合填写，不代表真实项目数据。
依赖登记清单示例
| 依赖编号 | 提出方 | 承接方 | 依赖内容 | 期望交付时间 | 影响范围 | 当前状态 | 责任人 |
|---|---|---|---|---|---|---|---|
| DEP-007 | 订单团队-李敏 | 支付平台团队-王磊 | 提供退款回调接口联调环境及接口文档，支持退款状态回传 | 2025-06-10（对应订单版本V3.2提测） | 订单版本V3.2、两个待上线客户 | 已关闭 | 李敏 |
升级跟踪记录示例
| 升级编号 | 关联依赖编号 | 升级触发条件 | 升级层级 | 升级对象 | 升级时间 | 诉求与承诺 | 下次跟进时间 | 关闭结论 |
|---|---|---|---|---|---|---|---|---|
| ESC-012 | DEP-007 | 超过期望交付时间2个工作日，接口文档未提供 | 接口人级 | 支付平台团队-王磊 | 2025-06-12 | 诉求：6月13日前提供接口文档；承诺：6月13日下班前提供文档，联调环境6月16日就绪 | 2025-06-13 | 继续升级：文档仍未提供，承诺未兑现 |
| ESC-013 | DEP-007 | 接口人级承诺未兑现，且影响V3.2提测 | 团队负责人级 | 支付平台团队负责人-赵强 | 2025-06-16 | 诉求：6月17日前完成文档与环境交付；承诺：6月17日上午提供文档，下午开放联调环境 | 2025-06-17 | 已解决：6月17日文档与环境均已交付，联调于6月18日完成 |
示例中，DEP-007 的状态从“已登记”推进到“已升级”，最终更新为“已关闭”；两条升级记录分别对应接口人级和团队负责人级，升级编号连续递增，关联依赖编号始终指向 DEP-007。关闭结论的写法遵循“结论加一句依据”的格式，例如“已解决：6月17日文档与环境均已交付”，便于复盘时判断结论是否有事实支撑。
调整与维护方法：让模板适配团队并长期可用
模板落地后需要按团队实际情况裁剪，并指定维护责任，否则字段会逐渐失效或无人更新。
- 按团队规模裁剪：小团队可合并“提出方”和“责任人”，由同一人跟进；跨团队依赖多时保留“影响范围”，用于排优先级。依赖类型单一（如只有接口依赖）时，可把“依赖内容”改为固定选项加备注。
- 按依赖类型裁剪：接口、数据、环境、人力等依赖类型差异大时，可在登记清单增加“依赖类型”列，但依赖编号、关联依赖编号、状态、责任人和关闭结论建议始终保留。
- 维护责任人：指定一名交付协调人或项目经理负责模板版本，字段增删需记录变更日期、变更内容和影响范围，变更记录附在模板末尾。
- 定期复盘：每两周或每个迭代结束时，统计升级记录条数、平均升级层级和关闭结论分布，识别反复升级的承接方和常见触发条件，据此调整触发条件或例会节奏。
- 与既有节奏衔接：把依赖登记清单作为交付计划评审的输入，把升级跟踪记录作为周例会的固定议题，例会只讨论“已升级”和“受阻”状态的依赖，避免逐条过表。
当依赖登记和升级跟踪需要跨角色实时同步时，可以把两张表的结构落到统一的工作项与状态管理中。ONES 通过统一的需求池、工单与任务看板实时同步状态与信息，支持追溯需求与问题，并可通过模板、权限和流程配置适配不同团队的协作方式。落地时可将依赖登记清单对应为一类工作项，用状态字段承载“已登记、推进中、受阻、已升级、已交付、已关闭”，升级记录作为关联记录追加，保持与本文模板相同的字段口径和编码规则。
常见问题
依赖登记清单和升级跟踪记录可以合并成一张表吗？
可以合并，但需要接受两个代价。合并后一条依赖的每次升级会挤在同一行里，要么反复覆盖历史内容，要么在一格里堆叠多次升级，回看时难以区分哪次升级、谁承诺了什么。如果团队依赖数量少、升级次数通常不超过一次，合并成一张表并增加“最近升级时间”“最近升级结论”两列是可行的简化做法。依赖多、升级频繁时，建议保留两张表，用依赖编号关联，升级记录只追加，统计升级次数和层级分布也更方便。
升级触发条件写成“对方一直没回复”可以吗？
这类写法在复盘时无法判断升级是否及时，也容易在跨团队沟通中引发争议。建议把触发条件写成可核对的事实，例如“超过期望交付时间3个工作日未提供接口文档”“承诺日期已过且未收到新的交付时间”。触发条件与期望交付时间、承诺时间挂钩，升级动作才有依据，后续统计反复升级的承接方时也能按条件归类。
依赖最终确认无法落实，登记清单和升级记录该怎么收口？
登记清单的当前状态更新为“已关闭”，并在影响范围中补充实际波及的版本、客户或里程碑。升级跟踪记录中新增一条收口记录，关闭结论写“转为风险”或“确认终止”并附一句依据，例如“承接方确认本版本不提供该接口，已转为订单版本V3.2风险项”。如果该依赖改由其他团队承接，建议新登记一条依赖并保留原编号作废记录，编号不复用，避免历史升级记录指向混乱。
小团队人手少，模板字段可以砍到多少？
可以合并角色类字段，例如提出方与责任人由同一人担任时合并为一列，承接方写到具体接口人即可。依赖类型单一时，依赖内容可改为固定选项加备注。建议保留的最小集合是：依赖编号、提出方/责任人、承接方、依赖内容、期望交付时间、当前状态，以及升级记录中的关联依赖编号、触发条件、升级对象、诉求与承诺和关闭结论。缺少这些字段，依赖找不到人、找不到时间或无法判断是否收口，模板就失去了跟踪作用。
模板里的状态和升级层级需要和现有工具里的字段保持一致吗？
建议保持一致，否则同一件事在文档和工具里会出现两套说法。落地时可以把依赖登记清单对应为一类工作项，用状态字段承载“已登记、推进中、受阻、已升级、已交付、已关闭”，升级记录作为关联记录追加，编码规则沿用 DEP- 与 ESC- 前缀。ONES 通过统一的需求池、工单与任务看板实时同步状态与信息，支持追溯需求与问题，并可通过模板、权限和流程配置适配不同团队的协作方式，可作为承载这套结构的工具选项之一。具体字段配置和状态流转范围需按实际使用版本确认。
