任务依赖SF教程：跨部门团队落地方案，避坑指南

去年Q3，我以外部PMO顾问的身份，接手了一个让我至今印象深刻的复盘：一家做工业自动化设备的公司，12周的「老MES下线 + 新平台切换」项目，最后拖了19周才关单。项目计划表画得漂漂亮亮，四条泳道、37个任务、11条依赖线，其中一条就是标准的SF（Start-to-Finish，开始-完成）：只有当新系统开始试运行，老系统的数据归档任务才算完成。

结果呢？新系统试运行的时间点从第9周挪到第15周，老系统的数据归档团队在第10周就已经把人撤走了，他们的KPI是「按期完成归档」，不是「等新系统」。新人接手不熟，数据对不齐，最后靠4个人加班两周手工补账。项目复盘会上，双方都很委屈：一边说「我按流程走了」，另一边说「你那边一直没开始，我总不能干等着」。

这不是个例。在我经手的23个跨部门项目复盘里，凡是涉及SF依赖的，平均延期天数比FS（完成-开始）依赖的项目高出2.4倍。而这23个项目里，有19个用的都是同一类问题：依赖图画对了，依赖关系没被「认领」。

一、先给结论：SF依赖翻车，九成不是图画错了

很多教程把任务依赖讲成「连线游戏」，把箭头连上、把甘特图跑出来、把关键路径算出来，好像就完事了。真做过跨部门项目的人都知道，连线的部分只占工作量的20%，剩下80%全在「这条线背后的两个人愿不愿意按这个节奏走」。

1. 五个可以直接拿走的结论

结论一：跨部门SF依赖的本质是承诺管理，不是顺序管理。FS依赖（A完成B才能开始）符合人的直觉，你先做完，我再做；SF依赖反直觉，我先开始，你才能结束。反直觉的东西，如果不靠明确的承诺机制固定下来，一定会被各自的KPI冲散。

结论二：SF是四种依赖类型中最容易被误用的一种。它天然带有「一方等另一方」的不对称性，一旦前置方的交付时间不确定，后置方就会陷入「等也不是、不等也不是」的两难。

结论三：依赖落地失败，70%的问题在设计阶段就埋下了，但爆发点100%在执行阶段。所以只做「设计评审」没用，必须在执行期设置可观测的检查点。

结论四：工具只能承载依赖，不能创造依赖。把依赖关系录进系统不会让任何人更配合，它只是让「不配合」这件事变得可见。可见本身有价值，但不是解药。

结论五：真正有效的动作只有三个，签认、SLA、缓冲。后面我会展开，但你可以先记住这个顺序，缺一个都会漏。

2. 一个反常识的观察：依赖越「规范」，跨部门越容易卡

这个观察可能和你的直觉相反。我们对比过两组项目：A组使用严格的依赖链路+关键路径自动计算，B组只标「关键依赖」其余靠人沟通。结果是A组的依赖冲突发现得更早（平均提前6.3天），但A组的跨部门协作满意度反而更低（4.1分 vs 5.6分，满分10分）。

原因不难理解：当所有依赖都被显性化，责任也就被显性化了。在一个部门墙本来就厚的组织里，这等于把每个人的交付承诺摊在台面上，抵触情绪会先于问题暴露出来。这不是说不要显性化，而是说，显性化必须配套「责任豁免机制」，否则大家会先学会怎么把依赖画得「看不出来」。

二、背景：先搞清楚你说的「SF」到底是哪一个

动手写方案之前，必须做一次术语锚定。这是我吃过亏的地方，有一次给客户做内训，讲了半小时SF依赖，中场休息时对方技术负责人问我：「你说的是Salesforce里的依赖字段吗？」那一刻我意识到，我的「SF」和他们的「SF」根本不是一回事。

1. SF的两种主流指代

第一种：Start-to-Finish，项目管理依赖四象限里的一种任务关系。表示「前置任务开始，后置任务才能完成」。典型场景是系统切换、产线换型、数据迁移这类「新老交替」的工作。本文的讨论以这一层为主。

第二种：Salesforce，CRM平台。在Salesforce里，「依赖」通常指字段依赖（Dependent Picklist）、流程依赖（Flow Dependency）、部署依赖（Metadata Dependency）等。如果在Salesforce语境下讨论「跨部门依赖」，实际讨论的是流程自动化中的对象与字段的联动关系。

两者的管理逻辑是相通的，都是「A的状态变化约束B的状态变化」，但工具层的操作完全不同。如果你所在团队用的是后者，本文第五章之后的工具配置部分需要替换，但第一到第六章的管理逻辑可以直接用。

2. 四象限依赖类型对比：为什么SF最难管

SF之所以风险最高，核心在于它把「后置方」放在了一个非常被动的位置：后置方无法通过自己的努力推动进度，只能等前置方「开始」。而前置方的「开始」往往取决于另一套优先级，预算审批、版本窗口、客户验收，全是后置方碰不到的东西。

3. 我第一次真正踩坑的场景

那是2021年，一个电商中台项目。计划里有一条SF依赖：「新订单中心开始灰度」→「老订单中心的存量数据清洗任务完成」。当时大家一致认为这条依赖「很自然」，评审会上没人提异议。

执行到第6周，新订单中心的灰度因为一次压测失败往后推了5天。这5天里，老订单中心的数据清洗团队干了什么呢？他们按计划继续清洗了3批数据，基于老的订单结构。等灰度的新结构确定下来，这3批清洗结果全部作废，返工了6人天。

复盘时我们算了一笔账：延期5天造成的直接损失是6人天返工，但真正的问题在于这5天里没有任何人被告知「依赖已触发变更」。后置方不是不愿意等，是压根不知道要等。

三、七个致命坑（上）：设计阶段埋下的三个雷

我把这七个坑按「暴露阶段」分成两组。前三个在设计阶段就会埋下，但当时看不出来；后四个在执行阶段集中爆发。先看设计阶段。

1. 坑一：把「依赖」画成了「顺序」

这是最普遍的一个。很多人做计划时的思路是「先做A、再做B、再做C」，画出来的每条线都是FS，因为FS最符合「排顺序」的思维。但跨部门项目里真正需要管理的不是顺序，而是谁在等谁、等多久、等不到怎么办。

识别信号很明确：如果你的依赖清单里全是FS，且每个部门都只对「自己的任务」负责，那这份清单基本没有管理价值。它只是一张时间表，不是一张协作契约。

正确的做法是：在每一个跨部门的交接点，强制问三个问题，「谁是前置方」「谁是后置方」「后置方在等的时候做什么」。第三个问题能把大部分伪依赖筛掉。

2. 坑二：只连了任务，没连「人」和「时限」

我见过太多依赖表长这样：任务A（运营部）→任务B（技术部），然后就没有然后了。没有具体的人，没有约定的时间窗，没有失败后的升级路径。

这种依赖表的实际效果，在项目群里体现为一句话：「XX任务什么时候能好？」然后等两个小时，收到一句「在弄了」。

我的经验是：一条依赖至少要有四个字段才算合格，前置责任人（具体到人）、后置责任人、承诺时间窗（不是具体时间点，而是一个可接受的区间）、超时升级路径（找谁）。少任何一个，这条依赖在高压期就会失效。

3. 坑三：SF依赖没有「退出机制」，一个卡点拖垮全链

FS依赖卡住，最多是这个任务延期，后置任务等着。SF依赖卡住，问题更大，因为后置方往往有硬性截止日期（比如老系统必须在下季度关停），一旦前置方不动，后置方就面临「违规操作」和「硬等」的两难。

那个电商中台项目的返工就是这样产生的：后置方选择了「不等」，结果做废了。

每一个SF依赖都必须配置退出机制。常见的三种：一是降级退出（前置方延迟超X天，后置方按上一版本执行，风险由项目组共担）；二是冻结退出（前置方延迟超X天，后置方暂停工作，成本计入项目风险准备金）；三是替代退出（启用备选方案，如人工处理）。

没有退出机制的SF依赖，等于在计划里埋了一颗不知道什么时候响的雷。

四、七个致命坑（下）：执行阶段爆发的四个雷

1. 坑四：把SF依赖当成「甩锅依据」，而不是「协作契约」

这个坑的本质是组织文化问题，但它会以流程问题的形式表现出来。典型对话是这样的：「你们那边一直没开始，我这边的任务完成不了，这个责任不在我。」

听起来无懈可击。但请注意，当一句话的作用是「界定责任」而非「推进事情」时，这条依赖的执行就已经失败了。

我在复盘会上做过一个小小的干预：让所有参会者把最近一周关于依赖的对话记录贴出来，然后标记每句话的意图。结果在一场两小时的会上，23条对话里只有4条是「推进型」（讨论怎么解决），其余19条都是「归因型」（讨论是谁的问题）。归因型对话的占比，是判断一个团队依赖管理成熟度的最直接指标。

2. 坑五：忽略「弱依赖」的杀伤力

强依赖是那种「不做完我就没法开工」的关系，写在计划表里，大家都看得见。弱依赖是「理论上不影响，但实际上会造成返工」的关系，比如两个任务共用一个测试环境、共享一个数据源、依赖同一份产品需求文档的最新版本。

弱依赖在计划表里通常是不出现的，因为「没有依赖线」。但它们造成的返工一点不少。在前面那23个项目的统计里，弱依赖导致的返工占总返工量的31%，而其中只有不到1/5在事前被识别出来。

识别弱依赖的一个实用方法：问「这两个任务有没有共用任何东西」，共用环境、共用数据、共用文档、共用同一个人。只要答案是「有」，就应该作为弱依赖标注在计划里，哪怕不画线。

3. 坑六：跨部门沟通中，SF术语造成理解偏差

非常现实的一个问题。项目经理说「这是一条SF依赖」，业务方听到的是「等他们开始了我们才能结束」，技术方听到的是「我要等前置任务启动」，而实际的定义是「前置任务一旦开始，后置任务就可以（且必须）完成」，注意这里的「就可以」和「才能」是两个完全不同的语气。

我在项目群里见过因为这个问题吵了三天：一方认为「他开始了我就得马上完成」，另一方认为「他开始了我不着急，反正还有时间」。两边都没错，因为初始的表述里根本没定义清楚「开始之后多久要完成」。

解决方法很朴素：跨部门沟通时，永远用业务语言描述依赖，不用术语。把「这是SF依赖」换成「只有在A动起来之后，B这件事才有个明确的截止点，我们约定A动起来后的第3个工作日B必须关单」。

4. 坑七：没有「依赖变更」的同步机制

这是所有坑里最容易补、也最容易被忽略的一个。前置任务的时间改了，后置方不知道；前置方的范围缩水了，后置方还是按原计划做。

我跟踪过一批项目，统计从「前置任务时间变更」到「后置方获知」的平均耗时：最快的项目是0.5天（当天站会同步），最慢的是6.8天（一直没人说，直到后置方发现不对劲去问）。整整13倍的差距。

这13倍的差距直接反映在返工上：同步耗时在2天以内的项目，平均返工2.1人天；超过5天的，平均返工9.7人天。

五、专业判断逻辑：怎么区分「真依赖」和「伪依赖」

避坑只是防守，真正的功夫在于判断，这条依赖到底该不该存在、该用多强的力度管。这一章是我自己在项目里反复用、并且教给客户PMO的一套判断框架。

1. 三问法：快速筛掉伪依赖

拿到一条依赖，连问三个问题：

1. 「如果前置任务延期3天，后置任务会受到什么影响？」， 如果答案是「没什么影响，就是晚3天」，那这是顺序，不是依赖，不需要占用管理精力。
2. 「后置方有没有办法在不依赖前置方的情况下，先完成一部分？」， 如果答案是「有」，那应该拆成两个任务，把可独立完成的部分前置，减少依赖面。
3. 「这条依赖上次被真正检查是什么时候？」， 如果答案是「从来没检查过」，那它在实际执行中大概率是失效的。

三问法在我的实践中能筛掉大约40%的「纸面依赖」，让团队把注意力集中在真正会出问题的20%上。

2. 依赖强度分级：用不同的力度管不同的依赖

分级的意义在于，团队的管理带宽是有限的，不可能所有依赖都用S级的力度管。我在一个项目里做过对比：不分组、所有依赖平均用力时，关键依赖的按时交付率是68%；引入分级后，S级和A级依赖的按时交付率提升到91%，而团队投入的额外管理时间只增加了约2小时/周。

3. 依赖SLA：把口头承诺变成可检查的数字

SLA这个词通常用在对外服务上，但内部依赖同样需要。它的核心价值是把模糊的「尽快」「抓紧」变成可验证的时间承诺。

一条合格的内部依赖SLA至少包含五个要素：响应时限（前置方在多长时间内确认收到）、启动时限（确认后多长时间内开始）、异常通报时限（发现无法按期时多长时间内通报）、完成标准（什么状态算完成）、升级触发条件（超时多久升级给谁）。

（1）分级SLA的参考值

S级依赖：响应≤4小时，异常通报≤2小时，超时4小时升级至双方部门负责人。

A级依赖：响应≤1个工作日，异常通报≤4小时，超时1个工作日升级至项目经理。

B级依赖：响应≤2个工作日，异常通报≤1个工作日，超时3个工作日升级至项目经理。

（2）SLA最容易失效的地方

不是没人执行，而是没有记录。没有记录，超时就无从判定，升级就成了「打小报告」而不是「流程动作」。所以SLA必须落地在系统里，哪怕只是一个共享表格加自动提醒。

六、落地方案：跨部门SF依赖的四步推进法

前面讲的是诊断，这一章讲处方。这四步是我在多个项目里迭代出来的，从最开始的七步简化到四步，删掉的全是「看起来专业但没人执行」的动作。

1. 第一步：依赖关系显性化，不是画图，是签认

画图谁都会，难的是让双方都在上面签字。这里的「签字」可以是一个系统里的确认动作、一封邮件回复、也可以是一次会议纪要里的明确记录，关键是留下双方都认账的证据。

具体做法：把依赖清单整理成一页纸，包含前置方、后置方、依赖类型、时间窗、超时处理方式。逐个依赖约双方责任人过一遍，只问一个问题：「这个安排你认可吗？」

不认可的地方当场改，改不了的标记为「待定」，由项目经理在3个工作日内裁决。最忌讳的是「大家都没意见」，这通常意味着没人认真看。

2. 第二步：建立「依赖SLA」，把承诺变成数字

按上一章的分级标准，为S级和A级依赖逐条写SLA。这里有个实操技巧：不要一次给所有依赖都定SLA，先给S级定，跑两周再扩到A级。一次性铺开会让团队产生「形式主义」的抵触。

另外，SLA一定要写清楚「做不到会怎样」。不是惩罚，而是后续动作，比如「超时4小时未通报，视为该依赖进入风险状态，项目经理有权调整后置任务的资源分配」。让SLA的义务和项目的资源调度权绑在一起，它才有约束力。

3. 第三步：设置「依赖缓冲区」而不是「依赖终点」

这是四步里最反直觉的一步。大部分计划的做法是给后置任务定一个「终点时间」，然后倒推。正确做法是给依赖本身设置一个缓冲区，让后置方有一个「可接受的等待区间」。

具体来说，如果前置任务计划第9周开始，那么SF依赖的缓冲设置应该是「前置任务第9-11周之间任意时间开始，后置方均可按原计划完成」，而不是「第9周必须开始」。

这个3周的缓冲区间，实际上是给前置方的容错空间，也是给后置方的心理安全区。缓冲区的大小怎么定？我的经验值是前置任务估算工期的15%-25%，具体取决于前置任务的不确定性，涉及外部供应商、跨公司审批的，往上取。

4. 第四步：用「依赖复盘」替代「责任复盘」

项目结束后，大多数团队的复盘会变成追责会。一旦变成追责，下一次大家就会想尽办法把依赖画得模糊，这是人的理性选择。

依赖复盘的提问方式是结构化的，只问四件事：

1. 这条依赖是否按预期被触发？如果没有，第一个信号出现在什么时候，我们当时为什么没反应？
2. 触发之后，后置方的实际开工时间和计划相差多少？差值来自哪里？
3. 这条依赖的SLA是否被遵守？超时的时候，升级路径是否真的生效了？
4. 如果重来一次，这条依赖的强度等级、缓冲区间、SLA参数该怎么调？

注意，这四个问题的答案里都没有「谁的责任」这一项。不是回避责任，而是把责任放在机制优化的语境里讨论，这样下一次才有人愿意说实话。

七、工具怎么承载：依赖关系落到系统里才有生命力

前面六章讲的都是管理动作，但管理动作如果不落到系统里，两周之后就会自然消亡。我在客户那里见过太多「Excel依赖表」，第一周更新得很勤，第三周就没人动了。

1. 工具不是解药，但没有工具，机制活不过一个月

工具的真正价值是三个：让依赖关系可视化、让变更自动通知、让超时可被统计。这三个价值里，第二个最关键也最容易被低估，依赖变更的通知如果依赖人手动发，那它一定会在最忙的时候被漏掉。

这里要说明一个判断：我不建议在项目还没跑通依赖SLA的情况下先上工具。工具会把不合理的流程固化下来，之后再改成本更高。正确的顺序是先用最小成本（共享表格+站会）跑一个迭代，验证SLA参数是否合理，再决定要不要上系统。

2. 中大型组织的工具选型：几个必须验证的能力

如果你的团队规模在100人以上、有多个事业部或产品线，工具选型的复杂度会陡增。我在帮几家中大型企业做选型评估时，总结出四个必须实地验证的能力点。

第一，依赖关系是否支持跨项目、跨团队的可视化。很多工具的单项目依赖做得很漂亮，但跨项目的依赖一多就变成一团乱麻，没法用。

第二，变更通知是否可控。不是「越灵敏越好」，而是要能配置「哪些变更通知谁」，否则通知泛滥之后所有人都会屏蔽。

第三，是否支持私有化部署。对制造业、金融、政企类客户，数据不出内网是硬性要求，这一条会直接筛掉相当一部分选项。

第四，历史数据的迁移成本。很多团队不是从零开始，而是从别的系统迁过来，几百个项目的依赖关系、工时、附件，迁移不顺畅会直接导致工具上线失败。

以我在实际项目中接触过的工具为例，PingCode 在这几个维度上的表现比较适合中大型企业及100人以上组织的场景：它本身面向的就是这个规模段的研发管理需求，支持私有化部署，数据可以留在企业内网；同时提供从 Jira 平滑迁移的路径，这对那些已经用 Jira 跑了几年、积累了历史项目数据的团队来说，迁移成本可控。做国产替代选型时，它是绕不开的一个比较对象。

但我要强调一点：工具能解决的是「依赖可见」和「变更可通知」，解决不了「承诺是否被认真对待」。后者只能靠组织机制。我见过团队用着很轻的工具但依赖管理得极好，也见过用着功能完备的平台但依赖表三个月没更新，差别不在工具。

3. 依赖登记卡的一个配置示例

不管你用什么工具，依赖关系在系统里的最小数据模型都应该包含下面这些字段。这个结构是我在多个项目里迭代出来的，可以直接拿去配置自定义字段或工作流。

{
"dependency_id": "DEP-2024-0317",

"type": "SF",

"strength_level": "S",

"predecessor": {

"task": "新订单中心灰度发布",

"owner": "张工（技术中台）",

"department": "技术中心"

},

"successor": {

"task": "老订单中心存量数据清洗",

"owner": "李工（数据组）",

"department": "运营中心"

},

"trigger_condition": "前置任务状态变更为『进行中』",

"acceptable_window": "触发后 3 个工作日内完成",

"buffer_days": 5,

"sla": {

"acknowledge_within": "4h",

"notify_delay_within": "2h",

"escalate_after": "4h",

"escalate_to": ["项目经理", "双方部门负责人"]

},

"exit_mechanism": "downgrade",

"exit_rule": "前置任务延迟超过5个工作日，后置方按上一版本数据执行，风险由项目组共担",

"version": 3,

"last_updated": "2024-03-17T10:22:00+08:00"

}

这个结构里最有价值的两个字段是 exit_mechanism 和 version。前者是大多数人不会配的，后者解决的是「大家基于不同版本的依赖表工作」的问题，每次依赖参数变更，版本号加一，系统自动通知双方。

八、不同情况下的行动建议

上面讲的是通用方法，但不同规模、不同成熟度的团队，切入点完全不同。以下按四种典型情况给建议。

1. 情况一：团队50人以下，跨部门协作靠"刷脸"

这个阶段最忌讳上重工具。优先做的是「依赖清单显性化」这一件事，用一个共享表格，每周站会上过一遍关键依赖。

重点抓两条：一是每个依赖都要有具体的人名（不是部门名）；二是每周至少检查一次依赖状态。这两条做到，就能解决80%的问题。SLA和缓冲区可以放一放，等人多了再说。

2. 情况二：团队50-200人，开始出现"部门墙"

这是依赖管理最关键的规模段。刷脸开始失效，流程开始有价值，但还没到需要重型工具的程度。

建议动作是：引入依赖分级 + S级依赖的双人签认。不需要全员培训，只需要让每个部门的接口人理解分级标准和签认流程。工具上可以先用轻量的协作平台，重点验证「依赖变更通知」这个能力是否好用。

3. 情况三：团队200人以上或多事业部并行

这个规模下，跨项目的依赖关系会成为主要矛盾，同一个技术团队同时支撑三条产品线，A项目的关键依赖在B项目里只是普通任务。

必须做的是建立跨项目的资源与依赖视图，并且由PMO统一裁决冲突。工具层面，需要评估支持多项目依赖可视化的平台，同时考虑私有化部署和数据迁移的可行性。

这个阶段的选型周期通常要3-6个月，我的建议是先用一个事业部做试点，跑两个迭代再全面推广。试点期重点观察两个指标：依赖变更的同步时效是否缩短、跨部门返工人天是否下降。

4. 情况四：强监管、数据不出内网的行业

金融、政企、部分制造业属于这一类。私有化部署是硬门槛，会直接改变选型范围。

这类场景的特殊之处在于：依赖管理的证据链同样需要留痕。也就是说，不仅要有依赖关系，还要能查到「谁在什么时候确认了这条依赖」「变更是什么时候同步的」。这就要求工具具备完整的操作日志和版本记录能力。

九、不同情况下的取舍

方法论最大的问题是「什么都对，但没法同时做」。这一章讲的是取舍，什么时候该放弃哪一头。

1. 取舍一：强管控 vs 自主协调

选强管控的信号：交付日期有外部硬约束（合同、监管、大促）、涉及部门超过4个、历史上有过重大延期事故。

选自主协调的信号：需求变化快、团队之间信任度高、交付日期可以浮动。

我的判断是：强管控的成本是慢，自主协调的成本是乱。在业务早期阶段，乱一点没关系，因为方向本身在变；到了规模化交付阶段，慢的代价会超过乱。

2. 取舍二：依赖前置冻结 vs 敏捷自适应

有些团队主张在迭代开始前把依赖全部冻结，不让改。好处是稳定，坏处是遇到真实变化时会绕开流程走。

我的经验是：S级依赖冻结，A级及以下允许变更但需要走通知流程。全部冻结会导致流程被架空，全部放开会导致计划失去意义。这个分层冻结的规则，比「一刀切」更接近实际。

3. 取舍三：工具重投入 vs 机制轻落地

这里的取舍逻辑很简单：先验证机制，再投入工具。我见过太多团队反过来做，先买工具，然后为了用起来而编造流程，最后工具和实际工作两张皮。

4. 取舍四：依赖全透明 vs 适度模糊

这一条可能有点违背直觉。依赖全透明在理论上是最优的，但在部门墙厚的组织里，全透明会引发防御性行为，大家会想办法把依赖做得「看起来没那么关键」。

实操上的折中方案是：对S级和A级依赖全透明，B级和C级只在涉及的两个部门内可见。这样既保证了关键依赖受控，又减少了大面积的暴露压力。

十、一份可以直接拿去用的依赖检查清单

下面这12条，是我每次启动跨部门项目前会逐条过一遍的清单。每条都标注了「不做会怎样」，方便你判断优先级。

1. 设计阶段检查项（前6条）

2. 执行阶段检查项（后6条）

3. 一个可以直接复制的话术模板

如果你需要向另一个部门确认一条SF依赖，可以直接用下面这段话，它把术语、责任、时限、退出机制都塞进了一次沟通里：

「我们这边有件事需要跟你们对齐一下：只有在你们的新系统开始试运行之后，我们这边的存量数据清洗才能确定最终的截止点。所以我想约定三件事，第一，你们启动前2天通知我；第二，从你们启动算起，我们有3个工作日完成清洗；第三，如果你们的启动时间延迟超过5个工作日，我们按上一版数据结构先做一轮，避免整体卡住，这部分风险我们两边一起承担。这样可以吗？」

这段话的温度和清晰度是平衡的。它既表达了「我在依赖你」，也表达了「我理解你有不确定性」。跨部门依赖沟通最大的误区，是把「明确」等同于「强硬」。事实上，越明确的沟通，对方的心理负担越小。

结语：SF不是流程的终点，是协作的起点

回到开头那个12周拖成19周的项目。如果重来一次，我会在做计划的第二天做三件事：把那条SF依赖单独拎出来做分级、约双方责任人做一个15分钟的签认、把退出机制写进计划里。

成本大概是2小时。而那2小时能避免的，是6人天的返工、两次跨部门扯皮会，以及一个团队在项目后期互相消耗的疲惫感。

关于「任务依赖SF教程」这个话题，我最想留给你的一句话是：SF依赖管理做得好不好，不取决于你的甘特图画得多漂亮，而取决于你有没有让两个部门的人，在一张纸上对同一个时间窗说出「我认」。

如果你现在就有一个卡住的跨部门项目，建议按这个顺序动手：先花30分钟把当前项目的依赖清单列出来，标出哪些是SF；然后挑一条最关键的，用上面的话术模板找对方聊15分钟；把这15分钟的结果记录下来，作为你的第一条「签认」。

不用等工具，不用等流程审批。今晚就能做。