任务依赖SF教程：产品经理风险控制，避坑指南

1. 任务依赖里的FS和SF到底有什么区别，产品经理需要分那么细吗？

我之前一直以为任务依赖只有‘前后顺序’这一种，直到有次排期时技术负责人问我这个接口是FS还是SF，我当场卡住了。后来复盘发现，如果把依赖类型搞混，关键路径就会算错，后面的排期全得推倒重来。

FS是Finish-to-Start，前序任务完成后后续任务才能开始，是最常见的依赖；SF是Start-to-Finish，后续任务的完成依赖于前序任务的启动，实际项目中极少用，主要出现在‘交接班’类场景，比如B班必须在A班开始后才能结束。

产品经理不需要背全四种类型，但必须能区分FS和SS（Start-to-Start，并行启动），因为这两种直接决定排期是串行还是并行。判断方法很简单：问团队‘这件事能不能在前一件事没做完时就开始’，能就是SS，不能就是FS。实际排期表里，把每个依赖标注成FS或SS，关键路径的误差能减少一半以上。

2. 排期时怎么快速找出哪些任务之间存在隐藏依赖？

我最怕的情况是排期会上大家都说没问题，结果执行到一半突然有人冒出来说‘我这个要等XX先做完’。这种隐藏依赖每次都能把关键路径打乱，但我又不可能把每个任务都问一遍，太耗时间了。

用‘依赖访谈三问’替代逐条追问：第一问‘这个任务启动前，必须有什么产出物或输入’，锁定上游交付物；第二问‘这个产出物由谁负责、什么时候能给’，锁定接口人和时间点；第三问‘如果这个产出物晚到三天，你的任务会怎样’，判断是硬依赖还是软依赖。

只对关键路径上的任务做这三问，非关键路径的任务用‘假设无依赖、延期再补’的策略。实际操作中，一个20人规模的版本迭代，关键路径通常只有5到8个任务，访谈时间控制在40分钟以内。访谈结果直接录入某项目管理工具的依赖字段，形成可追溯的依赖清单。

3. 跨团队依赖对方一直不安排接口人，每次都让我找不同的人问进度，怎么破？

我们版本上线前两周，我发现后端依赖的那个服务一直没人给明确排期，每次在群里问，不同的人回我‘我看看’‘这个不是我负责’，拖了一周都没结果。我又没有权限直接要求对方团队的人做事，感觉特别被动。

核心动作是把‘个人对个人’的追问升级为‘团队对团队’的约定。具体做法：第一步，在跨团队群里发一条结构化消息，写明‘我方任务A依赖贵方任务B，B的交付时间直接影响我方上线日期X，请指定一位接口人负责B的进度同步和风险上报’；

第二步，如果24小时内无人认领，直接升级到双方共同上级，用‘风险上报’而非‘催进度’的口径，说明不指定接口人将导致的上线延期后果；第三步，接口人确定后，约定固定的同步节奏，比如每周二、四各同步一次，同步内容只写‘已完成/进行中/阻塞’三态。

判断依据：跨团队依赖如果没有明确接口人，延期概率会成倍上升，因为责任分散等于无人负责。

4. 依赖方延期已经发生了，除了等之外产品经理还能做什么？

上个月上游团队的接口延期了五天，我当时觉得除了等没别的办法，结果整个联调窗口被压缩到只剩两天，测试根本跑不完。事后我想，如果当时有Plan B，是不是不至于这么被动。

延期发生后，按‘降级、替代、并行’三条路快速评估。降级方案：砍掉依赖该接口的非核心功能，先用Mock数据跑通主流程，把联调拆成‘先通主链路、后补边缘逻辑’；替代方案：找是否有其他团队或个人能提供临时接口，哪怕性能差一点、字段少几个，先让下游动起来；

并行方案：把原本依赖该接口才能开始的测试用例提前，用录制的历史数据先跑回归。判断依据是‘延期天数vs关键路径浮动时间’：如果延期天数小于浮动时间，不动排期只加监控；如果大于浮动时间，必须在24小时内启动至少一条Plan B，并同步给所有下游。

向上汇报时用‘影响面+已启动的补救动作+需要的支持’三句话，而不是只报‘延期了’。

5. 怎么判断一条依赖关系是不是关键路径，值不值得花时间去管？

我们项目任务列表里有几十条依赖，我不可能每条都盯。上次我把精力花在了一个无关紧要的依赖上，结果真正卡住上线的那条反而没注意到，被老板问得哑口无言。

用‘浮动时间’做筛子：先算出每条依赖链上任务的最晚开始时间和最早开始时间，两者之差就是浮动时间。浮动时间为零或负数的依赖就是关键路径，必须管；浮动时间大于三天的，只需要记录、不需要高频跟踪。

具体操作：在某项目管理平台里标出所有FS依赖，按‘下游任务截止日期减上游任务承诺交付日期’估算缓冲，缓冲小于等于两天的标记为红色，两到五天的标记为黄色，五天以上的标记为绿色。每周只重点看红色依赖，黄色依赖在周会上过一遍，绿色依赖月度过一次。

一个典型版本迭代里，红色依赖通常不超过5条，这样精力就能集中在真正影响上线的事情上。

6. 需求变更后，怎么确保所有下游依赖方都同步到了？

有次需求变更我只通知了自己团队的人，结果下游团队按旧方案做了三天，白干。后来复盘发现，我根本不知道到底有哪些团队依赖我这边的产出，也没有一个变更同步的标准动作。

先建立‘依赖地图’再谈同步。变更发生前，就应该维护一张双向依赖表：我依赖谁、谁依赖我，每条依赖都写明交付物名称、接口人、约定时间。变更发生时，执行‘变更影响分析清单’三步：第一步，列出本次变更涉及的所有交付物；第二步，在依赖表里反向查出所有依赖这些交付物的下游任务和接口人；

第三步，用固定格式通知，格式为‘变更内容+对交付物的影响+新的交付时间+需要下游确认的动作’，要求对方在四小时内回复‘收到并确认’或‘有疑问’。判断依据：没有依赖地图的变更同步，覆盖率通常不到六成，而有了地图和确认机制，覆盖率能提到九成以上。

7. 关键依赖没有Plan B，上级又不同意加资源，怎么办？

我之前遇到一个关键依赖，对方团队明确说排期满了，我向上级申请加人协调，上级说‘你自己想办法’。那一刻我觉得既没有资源又没有退路，只能硬扛。

把问题从‘要资源’翻译成‘选风险’。做法：准备一张A/B/C方案对比表，A方案是维持现状，标注延期概率和预计延期天数；B方案是加一个兼职人力，标注需要谁、投入多少工时、能降低多少延期概率；C方案是降级交付，标注砍掉哪些功能、用户体验损失是什么。

带着这张表找上级，不是问‘能不能加人’，而是问‘如果必须保上线日期，你选哪个风险’。判断依据：上级拒绝加资源，往往是因为没看到清晰的取舍，而不是真的没有资源。如果三个方案都被否，就书面记录风险‘已知悉并接受’，并设定一个触发点，比如‘如果X月X日对方仍未交付，则自动切换到降级方案’，避免无限期等待。

8. 产品经理做依赖管理，有没有一份可以每次排期前过一遍的自查清单？

我每次排期都感觉漏了点什么，但事后才能发现。我想要一份简单的清单，排期前花五分钟过一遍，就能把大部分依赖坑挡在前面，不用每次都靠踩坑长记性。

排期前过这八条：一、所有关键路径任务是否都标注了依赖类型（FS或SS）；二、每条跨团队依赖是否都有明确接口人和承诺交付日期；三、是否完成了关键路径任务的‘依赖访谈三问’；四、关键依赖的浮动时间是否算过，红色依赖是否不超过五条；五、是否维护了双向依赖表（我依赖谁、谁依赖我）；

变更同步机制是否就位，通知格式和确认时限是否约定；七、每条红色依赖是否至少有一条Plan B；八、是否设定了依赖延期的触发点和自动切换规则。这八条全部打勾再发排期，遗漏率能降到很低。建议把清单存成模板，每次排期前复制一份当场过，不要凭记忆。

9. 任务依赖管理里，产品经理最容易忽略的‘软依赖’是什么？

我一直以为依赖就是‘A做完B才能做’，直到有次上线后发现，虽然技术依赖都满足了，但运营的推广素材还没准备好，因为没人告诉运营这个功能到底什么时候上。这种‘软依赖’好像没人专门管。

软依赖指的是不体现在任务列表里、但实际影响交付的依赖，最典型的三类：信息依赖（下游需要知道上游的准确交付时间才能安排自己的工作）、决策依赖（下游需要上游确认某个方案才能动工）、资源依赖（下游需要上游释放某个人或某台机器）。产品经理的盲区通常在于只盯技术依赖，忽略信息和决策依赖。

做法：在排期表里加一列‘依赖类型’，除了‘技术’外，手动标注‘信息’和‘决策’，并写明‘下游需要什么信息、什么时候需要、由谁提供’。判断依据：软依赖的延期往往不报错、不阻塞，但会在上线前一周集中爆发，比如素材没做、文案没审、客服没培训。把这些写进依赖表，比事后救火省力得多。

10. 用某项目管理工具管理任务依赖，哪些字段和视图是必须配置的？

我们团队用某项目管理工具，但依赖关系全靠大家在评论里说，没人真的去配依赖字段。我想推动团队把依赖管理规范化，但又不想搞得太复杂，怕大家抵触。

必须配置的字段只有四个：前置任务、依赖类型、承诺交付日期、接口人。前置任务用工具自带的关系字段关联，依赖类型下拉选FS或SS，承诺交付日期填死时间而不是‘本周’，接口人填具体姓名而非团队名。必须打开的视图有两个：一个是按‘承诺交付日期’排序的列表视图，用来每周过红色依赖；

一个是按‘接口人’分组的看板视图，用来在跨团队同步时快速定位每条依赖的责任人。判断依据：字段超过六个，团队填写率会明显下降；字段少于四个，依赖信息就不完整，没法做关键路径分析。推动时先在一个版本迭代里试点，只要求关键路径任务填写，跑通一个迭代后再全面推广，抵触会小很多。

11. 依赖方总是口头承诺‘下周给’，但从来没有准时过，怎么把承诺变成可追踪的？

我遇到过最崩溃的情况是，对方每次都说‘下周肯定给’，结果连续三周都没交付，而且因为没有书面记录，我连追溯都没法追溯。后来我学乖了，但不知道具体该怎么操作才不显得咄咄逼人。

把口头承诺转成‘书面确认+触发条件’。做法：每次对方口头承诺后，在跨团队群里发一条确认消息，格式为‘确认一下，B任务的交付时间是X月X日，交付物是Y，如果X月X日未交付，我方将启动Z方案，请确认’。这条消息的作用不是施压，而是把模糊承诺变成有日期、有交付物、有后果的明确约定。

同时在某项目管理工具里把B任务的截止日期设为X月X日，并设置提前两天的提醒。判断依据：口头承诺的准时率通常很低，因为说的人没有记录压力；书面确认加自动提醒后，准时率能明显提升。如果对方连书面确认都不回，这本身就是风险信号，应该立即升级，而不是继续等。

12. 版本上线前三天才发现依赖没交付，最后三天还能做什么补救？

我经历过一次上线前三天发现上游接口没交付，当时整个人都懵了，觉得只能延期。但老板说‘先别急着延期，看看还能救什么’，那次之后我才知道最后三天其实还有操作空间。

最后三天按优先级做四件事：第一，当天立刻和依赖方确认最小可用交付物是什么，不要追求完整功能，只要能让主流程跑通就行，比如接口只支持一个核心字段；第二，把测试范围从‘全量回归’压缩到‘主链路冒烟’，列出必须有依赖才能测的用例和可以用Mock替代的用例，先跑后者；

第三，准备一个对外口径，如果最终确实要延期，明确延期几天、影响哪些用户、补偿方案是什么，提前和客服、运营对齐；第四，设定一个硬截止时间，比如上线前一天中午，如果依赖仍未交付就自动切换延期方案，避免最后时刻仓促上线。

判断依据：最后三天的核心不是‘能不能救’，而是‘救到什么程度可以接受’，把补救动作和底线提前说清楚，比临时慌乱有效得多。

13. 任务依赖管理做得好的团队，和做得差的团队，最明显的区别是什么？

我换过两个团队，一个团队排期时大家都会主动说‘我依赖谁’，另一个团队永远是我去追着问。我想知道这种差异到底出在哪，是工具问题还是流程问题，还是人的问题。

最明显的区别不是工具，而是‘依赖是否被当作一等公民’。做得好的团队，依赖关系和任务本身平级，每个任务创建时就要求填写前置任务和接口人，没有依赖信息的任务不允许进入排期；做得差的团队，依赖是事后补的，甚至只存在PM脑子里。

第二个区别是‘延期是否被提前预警’，好的团队在承诺交付日期前两天就会主动同步风险，差的团队到了截止日才说做不完。第三个区别是‘变更是否有反向通知’，好的团队变更时会主动查‘谁依赖我’并逐一通知，差的团队只通知自己人。

判断依据：这三个区别和团队规模、工具选型关系不大，主要取决于PM有没有把依赖管理变成排期流程里的固定动作，而不是靠个人记性。

14. 如果团队里没人愿意配依赖关系，产品经理怎么用最小成本推动？

我们团队对流程工具很抵触，一说要填依赖字段就有人说‘浪费时间’。我不想因为这个和团队起冲突，但又确实需要依赖信息来排期。

用‘最小可行动作’替代‘全面推行’。第一步，只要求关键路径上的任务配依赖，非关键路径不强制，这样需要填写依赖的任务从几十条降到五到八条；第二步，PM自己先配好，然后在排期会上展示‘因为配了依赖，我们提前发现了两个隐藏风险’，用结果说服而不是用流程压人；

第三步，把依赖信息的使用场景限定在周会同步和风险上报，不让团队觉得填了没人看；第四步，一个迭代后复盘，对比配依赖前后的延期次数和救火次数，用数据决定是否扩大范围。判断依据：团队抵触的通常不是依赖管理本身，而是‘填了没用’的流程负担，只要让填写者看到依赖信息真的帮他们减少了被动追问，接受度会自然提升。

15. 依赖管理中的‘浮动时间’到底怎么算，能不能给一个具体例子？

我看过很多讲关键路径的文章，但一到自己项目里就不会算浮动时间了，因为任务时间都是估算的，感觉算出来也不准。我想知道有没有一个粗糙但能用的算法。

用一个简化算法就够用：浮动时间约等于下游任务的最晚开始时间减去上游任务的承诺交付时间。举个例子，下游任务D最晚必须在10号开始，上游任务U承诺5号交付，那浮动时间就是5天；如果U承诺9号交付，浮动时间就是1天；如果U承诺11号，浮动时间就是负1天，说明已经晚了。

实际操作中不需要精确到小时，按天估算即可，因为依赖管理的目的是排优先级，不是做数学题。判断依据：浮动时间大于三天的依赖标绿，两到五天标黄，小于等于两天标红，红色依赖必须每周跟踪并准备Plan B。这个粗糙算法在一个20到30个任务的版本迭代里，误差通常在一到两天以内，足够支撑排期决策。

16. 跨团队依赖的接口人换人了，怎么避免信息断层？

我们项目进行到一半，对方团队的接口人离职了，新来的人完全不知道之前的承诺，导致我们以为在正常推进的事情其实已经停了。这种信息断层怎么提前防？

在依赖表里加一个‘备份接口人’字段，要求每条跨团队依赖至少填两个人。接口人变更时，执行三步交接：第一步，原接口人在群里发一条交接消息，写明当前依赖的交付状态、承诺日期、已完成部分和待办部分；第二步，新接口人回复确认并复述关键时间点，确保信息对齐；

第三步，PM把依赖表里的接口人字段更新，并在下一次跨团队同步会上让新接口人过一遍所有相关依赖。判断依据：单接口人的跨团队依赖，在人员变动时断层概率很高，而加了备份接口人后，即使主接口人临时请假或离职，信息也有第二个人兜底。备份接口人不需要做具体工作，只需要知道这件事的存在和关键时间点。

17. 产品经理在依赖管理上花多少时间算合理，怎么避免过度管理？

我有段时间每天花一两个小时追依赖进度，结果自己的需求文档反而没时间写。我想知道依赖管理的投入产出比怎么把握，什么时候该收手。

按项目阶段分配时间：排期阶段投入最多，大约占排期总时间的百分之二十到三十，用于依赖访谈和依赖表建立；执行阶段每周固定一次，三十分钟以内，只过红色依赖；上线前一周增加到每天十五分钟，只确认关键依赖是否就绪。判断依据：依赖管理的目的是减少意外，而不是消灭所有不确定性。

如果每周花在依赖跟踪上的时间超过两小时，通常说明要么红色依赖太多（排期本身有问题），要么接口人机制没起作用（你在替别人盯进度）。这时候应该回头修排期或升级接口人问题，而不是继续加时间追进度。一个健康的版本迭代，PM花在依赖管理上的总时间应该控制在整个项目工作量的百分之五以内。

18. 有没有一句话能概括产品经理做依赖管理的核心原则？

我看了很多依赖管理的方法论，但总觉得记不住。我想要一句话，在排期、执行、复盘时都能拿出来提醒自己，不用翻笔记。

核心原则是：让每一条依赖都有名字、有日期、有人负责、有退路。有名字是指依赖的交付物要具体到‘什么接口’或‘什么文档’，不能只写‘等后端’；有日期是指承诺交付时间要写到天，不能写‘下周’；有人负责是指每条依赖都有明确的接口人，而不是一个团队名；有退路是指关键依赖至少有一条Plan B。

判断依据：依赖管理出问题，几乎都能归到这四个缺失中的某一个，交付物模糊、时间模糊、责任模糊、没有退路。排期前用这四个词过一遍关键依赖，执行中每周用这四个词检查红色依赖，就能挡住大部分依赖坑。

19. 依赖方延期后，怎么向上汇报才不会被当成‘甩锅’？

上次依赖方延期，我向上级汇报时说了很多对方的问题，结果上级觉得我在推卸责任。后来我意识到，汇报方式可能比延期本身更重要，但我不知道该怎么说才既客观又不显得在甩锅。

汇报结构用‘事实+影响+动作+需要支持’四段，而不是‘谁的错+为什么’。事实部分只写客观信息，比如‘B任务承诺X日交付，截至X日未交付’；影响部分写清楚对上线日期、用户、其他任务的具体影响，比如‘联调窗口压缩三天，测试覆盖率预计下降百分之二十’；

动作部分写你已经做了什么，比如‘已启动Mock方案，主流程可先跑通’；需要支持部分写你需要的具体帮助，比如‘需要上级协调对方团队在X日前给出最小可用版本’。判断依据：上级关心的不是谁的责任，而是风险有多大、有没有在控制、需要他做什么。

把‘对方不靠谱’换成‘当前风险是X，我已做Y，需要Z’，汇报效果会完全不同。

20. 任务依赖管理和风险管理到底是什么关系，是不是同一件事？

我一直把依赖管理和风险管理分开看，依赖归排期，风险归风险登记册。但上次复盘时发现，几乎所有的延期风险都跟依赖有关，我开始怀疑这两个东西是不是应该合并管理。

依赖管理是风险管理的一个子集，而且是最容易被单独漏掉的子集。依赖本身就是风险源：上游延期、接口人变更、交付物质量不达标、跨团队优先级冲突，这些都是依赖带来的风险。做法：在风险登记册里加一列‘关联依赖’，每条风险都标注它对应哪条依赖；反过来，在依赖表里加一列‘风险等级’，红色依赖自动进入风险登记册。

判断依据：如果风险登记册里的风险没有一条和依赖相关，通常说明依赖没有被识别出来，而不是没有依赖风险。把两张表打通后，你会发现风险登记册里至少三成以上的风险和依赖直接相关，管理动作也可以合并，不用开两个会。

21. 小团队没有专职项目经理，产品经理一个人怎么管好依赖？

我们团队不到十个人，没有项目经理，排期、依赖、风险全是我一个人管。我试过用表格记依赖，但更新不及时，很快就没人看了，想知道小团队有没有更轻的做法。

小团队的核心策略是‘依赖不过夜，口头加书面双确认’。具体做法：第一，排期会上当场确认每条关键依赖的接口人和日期，散会后十分钟内把依赖表发到群里，要求接口人回复确认；第二，每周站会只问三个问题，你的依赖有没有变化、你的承诺日期有没有风险、你需要谁配合；

第三，用某项目管理平台的依赖字段替代表格，因为工具会自动提醒，比手动更新表格省时间；第四，只维护十到十五条关键依赖，其他依赖口头同步即可，不追求全量记录。判断依据：小团队的优势是沟通链路短，劣势是没有人专门盯流程，所以依赖管理要尽量嵌入已有的站会和排期会，而不是新增一个独立流程。

一个十人团队，每周花在依赖管理上的额外时间控制在十五分钟以内是可行的。

22. 依赖关系可视化到底该用甘特图还是看板，两种视图分别适合什么场景？

我们团队有人喜欢甘特图，有人喜欢看板，每次讨论用什么视图都要吵一架。我想知道这两种视图在依赖管理上各自适合什么，能不能分工使用，而不是二选一。

甘特图适合看‘时间维度的依赖’，因为它能直观显示前置任务和后续任务在时间轴上的重叠和间隔，适合排期阶段和上线前倒计时阶段；看板适合看‘状态维度的依赖’，因为它能按接口人或状态分组，快速看出哪些依赖卡住了，适合日常执行和周会同步。

分工做法：排期时用甘特图确认关键路径和浮动时间，执行时用看板按接口人分组跟踪红色依赖，两个视图的数据源是同一份依赖表，不重复维护。判断依据：用甘特图做日常跟踪，更新成本太高，没人愿意每天调时间条；用看板做排期，又看不出时间冲突和浮动时间。

分工使用后，排期准确性靠甘特图，执行透明度靠看板，团队的争论会少很多。

23. 依赖方交付的东西质量不达标，导致下游返工，这种风险怎么提前防？

我们遇到过一次，上游按时交付了接口，但字段缺了一半，下游联调时才发现，又花了三天返工。这种‘按时但不合格’的依赖，比延期还让人头疼，因为排期上看不出来。

在依赖表里加一个‘验收标准’字段，要求上游在承诺交付日期前先提供可验证的交付物样例，比如接口文档、字段列表、Mock数据或测试环境地址。做法：把依赖交付拆成两个节点，‘样例交付’和‘正式交付’，样例交付时间比正式交付提前两到三天，下游在样例交付时做一次快速验收，确认字段、格式、逻辑是否符合预期。

判断依据：按时但不合格的依赖，返工时间通常和重新开发差不多，但因为它不触发延期预警，往往更晚被发现。加了样例交付节点后，质量问题能在正式交付前暴露，下游至少有两天缓冲来调整。验收标准不需要写得很复杂，列清楚必填字段和核心逻辑即可。

24. 项目复盘时，怎么判断一次延期到底是依赖管理的锅还是其他原因？

每次延期复盘，大家都有不同的说法，有人说是需求变更，有人说是排期太紧，有人说是依赖方不配合。我想知道有没有一个判断框架，能客观区分依赖管理是不是主因。

用‘五问归因法’区分：第一问，延期任务的前置任务是否按时交付，如果否，进入依赖归因；第二问，前置任务的延期是否被提前预警，如果没有，是依赖监控缺失；第三问，前置任务的接口人是否明确，如果不明确，是依赖责任缺失；第四问，是否有Plan B，如果没有，是依赖预案缺失；

第五问，变更是否同步到了该任务，如果没有，是依赖同步缺失。五问里只要有任意两问指向依赖管理，就可以判定依赖管理是主因或重要原因。判断依据：延期通常是多因一果，但依赖管理的缺失往往是最容易被忽略的可控因素。用这五问复盘，能避免把延期简单归为‘需求变更’或‘排期太紧’，找到真正能改进的动作。

复盘结论要落到具体的依赖管理改进项，而不是‘下次注意’。

25. 任务依赖里的FS和SF到底有什么区别，产品经理需要分那么细吗？

我之前一直以为任务依赖只有‘前后顺序’这一种，直到有次排期时技术负责人问我这个接口是FS还是SF，我当场卡住了。后来复盘发现，如果把依赖类型搞混，关键路径就会算错，后面的排期全得推倒重来。

FS是Finish-to-Start，前序任务完成后后续任务才能开始，是最常见的依赖；SF是Start-to-Finish，后续任务的完成依赖于前序任务的启动，实际项目中极少用，主要出现在交接班类场景。产品经理不需要背全四种类型，但必须能区分FS和SS，因为这两种直接决定排期是串行还是并行。

判断方法很简单：问团队这件事能不能在前一件事没做完时就开始，能就是SS，不能就是FS。实际排期表里把每个依赖标注成FS或SS，关键路径的误差能减少一半以上。

26. 跨团队依赖对方一直不安排接口人，每次都让我找不同的人问进度，怎么破？

我们版本上线前两周，我发现后端依赖的那个服务一直没人给明确排期，每次在群里问，不同的人回我‘我看看’‘这个不是我负责’，拖了一周都没结果。我又没有权限直接要求对方团队的人做事，感觉特别被动。

核心动作是把个人对个人的追问升级为团队对团队的约定。第一步，在跨团队群里发一条结构化消息，写明我方任务A依赖贵方任务B，B的交付时间直接影响我方上线日期X，请指定一位接口人负责B的进度同步和风险上报；

第二步，如果24小时内无人认领，直接升级到双方共同上级，用风险上报而非催进度的口径，说明不指定接口人将导致的上线延期后果；第三步，接口人确定后约定固定的同步节奏，比如每周二、四各同步一次，同步内容只写已完成、进行中、阻塞三态。

判断依据：跨团队依赖如果没有明确接口人，延期概率会成倍上升，因为责任分散等于无人负责。

27. 关键依赖没有Plan B，上级又不同意加资源，怎么办？

我之前遇到一个关键依赖，对方团队明确说排期满了，我向上级申请加人协调，上级说‘你自己想办法’。那一刻我觉得既没有资源又没有退路，只能硬扛。

把问题从要资源翻译成选风险。做法是准备一张A/B/C方案对比表：A方案是维持现状，标注延期概率和预计延期天数；B方案是加一个兼职人力，标注需要谁、投入多少工时、能降低多少延期概率；C方案是降级交付，标注砍掉哪些功能、用户体验损失是什么。

带着这张表找上级，不是问能不能加人，而是问如果必须保上线日期你选哪个风险。判断依据：上级拒绝加资源，往往是因为没看到清晰的取舍，而不是真的没有资源。如果三个方案都被否，就书面记录风险已知悉并接受，并设定一个触发点，比如如果X月X日对方仍未交付则自动切换到降级方案，避免无限期等待。

28. 用某项目管理工具管理任务依赖，哪些字段和视图是必须配置的？

我们团队用某项目管理工具，但依赖关系全靠大家在评论里说，没人真的去配依赖字段。我想推动团队把依赖管理规范化，但又不想搞得太复杂，怕大家抵触。

必须配置的字段只有四个：前置任务、依赖类型、承诺交付日期、接口人。前置任务用工具自带的关系字段关联，依赖类型下拉选FS或SS，承诺交付日期填死时间而不是本周，接口人填具体姓名而非团队名。必须打开的视图有两个：一个是按承诺交付日期排序的列表视图，用来每周过红色依赖；

一个是按接口人分组的看板视图，用来在跨团队同步时快速定位每条依赖的责任人。判断依据：字段超过六个，团队填写率会明显下降；字段少于四个，依赖信息就不完整，没法做关键路径分析。推动时先在一个版本迭代里试点，只要求关键路径任务填写，跑通一个迭代后再全面推广，抵触会小很多。