项目依赖登记表用于记录一个项目对另一个项目的交付需要，让提出方、承接方和项目集管理者看到同一份事实。本文提供可直接复制到表格工具的空白模板，并说明每个字段的填写口径、必填与选填的划分、一条完整记录的写法，以及让登记表持续可用的维护要求。登记表可以放在ONES等协作工具中承载，下文在维护环节说明与登记动作直接相关的支持方式。
要点总览（TL;DR）
- 登记表以“一条依赖一行”为单位，核心字段分四组：标识与关联、内容与交付物、责任人与日期、状态风险与验证。
- 必填字段以“缺少后无法跟踪或无法判定完成”为标准，承诺交付日期在承接方确认后必须补齐。
- 维护要求包括统一入口登记、变更当天更新并留痕、固定节奏评审、关闭前完成验证、定期清理失效条目。
- 依赖数量增长后，可将登记表迁移到ONES中承载，用工作项记录依赖、自定义属性保存字段、状态流转推进交付。
- 模板字段增删需保持与历史记录兼容，新增字段先以选填试运行一个评审周期再决定是否转为必填。
可复制空白依赖登记表模板
登记表以“一条依赖一行”为基本单位。下表列出了一条依赖从提出到关闭所需的全部字段，复制表头到电子表格或在线文档即可开始登记。字段顺序按填写习惯排列：先标识与关联，再内容与交付，然后责任与日期，最后状态、风险与验证。
| 依赖编号 | 来源项目 | 目标项目 | 依赖内容 | 交付物 | 依赖类型 | 提出方责任人 | 承接方责任人 | 计划需要日期 | 承诺交付日期 | 状态 | 影响与风险 | 验证方式 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DEP-001 | 来源项目名称 | 目标项目名称 | 需要对方提供什么 | 可验收的具体产物 | 交付物/接口/资源/审批/信息 | 姓名 | 姓名 | YYYY-MM-DD | YYYY-MM-DD | 待确认/已承诺/进行中/已交付/已验证/已关闭/已取消 | 对来源项目的影响、主要风险 | 验收或确认方式 | 日期+变更内容+变更人 |
使用时保留表头行，删除示例行后逐条追加。若登记表服务于多个项目集，可在表头前增加“项目集”列作为筛选维度；若依赖数量较多，建议同时保留“登记日期”和“最后更新日期”两列，便于识别长期未动的条目。
字段说明：每个字段记录什么
字段说明的作用是让不同项目的人按同一口径填写，避免同一列出现“交付测试报告”和“测试完成”两种无法比较的记录。下表按四组字段解释含义与填写口径。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 依赖编号 | 依赖的唯一标识 | 采用“项目缩写-序号”格式，如DEP-001；一经分配不再复用，取消的条目保留编号 |
| 来源项目 | 提出依赖、等待交付的项目 | 填写项目正式名称，与项目清单保持一致 |
| 目标项目 | 承接依赖、负责交付的项目 | 同上；一条依赖只对应一个目标项目，涉及多方时拆成多条 |
| 依赖内容 | 需要对方完成的事项 | 用一句话写清动作和对象，如“提供用户中心登录接口的联调环境” |
| 交付物 | 可验收的具体产物 | 写可检查的成果，如接口文档、环境地址、签字确认单；避免只写“支持”“配合” |
| 依赖类型 | 依赖的性质分类 | 从交付物、接口、资源、审批、信息等固定选项中选，便于分类统计 |
| 提出方责任人 | 来源项目中负责跟进该依赖的人 | 填具体姓名，负责确认需求、验收交付 |
| 承接方责任人 | 目标项目中负责交付的人 | 填具体姓名，负责给出承诺日期并推进交付 |
| 计划需要日期 | 来源项目最晚可接受的交付时间 | 由提出方填写，说明晚于该日期会影响的后续工作 |
| 承诺交付日期 | 承接方确认的交付时间 | 由承接方填写；与计划需要日期不一致时，在影响与风险中说明差距的处理办法 |
| 状态 | 依赖当前所处阶段 | 从固定状态集中选择，不自行新增同义状态 |
| 影响与风险 | 依赖延误对来源项目的影响及已知风险 | 写具体后果，如“影响联调窗口，导致版本延期一周”，并注明风险等级或触发条件 |
| 验证方式 | 如何确认交付物可用 | 写验证动作和验证人，如“由提出方在测试环境完成登录流程验证” |
| 变更记录 | 日期、变更内容与变更人 | 每次修改日期、责任人、状态或交付范围时追加一行，保留历史，不覆盖原值 |
必填与选填的划分
划分依据是：缺少该字段是否会导致这条依赖无法被跟踪或无法判定完成。按此标准，登记时先填必填项即可建条目，选填项在后续协调中补齐，降低登记门槛。
| 类别 | 字段 | 理由或适用情形 |
|---|---|---|
| 必填 | 依赖编号、来源项目、目标项目、依赖内容、提出方责任人、承接方责任人、计划需要日期、状态 | 缺少编号无法引用；缺少双方项目和责任人无人跟进；缺少依赖内容无法判断范围；缺少计划需要日期无法排优先级；缺少状态无法跟踪 |
| 必填（承诺后） | 承诺交付日期 | 登记时可暂空，承接方确认后必须填写，否则无法判断是否逾期 |
| 选填 | 交付物、依赖类型 | 登记初期需求尚不清晰时可先写依赖内容，细化后再补交付物；类型用于统计时建议填写 |
| 选填 | 影响与风险 | 高优先级依赖建议登记时即填写；低风险依赖可在评审时补充 |
| 选填 | 验证方式 | 交付前必须明确，登记阶段可暂空 |
| 选填 | 变更记录 | 首次登记可为空，发生第一次变更后开始记录 |
缺失必填项时，登记表不应视为有效条目。处理方式是：由提出方在登记时补齐，无法当场确定的（如承接方责任人尚未指定），标记为“待确认”状态并指定补齐期限，在下次评审时检查。超过期限仍未补齐的条目，由项目集管理者协调确定责任人，或判定为无效需求后取消并保留编号。
填写示例：一条完整依赖记录
以下示例为演示情景，用于说明各字段如何配合支撑跟踪，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 依赖编号 | DEP-012 |
| 来源项目 | 会员系统改版 |
| 目标项目 | 统一用户中心 |
| 依赖内容 | 提供新版登录接口的联调环境与接口文档 |
| 交付物 | 接口文档v1.2、测试环境访问地址、联调账号 |
| 依赖类型 | 接口 |
| 提出方责任人 | 张明（会员系统改版，后端负责人） |
| 承接方责任人 | 李华（统一用户中心，接口开发） |
| 计划需要日期 | 2025-06-10 |
| 承诺交付日期 | 2025-06-12 |
| 状态 | 已承诺 |
| 影响与风险 | 晚于6月10日将压缩联调时间，可能影响6月20日的版本提测；风险在于接口字段可能随用户中心需求调整而变化 |
| 验证方式 | 张明在测试环境用联调账号完成登录、刷新令牌两个流程，确认后状态改为已验证 |
| 变更记录 | 2025-05-28 登记，张明；2025-06-03 承诺日期由6月10日调整为6月12日，李华，原因：接口字段评审延后 |
这条记录的关键在于：计划需要日期与承诺交付日期分列，差距两天被显式记录，评审时可以直接判断是否需要调整来源项目的联调计划；验证方式写明了验证人和验证动作，交付后不依赖口头确认；变更记录保留了日期调整的原因，后续复盘可以追溯。
维护要求与调整方法
登记表的价值取决于持续维护。以下要求围绕登记入口、责任分工、评审节奏、状态流转和模板演进展开，可按项目集规模裁剪执行频率。
登记与更新节奏
- 统一入口：每个项目集只保留一份依赖登记表，新依赖在识别当天登记，不在个人文档或聊天记录中另行维护副本。
- 更新时机：承诺日期、责任人、交付范围发生变化时，由变更发起方在当天更新对应行并追加变更记录。
- 定期评审：建议每周或每两周评审一次全部“待确认、已承诺、进行中”条目，重点检查临近计划需要日期且未交付的依赖。
- 定期清理：每月检查长期无更新的条目，确认是否仍然有效；失效条目改为“已取消”并注明原因，保留编号不删除。
责任人与评审机制
提出方责任人负责确认需求、验收交付并维护来源项目侧信息；承接方责任人负责给出承诺日期、推进交付并更新状态。项目集管理者负责组织评审、协调日期冲突，并对缺失必填项的条目设定补齐期限。评审会议以登记表为唯一议程来源，逐条过状态和日期，会议结论直接回写到表中。
状态流转与关闭验证
状态按“待确认→已承诺→进行中→已交付→已验证→已关闭”推进，取消的条目从任一状态转入“已取消”。每次流转需满足对应条件：进入“已承诺”须有承接方责任人和承诺交付日期；进入“已交付”须有交付物；进入“已验证”须按验证方式完成确认并记录验证人；进入“已关闭”表示来源项目已不再需要跟踪该依赖。关闭必须经过验证，避免交付物实际不可用却被标记完成。
模板字段增删的调整原则
- 新增字段先以选填方式试运行一个评审周期，统计填写完整度，再决定是否转为必填。
- 删除字段前确认历史记录中该字段是否仍被引用；需要保留追溯信息时，改为归档列而非直接删除。
- 字段名称和选项集变更时同步更新字段说明，保持模板、说明和示例三处一致。
- 调整后的模板对已有记录保持兼容，历史行缺失的新字段留空并在说明中注明生效日期。
当依赖数量增长到几十条以上，表格的筛选和状态提醒会变得吃力。此时可将登记表迁移到ONES中承载：用工作项记录每条依赖，通过自定义属性保存来源项目、目标项目、依赖类型等字段，借助状态流转推进“已承诺—已交付—已验证”的过程；ONES Plan的项目集管理可总览多项目信息，自定义项目属性便于按项目类型区分管理，多项目数据集合帮助按维度查看进度。登记表本身仍按上述字段和维护要求执行，工具承担的是集中存放、状态更新和跨项目查看的动作。
常见问题
依赖登记表应该由提出方还是承接方维护？
登记表本身由项目集管理者统一维护入口和格式，具体行由双方分工更新：提出方责任人负责登记依赖内容、计划需要日期，并在交付后完成验证；承接方责任人负责填写承诺交付日期、推进交付并更新状态。变更发生时由变更发起方在当天更新对应行并追加变更记录，避免只有一方掌握最新信息。
计划需要日期和承诺交付日期不一致时怎么处理？
两个日期分列的目的就是让差距可见。承接方给出晚于计划需要日期的承诺时，应在“影响与风险”中写明差距对来源项目的影响和应对办法，例如调整联调窗口或压缩后续测试时间。评审会上由项目集管理者协调，判断是调整来源项目计划，还是由承接方压缩交付时间。
依赖登记表条目很多时，还适合继续用表格维护吗？
条目在几十条以内时，电子表格配合固定评审节奏通常够用。数量继续增长后，筛选、状态提醒和跨项目查看会变得吃力，可以把登记表迁移到ONES中承载：用工作项记录每条依赖，通过自定义属性保存来源项目、目标项目、依赖类型等字段，借助状态流转推进交付过程。字段口径和维护要求保持不变，工具承担集中存放和状态更新的动作。
已取消的依赖条目要不要从登记表中删除？
建议保留编号并改为“已取消”，注明取消原因，不做物理删除。依赖编号一经分配不再复用，保留历史条目可以避免后续引用混乱，也便于复盘时看清哪些依赖曾被提出又取消。定期清理针对的是长期无更新的条目，处理方式是确认有效性后取消或关闭，而不是删除行。
登记表需要多久评审一次？
建议每周或每两周评审一次全部“待确认、已承诺、进行中”的条目，重点检查临近计划需要日期且尚未交付的依赖。项目集规模较小、依赖数量少时，可以并入现有的项目例会，不必单独开会；依赖跨多个项目且日期冲突频繁时，单独设置评审节奏更便于协调。评审结论直接回写到登记表，会议不再另行维护纪要副本。
