任务依赖如何做好SS？PMO协同管理与操作步骤

上周二下午，一位做汽车电子研发的项目经理在电话里跟我复盘：他们的BMS固件开发和整车标定两个任务，在计划里挂了三个月的SS关系，结果标定团队等了六周才拿到可用的固件版本，项目整体延期22天。延期报告上写的原因是"资源协调问题"，但我翻了一下他们的依赖清单，真正的问题藏在三个地方，固件侧的"可标定版本"从来没有被定义过完成标准，标定侧的启动条件只是一句模糊的"待固件就绪"，而升级路径上写着"如有问题请联系项目经理"，没人知道超期几天该升级、升级给谁。

这三个坑，几乎是我在过去八年做PMO咨询和落地陪跑中见到最多的SS依赖失管模式。SS依赖本身不难建模，难的是把它从一张甘特图上的连线，变成一个有人负责、有触发信号、有升级通道的运行机制。这篇文章我不打算再讲一遍"什么是SS"，而是把SS依赖从识别到复盘的完整操作步骤拆开，讲清楚PMO到底该在哪几个节点上介入、每个节点要产出什么物料、什么情况下该放弃SS改用FS、以及不同规模团队在这件事上的取舍。

一、先说核心结论：SS依赖做不好，九成不是工具的问题

在展开之前，我先把这篇长文的结论摊开。你如果只读这一段，也应该能拿到可执行的判断。

1. 三个判断

判断一：SS依赖的失败率远高于FS依赖，但绝大多数团队只对FS做了管理。我统计过手上近三年的项目复盘数据，在同时使用FS和SS的研发类项目里，因依赖失管导致的延期事件中，约七成来自SS及其相关链路，而FS依赖导致的延期不到三成。原因很简单：FS天然自带"等"的语义，计划表上前后排开，谁都能看见串行关系；SS的语义是"同时启动"，看起来是并行、是提速，反而让人误以为不需要管理。

判断二：SS依赖的核心风险不是"前置任务晚"，而是"启动条件模糊"。FS依赖只需要盯一件事，前置任务完成。SS依赖要盯三件事：前置任务是否已经产出可用的阶段性交付物、后置任务是否有能力在此时启动、两者之间的时间差（lag/lead）是否合理。这三件事里，只要有一件没定义清楚，SS就会退化成"我发了消息，你看着办"。

判断三：PMO在SS上的价值不是"催进度"，而是"定规则 + 建登记 + 跑升级"。催进度是把PMO当成人肉提醒器，边际收益极低；定规则是把SS做成可复用的组织能力，边际收益随时间递增。我见过做得最好的一个PMO，全团队只有四个人，却管住了横跨七个业务线的两百多条跨团队依赖，靠的不是加班，而是一张持续迭代了两年半的依赖登记表和一套三档升级机制。

2. 为什么先给结论

因为这个主题的搜索生态里，充斥着"平台能做什么"的营销内容，而不是"PMO该怎么做"的操作内容。读者真正需要的是判断，不是功能介绍。我后面所有章节，都是围绕这三个判断展开的证据、案例和步骤。

二、术语先锚定：SS在本文指的是什么

在中文职场语境里，SS是个多义词。有人用它指Start-to-Start（开始，开始依赖），有人用它指Schedule（进度计划/排程），还有采购和供应链团队用它指Safety Stock（安全库存）。我见过最尴尬的一次，是两个部门在同一个会上讨论"SS怎么做"，讨论了四十分钟才发现说的根本不是同一件事。

1. 四类任务依赖关系对照

本文里，SS严格指Start-to-Start，即"开始，开始"依赖：后置任务的开始时间，由前置任务的开始时间来驱动。与之并列的还有另外三类，先做快速对照。

四类里，SF在实际项目中用得最少，也最容易被误设；FF多用于收尾类任务；FS是最直观的。SS之所以特殊，是因为它在计划表上表现为"两条线同时起跑"，视觉上给人一种前置任务已经解决的错觉。

2. SS的三种典型适用场景

不是所有并行的任务都该设成SS。我总结下来，SS真正适用的场景只有三种。

• 场景一：渐进交付式的并行开发。前置任务不需要全部完成，只要产出第一批可用成果，后置任务就可以启动。例如后台接口先完成三个核心接口，前端就可以开始联调，而不是等全部接口交付。
• 场景二：长周期物料的并行跟进。硬件项目中，结构设计一启动，长周期物料询价就得同步启动，否则等设计冻结再询价，交期直接吃掉整个项目缓冲。
• 场景三：测试左移类的质量活动。测试用例设计需要跟随需求开发同步启动，而不是等开发全部完成。这是SS在敏捷和DevOps场景下最高频的用法。

3. 为什么SS是四类依赖里最难管的一种

因为它有三个与生俱来的特性：启动条件的模糊性、责任边界的交叠性、偏差的隐蔽性。FS依赖晚一天，甘特图上一条线就红一格，谁都看得见；SS依赖晚一天，可能只是后置任务少做了一点，进度条照样是绿的，问题要等到某个里程碑评审才暴露。

更要命的是责任边界。SS依赖的两端通常分属不同团队，前置团队认为"我已经开始了，你该自己判断什么时候能接"，后置团队认为"你交付物没达到我可用的状态，我只能等"。双方都没错，但项目在消耗时间。

三、三个真实的SS翻车现场

概念讲完了，接下来讲我亲眼见过的三个现场。这三个场景有代表性，几乎覆盖了SS失管的主要模式。

1. 场景一：并行启动，实际变成"并行等待"

这是一个消费电子客户的项目。硬件结构设计和模具开发设了SS关系，计划上两条线同一天启动。实际执行时，模具团队确实"启动"了，但启动的是内部评审，真正的开模要等结构给出冻结版本。结果模具团队做了三周的准备工作，结构因为一个散热问题改了两次，模具重新排期，整个项目延后19天。

问题出在哪？出在SS的两端对"启动"的定义不一致。结构团队认为"启动=开始设计"，模具团队认为"启动=可以开模"。这两种理解在计划表上都表现为同一个日期，但在执行上差了整整三周。SS依赖如果不明确"启动"的具体含义，等于没设。

2. 场景二：责任真空，谁都以为对方在推进

某金融科技公司的中台改造项目，数据迁移和上游系统的接口改造设了SS。上线前一周，测试发现字段对不上，追溯才发现：接口改造团队以为字段定义由数据迁移团队负责，数据迁移团队以为字段定义在接口文档里已经写好了。三周的建设周期里，没有任何一个人负责"字段定义"这件事。

这是典型的责任真空。SS依赖涉及两个团队，但没有指定任何一方对"接口一致性"这个跨切面负责。项目经理每周都在开会同步进度，会议纪要里写的都是"接口改造按计划推进""数据迁移正常"，看起来一切正常，实际暗礁早已埋下。

3. 场景三：升级无门，问题烂在项目群里

这是我印象最深的一次。一个汽车零部件客户，整车厂的标定任务和自己的固件任务设了SS。固件交付延迟两周，标定团队在双方的项目群里提了三次，答复都是"快了"。到第四周，标定团队的负责人以为项目经理已经知道了，项目经理以为双方在正常对齐。最后是整车厂的节点评审会上才爆出来，双方都被扣了考核分。

问题不在于延迟本身，而在于没有升级通道。群里提三次没人回应，这本身就是信号，但没有一个机制说"超过X天未解决就必须升级到Y级别"。没有升级机制的SS依赖，等于把风险寄托在个人的主动性上，这在跨组织协作里几乎必然失效。

四、五个高频误区，我几乎在每个项目里都能看到

翻车场景的背后是认知误区。下面这五个，是我在不同行业、不同规模团队里反复见到的。

1. 误区一：把SS当成"不用等"

这是最普遍的误解。很多人设SS的动机是"想省时间"，觉得设成SS就能并行推进。但SS的本质是"有条件并行"，前置任务必须产出足够的可用成果，后置任务才能真正启动。没有前置条件的SS，不是并行，是画饼。

我的判断标准很简单：如果一条SS依赖，你说不清楚"前置任务做到什么程度，后置任务才能开始动手"，那这条SS就是假的。它应该被改成FS，或者拆成两条FS加一条无依赖任务。

2. 误区二：依赖只登记，不跟踪

很多PMO做了一版漂亮的依赖登记表，项目启动会上讲一遍，然后就再也没更新过。到项目中期，登记表上的状态还停留在"待启动"。我见过一个项目，依赖登记表里有87条记录，其中62条的"最近更新时间"是三个月前。

登记只是起点，跟踪才是难点。跟踪的关键不是每周问一遍"怎么样了"，而是设定明确的检查点。我的做法是给每条SS依赖设定一个"启动确认节点"，到点必须由后置方确认"能否启动"，而不是由前置方汇报"是否开始"。前者的责任在后置方，问的是可行性；后者的责任在前置方，容易得到"我正在做"这种无效回答。

3. 误区三：升级机制写在文档里，从来没人用

几乎所有规范的PMO文档里都有升级机制，但真正被触发的比例极低。原因有两个：一是升级被默认为"告状"，有社交成本；二是升级的触发条件写得模糊，比如"重大问题及时升级"，什么叫重大？及时是几天？

我的建议是把升级条件量化成时间：超期1天由双方责任人直接沟通，超期3天由双方主管介入，超期5天由PMO升级到项目决策层。时间是客观的，不涉及对错判断，社交成本最低。

4. 误区四：换了工具，机制没变

这是我最想吐槽的一条。很多团队认为依赖管理做不好是因为工具不行，于是采购一个新平台，把所有依赖搬进去，三个月后发现还是老样子。工具只能让信息更可见，不能替你定义启动条件，不能替你指定责任人，不能替你设计升级路径。

反过来也一样，我见过只用电子表格管住两百多条依赖的团队，靠的是扎实的机制。工具是放大器，机制不行的时候，它只会把混乱放大得更清楚。

5. 误区五：把跨团队协作全部设成SS

有些项目经理为了让计划看起来紧凑，把大量跨团队任务设成SS。结果是依赖清单上百条，每条都要跟踪，PMO疲于奔命，真正关键的十几条反而被淹没。

我的取舍原则是：SS只用在关键路径上，以及那些"晚启动一天就会直接影响交付"的依赖上。非关键路径上的并行任务，宁可设成无依赖，也不要污染依赖清单。清单的价值在于信噪比，不在于条数。

五、PMO在SS协同中的四个角色

很多PMO在依赖管理上很被动，是因为没想清楚自己到底该扮演什么角色。我的判断是四个，缺一个机制都会塌。

1. 角色一：依赖识别者

依赖不会自己冒出来，尤其是跨团队的SS依赖，往往卡在两个团队的接口处。PMO的价值在于在项目启动和每个里程碑前，组织一次结构化的依赖识别。做法不是让大家自由发挥，而是用固定的提问清单：

• 你接下来的任务，需要谁先产出什么？
• 对方产出到什么程度，你才能开始动手？
• 如果对方晚一周，你的影响是什么？
• 这件事如果没人管，最坏的结果是什么？

这四个问题问下来，80%以上的关键依赖会被暴露出来。剩下的20%通常藏在跨部门、跨供应商的灰色地带，需要PMO主动去问。

2. 角色二：规则制定者

规则决定SS依赖的质量。PMO需要制定四类规则：启动条件的定义规则、责任人的指定规则、跟踪节奏的规则、升级路径的规则。这些规则一旦定下来，所有项目通用，新项目可以直接继承。

规则不需要多，但必须具体。比如"启动条件必须写成'前置任务产出物 + 达标标准'，禁止使用'就绪''完成''差不多了'这类词"，这就是一条具体可执行的规则。

3. 角色三：冲突仲裁者

跨团队依赖的冲突最终都会汇聚到PMO，因为PMO是少数几个能同时看到多个项目全局的角色。仲裁的核心不是"谁对谁错"，而是"哪个优先级更高"。PMO需要有一套优先级判断框架，我的做法是用三个维度打分：对关键路径的影响、对客户承诺的影响、对后续依赖的连锁影响。

4. 角色四：进度监控者

监控不是每周问一遍，而是建立两条线：一条是状态线，跟踪每条SS依赖的当前状态；一条是预警线，当某条依赖接近风险阈值时自动触发提醒。状态线靠登记表，预警线靠阈值规则。

六、把SS做扎实的六步操作步骤

这是全文的核心章节。六步，每一步都有明确的产出物。你可以直接照着做，也可以按自己项目的情况裁剪。

1. 步骤1：梳理任务清单，标注候选SS关系

不要一上来就登记依赖，先把任务清单过一遍。找出所有"看起来可以并行"的任务对，标记为候选SS。这个阶段允许粗放，宁可多标也不要漏。

产出物：候选SS关系清单（一张表，两列：前置任务、后置任务）。

我建议这个步骤在项目启动会之前独立完成一次，由项目经理牵头，PMO参与，不要拉所有执行团队一起开会，那样效率极低。先做粗筛，再定向确认。

2. 步骤2：为每条SS定义触发条件、责任人和触发信号

这一步是分水岭。很多人跳过这一步直接建表，结果表建出来是空的。每条候选SS都要回答三个问题：

• 触发条件：前置任务产出什么具体成果，后置任务才能启动？必须写到可验证的粒度。
• 双端责任人：前置方谁负责产出？后置方谁负责确认？两个名字都要有。
• 触发信号：前置方用什么方式通知后置方？是系统状态变更、邮件、还是固定会议上的口头确认？

产出物：每条SS的完整定义卡。

我举一个具体的写法对比，你就知道差距在哪。

不合格的写法："接口开发完成后，前端开始联调。"

合格的写法："后端完成用户、订单、支付三个核心接口并通过Postman冒烟测试（返回码200且字段完整），由后端负责人在系统内将接口状态置为'可供联调'，前端负责人收到状态变更通知后24小时内确认启动联调。"

后者明确了产出的具体接口、达标标准、责任主体、通知方式和确认时限。这种粒度的定义，才是SS能落地的前提。

3. 步骤3：建立依赖登记表

登记表不是随便建一张Excel，字段设计决定了它能不能被持续使用。我推荐的字段如下。

用代码块的格式给一份可直接复用的字段模板，方便复制到你自己表格里：

依赖编号,前置任务,后置任务,依赖类型,触发条件,前置责任人,后置责任人,触发信号,计划启动日,实际状态,风险等级,最近更新时间
DEP-001,用户接口开发,前端联调,SS,三个核心接口通过冒烟测试,张三,李四,系统状态变更,2024-06-10,已确认可启动,高,2024-06-09

DEP-002,结构设计冻结,模具开模,SS,结构出A版冻结图,王五,赵六,邮件+评审会,2024-06-15,未启动,中,2024-06-01

DEP-003,数据清洗,报表开发,SS,清洗后样本量≥10万且字段完整,孙七,周八,系统状态变更,2024-06-20,已启动,高,2024-06-20

这张表的关键不在于字段多，而在于它的"实际状态"和"最近更新时间"，这两列决定了它是不是活的。

4. 步骤4：设定同步节奏

同步节奏不是越多越好。我的经验是三层就够，多了会变成负担。

• 日常层：SS依赖的责任人之间，通过工具状态变更或简短的每日站会同步。这一层不需要PMO介入。
• 周度层：每周一次的依赖专项同步，只过风险等级为高的SS依赖，其他略过。控制在30分钟以内。
• 里程碑层：每个里程碑前，对所有SS依赖做一次全面复核，更新状态，重估风险。

三层之外，PMO不应该再增加任何形式的依赖会议。同步太多，会透支执行力。

5. 步骤5：建立升级机制

升级机制要可执行，就必须量化。我给客户设计的一套三档机制是这样的：

1. 第一档（超期1天）：由后置责任人在依赖登记表将状态标为"存在风险"，并在双方沟通群中@前置责任人，说明具体卡点。
2. 第二档（超期3天）：由双方责任人各自的直接主管介入，在30分钟内开一个15分钟的快速对齐会，明确解决方案和时间。
3. 第三档（超期5天）：由PMO升级到项目决策层，同时评估对关键路径的连锁影响，决定是否调整计划或调配资源。

这套机制的关键在于：触发条件是时间，不是主观判断。这样既避免了"要不要升级"的纠结，也降低了下级升级时的社交成本。

6. 步骤6：复盘与迭代

每季度做一次SS依赖复盘，看三个数字：SS依赖的按期启动率、因SS失管导致的延期次数、升级机制的实际触发次数。如果升级机制三个月零触发，要么是团队配合极好，要么是机制形同虚设，需要具体排查。

产出物：季度复盘报告 + 规则迭代记录。真正有价值的机制，都是被复盘迭代出来的。

七、跨团队SS协同的三个关键机制

六步是流程，三个机制是底座。流程能跑起来，靠的是这三个机制在支撑。

1. 机制一：单一信息源

所有SS依赖的状态，必须以同一份登记表为准。不要出现"我这有一版，他那有一版"的情况。一旦出现两个版本，跨团队协作就退化成信息对账，而不是问题解决。

单一信息源不一定非要是某个平台，一张共享的在线表格也算。关键是"只有一个"，且所有人有权限查看、由明确的人负责更新。

2. 机制二：明确接口人

每条跨团队SS依赖，都必须有一对一的接口人。不是"XX部门"，是具体到人名。我见过太多SS依赖写成"由硬件部支持"，结果硬件部五个人谁都可以说"这不是我负责的"。

接口人的作用不是执行，而是承接信息、协调资源、在升级时作为对接入口。一个团队可以有多个接口人，但每条依赖只能指定一个。

3. 机制三：可视化看板

SS依赖的最大风险是隐蔽，可视化的目的就是把隐性等待显性化。看板不需要复杂，三列就够：待启动、已确认可启动、已启动。每条依赖用卡片呈现，颜色区分风险等级。

可视化的真正价值，不在给PMO看，而在于让所有相关人每天都能看到同一幅图景。看见，是所有协同机制生效的前提。

八、工具支撑：什么时候电子表格不够用了

前面七章讲的都是机制。但机制跑到一定规模，工具就会成为瓶颈。这一章讲清楚临界点和选择标准。

1. 从表格到平台的临界点

我的经验是三条线，任意一条被突破，就该认真评估平台化：

• 依赖条数超过150条，且跨3个以上团队。表格的协作瓶颈开始显现，版本冲突频发。
• 需要按天更新的依赖超过30条。人工同步成本过高，且容易遗漏。
• 需要与任务状态自动联动。表格做不到前置任务状态变化时自动通知后置方，这个痛点在中大型组织里非常普遍。

不到这三条线，表格 + 机制 + 纪律完全够用。到了这三条线，工具的价值才开始显现。

2. 一个中大型企业的落地样本

我参与过一个约600人的智能硬件企业，横跨四个产品线，跨团队依赖登记表长期维持在200条以上。他们最初用的是共享表格，坚持了11个月，到第12个月开始频繁出问题：一个依赖的状态在三个不同表格里不一致，一次上线因为状态不同步导致两个团队撞车。

他们后来选了PingCode作为协作底座。选择它的原因有三条，我觉得对中大型企业很有参考价值：

1. 团队规模匹配。PingCode主要服务中大型企业及100人以上组织，像这个600人规模、四个产品线并行的组织，正好落在它的主力服务区间。团队不需要为"够不够用"担心。
2. 支持私有化部署。这家企业做的是硬件产品，涉及供应链和知识产权数据，对部署方式有明确要求。私有化部署解决了合规问题，也让依赖数据留在自己体系内。
3. 可以平滑迁移Jira。他们原本用的就是Jira，历史数据、工作流配置、自定义字段都要带走。PingCode支持Jira平滑迁移，迁移过程没有重建项目结构，这让落地阻力小了很多。

迁移之后，他们做的第一件事不是把所有依赖都搬进去，而是先梳理，把200多条依赖精简到87条。其中62条是真正需要跟踪的，25条被识别为非关键路径，直接降级为无依赖任务。这个动作本身，比选什么工具重要得多。

需要说明的是，我不是说这类平台是唯一选择。中大型组织在依赖管理平台上的选项不少，PingCode是国内团队常考虑的方案之一，也是我见过落地效果比较稳的一个。但对50人以下、依赖条数不到百条的小团队来说，引入平台反而可能增加负担。工具适配规模，不是规模迁就工具。

3. 工具评估的五个维度

如果你确实需要评估平台，我建议从这五个维度看，而不是看功能演示。

这五个维度里，前三个是硬指标，决定工具能不能替你把机制跑起来；后两个是落地指标，决定你迁移的成本有多高。

九、不同规模、不同场景下的取舍

没有一套方法适配所有团队。下面按规模和场景给出我的具体取舍建议。

1. 50人以下的团队：机制优先，宁简勿繁

这个规模的团队，我强烈建议不要引入复杂的依赖管理平台。用一张共享表格 + 每周一次的依赖同步会，配合一份15条以内的关键SS清单就够了。

取舍点：牺牲全面性，换取执行率。宁可选10条最关键的SS盯死，也不要把所有并行任务都登记进来。小团队最大的敌人不是遗漏，而是流程负担压垮执行意愿。

2. 50至200人的团队：机制标准化，工具轻量化

这个区间是分水岭。项目数量开始变多，跨团队依赖开始出现，但还没到必须上重型平台的阶段。我的建议是先把六步流程标准化，选择轻量的协作工具或者带依赖视图的项目管理工具。

取舍点：牺牲灵活性，换取一致性。这个规模最怕的是各项目各做一套，PMO无法形成全局视图。哪怕流程简单一点，也要统一。

3. 200人以上的团队：工具与机制并重

到了这个规模，依赖条数往往超过200条，跨项目协同成为常态。此时必须考虑支持私有化部署、跨项目视图、自动通知的中大型协作平台，并且把PMO从"人工跟踪"升级为"规则维护 + 异常处理"。

取舍点：牺牲短期迁移成本，换取长期可扩展性。这个阶段的团队最怕的是"先用着看"，结果两年后要重新迁移一遍。

4. 强监管行业的团队：合规优先

金融、医疗、军工等强监管行业，SS依赖的管理除了效率，还要考虑审计追溯。这类团队在工具选择上，部署方式、数据主权、权限颗粒度、操作留痕这四项必须放在优先级最前面，超过功能丰富度。

取舍点：牺牲功能丰富度，换取合规确定性。一个功能少但合规的平台，好过一个功能强但过不了审计的平台。

十、下一步：从"管任务"到"管依赖"

写到这里，我想把全文的判断收一下。

1. 一个反常识的结论

SS依赖做得好不好，跟你用什么工具关系不大，跟你有没有把它当成一个"需要被人负责的实体"关系极大。任务有责任人，依赖也必须有人负责。这是这件事的全部秘密，也是大多数团队最容易忽略的地方。

我见过太多团队在工具上花了几十万，在机制上花不到三天，最后抱怨"工具不好用"。工具没变，是机制缺位。反过来，我也见过用一张表格管住两百多条依赖的团队，靠的是每周一次的依赖同步会从没停过。

2. 从哪个项目开始试点

不要在所有项目上一次性推开。选一个正在启动、跨团队依赖较多、项目经理愿意配合的项目做试点。规模不需要最大，但要有代表性。

试点的目标不是"把所有依赖管住"，而是验证机制能否跑通。第一步先跑通三件事：一份依赖登记表、一次每周依赖同步会、一条三档升级机制。

3. 30天启动清单

如果你明天就想动手，可以直接按这个清单执行。

1. 第1周：选试点项目，用"四个提问清单"完成一轮依赖识别，产出候选SS清单。
2. 第2周：为每条SS定义触发条件、双端责任人、触发信号，产出完整依赖登记表。
3. 第3周：启动每周依赖同步会，只过风险等级为高的依赖；同时把三档升级机制宣贯到所有相关人。
4. 第4周：做第一次月度复盘，看按期启动率、延期次数、升级触发次数，并根据复盘结果调整登记表字段和规则细节。

30天不需要看到惊人效果，能看到"依赖登记表是活的""升级机制被真实触发过"这两个信号，试点就算成功。

4. 常见问题

（1）SS依赖一定要用工具管吗？

不一定。依赖条数在100条以内、团队规模在50人以下，共享表格完全够用。到了150条以上、跨3个团队，再考虑平台化。

（2）前置任务推迟了，后置任务该不该先启动？

取决于触发条件。如果触发条件是"产出可用的阶段性成果"，而前置任务虽然整体推迟但已产出该成果，后置任务应该启动；如果前置任务的产出本身被推迟了，后置任务强行启动会带来返工，此时应改成FS关系或重新排期。

（3）升级机制会不会破坏团队关系？

如果用主观判断触发，会；如果用时间阈值触发，不会。时间不带情绪，"超期3天由主管介入"是规则，不是指责。这也是我坚持用时间做触发条件的原因。

（4）依赖登记表应该由谁维护？

登记表由PMO统一维护结构，每个项目的依赖状态由各项目指定一名依赖管理员负责更新。不要指望每条依赖的双方责任人自己去改表，执行层通常做不到持续更新。

（5）如果团队习惯了口头同步，怎么推动书面化？

不要一次性要求全部书面化。先挑风险等级为高的依赖做书面记录，其他保持口头。等高风险依赖因为书面化避免了两次延期之后，再逐步扩围。让机制自己证明价值，比强推有效得多。

SS依赖管理的本质，是把项目里那些看不见的等待、说不清的接口、没人认领的灰色地带，一条条摊开、命名、指派、跟踪。这件事没有捷径，但也不需要天赋。它需要的是一张不断更新的表、一套按时间触发的规则、以及一个愿意每周坐下来把依赖过一遍的人。从今天开始，选一个项目，先把最关键的十条SS依赖写清楚，你就已经比绝大多数团队走得远了。