交付依赖迟迟未落实，常见原因是登记时只写了一句“等对方提供”，既没有责任人和时间，也没有升级路径。本文给出一套可直接复制使用的依赖登记清单与升级跟踪记录：登记清单负责把每条依赖写清楚，升级记录负责在未落实时留下谁在什么时间做了什么。两张表通过依赖编号关联，适用于研发交付计划中的跨团队、跨供应商依赖管理。
要点总览（TL;DR）
- 依赖登记清单以“一条依赖一行”为结构，核心字段包括依赖编号、依赖描述、提出方、责任方、依赖类型、期望就绪时间、承诺就绪时间、实际就绪时间、当前状态、影响范围、升级层级和关闭依据。
- 升级跟踪记录用依赖编号与登记清单关联，逐次记录升级时间、层级、发起人、接收人、诉求、答复、新承诺时间和结果，同一条依赖可多次追加。
- 依赖编号、依赖描述、提出方、责任方、依赖类型、期望就绪时间、当前状态和影响范围为必填；实际就绪时间、升级层级和关闭依据在对应节点补填。
- 期望就绪时间与承诺就绪时间之差是风险窗口，承诺晚于期望或临近仍未承诺时应触发升级，而不是等到交付当天才发现。
- 清单需按日更新、按周核对、按里程碑评审，字段增删以是否对应管理动作为判断标准。
可复制空白依赖登记清单
登记清单以“一条依赖一行”为基本结构。复制下表到文档或表格工具中，按列填写即可。字段顺序与后文字段说明、示例保持一致，便于对照使用。
| 依赖编号 | 依赖描述 | 提出方 | 责任方 | 依赖类型 | 期望就绪时间 | 承诺就绪时间 | 实际就绪时间 | 当前状态 | 影响范围 | 升级层级 | 关闭依据 |
|---|---|---|---|---|---|---|---|---|---|---|---|
表格下方建议保留一行填写说明：依赖编号唯一且不复用；状态与升级层级按约定取值；关闭依据须附可查证的记录位置。这样即使清单被多人维护，取值口径也能保持一致。
配套的升级跟踪记录空白表
升级跟踪记录解决“依赖没落实时，谁在多长时间内做了什么”。它与登记清单通过依赖编号关联，同一条依赖可以多次升级，每次升级追加一行，形成完整过程链，不覆盖历史记录。
| 依赖编号 | 升级时间 | 升级层级 | 发起人 | 接收人 | 诉求 | 答复 | 新承诺时间 | 结果 |
|---|---|---|---|---|---|---|---|---|
升级层级可按团队实际设置，例如一级为接口人协商、二级为双方负责人协调、三级为项目决策层裁决。每次升级后，登记清单中的“承诺就绪时间”“升级层级”“当前状态”同步更新，两张表始终指向同一事实。
每个字段的含义与填写口径
字段填写的共同目标是让依赖可验收、可追溯、可升级。下表逐字段说明含义与常见错误。
| 字段 | 含义与填写口径 | 常见错误 |
|---|---|---|
| 依赖编号 | 唯一标识一条依赖，建议采用“项目代号-依赖类型缩写-序号”，如 PRJ-A-API-001，编号一经使用不复用 | 多条依赖共用一个编号；关闭后编号被新依赖复用 |
| 依赖描述 | 写到可验收的程度：交付物名称、规格或接口版本、验收方式。例如“支付网关测试环境接口文档 v2.1，含签名规则与错误码” | 只写“等对方提供接口”，无法判断是否完成 |
| 提出方 | 提出依赖需求的一方，通常是受阻塞的交付团队，负责说明用途与时间要求 | 把提出方与责任方混为同一人，导致无人推动 |
| 责任方 | 承诺提供依赖交付物的一方，须写到具体团队或岗位，必要时附对接窗口 | 只写部门名称，没有具体接口人 |
| 依赖类型 | 按来源分类，常用取值：内部团队、外部供应商、平台或环境、数据与资料、审批与合规 | 类型随意填写，导致后续统计和差异化必填失效 |
| 期望就绪时间 | 提出方基于交付计划倒推的最晚可用时间，是需求侧时间 | 与承诺时间混用，无法识别双方时间差 |
| 承诺就绪时间 | 责任方确认可交付的时间，是供给侧时间；每次重新承诺时更新并保留升级记录 | 承诺时间晚于期望时间却不触发升级 |
| 实际就绪时间 | 依赖交付物实际可用并经提出方确认的日期 | 责任方单方标记完成，提出方未验证 |
| 当前状态 | 建议取值：待确认、已承诺、进行中、已就绪待验收、已关闭、已升级、已取消 | 状态长期停留在“进行中”，与实际进展脱节 |
| 影响范围 | 写明受影响的交付物、里程碑或版本，以及阻塞程度，如“阻塞联调，影响 3 月 15 日提测” | 只写“影响进度”，无法评估优先级 |
| 升级层级 | 记录当前已升级到的层级，与升级跟踪记录保持一致 | 清单与升级记录层级不一致 |
| 关闭依据 | 关闭所需的证据：验收记录、交付物链接、确认人及确认时间 | 口头确认即关闭，事后无法追溯 |
其中期望就绪时间与承诺就绪时间的区分最关键：两者之差就是风险窗口。当承诺时间晚于期望时间，或临近期望时间仍未承诺，就应触发升级，而不是等到交付当天才发现。
哪些字段必填、哪些可以选填
必填字段保证依赖能被识别、跟踪和关闭；选填字段按依赖类型和管理精度启用。下表给出对照。
| 字段 | 必填/选填 | 说明与启用条件 |
|---|---|---|
| 依赖编号 | 必填 | 关联两张表的唯一键，缺失则无法升级跟踪 |
| 依赖描述 | 必填 | 不可验收的描述视为未登记完整 |
| 提出方 | 必填 | 明确谁在等待、谁负责验收 |
| 责任方 | 必填 | 至少写到团队，建议写到接口人 |
| 依赖类型 | 必填 | 决定后续差异化必填要求 |
| 期望就绪时间 | 必填 | 风险判断的基准 |
| 承诺就绪时间 | 必填（可暂空） | 责任方确认前可暂空，但状态须为“待确认” |
| 当前状态 | 必填 | 驱动日常跟踪 |
| 影响范围 | 必填 | 用于排优先级和升级决策 |
| 实际就绪时间 | 选填 | 依赖就绪后填写，关闭时必填 |
| 升级层级 | 选填 | 发生升级后必填，未升级可留空 |
| 关闭依据 | 选填 | 关闭时必填，作为关闭凭证 |
按依赖类型可追加差异化必填要求：外部供应商依赖建议增加合同或采购单号、对接窗口；平台或环境依赖建议增加环境名称与申请单号；审批与合规依赖建议增加审批事项与法务或合规对接人。缺失必填字段时，清单不应进入“已承诺”状态，由提出方补齐后再提交责任方确认；已登记但描述不可验收的，退回补充而不是直接升级。
一份填好的依赖登记与升级示例
以下为演示情景，用于说明两张表如何配合，不代表真实项目数据。
登记行：
| 依赖编号 | 依赖描述 | 提出方 | 责任方 | 依赖类型 | 期望就绪时间 | 承诺就绪时间 | 实际就绪时间 | 当前状态 | 影响范围 | 升级层级 | 关闭依据 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| PRJ-A-API-001 | 支付网关测试环境接口文档 v2.1，含签名规则与错误码，按文档完成联调即验收 | 订单交付组 | 支付平台组（接口人：张工） | 内部团队 | 3 月 10 日 | 3 月 14 日 | 3 月 16 日 | 已关闭 | 阻塞支付联调，影响 3 月 15 日提测 | 二级 | 联调通过记录（3 月 16 日，订单组李工确认） |
对应升级跟踪记录：
| 依赖编号 | 升级时间 | 升级层级 | 发起人 | 接收人 | 诉求 | 答复 | 新承诺时间 | 结果 |
|---|---|---|---|---|---|---|---|---|
| PRJ-A-API-001 | 3 月 9 日 | 一级 | 订单组李工 | 支付平台组张工 | 确认文档能否 3 月 10 日前提供 | 文档尚在评审，预计 3 月 14 日 | 3 月 14 日 | 承诺晚于期望，登记风险 |
| PRJ-A-API-001 | 3 月 13 日 | 二级 | 订单组负责人 | 支付平台组负责人 | 3 月 14 日无法就绪将影响提测，请协调提前 | 抽调一人优先整理，3 月 16 日提供 | 3 月 16 日 | 再次延期，调整提测计划并上报 |
| PRJ-A-API-001 | 3 月 16 日 | 二级 | 订单组李工 | 支付平台组张工 | 确认文档已提供并完成联调 | 文档已交付，联调通过 | — | 关闭，附联调记录 |
过程说明：3 月 9 日首次登记并确认承诺时间晚于期望时间，状态为“已承诺”同时标记风险；3 月 13 日承诺再次延期，升级到二级并同步调整提测计划；3 月 16 日交付物到位，提出方完成联调验收后填写实际就绪时间与关闭依据，状态改为“已关闭”。整条链路中，登记清单保留最终事实，升级记录保留协商过程，两者用同一依赖编号对应。
清单的调整与日常维护方法
清单只有进入固定节奏才不会退化为一次性文档。以下维护规则可按团队规模裁剪。
- 更新时点：每日站会前由各提出方更新自己名下依赖的状态与实际就绪时间；每周固定一次全量核对，重点检查承诺时间已过但状态未变的条目。
- 状态调整规则：承诺时间晚于期望时间，或距期望时间不足约定预警天数仍未承诺，状态改为“已升级”并同步升级层级；责任方重新承诺时更新承诺时间，历史承诺保留在升级记录中。
- 字段增删标准：新增字段须能对应一个管理动作，例如增加“合同号”是为了供应商依赖可追溯；连续两个评审周期无人使用的字段应合并或删除，避免表格膨胀。
- 评审与复盘：每个交付里程碑前评审未关闭依赖，确认是否影响交付；里程碑结束后复盘升级次数、平均响应时长和延期原因，作为下一周期依赖管理的输入。
- 责任安排：指定一名依赖管理员负责清单完整性与升级记录归档，提出方负责描述与验收，责任方负责承诺与交付，三方职责在清单表头注明。
在协作工具中承载时，可以把每条依赖建成工作项，用状态字段对应清单状态、用自定义字段承载依赖编号与升级层级，让状态流转和责任人变更留痕；清单与升级记录放在项目文档中，按项目组织页面并关联对应任务，需求、依赖与交付物可以互相对应。ONES 支持项目制与产品制并行管理，提供统一的需求池、工单与任务看板，状态与信息可实时同步；ONES Wiki 支持文档关联项目任务、模板化创建文档并记录页面版本，适合承载依赖登记清单与升级跟踪记录的长期维护。具体字段配置与提醒方式建议在试用环境中按团队流程核验后再定稿。
常见问题
依赖登记清单和升级跟踪记录可以合并成一张表吗？
可以合并，但需要保留两类信息的区分。合并后每行仍以依赖编号为主键，升级过程用子表、关联记录或备注列承载；如果团队依赖数量较多、升级频繁，建议分开维护，登记清单保留最终事实，升级记录保留协商过程，查询和复盘时更清晰。合并的前提是每次升级追加记录而不覆盖历史，否则过程链会丢失。
责任方一直不确认承诺时间，清单上应该怎么记？
承诺就绪时间可以暂空，但当前状态应保持“待确认”，并在影响范围中写明期望时间和受阻塞的交付物。超过约定预警天数仍未承诺的，按升级规则发起升级，把升级层级同步到登记清单。这样清单反映的是“尚未承诺”这一事实，而不是用提出方的期望时间代替责任方承诺，避免后续判断风险时口径混乱。
依赖类型不同，必填字段需要调整吗？
需要。基础必填字段对所有依赖一致，差异化要求按类型追加：外部供应商依赖建议增加合同或采购单号、对接窗口；平台或环境依赖建议增加环境名称与申请单号；审批与合规依赖建议增加审批事项与对接人。追加字段的目的是让该类依赖在追溯和升级时有据可查，而不是让所有依赖都填一遍无关信息。
清单里的状态和升级层级由谁维护？
建议由提出方更新自己名下依赖的状态与实际就绪时间，责任方更新承诺时间，依赖管理员负责清单完整性与升级记录归档。三方职责写在清单表头，避免出现“都以为对方在更新”的情况。状态与升级层级以升级跟踪记录中的最新一条为准，两边不一致时以记录为准回填清单。
在协作工具中承载清单时，需要关注哪些配置点？
可以把每条依赖建成工作项，用状态字段对应清单状态，用自定义字段承载依赖编号、升级层级和期望就绪时间，让状态流转和责任人变更留痕；清单与升级记录放在项目文档中，按项目组织页面并关联对应任务。ONES 支持项目制与产品制并行管理，提供统一的需求池、工单与任务看板，状态与信息可实时同步；ONES Wiki 支持文档关联项目任务、模板化创建文档并记录页面版本，适合承载清单与升级记录的长期维护。具体字段配置与提醒方式建议在试用环境中按团队流程核验后再定稿。
