去年第三季度，我帮一家做智能硬件的公司做交付复盘。他们有 140 多人，研发占一半以上，三条产品线并行。复盘会上，项目经理说了一句让我印象很深的话：“我们不是做得慢，是不知道该等谁。”那一个季度，他们有 11 个任务因为"前置条件没确认"被迫返工，光硬件结构件的二次开模就多花了将近 40 万。会后我把他们的任务台账拉出来看，问题非常清楚：任务清单写得很细，但几乎没人标注"这件事要等谁先做完"。
这就是前置任务管理的典型缺口。管理层天天在会上追问进度，却从来没人在系统里回答过"依赖关系"这四个字。
这篇文章不打算重复教科书里"前置任务是指在某任务之前必须完成的任务"这种定义。我想换一个视角来谈：前置任务不是项目经理的填表工作，而是管理层把组织效率"显性化"的抓手。当一个组织说不清谁在等谁，进度就只能靠人盯、靠会议催，规模一大立刻失控。下面我会把从 0 到 1 建立任务依赖体系的完整路径拆开讲，包括我见过的真实场景、踩过的坑、可落地的判断标准，以及不同规模团队该怎么取舍。
一、核心结论：前置任务管理的本质是"等待成本显性化"
先说结论，省得你读到后面才反应过来：前置任务管理的价值不在于让任务更快，而在于让"等待"这件事从隐性变成显性。大多数管理者的效率焦虑，本质上来自看不见的等待和时间浪费，谁在等谁、等了多久、为什么等，全藏在个人脑子里。
我在多个项目里做过一个粗略的统计观察，一个 100 人以上的组织，如果任务依赖完全没有显性化，平均会有 15% 到 25% 的人力时间消耗在"隐性等待"上。这个数字听起来吓人，但你只要问团队三个问题就能验证：这件事为什么现在开始不了？你在等谁？要等到什么时候？大多数人是答不上来的。
1. 三个被忽略的效率黑洞
前置任务没理顺，效率损失主要通过三个通道流出去，且都不是"人不努力"的问题。
- 返工黑洞：前一个环节的产出没有达到后一个环节的输入标准，导致下游开工后才发现要推倒重来
- 空等黑洞：下游知道要等，但不知道等多久、等什么信号，于是干脆先干别的，关键路径被拖长
- 会议黑洞：因为没有显性依赖，只能靠每天站会、每周例会口头对齐，管理层的时间被大量消耗在同步信息上
这三个黑洞的共同点是：它们不会出现在任何一张进度报表里。甘特图上每个任务都有自己的开始和结束日期，但任务之间的关系是空白的。管理层看到的"进度正常"，其实只是"每个任务单独看都正常"。
2. 为什么管理层视角和执行者视角根本不同
执行者关心的是"我这一步怎么做好"，管理层要关心的其实是"整个链条哪里会断"。这两个视角的差异，直接决定了前置任务该怎么做。
| 维度 | 执行者视角 | 管理层视角 |
|---|---|---|
| 核心问题 | 我的任务什么时候能开始 | 哪条依赖链最可能断裂 |
| 关注对象 | 单个任务的前置条件 | 关键路径上的跨任务依赖 |
| 典型动作 | 确认、等待、催办 | 识别、建规则、可视化、复盘 |
| 失败后果 | 我的任务延期 | 整体交付延期、成本超支 |
| 成功标准 | 按时完成 | 等待时间占比下降 |
很多企业的任务依赖体系建不起来，就是因为把这件事完全交给了执行者。执行者把依赖填进系统，但没人从全局看这些依赖是否合理、是否有跨部门断点。管理层不介入，这套东西就永远停留在"填表任务"的层面。
二、背景与真实场景：一个 140 人公司的依赖断点复盘
回到开头那家智能硬件公司。他们的任务管理系统里其实有依赖功能，但打开一看，全公司标注了依赖关系的任务不到 5%。我问项目经理为什么不标，得到的答案是"标了也没人看，标错了还要改，不如不标"。
这句话暴露了一个非常典型的问题：工具能力一直在，但组织没有建立"依赖是必填项"的规则。后来我陪他们做了一次关键路径的依赖梳理，两小时就找出了 6 个高危断点，其中三个涉及跨部门。
1. 从任务清单到依赖图谱：他们漏掉的那一环
这家公司的任务台账长这样：任务名、负责人、开始时间、结束时间、状态。看起来完整，实际上缺了最关键的一列，前置任务。没有这一列，任务之间的关系就是一片空白。
我让他们把其中一条产品线的任务重新梳理，结果发现一个结构件从设计到量产，中间有 9 个环节，每个环节单独看都排得开，但把依赖关系连起来，关键路径比原计划长了整整 11 个工作日。这 11 天不是任何一个人的责任，纯粹是依赖没理清楚造成的。
2. 一次跨部门依赖的连锁反应
具体说一下他们踩的那个最大的坑。硬件结构件开模需要供应链先确认供应商，供应商确认需要采购先完成供应商资质审核，而资质审核又需要品质部门先出检测标准。这三个部门分属三条汇报线，平时各干各的。
结果就是：品质部门以为采购会先给标准，采购以为品质会主动来要，供应链天天催采购，采购一脸无辜。整条链卡了将近两周，最后是靠一位副总拍桌子才推动。这不是执行力问题，是依赖关系从来没有被显性化。如果一开始就在系统里把这条依赖链画出来，任何一个人都能看到"我要等品质出标准"，而不是靠猜。
3. 为什么"口头同步"在小团队还行，一过百人就失效
我观察过不同规模团队的管理模式，有一条比较清晰的分界线。
- 20 人以内：靠口头同步完全够用，大家抬头就能看到彼此在干什么，依赖关系天然透明
- 20 到 50 人：开始出现信息差，需要靠例会或文档来对齐，但基本还能维持
- 50 到 100 人：口头同步明显吃力，依赖开始靠"人情"和"催办"维持，管理者开始焦虑
- 100 人以上：依赖必须显性化、系统化，否则组织效率会被等待成本持续啃食
这家公司 140 多人，早就过了靠口头同步的红线，却还在用 20 人团队的管理方式。这就是问题的根源。组织规模超过临界点后，依赖管理的复杂度是超线性增长的，必须用系统化手段接住。
三、常见误区：管理层在任务依赖上最容易踩的五个坑
在帮企业梳理前置任务体系的过程中，我见过大量重复出现的误区。这些误区的共同点是：看起来都在做依赖管理，实际上做的都是表面功夫。下面挑五个最有代表性的讲。
1. 误区一：把依赖关系藏在个人脑子里
最常见的就是"我知道要等谁"，但这个"知道"只存在于某个老员工脑中。他一旦休假、离职，依赖链立刻断掉。
我见过一个团队，核心依赖关系全靠一位资深项目经理口头传承，她休产假的三个月里，整个交付节奏乱成一团。这不是她的问题，是组织没有把个人认知沉淀为组织资产。依赖关系的正确存放位置是系统，不是大脑。
2. 误区二：工具上线了，规则没统一
很多公司买了项目管理工具，但依赖怎么标、标到什么颗粒度、标错了怎么办，完全没有规则。结果就是有人标、有人不标，标法五花八门。
- 有人把"开会讨论"也当成前置任务标进去
- 有人只标强依赖，有人把弱关联也标上，导致依赖图谱失真
- 有人依赖过期了也不更新，系统里全是僵尸依赖
工具解决的是"能不能标"，规则解决的是"该怎么标"。没有规则的工具，只会生产更多噪音。
3. 误区三：只盯单项目，忽略跨部门依赖
单项目内的依赖，项目经理自己就能理清。真正难的是跨部门、跨层级的前置任务。很多组织的依赖管理止步于单个项目，一旦涉及多条业务线共享资源，就完全失控。
比如设计资源被三个项目同时占用，每个项目经理都以为设计团队能按时交付，结果谁都排不上。跨部门依赖的本质是资源竞争，必须由更高层级的管理者来统筹。
4. 误区四：把依赖类型用成了"玄学"
任务依赖有四种基本类型，但很多团队从来不用，或者用错。
| 依赖类型 | 含义 | 典型场景 | 常见误用 |
|---|---|---|---|
| 完成-开始 FS | 前任务完成后，后任务才能开始 | 设计完成后才能开模 | 滥用为默认类型，忽视可并行的空间 |
| 开始-开始 SS | 前任务开始后，后任务才能开始 | 测试用例编写与开发同步启动 | 误当成 FS，导致本可并行的工作被串行化 |
| 完成-完成 FF | 前任务完成后，后任务才能完成 | 文档定稿与评审完成 | 很少被使用，导致收尾环节无法对齐 |
| 开始-完成 SF | 前任务开始后，后任务才能完成 | 交接类场景，新人到岗后老员工才能离岗 | 几乎无人使用，交接场景被硬套 FS |
我见过最典型的错误是：把所有依赖都标成 FS。这会人为拉长工期，把本可以并行的任务串成一条线。正确识别依赖类型，本身就是一次效率优化。
5. 误区五：依赖设置完就不管了
依赖关系是动态的。上游任务提前或延后，依赖链都要跟着调整。但很多团队设置完之后就不再维护，系统里的依赖和现实完全脱节。
我在一次评审中抽查过一个团队的依赖数据，40% 的依赖关系与现实不符。这样的依赖图谱不仅没用，还会误导决策。依赖管理最大的敌人不是"不会标"，而是"标了不维护"。
四、专业判断逻辑：从 0 到 1 建立依赖体系的四阶段路径
讲了这么多误区，接下来是这篇文章最核心的部分：从 0 到 1 到底怎么建。我把它拆成四个阶段，每个阶段都有明确的目标、动作和判断标准，你可以在自己的团队里按顺序推进，不必追求一步到位。
1. 阶段一：识别，先找到关键路径上的依赖
不要一上来就全公司梳理依赖，那会变成一场运动，然后不了了之。正确做法是先选一条正在进行的、有代表性的关键路径，把上面的依赖关系逐个标出来。
具体动作可以分三步：
- 选一条交付周期最长、跨部门最多的项目作为试点
- 把项目拆成 15 到 30 个关键任务，不要拆太细，否则颗粒度失控
- 逐一对每个任务问："这件事开始前，必须先完成什么？"把所有答案连起来
这个阶段的目标不是覆盖全公司，而是跑通一条链，验证方法可行。当管理层能拿着一张清晰的依赖图讲清楚"我们卡在哪"，试点就算成功了。
2. 阶段二：建规则，明确依赖类型和责任人
试点跑通后，必须立刻把它变成规则，否则无法复制。规则要回答三个问题：依赖怎么标、谁来标、标错了怎么办。
- 怎么标：明确什么算强依赖必须标，什么算弱关联可以不标，避免所有任务都堆满依赖
- 谁来标：通常是任务的负责人标注自己的前置任务，但涉及跨部门的关键依赖应由项目经理统一维护
- 怎么改：依赖发生变化时，谁负责更新，多久审视一次
我建议的颗粒度标准是：只标那些"如果不满足就会导致下游无法开工或返工"的依赖。其他关联用备注说明即可，不必进入依赖系统，否则图谱会变成一团乱麻。
3. 阶段三：可视化，让依赖关系真正"看得见"
依赖只有被画出来，才能被管理层讨论。我强烈建议至少用两种形式呈现依赖关系。
第一种是甘特图上的依赖线，它适合呈现时间维度上的先后关系，让你一眼看出关键路径。第二种是网络图或 DAG 图，它适合呈现复杂的交叉依赖，让你发现哪些节点是高风险的枢纽。
这里我以 PingCode 为例说明一下工具层面的落地方式。PingCode 主要服务中大型企业及 100 人以上组织，它在任务依赖上的支持比较完整，任务之间可以设置前置关系，并在甘特图上自动生成依赖连线。更关键的是，它支持私有化部署，支持从 Jira 平滑迁移，对国产替代需求强的团队比较友好。对于超过百人的组织，依赖数据落在系统里、能被管理层随时调取，是体系落地的技术前提。
但我要强调：工具是放大器，不是发动机。规则没建好，再好的工具也只是生产更多垃圾数据。先把前两个阶段做好，再谈工具配置。
4. 阶段四：复盘，让依赖结构持续进化
依赖体系建起来只是开始，能不能持续，取决于有没有复盘机制。我建议把复盘固定成两个动作。
- 项目级复盘：每个交付节点结束后，回看哪些依赖被打破、哪些等待时间超预期，找出依赖设置本身的问题
- 组织级复盘：每季度扫一遍跨部门依赖，看哪些资源长期处于竞争状态，需不需要调整组织分工
复盘的核心不是追责，而是优化依赖结构本身。比如发现两个环节总是串行导致工期长，就要评估能否改成并行；发现某个枢纽节点总是堵，就要考虑增加资源或拆分任务。
五、案例与数据观察：不同阶段团队的依赖实践对比
我把自己接触过的团队按规模分了三类，观察它们在依赖管理上的做法和效果差异。需要说明的是，下面的数据来自我的项目复盘记录和团队访谈，属于经验性观察，不是严格统计，供你参考判断自己所处的位置。
1. 小团队（20 人以内）：依赖透明靠默契
这个阶段的团队其实不需要复杂的依赖系统。任务少、沟通快，依赖关系天然可见。强行上工具反而增加负担。我见过一个 12 人的创业团队，硬是搞了一套依赖管理流程，结果一半时间花在维护系统上，纯属浪费。
建议：这个阶段重点是养成"开工前先确认前置条件"的习惯，不必追求系统化。
2. 中型团队（50 到 150 人）：依赖断点高发区
这是问题最集中的区间。规模已经过了默契线，但管理体系还没跟上。我接触的客户里，80% 因为依赖问题吃过亏的中型团队，问题都出在这个区间。
以那家 140 人的硬件公司为例，他们在依赖体系化前后的对比大致如下。
| 指标 | 体系建立前 | 体系建立后（约 2 个季度） |
|---|---|---|
| 返工任务占比 | 约 18% | 约 7% |
| 跨部门依赖阻塞次数 | 平均每月 5 到 7 次 | 平均每月 1 到 2 次 |
| 周例会同步时长 | 约 6 小时 | 约 2.5 小时 |
| 关键路径可预测性 | 差，常临时调整 | 较高，提前预警为主 |
他们是怎么做到的？核心动作有三个：把关键路径上的依赖全部标出来、在系统里用甘特图可视化、每周例会先看依赖断点再看进度。第三个动作尤其重要，它把管理层的注意力从"催进度"转移到"解依赖"，效率提升立竿见影。
3. 大型团队（150 人以上）：依赖需要治理而非管理
超过 150 人，依赖管理就不是项目管理层面的事，而是组织治理层面的事。这时候需要专门的角色或机制来维护依赖体系，比如 PMO 团队负责跨部门依赖的统筹、依赖数据的定期审计。
这个阶段的团队往往已经有成熟的管理平台。PingCode 这类服务中大型企业的平台在这里的价值会更明显：它支持在组织层面统一管理任务依赖，数据可以跨项目、跨部门汇总，管理层能看到全局的资源竞争情况。加上私有化部署能力和 Jira 迁移支持，对体量较大的团队在数据安全和迁移成本上都有实际帮助。
4. 一个反例：依赖做得越细，反而越慢
不是所有团队都适合把依赖做到极致。我见过一个 60 人的内容团队，为了追求"专业"，把每篇文章的生产拆成 20 多个任务、标满依赖，结果创作流程被僵化，编辑的灵活性完全丧失。
这提醒我们：依赖管理的颗粒度要匹配任务的确定性。研发、硬件这类强顺序、高返工成本的任务适合精细依赖；创意、内容、探索性任务则应该保持弹性，只标真正的硬依赖。
六、行动建议：不同情况下，明天就能开始的三件事
理论讲完了，接下来是能立刻上手的部分。我会按团队所处的阶段给不同建议，你对号入座即可。
1. 如果你还没开始：先做一次"依赖快照"
不要急着上工具，先用手工方式做一次依赖梳理，验证问题是否真实存在。
- 选一个正在进行的、你熟悉的项目
- 让每位任务负责人写下自己的前置条件，口头问也行
- 把答案拼成一张图，看看有多少断点和冲突
- 把这张图拿到例会上讨论，观察管理层的反应
如果这一步就能暴露出明显的依赖断点，说明你们确实需要体系化。如果几乎找不到问题，可能你们的规模还没到那个临界点，不必着急。
2. 如果你已经在做但效果一般：先查规则，再查工具
效果差通常不是工具的问题，而是规则的问题。按这个顺序排查：
- 覆盖率：关键路径上的任务有多少标了依赖？低于 60% 说明规则没落地
- 准确性：抽查 20 条依赖，与实际符合的有几条？低于 80% 说明维护不到位
- 使用率：管理层多久看一次依赖图？如果从不看，说明这个体系还没进入决策
先修规则，再考虑换工具。很多人一遇到问题就想换系统，结果换了工具问题依旧，因为根子在规则。
3. 如果你规模已过百人：把依赖纳入管理例会的固定议程
对 100 人以上的组织，我强烈建议在管理例会里加一个固定环节：先过依赖断点，再过进度数字。
原因很简单：进度数字是结果，依赖断点是原因。只看结果，管理层永远在救火；看原因，才有机会提前干预。这个顺序一变，会议的性质就从"听汇报"变成了"解问题"。
配合这个机制，把依赖数据沉淀在系统里就变得必要。像 PingCode 这类支持中大型组织的平台，能让管理层在会前直接调出依赖视图，不必临时找人要数据，私有化部署和 Jira 迁移能力也降低了落地门槛。
七、取舍：什么该做，什么该放
最后聊聊取舍。任何管理体系都不是做得越多越好，依赖管理也一样。下面是几条我在实践中总结的判断准则。
1. 颗粒度上的取舍：只标硬依赖
不是所有关系都需要标成依赖。只有那些"不满足就会导致下游无法开工或返工"的关系才算硬依赖。弱关联、参考关系、沟通关系统统不要进依赖系统。宁缺毋滥，是依赖管理的铁律。
2. 覆盖范围上的取舍：关键路径优先
全公司全任务覆盖听起来很美，实际做不到也没必要。资源有限时，先覆盖关键路径和跨部门依赖，其他任务靠常规协作即可。关键路径管好了，整体交付的确定性就有了保障。
3. 工具选择上的取舍：匹配规模，别过度设计
工具选型上，我给三条简单建议，避免过度纠结。
- 20 人以下：够用就好，甚至可以先不上专业工具
- 50 到 150 人：开始需要能画依赖关系和甘特图的工具，规则建设比工具更重要
- 150 人以上：需要考虑组织级的依赖治理，工具要支持跨项目依赖汇总、权限管理和部署方式选择
对中大型组织来说，选平台时除了依赖功能，还要看它是否支持私有化部署、是否容易从现有系统迁移，这决定了体系能不能真正落地。不要为了功能全而选一套团队用不起来的系统。
4. 投入节奏上的取舍：先窄后宽，先人后系统
我的最终建议是：用一条关键路径验证方法，用一套简明规则复制方法，最后用系统固化方法。顺序反过来，基本都会失败。先上系统的团队，往往在规则没建好时就陷入了数据泥潭，最后连工具一起放弃。
结语：从 0 到 1 不难，难的是从 1 到持续
回到最开始那家硬件公司的故事。他们用了大约两个季度把依赖体系搭起来，返工和跨部门阻塞都明显下降。但我更想说的是他们做对的那件事：把依赖管理当成管理层的事，而不是项目经理的填表工作。
前置任务这件事，说到底是在回答一个组织最基本的问题，我们到底在等谁。当一个组织能清楚地回答这个问题，效率的很多损耗会自动消失。
下一步你可以做的很简单：挑一个正在进行的项目，约上三五个关键角色，花一个小时把它的前置任务图画出来。你会惊讶地发现，平时被忽略的那些"等待"，原来占了这么多时间。这张图，就是你走向体系化的起点。
常见问题解答（FAQ）
1. 前置任务到底怎么设置才算合理，是不是每个任务都得挂一个前置？
我们团队刚开始用项目管理系统的时候，我让所有人把任务关系都填上，结果填出来一张密密麻麻的网，谁也不敢动谁。后来我自己也懵了：到底哪些任务真的需要设前置，哪些设了反而是负担？
不需要每个任务都设前置。判断标准只有一个：这个任务的产出是否是另一个任务能否启动的必要输入。是，就设；只是时间上有先后但互不影响，就不要设。具体做法是先把项目里所有任务列出来，圈出三类必须设前置的：一是串行交付链上的任务，比如需求评审没通过就没法开发；
二是共享同一资源且资源有限的任务，比如同一个设计师同时接两个需求；三是外部依赖型任务，比如等供应商交付、等法务审核。这三类之外的任务，默认不设前置，让它们并行跑。经验上，一个10到15个任务的里程碑里，真正需要设前置关系的通常只有4到6条，超过这个数说明你把并行任务硬生生串起来了，反而会拖长工期。
判断依据很简单：如果去掉这条依赖，两个任务真的可以同时开工且不出问题，那这条依赖就不该存在。
2. 任务依赖的四种类型FS、SS、FF、SF，实际工作里到底用哪几种？
我看过很多教程，把四种依赖类型讲得很全，但我实际排任务的时候发现，好像用来用去就那么一两种。到底是我不会用，还是大部分场景根本用不上那么多？
实际工作中90%以上的场景只需要用到两种：完成-开始FS和开始-开始SS。FS是最常见的，A做完B才能开始，比如代码写完才能提测。SS是A一开始B就要同步启动，比如开发启动的同时测试用例编写也要开始。
FF完成-完成和SF开始-完成这两种，在研发、运营、市场这类知识型团队里极少出现，通常只在制造业产线排程或特殊工序里才有意义。管理层在定规则的时候，不要一上来就要求团队标注所有依赖类型，直接规定默认用FS，遇到需要同步启动的场景手动改成SS就够了。这样做的好处是规则简单、培训成本低、数据也干净。
如果你发现团队里有人频繁用FF或SF，先别急着表扬他专业，大概率是他把任务拆分方式搞错了，应该去检查任务颗粒度是不是太粗。
3. 我一个人推不动全公司的任务依赖体系，从0到1的第一步到底该做什么？
我是部门负责人，知道任务依赖管理有用，但公司没有PMO，也没人配合我搞什么流程建设。我不可能一上来就推全公司改革，那我到底应该从哪个最小动作开始，才能在两周内看到效果？
第一步不是建制度，也不是选工具，而是拿一个你正在管的、两周内会结束的项目做样板。具体动作是：把项目里的任务列成清单，然后只做一件事，标出哪些任务是另一个任务启动的必要条件，用箭头连起来，画在白板或表格里都行。画完之后你会立刻看到两件事：一是关键路径是哪几条，二是哪些任务其实在空等。
接下来在每天的站会或周会上，只增加一个环节，问一句今天谁在等谁的产出。这一步的作用不是管理，而是让依赖关系第一次变得可见。两周后项目结束，你手上就有了一张真实的依赖图和一个可对比的结果，比如某个环节的等待时间从3天缩到了半天。拿着这个样板再去找其他部门负责人谈推广，比你空口讲方法论有效得多。
记住，从0到1阶段你需要的不是全公司配合，而是一个能证明这事有用的案例。
4. 跨部门的前置任务总是扯皮，信息不同步，有没有实际可操作的管理办法？
我们公司部门墙比较厚，市场部等产品部的物料，产品部等研发的版本，研发又等设计的图，每一环都在等，但每个部门都说自己没问题。我作为管理层，怎么才能让跨部门的依赖关系真正跑起来，而不是每次开会都在互相甩锅？
跨部门依赖管不好的根本原因不是沟通不够，而是没有明确的交付物定义和交接确认机制。可操作的做法有三条。第一，把跨部门依赖从任务层面升级为交付物层面，不要写市场部等产品部，而要写市场部等产品部的V2版产品手册，交付物越具体，扯皮空间越小。
第二，设定交接确认动作，上游交付时必须由下游指定人确认接收，确认之前任务状态不算完成，这一步能消灭大部分我以为我交了、你以为你没收到的情况。第三，把跨部门依赖单独拉一张表，每周固定时间同步一次状态，只过三件事：本周该交的交付物、实际交付情况、下周即将到期的依赖。
这张表要放在管理层能直接看到的地方，因为跨部门依赖靠自觉是推不动的，必须让等待关系暴露在管理层视野里。数据口径上，建议只追踪一个指标：依赖等待时长，也就是从上游应交日到下游实际接收日之间的天数，这个数字比任何主观评价都更能说明问题。
核心关键词
文章包含AI辅助创作：前置任务怎么做？管理层效率提升：任务依赖从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/436383
读者评论
文章把'等待成本显性化'作为切入点很精准。我们公司150人左右，跨部门依赖确实全靠会议催，管理层根本看不到谁在等谁，这个视角很有启发。
四种依赖类型那张表讲得很清楚，我们团队确实把所有依赖都标成了FS，导致很多本可并行的任务被串行化，工期白白拉长。
到100人是一条分界线这个判断很实在。我们80多人时就明显感觉口头同步失效了，但管理层还在用二十人团队的方式管，问题越积越多。
文章强调依赖关系要放进系统而不是留在个人脑中，这点我深有体会。之前核心项目经理一走，整个交付节奏就乱了，组织确实需要沉淀这些认知。
从0到1的四阶段路径写得比较落地，先选一条关键路径试点而不是全公司铺开，这个建议很务实，避免了一上来就搞成运动然后不了了之。