交付依赖未落实时，依赖登记清单应包含哪些字段

交付依赖迟迟未落实，常见原因是清单只记了“要什么”，没记“谁给、何时要、卡在哪、找谁升级”。本文提供两张可直接复制使用的表格：依赖登记清单主表和升级跟踪记录，并逐字段说明填写口径、必填与选填的划分，再用一条完整示例演示从登记到关闭的过程。

要点总览（TL;DR）

• 依赖登记清单要回答五件事：依赖什么、由谁提供、何时需要、进展到哪、卡住找谁升级，字段按这五问分四组组织。
• 最小可用字段集为依赖编号、依赖名称、依赖类型、提供方、提供方接口人、我方接口人、需要时间、期望交付物、当前状态、最近更新日期、升级层级共11项。
• 主表与升级跟踪记录通过依赖编号关联，主表保留一行，升级细节全部落在升级记录中，关闭状态两表同步。
• 必填项按依赖类型调整：外部供应商和系统接口建议把验收标准、关闭确认人设为必填，内部团队可先口头确认后补。
• 清单需固定更新节奏与状态口径，字段增删记录版本，项目结束后归档作为后续估算依赖周期的参考。

依赖登记清单空白模板（可直接复制）

主表用于逐条登记交付链路中的每一项依赖，升级跟踪记录用于承接主表中超期、阻塞或需要跨层级协调的事项。两表通过“依赖编号”关联：主表每条依赖有唯一编号，升级记录每次升级都引用该编号，查一条依赖的全部升级过程时按编号筛选即可。

表一：依赖登记清单（主表）

依赖编号	依赖名称	依赖描述	依赖类型	提供方	提供方接口人	我方接口人	需要时间	期望交付物	验收标准	当前状态	最近更新日期	阻塞原因	升级层级	关闭确认人	关闭日期	备注

表二：升级跟踪记录

记录编号	依赖编号	升级日期	升级原因	升级发起人	升级对象	协调结论	新承诺时间	后续动作	下次跟进日期	是否关闭

使用约定：依赖编号建议采用“项目代号-序号”格式，如“PAY-012”，保证全项目唯一；升级记录编号可采用“依赖编号-U01”的格式，同一依赖多次升级依次递增。主表“当前状态”与升级记录“是否关闭”需保持同步，避免出现主表已关闭而升级记录仍挂起的情况。

每个字段登记什么：字段说明与填写口径

字段按四组组织：依赖标识与描述、责任与时间、状态与验证、升级与关闭。同一字段在不同人手里填写结果不一致，通常是因为口径没写清，下表把每个字段的含义和写法固定下来。

字段	所属分组	含义	填写口径
依赖编号	标识与描述	依赖的唯一标识	“项目代号-三位序号”，登记后不再变更，作废也保留编号
依赖名称	标识与描述	一句话概括依赖内容	动宾结构，如“支付网关测试环境开通”，不超过20字
依赖描述	标识与描述	依赖的具体内容和范围	写清需要对方提供什么、覆盖哪些功能或环境，避免只写“支持一下”
依赖类型	标识与描述	依赖的来源类别	从“内部团队、外部供应商、系统接口”中选一，便于分类统计
提供方	责任与时间	承担交付责任的团队或公司	写团队名或公司名，不写个人姓名
提供方接口人	责任与时间	对方具体对接人	写姓名，多人时写主接口人并在备注列补充
我方接口人	责任与时间	本方负责跟进该依赖的人	写姓名，此人负责更新状态和发起升级
需要时间	责任与时间	本方最晚可接受依赖到位的时间	写具体日期，不写“尽快”“月底前”等模糊表述
期望交付物	责任与时间	依赖落实后应拿到的具体成果	写可核对的物，如“测试环境账号及访问文档”“接口联调通过记录”
验收标准	状态与验证	判断依赖是否真正落实的依据	写可验证的条件，如“联调用例全部通过”“环境连续可用3个工作日”
当前状态	状态与验证	依赖所处的进展阶段	统一使用“未启动、沟通中、已承诺、部分交付、已交付待验收、已关闭、已取消”七种口径
最近更新日期	状态与验证	该行信息最后一次变更的日期	每次修改状态或承诺时间时同步更新，用于识别长期未动的条目
阻塞原因	状态与验证	当前无法推进的具体原因	写事实，如“对方排期在两周后”“接口文档未定稿”，不写“对方不配合”这类评价
升级层级	升级与关闭	当前已升级到的层级	如“接口人、双方负责人、项目决策层”，未升级填“无”
关闭确认人	升级与关闭	确认依赖已按验收标准落实的人	由我方接口人或验收人签字确认，不能由提供方自行关闭
关闭日期	升级与关闭	依赖正式关闭的日期	验收通过当天填写，与升级记录“是否关闭”同步
备注	升级与关闭	补充信息	记录口头承诺、会议结论、替代方案等不宜放入固定字段的内容

升级跟踪记录的字段口径：升级原因写触发升级的事实，如“超过需要时间3个工作日仍未交付”；协调结论写升级后达成的明确结果，如“对方负责人承诺周五前提供测试账号”；新承诺时间必须落到具体日期，并回写主表的“需要时间”或备注；下次跟进日期用于防止升级后无人跟踪。

必填与选填：最小可用清单怎么定

依赖未落实时，清单首先要保证“能追、能催、能升级”。最小可用字段集是：依赖编号、依赖名称、依赖类型、提供方、提供方接口人、我方接口人、需要时间、期望交付物、当前状态、最近更新日期、升级层级。这11个字段填全，一条依赖就能被定位、跟进和升级；其余字段可在依赖推进过程中补充。

字段	必填/选填	理由或适用情形
依赖编号	必填	两表关联和检索的基础
依赖名称	必填	快速识别依赖内容
依赖描述	必填	范围不清是依赖扯皮的主要来源
依赖类型	必填	决定后续升级路径和统计口径
提供方	必填	明确责任主体
提供方接口人	必填	没有具体对接人，跟进无法落地
我方接口人	必填	明确谁负责更新和升级
需要时间	必填	判断是否超期的基准
期望交付物	必填	避免“给了但不对”
验收标准	选填	内部团队口头可确认时可后补；外部供应商和系统接口建议必填
当前状态	必填	清单的核心信息
最近更新日期	必填	识别僵尸条目
阻塞原因	选填	状态为“沟通中”及以后建议填写
升级层级	必填	未升级填“无”，保证字段不空
关闭确认人	选填	关闭时必填
关闭日期	选填	关闭时必填
备注	选填	按需使用

按依赖类型调整必填项：内部团队依赖可先不填验收标准，靠双方负责人口头确认，但需要时间和提供方接口人必须明确；外部供应商依赖建议把验收标准、关闭确认人设为必填，合同或采购场景下还需在备注中记录对应订单或协议编号；系统接口依赖建议把期望交付物细化为接口文档、联调环境和联调记录三项，验收标准写清联调通过条件。

填写示例：一条未落实依赖从登记到关闭

以下为演示情景：某项目需要第三方支付服务商开通测试环境，原定日期未到位，经两次升级后落实。示例中的名称和日期均为虚构，仅用于说明填写方式。

主表填写（一行）

字段	填写内容
依赖编号	PAY-012
依赖名称	支付网关测试环境开通
依赖描述	提供测试商户号、沙箱地址及回调配置说明，覆盖下单、退款两个场景
依赖类型	外部供应商
提供方	某支付服务商
提供方接口人	张工（商务对接）
我方接口人	李敏
需要时间	3月10日
期望交付物	测试商户号、沙箱地址、回调配置说明文档
验收标准	下单与退款两个场景联调用例全部通过
当前状态	已关闭
最近更新日期	3月21日
阻塞原因	（关闭时清空，历史原因见升级记录）
升级层级	双方负责人
关闭确认人	李敏
关闭日期	3月21日
备注	3月18日对方更换接口人，新接口人为王工

升级跟踪记录（三行）

记录编号	依赖编号	升级日期	升级原因	升级发起人	升级对象	协调结论	新承诺时间	后续动作	下次跟进日期	是否关闭
PAY-012-U01	PAY-012	3月11日	超过需要时间1个工作日未提供沙箱地址	李敏	提供方接口人张工	对方称内部审批未完成，承诺3月14日前提供	3月14日	每日跟进审批进度	3月12日	是
PAY-012-U02	PAY-012	3月15日	新承诺时间已过，仍未提供	李敏	双方负责人	对方负责人协调加急审批，承诺3月18日提供全部材料	3月18日	负责人层面每周同步一次	3月18日	是
PAY-012-U03	PAY-012	3月19日	材料已到但回调配置缺失，联调无法开始	李敏	提供方新接口人王工	王工当日补充回调配置说明	3月19日	补充后启动联调	3月20日	是

状态推进过程：3月8日登记时状态为“沟通中”；3月11日首次升级后改为“已承诺”；3月18日材料部分到位改为“部分交付”；3月20日联调用例全部通过改为“已交付待验收”；3月21日李敏确认验收标准满足，改为“已关闭”并填写关闭日期，同时把三条升级记录的“是否关闭”置为“是”。整个过程主表只保留一行，升级细节全部落在升级记录中，回溯时按PAY-012筛选即可看到完整经过。

清单的调整与维护方法

清单上线后最常见的失效方式是“登记一次就不再更新”。维护的重点是固定更新节奏、统一状态口径、控制字段增删，让清单始终反映真实进展。

更新频率与责任人

• 我方接口人对所负责的每条依赖至少每周更新一次状态和最近更新日期；临近需要时间的依赖改为每日更新。
• 项目例会上逐条过“已承诺”和“部分交付”状态的依赖，超期条目当场决定是否升级。
• 依赖关闭由我方接口人确认，关闭确认人和关闭日期不得空缺。
• 连续两周未更新的条目由清单管理员标黄，要求接口人说明原因或关闭。

状态口径的维护与复盘

状态口径一旦确定，全项目统一使用，新增状态需经项目负责人同意并写入清单说明。建议每两周做一次小复盘：统计超期依赖数量、平均升级次数、升级后按时交付的比例，找出反复卡住的提供方或环节。复盘结论用于调整需要时间的设定方式和升级触发条件，例如把“超期1个工作日即升级”改为“超期当天升级”。

字段增删的调整原则与版本记录

• 新增字段先问三个问题：是否每条依赖都要填、是否有人负责维护、是否影响升级判断。三个都答“是”才加入主表。
• 删除字段前确认历史数据已归档，避免追溯时信息缺失。
• 每次调整字段或状态口径，在清单说明中记录版本号、调整内容、生效日期和批准人。
• 项目结束后将主表和升级记录一并归档，作为后续项目估算依赖周期的参考。

当依赖登记从个人表格转为团队共用工具时，可以把主表字段映射为工作项属性，把升级记录作为关联记录挂在同一工作项下。ONES 提供统一的需求池、工单与任务看板，支持实时同步状态与信息，便于跨角色、跨团队追溯依赖进展；其模板、权限和流程配置可用于固定状态口径和升级路径。团队可据此把依赖编号、提供方、需要时间、当前状态等字段落到工作项上，让接口人更新状态与升级记录在同一处完成，减少两表脱节。

常见问题

依赖登记清单和升级跟踪记录可以合并成一张表吗？

可以合并，但需要接受信息密度上升的代价。合并后每条依赖只占一行，升级过程用备注列或追加列记录，适合依赖数量少、升级次数低的项目。依赖多、升级频繁时，合并表会出现一行内多次升级信息堆叠，回溯困难。更稳妥的做法是保留两张表，用依赖编号关联，主表看全局，升级记录看过程。

依赖的“需要时间”和提供方承诺的时间不一致时，以哪个为准？

主表“需要时间”记录本方最晚可接受的时间，是判断是否超期的基准；提供方承诺的时间写入升级记录的“新承诺时间”，并回写主表备注。两者不一致时，超期判断仍以需要时间为准，同时把承诺时间作为跟进节点。若承诺时间晚于需要时间，应在升级记录中写明影响范围，由双方负责人决定是否调整交付安排。

依赖已经口头承诺，还需要登记吗？

需要。口头承诺没有落到清单上，就无法判断是否超期，也无法在接口人变动时交接。登记时状态填“已承诺”，在备注中记录承诺人、承诺时间和承诺内容。承诺时间到期未兑现，即按超期处理并触发升级，避免依赖停留在口头阶段无人跟进。

清单里的状态口径可以按团队习惯自行增减吗？

可以调整，但同一项目内必须统一。增减状态前先确认新状态能被所有人一致理解，且不影响超期判断和升级触发。调整后写入清单说明，记录版本号、调整内容、生效日期和批准人。跨项目汇总时，建议保留一套基础状态映射，避免各项目口径不同导致统计失真。

依赖关闭后还需要保留在清单里吗？

项目进行期间建议保留，便于回溯和统计升级次数；项目结束后随升级记录一并归档。关闭的依赖不再参与超期统计，但保留依赖编号、关闭确认人和关闭日期，作为后续项目估算依赖周期的参考。若清单条目过多影响查看，可按状态筛选，不必删除历史行。