指南 › 指南

项目依赖关系跟踪模板

项目很少因为工作太难而失败。它们失败，是因为别人答应的某样东西没有到，而且没人记下来。依赖日志，就是把“我以为他们有了”变成“一个日期，旁边一个名字”的办法。

先弄清要跟踪什么

依赖项是您的项目需要、但不在自己掌控之内的东西，或者是另一项工作需要您交付的东西。把两个方向分开，因为沟通方式不同：入向依赖要您去催，出向依赖是您做出的承诺。

同时把内部依赖（您自己计划里任务之间的）和外部依赖（来自另一个项目、供应商、监管方或业务团队的）分开。外部依赖风险最大，因为您自己无法调整它们的排期。

• 入向：我们需要别人提供什么。
• 出向：别人需要我们提供什么。
• 内部：计划内任务与任务之间。
• 外部：另一个项目、供应商或部门。

模板的列

复制这张表，每个依赖项一行。要短到会议上读得完，又具体到没人能说措辞含糊。

• 编号，以及对所需事项的清晰描述。
• 方向（入向或出向）和类型（内部或外部）。
• 提供方和接收方，各是一位明确的人。
• 需求日期、它所保护的计划任务或里程碑，以及与提供方商定的承诺日期。
• 状态（未开始、进行中、已交付或有风险）、RAG，以及带日期的最新进展。
• 如果有，关联的相关风险或问题。

与提供方达成一致

您一个人写下来的依赖项，只是一个愿望。与负责交付的人确认，一起商定日期，并记录对方已接受。如果对方不肯承诺，这本身就说明了问题：立刻登记一条风险。

问问对方也需要您提供什么。依赖往往是相互的，互相交换是商定日期最容易的办法。

• 把承诺落成文字，哪怕只是一条简短的消息。
• 问对方什么可能让他们延误。
• 约定如果延误，他们如何、何时告诉您。

催办但不唠叨

催办节奏要与风险成正比。三个月后到期的依赖每月查一次；下周到期的，今天就要谈。每次出状态报告之前，把整份日志过一遍，让迟到的事项由您而不是别人告诉发起人。

• 两周内到期的依赖，每周复查。
• 凡是错过承诺日期的，立即升级。
• 依赖延误的当天，就把它转为风险或问题。
• 升级时要说明受影响的里程碑。

与计划连起来

当每个依赖项都指向被它卡住的任务时，这份日志最有用，您一眼就能看出延误是否落在关键路径上。在 Senshin 中，RAID 日志把事项与它们影响的计划任务关联起来，这种影响一目了然，不必靠手工推算。

• 在计划中标出由依赖驱动的任务。
• 任何延误之后，都要检查关键路径。
• 交付确认后才关闭事项，而不是承诺时就关闭。

它在 Senshin 中的位置

常见问题

更多指南

最后更新: 2026-10-22