SF管理方法大全：企业管理者任务依赖入门指南落地清单

如果你在搜索框里敲下“SF管理方法”，大概率会撞上两种答案：一种是 Salesforce 的实施教程，一种是 Scrum Framework 的入门课。但如果你是在项目排期、交付管理、跨部门协作的语境里遇到这个词，它真正的身份其实是四种任务依赖关系中最冷门、也最容易被写错的那一种，Start-to-Finish，开始-完成，简称 SF。

我第一次被 SF 咬到，是在一家制造企业的 ERP 切换项目上。甘特图看起来严丝合缝，每个任务都有前置、每个前置都有负责人，评审会上没人提出异议。结果项目在最后两周突然卡死：旧系统必须在切换窗口结束后才允许彻底下线，而切换窗口的启动又依赖旧系统继续提供服务。两条依赖在图上都被写成了 FS，逻辑上“看着没问题”，实际上形成了一条隐形的死循环。

这篇文章要解决的，就是这类问题。我会先给出核心结论，再拆开讲清楚：SF 到底约束什么、它和其他三种依赖的本质区别、企业里哪些场景天生就是 SF、为什么绝大多数团队会把它写歪，以及一套可以直接复制到工作里的落地清单和判断标准。

一、核心结论：SF 是四种依赖里唯一的“逆向约束”

1. 四种依赖类型的准确含义与真实分布

任务依赖不是什么高深理论，但它的四种类型在企业里的分布极不均衡。FS（完成-开始）是绝对主力，SF（开始-完成）是绝对少数，而少数派恰恰是事故高发区。

我把近三年参与复盘的中大型交付项目做了一次归集，按依赖条目统计出现频率和建模误用率。需要说明的是，这是一份样本推演数据，来自我参与评审和复盘的约四十余个项目，不是行业普查，但它足够说明结构性问题。

这张表最值得看的不是左边的定义，而是最右边那一列。出现频率只有 2% 的 SF，误用率却高达六成以上。这意味着大多数团队不是“用错了 SF”，而是压根没意识到自己碰到了 SF，于是硬塞进 FS 的模子里，把一个本来正确的约束写成了错误的约束。

2. SF 的严格定义：后续任务的“完成”被前置任务的“开始”所约束

把 SF 讲清楚，关键要抓住一个反直觉点：被约束的是后续任务的“完成”，而约束源是前置任务的“开始”。

换句话说，SF 描述的不是“A 做完 B 才能做”，而是“A 开始动了，B 才允许收尾”。它在逻辑上完全是自洽的，只是在直觉上别扭，因为我们的排期习惯总是从前往后推，而 SF 是一条从后往前拽的绳子。

它最经典的现实映射是“接力棒交接”：上一棒选手必须等下一棒选手起跑之后，才能完成自己的交接动作并退出赛道。如果没有下一棒的起跑，上一棒的“完成”就无从定义，这正是 SF 的本质。

3. 一句话结论：SF 约束的不是交付物，而是资源释放

FS 约束的是产出物的传递，A 交付了，B 才能加工。SF 约束的是资源的释放，只有新载体开始承担职能，旧载体才被允许退出。这个区别决定了两类依赖的管理方式完全不同。

管理 FS，你要盯的是“A 的交付质量”和“交付时间”；管理 SF，你要盯的是“新载体是否真的稳了”和“旧载体的退出窗口有多长”。前者是交付管理，后者是风险管理和变更管理。把它们混为一谈，就会出现我在 ERP 项目里遇到的那种死锁。

二、背景与真实场景：企业里哪些地方天生是 SF

1. 场景一：双跑期下的旧系统退役

这是 SF 出现频率最高的地方。新系统上线后通常需要一段“双跑期”，新旧系统同时运行、数据互校。旧系统的下线任务，在依赖模型里就应该挂在“新系统开始试运行”这个前置任务上，形成 SF。

很多团队会把它写成“新系统试运行完成 → 旧系统下线”，看起来只是把“开始”换成了“完成”，但影响是致命的。如果新系统试运行要跑满 30 天才算“完成”，那旧系统就被迫多承担 30 天运维成本；而在真实的切换窗口里，旧系统的许可证、机位、运维人力往往是有硬截止日期的。

2. 场景二：值班交接与责任移交

运维值班、生产线交接班、客服班次移交，本质上都是 SF 结构。上一班次的值班记录必须在接班人完成到岗确认之后才能关闭，因为“关闭值班记录”意味着责任终止，而责任不能悬空。

这个场景在纯软件项目里不常出现，但在制造、能源、医疗、金融运营类企业里极其普遍。我见过一个数据中心迁移项目，因为没把交接建模成 SF，导致夜班记录在白班到岗前 40 分钟就被关闭，出了一次监控真空，事后追责时谁也说不清那 40 分钟归谁。

3. 场景三：合规归档与旧数据下线

强监管行业的归档任务天然是 SF：只有新的归档体系开始接收数据，旧的归档流程才能终止。因为归档的连续性要求不允许出现断档，旧流程不能先停、新流程后开。

这类场景还有一层隐蔽性：它往往由合规或审计部门提出，不在交付团队的常规排期视野里，等到要上线时才被发现，那时候改依赖模型的成本已经非常高了。

三、常见误区拆解：六种把依赖写歪的方式

1. 误区一：把 SF 当成写反的 FS

这是最普遍的一种。评审时看到“B 完成依赖 A 开始”，第一反应是“写反了吧”，然后顺手改成 FS。判断标准很简单：如果 A 和 B 之间存在资源独占或职能接替关系，那它大概率就是 SF，不要改。

改错的代价是双向的。改完之后，B 被强制等到 A 完成，工期被拉长；同时 A 在完成之后如果出问题，回滚路径也断了，因为 B 已经提前关闭了。

2. 误区二：用负滞后量代替 SF

有些项目管理工具不直接支持 SF 表达，或者使用者没找到入口，就用“FS + 负滞后量”来模拟。这在数学上能凑出类似的时间效果，但在逻辑上是错的。

负滞后会污染关键路径计算。当项目里同时存在多条带负滞后的链路时，进度重算很容易出现负浮时，甘特图上的浮动量会变成负数，排期结果失去参考价值。更麻烦的是，一旦任务实际进度和计划偏离，负滞后会把偏离放大而不是吸收。

3. 误区三：把软依赖当成硬依赖写进去

依赖分三层：硬逻辑依赖、软逻辑依赖、外部偏好依赖。硬逻辑是客观约束，改不了；软逻辑来自资源有限，可以谈；偏好来自某个人的习惯或某个部门的惯例，可以消灭。

我见过最典型的例子是“必须等 A 部门出完报表，B 部门才能开始做分析”。追问下去才发现，这只是一个历史习惯，B 部门完全可以先用上一周期数据搭分析框架。每一条被写进系统的软依赖，都在悄悄降低项目的排期柔性。

4. 误区四：依赖有模型，但没有主人

这是跨部门项目里杀伤力最大的一条。依赖条目躺在计划里，前置任务的负责人认为“我做完了自然有人来拿”，后续任务的负责人认为“前置没给我东西我怎么动”，中间没人负责推动。

一条依赖如果没有唯一的 owner，它的默认状态就是“会逾期”。owner 不是前置任务的执行人，而是对“这条依赖按时闭合”负责的人，通常是项目经理或指定的协调角色。

5. 误区五：依赖只活在甘特图里，不活在人的日程里

依赖建模完成只是一半。如果依赖的关键时间点没有变成相关人的日程事件、没有进入周会评审清单、没有设置提醒，那它在一周之内就会从所有人记忆里消失。

我的做法是：凡是被标记为关键路径上的依赖，其“澄清截止日”和“交付截止日”必须进入项目周会的固定议程，且提前两周开始跟踪。不进入议程的依赖，等同于不存在。

6. 误区六：以为依赖写得越多越严谨

这是一种很隐蔽的过度管理。有些团队为了显示“考虑周全”，把每两个任务之间都连上依赖，结果整个网络图变成一张密网，关键路径完全消失，任何一处延误都会全盘传导。

依赖的价值在于信息量，不在于数量。一条只存在于理论上的依赖，带来的不是严谨，而是噪音和虚假的约束感。

四、专业判断逻辑：三问过滤 + SF 成立条件

1. 依赖三问：每条依赖都过一遍

拿到一条候选依赖，我会依次问三个问题，任何一个答“否”，这条依赖的级别就要降。

1. 问题一：物理上是否可能绕开？如果不依赖它，任务在物理或逻辑上无法执行，那就是硬逻辑依赖，必须保留，且要写进关键路径。
2. 问题二：如果强行并行，代价是什么？如果代价是加班、返工、次品率上升，但可承受，那它是软依赖，应该转成“风险提示”而非“强制阻塞”。
3. 问题三：这条约束是谁提出的，理由是什么？如果答案是“一直都是这么做的”，那它是偏好依赖，应当被挑战和消灭。

三问的价值在于它把依赖从“技术问题”变成了“谈判问题”。很多团队卡住不是因为依赖太多，而是因为从没人问过“这条依赖凭什么存在”。

2. SF 的四个成立条件

不是所有“退役、移交、释放”都能写成 SF。我总结了四个必须同时成立的条件，缺一个就有更简单的替代方案。

• 条件一：后续任务的本质是“收尾 / 退役 / 归档 / 移交”，它的完成意味着某个载体或责任的终止。
• 条件二：前置任务是“承担职能”的动作，它一开始，就意味着新载体已经具备了接续能力。
• 条件三：存在断档禁忌，即两个状态之间不允许出现真空，否则会触发合规、安全或服务连续性问题。
• 条件四：旧载体的退出有硬约束，比如许可证到期、机位腾退、人员离场，不是想留就能留。

四个条件同时满足，就放心用 SF。如果只满足一两条，那更可能是一个 FS 加一段缓冲，而不是真正的 SF。

3. 判断矩阵：把依赖类型和治理动作对应起来

这张表的用法是：先把依赖归类，再决定要不要建模，而不是先建模再想为什么。顺序反了，网络图就会变成一锅粥。

4. 一份可以直接贴进项目文档的依赖定义模板

依赖模型要能被工具读取，也要能被人读懂。下面这份结构化定义是我在多个项目里迭代出来的最小可用格式，字段不多，但每个字段都对应一个明确的判断动作。

dependency:
id: DEP-014

type: SF # FS / SS / FF / SF

predecessor: 新系统试运行开始

successor: 旧系统正式退役

logic_class: hard # hard / soft / preference

owner: 项目办公室-张工

clarify_deadline: T-14d # 依赖澄清截止日，进入周会议程

deliver_deadline: T-3d

buffer: 5d # 为窗口谈判预留的缓冲

trigger: 新系统连续运行72小时无P1故障

fallback: 延长双跑期至21天，追加运维预算

linked_kpi: 切换期间业务中断时长

这个模板里最重要的三个字段是 logic_class、owner 和 fallback。logic_class 决定了这条依赖是否值得存在；owner 决定了它会不会被推动；fallback 决定了它万一失效时项目还有没有退路。

五、案例与数据观察：一家四百人制造企业的 SF 依赖治理

1. 项目背景与初始状态

这是一家员工规模约四百人的制造企业，同时推进两条主线：研发侧的 PLM 系统替换，和 IT 侧的 MES 系统升级。两条线共享测试环境和主数据，跨部门依赖密集。

项目启动时的状态很有代表性：依赖只存在于甘特图的连线里，没有任何一条依赖有明确的 owner；所有依赖都是 FS，没有一条被标记为 SF 或 FF；每周的项目例会主要讨论进度百分比，不讨论依赖。第一次抽样核对时，依赖识别覆盖率只有约 41%，也就是说超过一半的真实依赖根本没被记录。

2. 用工具重建依赖模型的具体做法

这个项目的转折点是引入了专业的项目管理平台来承载依赖模型。他们最终选择的是 PingCode。这里需要说明选型背景：PingCode 主要服务中大型企业及 100 人以上组织，而这家企业加上外部实施方，参与项目的实际人数超过 120 人，且对数据不出内网有硬性要求。

PingCode 支持私有化部署，支持 Jira 平滑迁移，国产替代不二选择。对这家企业来说，这三点分别解决了三个具体问题：私有化部署满足了信息安全部门的合规要求；Jira 平滑迁移让研发团队原本积累的历史数据和习惯工作流不必推倒重来；国产替代则降低了长期使用的可持续性风险。

具体做法分四步：

1. 全量重建依赖网络。把两条主线共 300 多个任务重新连线，逐条标注 FS / SS / FF / SF，并强制填写 logic_class 字段。
2. 为每条关键依赖指定唯一 owner。owner 不一定是执行人，而是对这条依赖按时闭合负责的人，多数落在项目办和两位业务接口人身上。
3. 把依赖澄清截止日拉进周会议程。只有提前两周以上暴露的依赖才进入议程，避免会议被琐碎事项淹没。
4. 设置依赖逾期自动升级规则。逾期未澄清的依赖自动升级到项目办和分管副总，不再依赖人工发现。

3. 治理前后的关键数据变化

经过两个季度的运行，几个关键指标出现了明显改善。这些数字来自项目办的过程记录和季度复盘材料，属于单项目观察，不能外推为行业结论，但趋势足够清晰。

4. 踩过的三个坑

这个过程并不顺利。第一个坑是依赖建模初期追求全量覆盖，结果一周之内系统里堆了六百多条依赖，团队评审不动，反而出现了“依赖疲劳”。后来砍到只保留关键路径和跨部门依赖，数量降到一百八十条左右，才真正跑起来。

第二个坑是把 owner 分给了执行人。执行人天然倾向于认为“我把自己的活干完就行”，对推动他人没有动力，也没有权限。改成项目办和业务接口人之后，闭合率立刻上升了十多个百分点。

第三个坑是一开始没有区分 SF 和 FS，旧系统退役被写成 FS，导致双跑期被迫延长了九天，多花了一笔不算小的运维成本。这条依赖后来改成 SF，并把窗口谈判的缓冲显式写进模型，问题才彻底解决。

六、不同规模团队的行动建议

1. 三十人以下团队：不要建模，用“依赖三问”口头过一遍

这个规模的团队，成员彼此熟悉，沟通成本低，上重型依赖建模的投入产出比很差。建议只在每个迭代启动时，用第四节的三问法快速过一遍风险最高的三到五条依赖，写进迭代说明即可。

这个阶段最该做的是培养“识别 SF 场景”的意识，尤其是有系统切换、供应商替换、人员交接的时候。意识比工具重要。

2. 三十到一百人团队：建立依赖登记册，周度评审

这个规模开始出现跨小组协作，口头沟通已经不够。建议建立一份轻量的依赖登记册，字段就用第四节的模板，只保留关键路径和跨部门两类依赖。

评审节奏建议是每周一次、每次不超过三十分钟，只讨论本周需要澄清和下周即将到期的依赖。不要把它开成进度汇报会，那是最常见的失败方式。

3. 一百人以上或跨部门项目：必须工具化，且优先私有化部署

到了一百人以上的规模，依赖数量、参与角色和变更频率都会超过人工维护的极限。此时必须用项目管理平台承载依赖模型，让关键路径自动计算、依赖逾期自动升级、变更影响自动传导。

选型时我会优先看三件事：能不能原生支持 FS / SS / FF / SF 四种依赖类型，而不是用负滞后凑；能不能做私有化部署，尤其是制造、金融、医疗这类数据敏感行业；能不能从现有工具平滑迁移，避免历史数据成为沉没成本。

这也是前面那家制造企业最终选择 PingCode 的原因，它面向中大型企业和百人以上组织，私有化部署能力和迁移路径都比较明确，落地时不需要把原有工作方式全部推倒。

4. 强监管行业：把依赖数据纳入审计范围

金融、医疗、能源、政务类项目，依赖管理不只是效率问题，还是合规问题。建议把关键依赖的澄清记录、变更记录、逾期升级记录全部留存，作为项目审计材料的一部分。

这类场景对工具的要求会更苛刻：需要完整的操作日志、需要权限分级、需要数据不出内网。私有化部署在这种情况下不是加分项，而是准入门槛。

七、不同情况下的取舍

1. 建模粒度 vs 维护成本

粒度越细，风险看得越清楚；但每增加一条依赖，就多一份澄清、跟踪、变更的成本。我的一般原则是：只对关键路径上的依赖和跨部门依赖做精细建模，其余依赖用里程碑对齐即可。

一个可用的量化参考是：依赖条目数控制在任务总数的 30% 到 50% 之间。超过 60% 通常意味着你在把软依赖和偏好依赖也塞进去了。

2. 甘特图 vs 看板

这不是二选一的问题，而是场景不同。甘特图适合排期阶段和窗口谈判，因为它能直观表达时间关系和缓冲；看板适合执行阶段，因为它能直观表达流动和阻塞。

我的建议是两者并存，但明确各自的职责边界。用甘特图定依赖和关键路径，用看板跑日常执行，不要在甘特图上追每日进度，也不要在看板上谈三个月后的窗口。

3. 强依赖冻结 vs 快速迭代

依赖一旦冻结，排期就稳定，但响应变化的能力下降；依赖保持柔性，响应快，但计划的可信度下降。取舍的关键不是选哪一边，而是明确“哪些依赖绝对冻结、哪些随时可谈”。

我的做法是把依赖分成冻结区和协商区。冻结区通常是硬逻辑依赖和外部承诺相关的依赖，一旦确定不再变更，变更需走正式审批；协商区放软依赖，由团队内部自行协调。

4. 工具化 vs 人工协调

工具能解决“看得见”和“算得准”，但解决不了“推动力”。人工协调能解决推动力，但规模一上来就会漏。比较务实的组合是：工具负责发现和升级，人负责谈判和决策。

具体来说，让系统自动识别逾期依赖并升级，把人的精力从“找问题”转移到“谈方案”，这才是工具化真正的价值所在。

5. 迁移成本 vs 长期可控性

换工具是有成本的，历史数据、工作流、团队习惯都要重建。但如果现有工具无法原生表达 SF 这类依赖，长期付出的代价会更高。判断标准是：这个工具的能力缺口，是不是你未来三年一定会频繁遇到的场景。

如果答案是肯定的，那迁移成本就是一次性投入。如果只是偶发场景，用变通方案撑一撑也合理。对中大型组织来说，支持从主流工具平滑迁移的能力，往往能把这个决策的门槛显著降低。

八、落地清单：拿来即用的四张表

1. 任务依赖识别清单（10 项）

用途：在排期评审前，逐条核对是否遗漏了关键依赖。建议由项目经理和执行骨干各过一遍，交叉比对差异。每一条勾选的标准是“能在系统里指出具体任务”，而不是“感觉有”。

1. 是否存在旧系统、旧流程、旧供应商的退役或下线任务？如果有，是否已标注为 SF？
2. 是否存在值班、班次、责任移交类任务？如果有，交接的完成是否依赖接班人已到岗？
3. 是否存在归档、审计、合规留痕类任务？旧归档流程是否在新体系开始接收数据之前就被关闭？
4. 是否存在跨部门的审批、评审、签字环节？责任人是否明确到具体的人？
5. 是否存在共享资源（测试环境、机位、设备、专家）被多个任务同时占用？
6. 是否存在“等对方先动我才好收尾”的任务？这类任务大概率是 FF 或 SF，不是 FS。
7. 是否存在外部承诺日期（交付给客户、对上汇报、对监管报送）？其上游依赖是否已全部识别？
8. 是否存在历史惯例型依赖？能否指出其物理必然性？指不出就应该被挑战。
9. 是否存在负滞后量？如果有，是否可以用正确的依赖类型替代？
10. 关键路径是否唯一？如果网络图里找不到唯一关键路径，依赖可能连得过密。

2. 依赖风险评估清单（8 项）

用途：对识别出的依赖做风险定价，决定资源投放优先级。每一条给出是 / 否判断，勾选“是”的条目即进入重点跟踪。

1. 这条依赖是否在关键路径上？
2. 这条依赖是否跨越两个以上的部门或供应商？
3. 这条依赖的 owner 是否明确且唯一？
4. 这条依赖的澄清截止日是否在两周以内？
5. 这条依赖是否涉及外部合同、许可证或监管约束？
6. 这条依赖失效时，是否有明确的 fallback 方案？
7. 这条依赖的前置任务历史上是否有延期记录？
8. 这条依赖滞后是否会触发对外承诺违约？

3. 跨部门依赖协调清单（6 项）

用途：跨部门依赖是最容易失控的一类，这张表用于协调会前的准备和会后的跟踪。

1. 依赖的双方接口人是否都已明确，且双方都知情？
2. 依赖的交付物是否有可验证的验收标准，而不是“差不多就行”？
3. 依赖的时间承诺是否有双方主管确认，而不只是执行层口头承诺？
4. 是否设置了升级路径？当双方谈不拢时，谁来决策？
5. 依赖的变更是否需要重新评审，而不是单方面通知？
6. 依赖关闭后，是否双方都做了书面确认？

4. 依赖管理周检查清单（5 项）

用途：固定在每周项目例会的最后十分钟执行，不需要额外开会。

1. 本周是否有依赖逾期？逾期原因是否已归类（没识别 / 没主人 / 没推动 / 客观变化）？
2. 未来两周内即将到期的依赖，是否都已澄清？
3. 是否有新的依赖被识别出来，需要补录进模型？
4. 是否有依赖的 owner 需要变更？
5. 关键路径是否发生了变化？如果变了，原因是什么？

九、常见问题解答

1. 拿到一条依赖，怎么一眼分清是 SF 还是 FS？

问一句就够了：后续任务做完之后，前置的那件事还需要继续存在吗？如果答案是“不需要了，可以退场了”，那它就是 SF，因为后续任务的完成等于前置载体的终止。如果答案是“还得继续”，那就是标准的 FS。

再给一个更实用的判断法：看后续任务是不是“退役、下线、归档、移交、清理”这类词。是的话，先按 SF 假设，再验证，比默认按 FS 处理安全得多。

2. SF 会不会造成循环依赖？

会，而且这是它最容易出问题的地方。典型循环是：A 开始 → B 完成（SF），同时 B 完成 → A 开始（FS）。两条依赖一叠加，A 和 B 就互相锁死了。建模时必须做一次环路检查，任何形成闭环的依赖组合都要立即拆解。

实操上，我会在依赖评审时专门花五分钟看环路，尤其是 SF 和 FS 混用的地方。工具如果支持关键路径自动计算，通常也能提示环路，但不要完全依赖工具的自动提示，人工过一遍更稳。

3. 远程或分布式团队怎么管任务依赖？

远程环境下，依赖管理的核心矛盾从“看不见”变成“异步沟通延迟”。补偿手段是三件事：时间盒更短、书面化程度更高、升级路径更明确。

具体做法：把依赖澄清周期从两周压到一周；所有依赖的口头沟通必须在二十四小时内转为书面记录；升级路径写进项目章程，不要指望临时找人拍板。时区跨度大的团队，还要额外预留一天的异步沟通缓冲。

4. 依赖管理工具应该怎么选？

我会按四条硬标准筛：第一，能不能原生支持四种依赖类型，而不是让你用负滞后变通；第二，能不能自动计算关键路径并做变更传导，否则依赖改了你也不知道影响谁；第三，能不能私有化部署，数据敏感行业基本是必选项；第四，能不能从现有工具平滑迁移，直接决定落地阻力大小。

对一百人以上的中大型组织来说，第四点尤其容易被低估。历史数据和既有工作流是真实资产，迁移路径顺不顺，往往决定这个工具是三个月后落地还是三个月后废弃。

5. 团队里没有专职项目经理，这套东西还能跑吗？

能跑，但要做减法。没有专职项目经理的团队，建议只保留两件事：依赖三问和每周十分钟的逾期检查。不要一开始就上完整的依赖模型和风险清单，那会变成没人维护的文档。

等到团队规模超过五十人，或者开始有跨部门协作，再考虑引入登记册和工具化。节奏很重要，工具和流程超配，比缺配更容易失败。

十、结语：把依赖从风险变量变成设计参数

回到开头那个 ERP 项目的死锁。它最后的解法其实很简单：把两条错误的 FS 改成一条正确的 SF，再补上一条回滚路径，同时把旧系统的许可证到期日写进模型作为硬约束。改完之后，甘特图只动了两条线，但整个项目从“随时可能卡死”变成了“知道卡在哪里、也知道卡住之后怎么办”。

这就是依赖管理的价值所在。它不让你变快，它让你知道自己有多慢、为什么慢、慢在哪里。而这一点，恰恰是大多数延期项目最缺的东西。

关于本文讨论的 SF，我想留下三个可以马上带走的判断：第一，SF 约束的是资源释放而不是交付物传递，看到退役、移交、归档类任务就要提高警惕；第二，SF 的出现频率只有几个百分点，但误用率超过六成，它值得你专门花时间识别；第三，一条依赖如果没有唯一 owner，它的默认结局就是逾期，这跟它写得对不对没有关系。

接下来你可以做三件小事。第一件，打开你现在手上的项目计划，找出所有“退役、下线、归档、移交”类任务，检查它们的依赖类型是否正确，这一步大概只需要半小时。第二件，随机抽十条依赖，看有没有 owner，如果没有，今天就补上。第三件，把“依赖澄清截止日提前两周”写进下一次项目例会的议程，从下个迭代开始执行。

三件事做完，你的依赖管理就已经超过大多数团队了。剩下的，是把它变成习惯。