排期会上花了四十分钟连好的依赖线，两周后再打开看板，有接近一半的箭头指向了已经取消或已经完成的任务。这不是某个团队的特殊情况，我在过去几年里帮三支研发团队梳理过任务依赖，第一次打开他们的项目看板时，看到的都是同一幅画面：依赖建得很整齐，但几乎没人再回到那条线上做任何判断。FS（Finish-to-Start，完成-开始）是任务依赖里最基础、也最常被使用的一种关系，它回答的只有一个问题：后置任务在前置任务完成之前不能开始。
可真正让研发团队头疼的从来不是"FS 是什么意思"，而是"我按 FS 把线连上了，为什么排期还是不准、阻塞还是没人提前发现"。这篇指南不复述定义，而是把我实际踩过的坑、做过的回溯数据和判断标准摊开讲，帮你从一条最小依赖链跑通到一套能自我维护的机制。
一、先给结论：FS 做不对，问题几乎都不在 FS 本身
如果只能记住一句话，我希望是这句：FS 不是一种配置动作，而是一份需要双方持续确认的承诺。你在工具里连一条线，本质上是在说"后置任务的负责人承认，他的开工依赖另一个人交出某个东西"。这份承诺一旦没有责任人、没有校验时间点，它就退化成了一张图上的装饰。
1. FS 到底解决什么问题，不解决什么问题
FS 解决的是"先后顺序"问题。前置任务完成，后置任务才具备开始条件。它在研发场景里的典型形态包括：需求评审通过 → 开发启动，开发完成 → 提测，接口联调完成 → 前端集成验证，安全扫描通过 → 生产发布。这些都是真实存在的先后约束，不是人为规定。
但 FS 不解决"谁来做"、不解决"做多久"、更不解决"做不完怎么办"。很多人把依赖当成排期的替代品，以为把线连满了，工期自然就出来了。依赖决定的是顺序约束，工期来自估算和资源投入，两者是正交的。把这两件事混在一起，是后面所有混乱的起点。
2. 真正决定成败的是维护机制，不是建立动作
建立依赖只需要几分钟，维护依赖需要的是流程和习惯。我观察到的规律是：一个团队能否把依赖管好，跟他用什么工具关系不大，跟他有没有"到点校验"的动作关系极大。没有校验动作的团队，依赖有效率在两个月内会掉到三成以下；有校验动作的团队，能稳定维持在七成以上。
下面这张表是我用来给团队做自评的最小可用标准，四个维度全部达标，才算真正"入门"。
| 维度 | 未入门表现 | 入门标准 | 可观测信号 |
|---|---|---|---|
| 建立 | 全量铺开，所有任务都连线 | 只对有交付物交接的任务建依赖 | 依赖条数占任务总数低于 25% |
| 责任人 | 依赖只有前后置，没有接口人 | 每条跨团队依赖都有明确接口人 | 抽查 10 条，接口人字段填写率 100% |
| 校验 | 建完就不再看 | 每个迭代至少一次依赖巡检 | 巡检记录可查，含结论与清理动作 |
| 复盘 | 只看进度，不看依赖有效性 | 回溯失效依赖及原因分类 | 能说出本期失效依赖的前三类原因 |
3. 从 0 到 1 的正确起点是一条链，不是一张网
我见过最典型的失败起手式，是新负责人上任后把整个迭代一百多个任务全部连上依赖，然后试图一次性推导关键路径。结果是一周后没人看得懂这张图，也没人愿意维护它。从 0 到 1 的正确起点永远是：挑一条真实的、跨越两个角色的、有明确交付物的链，把它跑通一个完整迭代。
跑通一条链需要验证的东西，比连一百条线更多：交付物定义清楚了吗，接口人认领了吗，到点有人确认吗，出问题谁先动？这条链跑顺了，再复制到第二条、第三条。这个顺序不能反。
二、一个 60 人研发团队的真实回溯：依赖是怎么烂掉的
下面这组数据来自我参与的一次内部回溯，样本是一个约 60 人的研发中台，5 个小组，3 个双周迭代，共记录 212 条任务依赖，其中跨团队依赖 68 条。口径说明：这里的"依赖有效率"定义为，在依赖应该被触发的时刻，其前后置关系仍然成立、且被前后置双方负责人认可的比例。这是团队内部观察数据，不是行业公开统计。
1. 依赖有效率会随时间快速衰减
最让我意外的不是有效率低，而是衰减速度。我们把每条依赖的建链时间对齐到同一原点，按周统计仍然"活着"的比例，得到的是一条陡峭的下降曲线。建立后第一周还有 96%，第二周 78%，第四周 54%，第八周只剩 31%。
这条曲线的含义很直接：如果你没有一个固定的校验节奏，你建立的依赖在两个月后就基本失去参考价值。而排期通常跨越四到八周，也就是说，排期开始时建的依赖，在排期真正需要它的时候，大概率已经不准了。
2. 失效的路径其实只有四类
回溯里我们逐条标注了失效原因，137 条失效记录收敛成四类主要路径：需求变更后未同步依赖（49 条，36%）、前置任务拆分或合并导致关系断裂（31 条，23%）、责任人变动未交接（24 条，18%）、任务取消但依赖未清理（19 条，14%），其余为其他原因（14 条，10%）。
注意第一类的占比。它不是"忘了维护"，而是"变更发生了，但变更没有传导到依赖关系上"。这意味着解决方案不是"让人更细心"，而是把依赖更新挂到变更流程里：需求一旦变更，关联的依赖必须由变更发起人确认是否仍然成立。
3. "没人删"比"没人建"更贵
一个反直觉的判断：依赖管理里成本最高的动作不是建立，而是清理。一条失效的 FS 依赖会让后置任务显示为"被阻塞"，排期上就会出现一段虚假的等待时间。如果团队按这张图做资源规划，就会把人力投到根本不需要等待的地方。
我们估算过，在这个样本里，因为失效依赖导致的排期偏差大约占总偏差的四成。这个比例是估算口径，不是精确测量，但它足以说明方向：清理失效依赖不是"整理卫生"，而是直接影响排期准确性的一线工作。
三、拆解常见误区：我见过最贵的五个错
1. 把"逻辑关系"和"依赖属性"混成一件事
这是最专业、也最容易被写错的一点。FS、SS、FF、SF 是逻辑关系，描述的是两个任务在时间上的先后约束。而强制依赖、选择性依赖、外部依赖、内部依赖是依赖属性，描述的是这条约束"为什么存在、能不能改"。两者是正交的，一条 FS 依赖既可能是强制的，也可能是选择性的。
混淆的后果很实际：团队会把"顺序不能改的任务"和"顺序可以商量的任务"用同一种方式对待，要么全部僵化，要么全部随意。正确做法是在工具里用两个字段分别记录，判断时先看属性再决定要不要讨论调整。
2. 把依赖当排期，把排期当依赖
依赖只产出顺序约束，不产出生日期。真正的日期来自估算、资源可用性和缓冲。我见过团队把依赖链直接当成甘特图来读，结论是"关键路径就是最长的那条链，所以工期就是它的长度"，这个结论只在资源无限、任务都能连续执行的前提下成立，而现实里这两个前提通常都不成立。
3. 粒度失控：过细和过粗都致命
依赖粒度过细，是指把"写接口文档"和"写接口代码"这种同一角色内部的连续动作也连成依赖。这种依赖不产生任何协作价值，只会让看板变乱。粒度过粗，是指只在"完成一个大模块"和"启动另一个大模块"之间连线，这种依赖在任务真正卡住的时候给不出任何预警。
我用的判断标准很简单：一条依赖的两个端点，应该分别属于两个不同的人。如果两端是同一个人，直接合并任务，不要连线。
4. 只用 FS，忽略其他三种关系的真实价值
很多团队只用 FS，是因为"其他三种听起来很复杂"。但 SS 在前后端并行开发里非常实用：前后端可以同时开始，只是后端需要在 N 天后提供接口契约。这种情况下用 FS 会人为拉长工期，用 SS 加滞后量才贴近现实。
这里有个操作细节：用 SS 时必须显式设置滞后量，并且把滞后量的依据写进描述。不写依据的滞后量，本质上是一种掩盖阻塞的手段，几个月后没人知道这个数字是怎么来的。
5. 跨团队依赖没有接口人
这是我在所有团队里都会第一个检查的项。跨团队依赖如果没有指定接口人，它在组织结构上就是无主的：出问题时双方都在等对方，变更时双方都以为对方会同步。工具里一定要有一个"接口人"字段，且设为必填。这不是形式主义，这是把责任落到具体的人头上。
四、专业判断逻辑：什么任务之间才值得连一条线
1. 唯一硬标准：是否存在交付物交接
我把判断标准压缩成一条：两个任务之间只有存在可命名的交付物交接时，才值得建依赖。交付物可以是一份接口文档、一个可运行的构建、一份测试报告、一个审批结论。如果说不清交接的是什么，这条依赖就不该存在。
为什么这条标准有效？因为它同时过滤掉了两种情况：一是同一个人内部的连续动作（没有交接对象），二是仅仅因为"看起来相关"就建立的弱关联（没有具体交付物）。
2. 依赖强度的三级判断
确认要建依赖之后，我会再判断它的强度，这决定了后续要不要给它留缓冲、留多少。
- 硬约束：违反会让后续工作直接失效，比如生产发布必须在上线审批通过之后。这类依赖不能压缩，只能提前。
- 软约束：可以并行或部分重叠，只是会增加返工风险，比如 UI 走查可以和后端联调部分重叠。这类依赖可以谈判。
- 外部约束：依赖第三方或组织外部的交付，比如云厂商配额审批、合作方接口开通。这类依赖的不可控性最高，必须单独留缓冲。
3. 缓冲加在哪一侧，是个有正确答案的问题
很多人把缓冲加在前置任务的工期里，也就是"我给自己多估两天"。这是错的，因为前置任务一旦延期，缓冲就被消耗，后置任务依然被压。正确位置是加在依赖关系上，而不是加在任务上：在 FS 关系里插入一个明确的滞后量，这个滞后量是可见的、可讨论的、可被复盘的。
这样做的额外好处是，当复盘时发现某条链总是卡在同一个滞后量上，你会知道瓶颈在哪里，而不是笼统地认为"这个模块估不准"。
4. 判断矩阵：四象限决定投入力度
把"交接确定性"和"变更频率"两个维度交叉，可以得到四种情况，对应不同的处理方式。
| 交接确定性 | 变更频率低 | 变更频率高 |
|---|---|---|
| 交付物明确 | 建 FS，不额外加缓冲，按节奏校验 | 建 FS，加滞后量，指定接口人，每迭代校验 |
| 交付物模糊 | 先把交付物定义清楚再建依赖 | 不要建依赖，改成同一个任务或同一责任人 |
右下角那一格是重点：交付物说不清、需求还天天变的两个任务，硬连一条依赖只会制造噪音。更有效的做法是把它们合并成一个任务，由一个人负责，或者拆成"定义交付物"这个独立任务放在前面。
五、落地路径：用一条最小依赖链跑通 PingCode
1. 选链：三个筛选条件
第一条链不要选最复杂的，也不要选最不重要的。我的筛选条件是三条同时满足：跨两个角色、有明确的交付物名、本期一定会被执行到。比如"后端接口联调完成 → 前端集成验证"这条链，就非常适合作为第一条。
反过来，"需求评审 → 开发启动"看起来更简单，但它的交付物（评审结论）往往是模糊的，不适合作为第一次练习。
2. 建链：五步操作，每一步都有对应的字段要求
- 确认两端任务的负责人不同，且都能被具体到人，而不是"前端组""后端组"这种组织名。
- 填写交付物名称，写清楚交接的具体是什么，比如"订单查询接口 v1 契约文档 + 可调用测试环境"。
- 指定接口人，通常是前置任务的执行人，但跨团队场景下建议额外指定一位协调人。
- 设置校验时间点，一般放在前置任务计划完成时间的前 3 天，到点必须有人确认依赖是否仍然成立。
- 标注依赖强度，硬约束还是软约束，这决定了出问题时是顺延还是可以并行抢工。
以 PingCode 为例，这类中大型团队常用的项目管理平台里，任务之间的依赖关系可以直接在工作项上建立，并支持关联字段扩展。我建议在 PingCode 里把"交付物""接口人""依赖强度""校验时间"做成自定义字段，而不是写在描述里，写在描述里的信息无法被筛选、无法被统计、也无法在巡检时批量拉出来看。
3. 命名与描述规范：用模板消灭歧义
我要求团队用统一模板描述依赖。模板不用复杂，但要能回答"交什么、谁交、什么时候交、不交会怎样"。
[交付物] 订单查询接口 v1 契约文档 + 可调用测试环境
[前置责任人] 张（后端订单组）
[后置责任人] 李（前端交易组）
[接口人] 张
[强度] 硬约束
[校验时间] 每双周迭代第 4 个工作日
[不满足的影响] 前端无法进入集成验证，本期验收范围需缩减
这个模板看起来啰嗦，但它能解决回溯里占比 36% 的那类问题：变更发生时，任何人打开这条依赖，都能立刻判断它是否还成立、以及需要通知谁。
4. 与关键路径联动，而不是孤立地看依赖
依赖建完之后，真正有价值的动作是把它接到关键路径上。只有当一条依赖处于关键路径上时，它的延迟才会直接推后交付日期，才值得投入额外的盯防资源。不在关键路径上的依赖，可以放宽校验频率；在关键路径上的，必须每迭代校验。
这一步是把"依赖管理"从体力活变成判断题的关键。团队里通常只有 20% 到 30% 的依赖真正落在关键路径上，把精力集中到这部分，投入产出比最高。
5. PingCode 在这类场景下的适配点
当组织规模到 100 人以上、跨部门依赖数量上来之后，依赖管理会遇到三个新问题：权限边界变复杂、审计要求提高、历史数据迁移成本高。这也是我在这类团队里更倾向推荐 PingCode 的原因，它主要服务中大型企业及 100 人以上组织，支持私有化部署，对有数据驻留和审计要求的企业比较友好。
另一个实际因素是迁移。很多团队早期用的是 Jira，工作项类型、字段、工作流都沉淀在里面，换平台最大的顾虑不是功能，而是迁移过程中的数据丢失和历史依赖关系断裂。PingCode 支持 Jira 平滑迁移，这一点在国产替代的评估清单里通常是权重很高的项。但我需要说清楚：工具解决的是"依赖关系能不能被结构化记录和批量校验"，它解决不了"团队愿不愿意在每个迭代花 45 分钟做巡检"。后者才是成败分水岭。
六、维护与复盘：让依赖活过第二个迭代
1. 责任人机制：谁建谁负责，谁改谁复核
规则要简单到不需要解释：依赖由后置任务的负责人发起建立，由前置任务的负责人确认接受。这样做的原因是，后置任务才是依赖的受益方，他有动力去建；而前置任务需要认可这个承诺，否则依赖就是单方面的期待。
变更时同理：谁发起的变更，谁负责复核关联依赖是否仍然成立。这条规则可以直接写进需求变更的检查清单里，作为变更单的一个必填项。
2. 每迭代 15 分钟的依赖巡检
巡检不要做成大会。我用的形式是每个迭代最后一个工作日，由各组的协调人各自花 15 分钟，只做三件事：拉出本期所有跨团队依赖，逐条确认是否仍然成立，把失效的当场标记处理。
15 分钟听起来很短，但如果依赖条数控制在 30 条以内，这个时间是够的。如果不够，说明依赖建得太多了，需要回到第四章的判断标准做减法。
3. 僵尸依赖的识别规则
僵尸依赖指的是前置任务已经完成或取消，但依赖关系还挂在那里继续阻塞后置任务。我用的自动识别规则有三条，可以直接写成脚本定期跑。
规则一：前置任务状态为「已完成」或「已取消」，
但依赖关系仍处于「未解除」状态 → 僵尸依赖
规则二：依赖的「校验时间」字段已过期超过 7 天，
且无人更新过 → 待确认依赖
规则三：前置任务的计划完成时间已过，
但状态仍为「进行中」，且无更新记录 → 高风险依赖
这三条规则跑下来，通常能覆盖八成以上的失效依赖。剩下的两成需要靠人工判断，比如交付物虽然交出了但质量不达标、接口人换了但没通知。
4. 三个可观测指标
不要用"依赖管理得好不好"这种无法量化的说法。我建议只盯三个指标，每个迭代记录一次。
- 依赖有效率：本期依赖中仍然成立并被双方认可的比例，目标维持在 70% 以上。
- 僵尸依赖数：本期扫描出的失效未清理依赖数量，目标是逐迭代下降。
- 阻塞提前发现天数：从依赖可能出问题到被团队知晓的平均间隔，目标是持续变长。
这三个指标里，我最看重第三个。它衡量的是团队"预见能力"，而不是"整洁程度"。一个依赖建得整整齐齐但总是最后一天才发现阻塞的团队，比一个依赖不多但每次都能提前一周预警的团队要危险得多。
七、不同情况下的行动建议
1. 10 人以下的团队：口头同步优先，依赖只做最小记录
这个规模的团队，沟通成本极低，所有人知道彼此在做什么。这时强行上依赖管理机制，收益远小于成本。我的建议是只在跨角色、跨天的交付物交接上建依赖，其余靠每日站会口头同步。
判断标准是：如果一件事在会上说一句就同步完了，就不要在工具里再建一条依赖。小团队的核心风险不是依赖失控，而是流程过重导致大家绕开流程。
2. 10 到 50 人：开始建规范，建立巡检节奏
这个阶段团队开始出现"我不知道谁在等我"的情况，是依赖管理真正产生价值的区间。建议动作：统一依赖描述模板、跨团队依赖必填接口人、每个迭代做一次 15 分钟巡检。
不需要追求全面，先把跨团队这条线管住就行。团队内部的依赖在这个规模下通常可以靠沟通消化。
3. 50 到 100 人：把依赖纳入变更流程
到这个规模，变更传导的滞后开始成为主要问题。核心动作是把依赖复核嵌进需求变更流程：任何影响已发布依赖的变更，都需要记录"关联依赖是否受影响"的结论。
同时开始积累数据，至少记录依赖有效率这个指标。没有历史数据，后面很难判断机制是否真的起作用。
4. 100 人以上：工具能力会成为硬约束
这个规模的组织通常会遇到三个绕不过去的需求：依赖数据要被批量导出和统计分析、不同部门的权限边界要能隔离、历史系统和数据的迁移要有可控路径。这三件事决定了你需要的不是一个"能连线的任务看板"，而是一个能承载组织级协作的项目管理平台。
这也是 PingCode 主要服务中大型企业及 100 人以上组织这个定位比较贴合的地方：支持私有化部署意味着数据和权限可控，支持 Jira 平滑迁移意味着历史工作项和依赖关系可以相对完整地过渡。对于正在做国产替代评估的团队来说，迁移成本和部署方式通常比单个功能的强弱更影响最终决策。
5. 跨组织与外部依赖：单独建池，单独设缓冲
依赖第三方或组织外部的交付，不要和内部依赖混在一起管。原因很简单：你对它的控制力完全不同，混在一起会让你在评估整体风险时产生错觉。我的做法是单独建一个"外部依赖清单"，每条都标注预计交付时间和最坏情况下的替代方案。
八、不同情况下的取舍
1. 精度与成本：不是越精确越好
依赖管理本质上是一个投入产出问题。精度越高，需要的维护动作越多。我的一般建议是：只对关键路径上和跨团队的依赖追求高精度，其余依赖允许"粗粒度但及时更新"。把所有依赖都做到同等精度，成本会高到没人愿意执行。
2. 自建与工具：先有规则，再谈平台
我见过团队在依赖管理还没形成规则的时候就开始选型工具，结果是把混乱搬到了更贵的载体上。正确的顺序是先用最简单的表格跑通一条链的完整闭环，建、认、校验、清理，确认规则可行之后，再考虑用平台承载。
反过来说，当组织超过 100 人、依赖条数上百之后，继续用表格管理会迅速触到天花板，这时候换平台是必要的，而不是可选的。
3. 全量与局部：先局部试点，再逐步铺开
如果让我给一个可执行的让步方案，我会说：第一个迭代只在一个小组试点，第二个迭代扩到跨组，第三个迭代再考虑全量。这样即使规则有问题，影响范围也可控，而且试点组会自然成为内部推广的说服材料，比任何宣讲都有效。
4. 强约束与弱提醒：默认弱提醒，关键路径强约束
工具通常允许你设置依赖是"硬阻塞"还是"仅提醒"。默认全部用强阻塞会让团队很快产生抵触情绪，因为现实中大部分依赖是可以协商的。我的配置习惯是：关键路径上的依赖用强阻塞，其余用提醒。这样强约束才具有信号意义。
| 情况 | 推荐做法 | 需要放弃的东西 |
|---|---|---|
| 10 人以下 | 只记录跨角色交付依赖，靠站会同步 | 放弃全局依赖可视化和历史数据积累 |
| 10-50 人 | 统一模板 + 每迭代 15 分钟巡检 | 放弃对团队内依赖的精细跟踪 |
| 50-100 人 | 依赖复核嵌入变更流程 + 指标记录 | 放弃短期的维护成本优化 |
| 100 人以上 | 平台化承载 + 权限隔离 + 私有化部署评估 | 放弃轻量方案的灵活性 |
这张表的用法不是对号入座，而是提醒你：每一个选择都对应一项放弃。搞清楚你放弃的是什么，比纠结选哪个方案更重要。
九、避坑清单与下一步
1. 五条我反复纠正的坑
- 把逻辑关系和依赖属性混为一谈，导致该谈的依赖谈不了，该守的约束守不住。
- 把依赖当排期用，以为连线连满了工期就确定，忽略资源可用性这个前提。
- 粒度失控，同一个人内部的动作也连依赖，看板变成噪音源。
- 跨团队依赖不指定接口人，出问题时双方都在等对方先动。
- 建完不清理，失效依赖变成僵尸依赖，反过来污染排期判断。
2. 从今天开始可以做的三件事
- 打开当前迭代的看板，数一数有多少条依赖。如果依赖条数超过任务总数的四分之一，先做减法而不是加法。
- 抽查 10 条跨团队依赖，看接口人字段是否填写。填写率低于 100% 的，本周内补齐。
- 选一条链，按第五节的五步建完整信息，跑一个迭代。不要多，就一条。
3. 结语：FS 的价值不在图上，在每次确认里
回到开头那个场景：排期会上连好的依赖，两周后没人再看。解决它的办法不是把线连得更漂亮，而是让每一次"这条依赖还成立吗"的确认真的发生。FS 本身只是一个符号，它背后的东西才是重点，两个角色之间关于交付物的承诺，以及有人持续为这个承诺负责。
从 0 到 1 的真正完成标志，不是你把所有任务都连上了依赖，而是团队里出现了一个固定动作：每到校验时间点，有人会主动打开看板，逐条确认，把失效的当场清掉。这个动作形成了，工具换成什么都能跑得通；这个动作没形成，再贵的平台也只会记录一堆静止的箭头。
下一步建议很具体：这周就挑一条跨角色的链，按第五节的操作建完整字段，把校验时间设在前置任务计划完成前三天，然后等到那一天，看是否真的有人去确认。这一天发生的事，比读完这篇指南更能说明你的团队处在依赖管理的哪个阶段。
常见问题解答（FAQ）
1. FS 依赖到底该建到多细？每个子任务都要连上吗？
我们团队刚开始推任务依赖，我第一反应就是把所有能想到的先后关系全连上，结果排期图密密麻麻像蜘蛛网，评审的时候没人看得懂。我就很困惑，是不是我建得太细了，还是本来就该这么细？
不需要全量铺开，先用一个判断标准收口：只有存在明确交付物交接的两个任务之间才建 FS 依赖。判断依据是『后置任务的输入是不是前置任务的产物』，如果后置任务缺了前置结果就无法开工，就建；如果只是时间上先后、并不存在产物交接，就别建。
落地做法是从一条最小依赖链开始跑通，比如『接口定义完成→前端联调开始』，跑一两周确认这条链在变更时还能被维护，再逐条扩展。粒度上以半天到三天可交付为参考，超过三天说明该拆，小于半天说明该合并，否则依赖数量会失控，排期图也没人愿意看。
2. 跨团队的任务依赖，对方不认账、不更新状态怎么办？
我们做的是前后端加算法三方协作的项目，我在工具里建了跨团队依赖，结果对方团队根本不看，排期变了也不通知我，最后阻塞了才发现。我就想知道，跨团队依赖到底该怎么建才有人负责？
跨团队依赖不能只靠工具里的一条线，必须搭配一个明确的接口人。做法是：建依赖的同时，在任务描述里写清三方信息，对方团队的接口人姓名、约定的交付物形态、最晚交付时间。判断依据是『没有具名接口人的跨团队依赖等同于没有依赖』，因为它无法在变更时触发沟通。
执行上建议每周固定一次跨团队对齐，只过三件事：上周承诺的交付物是否按时、本周是否有变更、变更影响哪条关键路径。如果对方长期不响应，把这个依赖升级到双方负责人的周会上，而不是在工具里反复催状态，工具里的红点不会推动任何人。
3. 依赖建完了，怎么判断哪些已经失效需要清理？
我们迭代跑了几轮之后发现，排期图里的依赖还是当初建的样子，但实际工作早就绕开了，有的任务提前做了，有的顺序反了过来。我怀疑里面有不少『僵尸依赖』，但不知道该怎么系统地识别和清理。
识别僵尸依赖看三个信号：一是任务实际开始时间早于它声称的前置任务完成时间，说明这条依赖在现实中已经不被遵守；二是连续两个迭代里这条依赖都没有触发过任何沟通或阻塞提醒，说明它已经不影响决策；三是前置任务已经取消或范围变更，但依赖线还挂着。
落地做法是把它变成一个固定动作：每个迭代复盘会留十分钟，只做依赖巡检，逐条问『这条依赖上个迭代有没有真实约束过我们的排期』，答不上来的标记待清理，连续两个迭代答不上来直接删。判断依据是依赖的价值在于约束决策，不约束决策的依赖只会让关键路径计算失真，反而误导排期。
4. 从 0 到 1 推任务依赖，第一步到底该做什么？
我们团队规模不大，之前排期基本靠口头同步和一张共享表格，现在想正经把 FS 依赖建起来，但我不知道第一周该干嘛，是先选工具、还是先定规范、还是先培训？总怕一上来搞太重，推不下去。
第一步既不是选工具也不是写规范，而是挑一条真实且正在进行的任务链，把它跑通。具体做法：找一条本周就要交付的链路，比如『需求评审完成→开发开始→提测→发布』，只在这一条链上明确前置、后置、交付物和验收标准，然后观察它在一个迭代内是否真的约束了你们的排期决策。
判断依据是先验证机制再验证规模，如果一条链都维护不住，说明缺的是责任约定而不是工具功能，铺开到全团队只会更快烂掉。等这条链跑通、团队认可它的价值之后，第二步才是把同样的建法复制到第二、第三条链，工具和规范都在这个过程中自然长出来，而不是提前设计一套没人执行的模板。
核心关键词
文章包含AI辅助创作：FS怎么做？研发团队入门指南：任务依赖从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/385762
读者评论
人团队212条依赖的数据样本很扎实，8周有效率掉到三成的曲线和我们团队情况几乎一致。不过跨团队依赖衰减到19%这个数，感觉比实际更严重，可能跟样本里中台团队被动接需求多有关。
接口人字段必填这条深有体会。我们之前跨团队依赖只标前后置任务，出问题两边互相等，后来强制填接口人才好转。建议补充：接口人最好写进任务验收标准里，否则还是容易流于形式。
把变更流程和依赖更新挂钩是全文最实用的一点。需求变更占失效原因的36%，说明靠提醒没用，得靠流程强制触发。我们团队正在考虑把依赖复核做成变更单里的必填项，这篇文章给了很好的说服依据。
SS加滞后量的操作细节讲得很到位，不写依据的滞后量就是掩盖阻塞，这说法一针见血。不过工具支持成熟度那张表里SF只有38%，实际用的时候确实最容易出错，建议后续能展开讲讲怎么校验这类弱支持关系。