项目依赖登记表：字段清单、填写示例与维护要求

2026年11月9日

项目依赖登记表用来记录项目之间的交付关系，一条依赖占一行，让前置交付、后置使用、时间和责任人都有据可查。本文提供可直接复制的空白表格，逐字段说明填写口径，区分必填与选填，并用一条跨项目依赖演示完整填法，最后给出登记、更新、复核和关闭的维护规则。

Table of Contents

要点总览（TL;DR）

登记表按“一条依赖一行”组织，主表记录依赖编号、前置项目、交付物、后置项目、受影响事项、依赖类型、计划需要时间、承诺交付时间、当前状态、责任人、影响程度，变更记录区按时间追加历史变化。
必填字段以保证依赖可被跟踪和协调为准：依赖编号、登记日期、前置项目、交付物、后置项目、计划需要时间、当前状态、责任人；承诺交付时间、受影响事项、依赖类型、影响程度为条件必填。
填写时区分计划需要时间与承诺交付时间，交付物写到名称、形态和版本，受影响事项落到工作项或里程碑，状态变化同步写入变更记录。
维护上明确唯一登记入口、登记时点、每周更新节奏、待确认到已关闭的状态流转、定期复核与升级协调、关闭归档条件，并与项目计划和例会共用同一份数据。
模板按项目集规模增减字段、按项目或状态拆分视图，标注版本号与字段口径说明，指定维护人定期检查字段使用情况。

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

下面的模板分为主表和变更记录两个区域。主表记录依赖关系本身，变更记录区按时间追加承诺调整、状态变化和影响说明。复制到表格工具时，建议主表与变更记录放在同一工作簿的不同工作表，用“依赖编号”关联。

主表：依赖关系登记

依赖编号	登记日期	前置项目	交付物	后置项目	受影响事项	依赖类型	计划需要时间	承诺交付时间	当前状态	责任人	影响程度	备注
DEP-001	（填写日期）	（项目名称）	（交付物名称与版本）	（项目名称）	（受影响的工作项或里程碑）	（交付物/审批/资源/信息）	（后置项目需要的日期）	（前置项目承诺的日期）	（待确认/已确认/进行中/已交付/已关闭/已取消）	（前置方对接人）	（高/中/低）	（补充说明）
DEP-002

变更记录区：按时间追加

记录日期	依赖编号	变更类型	变更前	变更后	变更原因	记录人
（填写日期）	DEP-001	（时间调整/状态变化/责任人变更/范围变更）	（原值）	（新值）	（原因说明）	（填写人）

主表只保留当前有效信息，历史变化全部进入变更记录区，避免主表被反复覆盖后失去追溯依据。若团队使用在线表格，可把“当前状态”设为下拉选项，把“依赖编号”设为唯一值校验。

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

字段按五组理解：标识类、关系类、时间类、状态与责任类、变更记录类。同一列在不同项目中必须按同一口径填写，否则登记表无法横向比较和汇总。

字段	所属分组	记录内容	填写口径	常见错误
依赖编号	标识类	该条依赖的唯一编号	采用“DEP-序号”格式，全表不重复，创建后不改	复用已关闭依赖的编号，导致变更记录串号
登记日期	标识类	该条依赖首次进入登记表的日期	填写首次登记当天，后续更新不改此列	每次更新都改登记日期，失去登记时点
前置项目	关系类	提供交付物的一方	填写项目正式名称，与项目立项名称一致	填成部门名或个人名，无法对应到项目
交付物	关系类	前置项目需要交出的具体成果	写清名称、形态和版本，如“接口文档 v1.2”“测试环境访问权限”	只写“资料”“支持”等笼统词，验收时无法判断是否完成
后置项目	关系类	接收并使用交付物的一方	填写项目正式名称，一条依赖只对应一个后置项目	一条记录塞入多个后置项目，状态无法分别跟踪
受影响事项	关系类	后置项目中因该依赖受阻的工作项或里程碑	写到工作项、阶段或里程碑层级，便于判断延误后果	只写项目名，无法定位具体受阻环节
依赖类型	状态与责任类	依赖的性质分类	按团队约定枚举，如交付物依赖、审批依赖、资源依赖、信息依赖	类型随意填写，统计时无法归类
计划需要时间	时间类	后置项目希望拿到交付物的日期	由后置项目根据自身计划提出，填写日期而非时间段	与承诺交付时间混为一谈
承诺交付时间	时间类	前置项目确认可以交付的日期	由前置项目评估后填写，与计划需要时间不一致时须在备注说明差距	未经评估直接照抄计划需要时间
当前状态	状态与责任类	依赖当前所处阶段	按统一状态集填写，状态变化同步写入变更记录	状态长期停留在“进行中”，与实际交付脱节
责任人	状态与责任类	前置项目中对该交付物负责的对接人	填写具体个人，不填团队或岗位	填项目经理本人，实际交付人不在记录中
影响程度	状态与责任类	依赖延误对后置项目的影响级别	按高/中/低约定判断标准，如是否影响关键里程碑	全部标为“高”，失去优先级区分
备注	状态与责任类	补充条件、假设或协调结论	简短记录，不替代变更记录	把历次调整都堆在备注里
变更记录	变更记录类	时间、状态、责任人、范围的历史变化	每次变化追加一行，记录变更前后值与原因	直接覆盖主表原值，无法追溯

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

判断必填的标准是：缺少该字段，这条依赖就无法被跟踪或协调。按此标准，关系类、时间类和责任类中的关键字段必须填写；部分字段在特定情形下才需要填；备注类字段可按需补充。

字段	填写要求	理由或触发条件
依赖编号	必填	唯一标识，变更记录和沟通引用都依赖它
登记日期	必填	判断依赖登记早晚和复核周期的依据
前置项目	必填	缺少则无法确定由谁交付
交付物	必填	缺少则无法验收，也无法判断依赖是否解除
后置项目	必填	缺少则无法确定影响范围
计划需要时间	必填	后置项目的需求时点，是协调的起点
当前状态	必填	跟踪和汇总的基本依据
责任人	必填	没有具体对接人，依赖无法推进
承诺交付时间	条件必填	前置项目确认承接后必须填写；处于“待确认”状态时可暂空，但须在约定时间内补齐
受影响事项	条件必填	影响程度为“高”时必须写到具体工作项或里程碑；影响为“低”时可只写项目名
依赖类型	条件必填	团队按类型统计或分流协调时必填；仅做简单台账时可暂不分类
影响程度	条件必填	进入升级协调或排优先级时必填
备注	选填	用于记录假设、前置条件或协调结论
变更记录	条件必填	主表任一跟踪字段发生变化时必须追加，未发生变化可不填

填写示例：一条跨项目依赖的完整登记

以下为演示情景，用于说明各字段如何配合填写。背景：A 项目负责建设统一登录能力，B 项目负责上线会员中心，B 项目的会员登录功能需要接入 A 项目提供的登录接口。

字段	填写内容
依赖编号	DEP-007
登记日期	3月4日
前置项目	A 项目（统一登录建设）
交付物	登录接口及接口文档 v1.0，含测试环境地址
后置项目	B 项目（会员中心上线）
受影响事项	会员登录功能联调，关联 B 项目“会员中心上线”里程碑
依赖类型	交付物依赖
计划需要时间	4月10日
承诺交付时间	4月8日
当前状态	已确认
责任人	A 项目接口负责人（填写具体姓名）
影响程度	高
备注	接口需支持手机号登录；测试环境由 A 项目提供

随着进展，这条依赖的状态和变更记录按如下方式更新：

3月4日登记，状态为“待确认”，承诺交付时间暂空，由 B 项目提出计划需要时间 4月10日。
3月6日 A 项目评估后确认 4月8日可交付，状态改为“已确认”，变更记录追加一行：承诺交付时间由空变为4月8日，原因“前置项目评估完成”。
3月25日接口开发启动，状态改为“进行中”，变更记录注明启动日期。
4月7日接口文档先行发出，4月8日接口交付，状态改为“已交付”，变更记录写明实际交付日期与交付物版本。
B 项目联调通过后，状态改为“已关闭”，变更记录注明关闭依据。

若中途 A 项目发现交付需要推迟到4月15日，应先在变更记录中登记新的承诺时间和原因，再同步给 B 项目评估对里程碑的影响，而不是直接改主表了事。

维护要求：登记、更新、复核与关闭规则

登记表能否支撑跟踪与协调，取决于是否明确谁在什么时候登记、多久更新一次、状态如何流转、由谁复核和升级。以下规则可作为团队约定的起点。

登记入口与登记时点

登记入口唯一：指定一张在线表格或一个固定文档作为唯一登记表，避免多个副本并存。
登记时点：在项目计划评审、跨项目接口确认、里程碑排期会议中识别出依赖时即登记，不等到依赖受阻才补录。
登记责任：由后置项目提出依赖并填写关系类和时间类字段，前置项目确认后补充承诺交付时间和责任人。

更新频率与状态流转

更新频率：责任人至少每周更新一次自己负责的依赖状态；临近承诺交付时间的依赖提高到每周两次或每日更新。
状态流转：待确认→已确认→进行中→已交付→已关闭；任一环节无法继续时改为已取消，并写明原因。
状态变化必须同时写入变更记录，主表只保留当前值。

定期复核与升级协调

每周例会上按“影响程度高、承诺交付时间临近、状态停滞超过一周”三个条件筛选待讨论条目。
承诺交付时间晚于计划需要时间时，由后置项目评估影响并在会上提出调整方案，必要时升级到项目集负责人协调。
复核结论回写到登记表，形成“会上讨论—表内留痕—下次复核”的闭环。

关闭与归档条件

交付物经后置项目验收确认后，状态改为已关闭，并在变更记录中写明验收结论。
依赖取消时保留记录，不删除行，便于后续复盘。
项目结项后，将登记表按项目集归档，保留只读版本。

与项目计划和会议机制的衔接

登记表中的计划需要时间和承诺交付时间应回写到两个项目的计划中，作为里程碑的前置条件；周例会、月度项目集 review 直接以登记表筛选结果作为议题来源。这样登记表与计划、会议使用同一份数据，减少重复维护。

当团队把登记表落到 ONES 中时，可以把每条依赖作为跨项目的工作项记录，用自定义项目属性标注前置项目、依赖类型和影响程度，并在项目计划中查看相关项目和迭代的进度与工作量；依赖的背景说明、接口文档和历次协调结论可放在关联的项目文档页面中，借助页面版本记录查看和回滚历史内容。这样登记、更新和复核在同一套工作项与文档中完成，状态变化有迹可循。

按团队情况调整模板与长期维护

模板需要随项目集规模和协作复杂度调整，但调整应保持字段口径稳定，避免每个项目各用一套说法。

字段增减的取舍原则

项目集较小、依赖数量在几十条以内时，可保留核心字段，暂不启用依赖类型和影响程度，减少填写负担。
涉及多个项目集或外部供应商时，增加“依赖来源”“合同或协议编号”等字段，便于区分内部协调与外部约束。
新增字段前先确认它是否会被用于筛选、统计或升级判断；仅作说明用途的内容放入备注，不单独设列。
删除字段前检查历史数据是否仍被引用，已关闭依赖的相关字段建议保留只读。

按项目或状态拆分视图

主表数据保持一份，通过筛选视图满足不同使用场景：按前置项目拆分，供各项目负责人查看自己需要交付的依赖；按当前状态拆分，供例会选择待确认和进行中的条目；按影响程度和承诺交付时间排序，供项目集负责人识别高风险依赖。视图只改变展示方式，不复制数据。

模板版本与字段口径维护

为模板标注版本号和生效日期，字段增删或口径变化时发布新版本，并在变更说明中写清调整原因。
维护一份字段口径说明，与模板放在同一位置，新成员登记前先阅读。
每季度检查一次字段使用情况：长期为空的字段考虑删除，频繁在备注中补充的信息考虑升级为独立字段。
指定一名登记表维护人，负责模板版本、字段口径和视图配置，避免多人各自修改造成口径分裂。

常见问题

依赖登记表与项目计划中的任务依赖是什么关系？

登记表记录的是项目之间的交付关系，回答“哪个项目需要另一个项目交出什么、什么时候要”。单个项目内部任务之间的先后依赖属于任务排期范畴，通常在项目计划或任务列表中维护。两者可以互相引用：登记表中的计划需要时间和承诺交付时间应回写到两个项目的计划里，作为里程碑的前置条件，避免同一件事在两处出现不同日期。

承诺交付时间还没确定时，这条依赖可以先登记吗？

可以。登记时状态填“待确认”，承诺交付时间暂空，但计划需要时间必须填写，否则前置项目无法评估。团队需要约定一个补齐时限，例如登记后三个工作日内由前置项目给出承诺日期；超过时限仍未确认的条目，在例会上按待协调事项处理。补齐承诺时间时，同时在变更记录中追加一行，写明原值为空、新值和评估依据。

一条依赖涉及多个后置项目时怎么登记？

建议拆成多条记录，每条对应一个后置项目，共用同一个交付物描述，依赖编号分别编制。这样每个后置项目的受影响事项、影响程度和验收结论可以独立跟踪，前置项目的交付进度也能对应到具体使用方。如果确实需要体现它们同源，可在备注中注明关联的依赖编号，或增加一个“关联依赖”字段用于分组查看。

登记表用在线表格维护，还是放进项目管理工具？

依赖数量少、参与项目不多时，一张在线表格即可满足登记和筛选需求，启动成本低。当依赖需要与项目计划、工作项进度和文档放在一起查看时，可以考虑放进项目管理工具：把每条依赖作为跨项目的工作项记录，用自定义属性标注前置项目、依赖类型和影响程度，背景说明和协调结论放在关联文档页面中。ONES 中可通过项目属性自定义和多项目进度查看支持这类记录方式，具体字段配置范围以实际版本为准。选择哪种载体，关键看登记表是否需要与计划数据联动、是否需要多人按权限查看。