研发交付依赖清单模板：字段、状态与填写规范

2026年11月11日

研发交付依赖登记表用来把跨团队、跨系统的依赖从口头约定变成可跟踪的记录。本文直接给出一张可复制的空白表，并说明每个字段怎么填、哪些不能空、七种状态如何流转，最后用一条完整记录示范填写。字段与状态保持一致，是这张表能长期使用的前提。

Table of Contents

要点总览（TL;DR）

依赖登记表以“一条依赖一行”为单位，核心字段分五组：标识与归属、内容与验收、时间、影响与风险、跟踪。
状态建议设为待确认、已确认、进行中、已交付待验收、已关闭、已取消、阻塞七种，每种状态有明确的进入条件和可流转方向。
必填规则按阶段递进：登记时保证可识别和可跟进，确认或进行中后补齐验收口径与承诺时间，关闭时补齐实际交付时间与验收结论。
已交付待验收与已关闭的区别在验收是否完成；阻塞状态需写明原因与解除条件，解除后回到进入前的状态。
登记表需定期评审与清理，并与交付计划、评审会议衔接，依赖数量增多时可承载到工作项管理中跟踪。

可复制空白依赖登记表模板

登记表以“一条依赖一行”为基本单位：一个提出方对承接方的一项具体诉求占一行，不要把多个依赖合并写在同一行，也不要把一个依赖拆成多行。下表可直接复制到电子表格或在线表格工具中，第一行为表头，第二行为空白填写行。

依赖编号	提出方	承接方	责任人	依赖内容	验收口径	交付物形式	期望交付时间	承诺交付时间	实际交付时间	影响范围	风险等级	阻塞说明	当前状态	状态变更时间	变更原因	跟进记录
													待确认 / 已确认 / 进行中 / 已交付待验收 / 已关闭 / 已取消 / 阻塞

使用时有三个约定：依赖编号在团队内唯一且不复用；提出方与承接方写到具体团队或具体人，不写“相关部门”；当前状态只能从七个取值中选择，不自行新增同义状态。若团队使用在线表格，可把“当前状态”列设置为下拉选项，把“状态变更时间”设置为自动记录，减少手工维护成本。

字段说明：每个字段记录什么、怎么填

十七个字段可以归为五组：标识与归属、内容与验收、时间、影响与风险、跟踪。分组的作用是让填写人有稳定的填写顺序，也方便后续按组筛选和统计。

字段	含义	填写口径	常见错误
依赖编号	该条依赖的唯一标识	采用“项目或团队缩写-序号”格式，如 PAY-012，创建后不再修改	多条依赖共用一个编号；编号随状态变化被改写
提出方	需要这项依赖的一方	写到团队名加具体对接人	只写“业务方”，无法追溯
承接方	提供依赖交付物的一方	写到团队名加具体负责人	写多个团队，实际无人负责
责任人	对这条依赖跟进到底的人	一般为提出方对接人，负责推动确认、催办与验收	填成承接方负责人，导致无人对验收负责
依赖内容	需要对方提供什么	一句话说清对象与动作，如“提供订单查询接口的联调环境”	写成“支持一下项目”，无法判断是否完成
验收口径	怎样算交付合格	写可检查的条件，如“接口返回字段与文档一致，联调通过 3 个核心场景”	写“满足需求”这类无法核验的表述
交付物形式	交付以什么形态存在	接口、文档、环境、数据、配置、代码分支等，可多选	留空，验收时对“交付了什么”产生分歧
期望交付时间	提出方希望拿到的时间	写日期，来源于本方计划的最晚需要时间	随手填写，与自身排期无关
承诺交付时间	承接方确认可以交付的时间	由承接方填写并确认，与期望时间不一致时在跟进记录中说明	提出方代填，承诺失去约束力
实际交付时间	实际完成交付的日期	交付动作发生时填写，用于对比承诺	验收通过后才填，混淆交付与验收
影响范围	依赖不到位会波及什么	写受影响的版本、功能、里程碑或其他依赖编号	写“影响很大”，无法用于排优先级
风险等级	依赖不能按期满足的后果程度	高：阻断关键路径；中：影响部分功能或需调整排期；低：有替代方案	全部填“高”，失去区分度
阻塞说明	当前卡在哪里	状态为阻塞时必填，写清阻塞原因与解除所需条件	只写“有阻塞”，不写原因
当前状态	依赖所处的阶段	从七个取值中选择，规则见状态流转一节	自造“基本完成”“差不多”等状态
状态变更时间	最近一次状态变化的时间	每次改状态时同步更新	状态改了时间不改，无法判断停留时长
变更原因	本次状态变化的原因	如“承接方排期调整”“验收发现字段缺失退回”	留空或写“正常推进”
跟进记录	过程沟通的要点	按“日期+结论”追加，不覆盖历史	每次重写整段，丢失过程

必填与选填：哪些字段不能空

必填规则随状态递进：登记时保证这条依赖能被识别和跟进，进入确认或进行中后保证交付可被验收，关闭时保证结果可被追溯。按阶段设置必填，比一次性要求全部填满更容易执行。

字段	登记时（待确认）	已确认 / 进行中	关闭时
依赖编号	必填	必填	必填
提出方、承接方、责任人	必填	必填	必填
依赖内容	必填	必填	必填
期望交付时间	必填	必填	必填
影响范围、风险等级	必填	必填	必填
当前状态	必填	必填	必填
验收口径	选填	必填	必填
交付物形式	选填	必填	必填
承诺交付时间	选填	必填	必填
阻塞说明	选填	状态为阻塞时必填	选填
实际交付时间	选填	选填	必填
状态变更时间、变更原因	选填	每次变更时必填	必填
跟进记录	选填	选填	必填，至少一条验收结论

可以留空的字段主要有三类：尚未与承接方确认时的验收口径、交付物形式和承诺交付时间；未发生交付时的实际交付时间；未进入阻塞时的阻塞说明。留空表示“尚未确定”，一旦对应条件成立就应补齐，避免长期空置。

状态流转规则与状态取值

七种状态覆盖一条依赖从提出到结束的完整过程。状态的作用是让所有人对“现在进行到哪一步”有同一判断，因此每个状态都要有明确的进入条件和退出方向。

状态	定义	进入条件	可流转到
待确认	依赖已登记，承接方尚未确认	提出方完成登记	已确认、已取消
已确认	承接方认可内容、验收口径与承诺时间	承诺交付时间与验收口径填写完整	进行中、阻塞、已取消
进行中	承接方已开始实际投入	有明确的承接人和工作安排	已交付待验收、阻塞、已取消
已交付待验收	交付物已提供，等待提出方验收	实际交付时间已填写	已关闭、进行中（验收不通过退回）
已关闭	验收通过，依赖正式结束	验收结论写入跟进记录	无（如需返工另建新依赖）
已取消	依赖不再需要或改由其他方式解决	变更原因写明取消理由	无
阻塞	依赖无法按当前安排推进	阻塞说明写明原因与解除条件	进行中、已确认、已取消

阻塞状态可以从已确认或进行中进入，解除后回到进入前的状态，而不是直接跳到已交付。阻塞说明要写清两件事：卡在什么条件上，以及什么情况下可以解除。例如“等待安全团队完成接口权限审批，审批通过后恢复联调”，比“等待对方”更有跟进价值。

已交付待验收与已关闭的区别在于验收是否完成：前者表示交付物已到手但尚未核验，后者表示按验收口径核验通过。验收不通过时，状态退回进行中，并在跟进记录中写明缺失项，实际交付时间保留首次交付日期，避免反复覆盖。

每次状态变化都要同步更新状态变更时间和变更原因，并在跟进记录中追加一条说明。这三项一起构成可追溯的变更链条，也是后续复盘依赖准时率的数据来源。

填写示例：一条完整依赖记录

以下示例为演示情景，展示一条依赖从登记到阻塞再恢复的完整填写方式，字段与第一节模板一一对应。

字段	填写内容
依赖编号	PAY-012
提出方	支付团队 / 李某
承接方	用户中心团队 / 王某
责任人	李某
依赖内容	提供企业账户信息查询接口，供支付结算页调用
验收口径	接口字段与接口文档一致，联调通过开户、变更、注销 3 个场景，响应时间在测试环境不超过 500 毫秒
交付物形式	接口 + 接口文档 + 联调环境
期望交付时间	3 月 20 日
承诺交付时间	3 月 22 日
实际交付时间	空（尚未交付）
影响范围	结算页 2.3 版本上线；影响 PAY-015 对账依赖
风险等级	高
阻塞说明	接口涉及企业敏感字段，等待安全团队完成权限审批；审批通过并开放测试环境访问权限后解除
当前状态	阻塞
状态变更时间	3 月 12 日
变更原因	安全审批未完成，承接方无法开放联调环境
跟进记录	3 月 8 日：双方确认接口范围与验收口径，承诺 3 月 22 日交付。3 月 12 日：承接方反馈安全审批中，转入阻塞，责任人每周一、周四跟进审批进度。3 月 18 日：审批通过，恢复进行中。

这条记录中，状态与时间保持一致：承诺时间晚于期望时间，差异在跟进记录中体现；阻塞说明写明了原因与解除条件；跟进记录按日期追加，保留了从确认到阻塞再到恢复的过程。实际交付时间在交付发生前保持为空，符合必填规则。

调整与维护：让登记表长期可用

登记表在使用一段时间后会出现字段冗余、状态滥用和过期记录堆积。维护的重点是让表随团队实际需要演进，而不是一次设计后长期不动。

字段增删的判断标准可以看三点：新字段是否会被用于筛选、排序或统计；是否每次填写都需要它；去掉后是否会导致同类问题反复沟通。满足前两条且第三条成立的字段值得新增；长期空置或只在一两次场景中用到的字段可以删除，删除前把历史数据归档。

状态集合的精简或扩展要看团队规模与依赖数量。依赖条数较少的小团队可以把已确认与进行中合并，减少维护动作；跨团队依赖多、阻塞频繁时，保留阻塞状态并单独统计阻塞时长更有价值。扩展状态时优先复用现有取值，避免出现含义重叠的状态。

定期评审建议按固定节奏进行：责任人每周检查一次阻塞和逾期记录，推动状态更新；每两周在交付例会上过一遍高风险依赖；每个版本结束后清理已关闭和已取消超过一定时间的记录，归档到历史表。评审时同步检查必填字段的空置情况，空置集中的字段说明填写口径需要简化。

登记表要与交付计划衔接：计划中的关键路径事项应在登记表中有对应依赖编号，排期调整时同步更新期望交付时间与影响范围。评审会议上以登记表为输入讨论阻塞与风险，会议结论回写到跟进记录，形成“计划—登记—评审—回写”的闭环。当依赖数量增多、跨团队协作频繁时，可以把登记表承载到工作项管理中，用工作项记录每条依赖，用自定义状态对应七种取值，用字段保存提出方、承接方、承诺时间与风险等级，状态变更自动留下时间记录。ONES 的工作项与状态流转可以承担这类承载，让登记表从静态表格变成随交付过程更新的跟踪记录；具体字段与状态配置可按团队实际流程设置。

常见问题

小团队依赖数量不多，七种状态可以精简吗？

可以。状态集合按团队规模和依赖数量调整，依赖条数少、跨团队协作简单时，可把“已确认”与“进行中”合并，减少维护动作。精简的前提是每种保留状态仍有明确的进入条件，且合并后不会让“谁在等谁”变得模糊。跨团队依赖多、阻塞频繁时，建议保留“阻塞”状态并单独统计阻塞时长，便于在例会上定位卡点。

承接方一直不确认承诺交付时间，这条依赖该怎么记？

依赖先以“待确认”状态登记，期望交付时间、影响范围和风险等级照常填写，承诺交付时间留空。责任人在跟进记录中写明催办日期与对方反馈，并在例会上作为待确认事项提出。若临近期望交付时间仍未确认，可把风险等级上调，并在影响范围中标注受波及的版本或里程碑。承诺交付时间由承接方填写并确认，提出方代填会让承诺失去约束力。

验收不通过退回后，实际交付时间要改成新的日期吗？

建议保留首次交付日期，不反复覆盖。验收不通过时状态从“已交付待验收”退回“进行中”，在跟进记录中写明缺失项和退回日期；承接方补充交付后，可在跟进记录中追加新的交付时间，实际交付时间字段仍以首次交付为准。这样后续统计交付准时率时，口径保持一致，也能看出返工发生在哪个环节。

依赖登记表和项目计划里的任务是什么关系，会不会重复维护？

两者记录的对象不同：项目计划安排本方要完成的工作，依赖登记表记录需要其他团队提供什么。计划中的关键路径事项应在登记表中有对应依赖编号，排期调整时同步更新期望交付时间与影响范围。为减少重复，可只把跨团队、跨系统的依赖登记入表，本方内部任务留在计划中；评审会议以登记表为输入讨论阻塞与风险，结论回写到跟进记录。