跨项目依赖跟踪要解决的是“别人答应的事什么时候能到”这个不确定问题。做法是把依赖从口头约定变成登记项：每条依赖有提出方、承接方、唯一责任人、需要日期和承诺日期，并按提出、确认、跟踪、关闭四个动作流转。本文给出登记表字段、角色分工、评审节奏和完成检查清单，适用于需要协调多个项目的项目集或PMO场景。
要点总览（TL;DR）
- 跨项目依赖跟踪的对象是项目之间的交付物、决策、资源和环境依赖，单项目内部任务先后顺序不进入台账。
- 登记表至少包含提出方、承接方、依赖内容、需要日期、承诺日期、状态、影响范围和责任人，需要日期与承诺日期分开记录。
- 依赖按提出、确认、跟踪、关闭四个动作流转，每个动作有明确输入、输出、完成标志和主责角色。
- 用固定频率的依赖评审会集中处理新增、临期和逾期依赖，逾期项按两级升级路径裁决并记录。
- 机制是否运转可用台账完整性、承诺日期覆盖率、逾期率、评审会执行情况和关闭记录逐项检查。
跨项目依赖跟踪先建什么：一张登记表的最小字段
跨项目依赖跟踪的第一件交付物是一张统一的依赖登记表。它记录的是项目之间的交付物、决策、资源和环境依赖：A项目要用的接口由B项目提供，C项目的上线时间取决于D项目的环境就绪。单项目内部任务的先后顺序由本项目排期解决，不进入这张表，否则台账会被日常任务淹没，跨项目协调的重点反而看不清。
登记表字段不必多，但每条依赖必须能回答四个问题：谁需要、谁提供、什么时候要、现在到哪一步。建议的最小字段如下。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 依赖编号 | 台账内唯一标识 | 按“项目缩写-序号”生成，便于会议和沟通中引用 |
| 提出方项目 | 依赖的需求来源 | 填写项目名称，不填个人姓名 |
| 承接方项目 | 负责提供交付物或决策的项目 | 同上；跨部门时注明所属部门 |
| 依赖类型 | 交付物、决策、资源、环境 | 四选一，类型决定后续确认方式 |
| 依赖内容 | 具体需要什么 | 写到可验收的程度，例如“支付接口联调环境及测试账号”，不写“支持支付” |
| 需要日期 | 提出方按自身里程碑倒推的最晚可用时间 | 由提出方填写，代表业务约束 |
| 承诺日期 | 承接方评估后给出的交付时间 | 由承接方填写，代表正式承诺 |
| 状态 | 依赖当前所处阶段 | 从固定取值中选择，见下文 |
| 影响范围 | 依赖未按时到位会波及的里程碑、交付或项目 | 写明具体节点，便于评估升级优先级 |
| 责任人 | 对该条依赖负责的唯一人 | 提出方与承接方各一名，承接方责任人对承诺日期负责 |
需要日期与承诺日期必须分开记录，这是台账能否起作用的关键。需要日期表达提出方的业务约束，承诺日期表达承接方的可行性判断。两者不一致时，差异本身就是需要协调的事项，应在评审会上讨论，而不是由提出方自行把期望写成承诺。
状态建议使用固定取值：已提出、已确认、进行中、已交付待验收、已关闭、已逾期。流转规则是：提出方登记后为“已提出”；承接方给出承诺日期后转为“已确认”；承接方开始实际投入后转为“进行中”；交付物提交后转为“已交付待验收”；提出方验收通过后转为“已关闭”；承诺日期已过且未交付的，由台账责任人标记为“已逾期”。每次状态变更记录变更时间，避免事后无法追溯。
依赖类型影响确认方式：交付物依赖需要明确验收标准；决策依赖需要明确决策人和决策时限；资源依赖需要明确资源数量、占用时段和释放条件；环境依赖需要明确就绪的技术标准和验证方式。类型填错会导致确认环节反复，登记时就应选准。
依赖从提出到关闭的四个动作与责任人
台账建好后，依赖需要按固定动作流转。四个动作各有输入、输出和完成标志，缺一个环节，依赖就会停在“已提出”状态无人推进。
提出：在里程碑确定后登记
提出方项目经理在项目里程碑和交付范围确定后，识别出需要其他项目配合的事项，逐条登记。输入是本项目的排期与交付清单，动作是判断哪些事项超出本项目可控范围、需要外部承接，输出是状态为“已提出”的台账记录。完成标志是每条记录都有明确的依赖内容、需要日期和影响范围。提出时点建议放在项目计划评审前后，避免计划已对外承诺才发现依赖未登记。
确认：承接方给出承诺日期
承接方负责人收到依赖后，评估自身排期、资源和技术可行性，给出承诺日期或提出替代方案。输入是提出方登记的依赖内容与需要日期，动作是可行性判断，输出是承诺日期和承接方责任人。完成标志是状态转为“已确认”，且承诺日期有明确依据。承接方无法满足需要日期时，应在确认环节直接说明差距，由双方在评审会上协调，而不是先答应再拖延。
跟踪：按固定频率更新状态
跟踪由承接方责任人执行，按周更新状态；临近承诺日期的依赖提高更新频率。输入是当前实际进展，动作是更新状态并注明变更时间，输出是最新的台账记录。完成标志是台账状态与实际进展一致，且逾期项已被标记。跟踪的责任在承接方，提出方可以查看和跟催，但状态更新不能依赖提出方反复询问。
关闭：凭验收证据关闭
交付物提交后，提出方按登记时约定的验收标准检查，通过后关闭。输入是交付物与验收标准，动作是验收确认，输出是状态“已关闭”及验收记录。完成标志是验收证据可查，例如测试通过记录、决策纪要或环境就绪确认。仅有口头确认的依赖不建议直接关闭。
逾期与争议的升级路径
承诺日期已过且未交付，台账责任人标记“已逾期”，并在最近一次依赖评审会上列为第一优先级。升级路径建议分两级：第一级由提出方项目经理与承接方负责人协商新的承诺日期；协商不成或影响关键里程碑的，第二级升级至项目集经理或PMO裁决，裁决结果记录在台账中。承接方对依赖归属有异议时，同样提交评审会裁决，不在私下反复沟通中消耗时间。
角色分工：项目集经理、项目经理与承接方各管什么
依赖跟踪失效的常见原因是责任分散：提出方觉得已登记就算完成，承接方觉得没被正式告知，PMO觉得台账只是收集表。按角色划清边界，可以让每条依赖都有明确的主责人。
| 角色 | 核心职责 | 具体动作 |
|---|---|---|
| 项目集经理 | 统筹与升级裁决 | 主持依赖评审会，裁决跨项目优先级冲突，批准承诺日期变更，对影响关键里程碑的逾期项做出处置决定 |
| 提出方项目经理 | 登记与跟催 | 识别并登记依赖，填写需要日期与影响范围，参与验收，对临期依赖主动跟催 |
| 承接方负责人 | 承诺与交付 | 评估可行性并给出承诺日期，指定承接方责任人，按周更新状态，交付时提交验收证据 |
| 依赖协调人或PMO | 台账维护 | 维护字段口径与状态取值，会前筛选新增、临期与逾期依赖，记录会议决议，跟踪升级事项闭环 |
角色冲突时的裁决归属需要事先约定。两个项目对同一资源的占用时间冲突，由项目集经理按对整体目标的影响裁决；依赖内容是否属于跨项目依赖存在争议，由PMO按台账口径判断；承接方认为承诺日期被单方面修改，提交评审会复核。裁决结果写入台账，作为后续跟踪依据。
当组织使用项目协作工具承载这套机制时，台账可以落在统一的工作项或项目集视图中。ONES Plan 提供多项目进度管控和资源管理，支持借助项目集管理总览多项目信息，并可自定义项目属性管理不同类型项目，适合把依赖台账与项目进度放在同一处查看。依赖状态的流转与评审决议仍按上述角色和动作执行，工具承担的是记录与汇总。
跟踪节奏：依赖评审会怎么开、看什么
单条依赖靠四个动作流转，整体依赖状况靠固定节奏的评审会集体跟踪。评审会的作用是让新增依赖被确认、临期依赖被关注、逾期依赖被处置，而不是逐条汇报进度。
频率建议与项目集的管理节奏一致，双周一次是常见起点；项目集规模大、依赖密集时可改为每周。参与人包括项目集经理、各项目项目经理、承接方负责人和PMO。会前由PMO从台账中筛选三类记录：本周新增的“已提出”依赖、承诺日期在两周内的临期依赖、已标记“已逾期”的依赖，并提前发给参会人。
议程按三类记录依次进行：新增依赖逐条确认承接方与承诺日期；临期依赖核对进展与风险；逾期依赖由承接方说明原因，提出方说明影响，当场形成处置决议。每类议题设定时间上限，避免会议被单条依赖拖长。
会议输出包括三类记录：承诺变更记录，写明哪条依赖的承诺日期调整及批准人；升级决议，写明逾期项的处理方式和责任人；关闭确认，写明本周验收通过的依赖。会后由PMO更新台账并分发纪要。评审会与项目周报衔接的方式是：周报中引用台账编号说明本项目依赖状态，不重复描述细节；与里程碑评审衔接的方式是：里程碑评审前检查该里程碑相关的依赖是否全部关闭，未关闭的列为风险项。
示例：三个项目共用一套依赖台账的跟踪过程
以下为演示情景，用于说明机制如何串联运转。某产品线同时推进三个项目：A项目负责客户端改版，B项目负责后端接口升级，C项目负责数据迁移。A项目的上线里程碑依赖B项目的接口交付和C项目的迁移完成。
A项目项目经理在计划评审后登记两条依赖：依赖001，承接方B项目，类型为交付物，内容为“新版订单接口及联调环境”，需要日期为6月20日，影响范围为A项目7月上线；依赖002，承接方C项目，类型为资源，内容为“两名数据工程师支持两周”，需要日期为6月10日。B项目负责人评估后给出承诺日期6月18日，C项目负责人给出承诺日期6月12日，两条依赖转为“已确认”。
两周后，依赖002进入“进行中”，C项目按周更新状态。依赖001在6月18日未交付，PMO标记“已逾期”。评审会上，B项目说明接口开发受上游系统变更影响，需延至6月25日；A项目说明这将压缩联调时间并影响7月上线。项目集经理裁决：B项目优先完成接口核心部分，6月22日先提供联调环境，完整接口6月25日交付；A项目调整联调计划。裁决写入台账，承诺日期变更获批准。
6月22日联调环境就绪，依赖001转为“已交付待验收”；6月25日完整接口交付，A项目完成联调测试并留存测试通过记录，依赖001关闭。依赖002于6月12日完成资源支持，C项目提交工时记录，A项目确认后关闭。该示例可迁移的做法是：需要日期与承诺日期分开、逾期项在评审会上当场裁决、关闭时保留可查的验收证据。
完成检查：依赖跟踪机制是否跑起来的判断标准
机制是否运转，可以用以下清单逐项核对。建议每月检查一次，由PMO执行并记录结果。
- 台账完整性：所有跨项目依赖是否都已登记，是否存在只在会议纪要或聊天记录中出现、未进入台账的依赖；每条记录的关键字段是否填写完整。
- 承诺日期覆盖率：处于“已确认”及之后状态的依赖中，填写了承诺日期的比例是否接近全部；长期停留在“已提出”状态的依赖数量是否可控。
- 逾期率观察：统计当期逾期依赖数量与依赖总数的比例，并观察趋势；逾期项是否都在评审会上有过处置记录。
- 评审会执行情况：评审会是否按约定频率召开，会前筛选材料是否按时发出，议程是否覆盖新增、临期、逾期三类依赖。
- 升级与关闭记录：升级决议是否有明确责任人和完成时间；关闭的依赖是否都有验收证据，是否存在无记录直接关闭的情况。
- 机制失效信号：依赖长期靠个人催办推进、台账状态与实际进展明显不符、评审会沦为进度汇报、逾期项反复延期却无裁决，出现这些信号时应检查字段口径和角色分工是否需要调整。
检查结果用于调整机制本身：字段过多导致填写负担重，可以精简；升级层级与实际决策权不匹配，应重新约定裁决归属。频率、字段和升级层级需结合组织规模与项目集复杂度设定，上述取值可作为起点。
常见问题
依赖台账建起来后，怎么避免它变成只收集不处理的表格？
关键是把台账和固定的评审节奏绑定。台账本身只是记录，真正推动依赖前进的是评审会上的确认、裁决和关闭动作。建议每次评审会前由PMO从台账中筛出新增、临期和逾期三类记录，会上逐条形成结论并回写台账。如果台账连续几周只有新增记录、没有状态变更和关闭记录，说明评审会没有真正处理依赖，需要检查议程是否被进度汇报占满。
承接方给出的承诺日期晚于提出方的需要日期，这种情况怎么处理？
两个日期不一致本身就是需要协调的事项，不建议由提出方自行把需要日期改成承诺日期来“消除差异”。处理方式是在评审会上由双方说明依据：提出方说明需要日期对应的里程碑约束，承接方说明排期和资源限制，再由项目集经理判断是调整承接方优先级、拆分交付范围，还是由提出方调整自身计划。无论哪种结论，都应把新的承诺日期和批准人记录在台账中，作为后续跟踪依据。
项目集规模不大，是否也需要单独设依赖协调人或PMO来维护台账？
不一定。台账维护职责的核心是保证字段口径一致、会前筛选材料、会后记录决议，规模较小的项目集可以由项目集经理或某位项目经理兼任。需要单独设岗的常见条件是：依赖数量多、涉及项目超过三四个、跨部门协调频繁，或者台账维护已经明显挤占项目经理自身的交付工作。无论由谁承担，这项职责都应在启动时明确到人，避免出现台账无人更新、会议无人准备的情况。
依赖已经关闭后，提出方发现交付物不满足实际使用要求，还能重新打开吗？
可以，但应作为新记录处理，而不是直接修改已关闭记录的状态。关闭时依据的是登记阶段约定的验收标准，如果实际使用中发现新问题，说明验收标准当时定义得不够完整。建议新建一条依赖记录，写明问题内容、影响范围和需要日期，重新走提出与确认流程；同时在检查机制时回看原验收标准，补充同类依赖的验收口径，减少后续重复出现。
用项目协作工具承载依赖台账时，需要关注哪些配置要点？
重点看三件事：字段能否自定义到满足登记表要求，状态能否按固定取值流转并保留变更时间，多项目信息能否在同一视图下汇总查看。ONES Plan 提供多项目进度管控和资源管理，支持借助项目集管理总览多项目信息，并可自定义项目属性管理不同类型项目，适合把依赖台账与项目进度放在同一处查看。工具承担记录与汇总，确认、裁决和关闭仍按角色分工执行。具体是否提供专门的依赖登记与逾期提醒能力，建议在选型时向厂商核实。
