方案已经验过：有效（未来图）、安全（负面分支）。可你要是明天一早冲进公司宣布「从今天起需求排队、限制开工」，大概率当天就崩——因为老板不同意、没有记录队列的地方、没人会估交付日期、客户还蒙在鼓里。理想和现实之间，横着一地石头。这一章的工具，专门用来把石头摸清楚、排好搬运顺序：前提条件树（英文 Prerequisite Tree，缩写 PRT，字面「先决条件树」——要达成目标，必须先满足哪些前提，按什么顺序满足）。
这里，障碍是好东西
前面几棵树都在跟各种「坏东西」较劲——坏结果、坏冲突、坏副作用。前提条件树反过来：它主动欢迎障碍，越多越好。
为什么？因为它用的是必要条件逻辑——「要想达成目标，就必须先跨过某个障碍」。每一个障碍，都是通往目标路上一块必须搬开的石头；石头认得越全，路才画得越准。所以这棵树的第一步，是使劲往外倒障碍：把所有「这事儿办不成，因为……」的理由，一条不落全写下来。给救火小组落地那套注入，障碍清单大概是：
- 老板和销售习惯了「客户要就得马上做」，根本不同意排队。
- 没有一个地方能把所有需求记下来、给所有人看。
- 没人知道「同时开几个」才算合适。
- 没人会根据队列估出一个靠谱的交付日期。
- 真遇到老板拍板插队，规则当场破功。
- 客户完全不知道新规矩，可能一上来就抵触。
把每块石头翻个面：中间目标
障碍本身是负面的（「没有……」「不会……」「不同意……」）。前提条件树的巧劲，是把每块石头翻个面——问一句：「要跨过这个障碍，得先达到一个什么状态？」这个状态，就是中间目标（英文 Intermediate Objective，缩写 IO，一个为了扫清某个障碍而必须先到达的里程碑）。障碍和中间目标一一对应：
障碍「老板销售不同意排队」→ IO：老板和销售认同并公开支持排队规则。
障碍「没地方记录需求」→ IO：有一块所有人可见的需求看板。
障碍「不知道开几个合适」→ IO：定出一个明确的在制品上限。
障碍「不会估日期」→ IO：有一套用历史完成速度推算交付日期的简单方法。
障碍「插队破功」→ IO：有一条公开、有限的加急规则。
障碍「客户不知情」→ IO：客户被告知并接受新的排期与加急规则。
看出转变没有：一份让人泄气的「办不成的六个理由」，被翻译成了一份让人有底的「必须先拿下的六个里程碑」。这一步的心理价值不小——障碍让人瘫痪，中间目标让人有方向。而它俩其实是同一块石头的正反面。
排序：先搬哪块，后搬哪块
六个中间目标不是并列的，也不能一拥而上——它们之间有依赖关系。前提条件树最后、也是最关键的一步，就是用必要条件逻辑，把这些 IO 排出先后：问「要想达成这个 IO，是不是必须先达成另一个 IO？」是，就画一根箭头，从「先」指向「后」。
要想「客户接受新排期规则」，就必须先「团队内部真的有了看板、在制品上限和估算方法」——不然拿什么给客户承诺？
要想「有靠谱的估算方法」，就必须先「有看板和在制品上限」——没有队列数据，估不出来。
而要想「建看板、定上限、改规则」，就必须先「老板和销售认同排队」——老板不点头，这些动作根本推不动。
顺着箭头一捋，一条清清楚楚的路就浮出来了：
① 先说服老板和销售认同排队 → ② 建看板、定在制品上限、立加急规则 → ③ 用积累的数据搞出估算方法 → ④ 拿着这套内部机制去和客户沟通、取得接受 → 🎯 注入落地。
请注意这个顺序不是按重要性排的，是按依赖排的——回答的是「必须先迈哪只脚」。你可能觉得「说服客户」最重要，但它排在最后，因为在你自己都没有一套能说清楚的机制之前，去找客户谈只会更砸。前提条件树逼你认清：有些事再重要，也得等它的前提先就位。这正是无数改革死掉的地方——顺序错了，第一步就踩空。
它给你的，是一张地图，还不是脚步
前提条件树画完，你手里有了一张从今天到目标的里程碑地图：几个中间目标，按必须的先后串成一条路。这已经比绝大多数人的「计划」靠谱得多——因为每个里程碑都对应一块真实的石头，每一段顺序都有必要条件撑着，不是拍脑袋排的。
但地图上的一个个里程碑，比如「说服老板认同排队」，还是太大——它本身还不是一个动作。你没法「今天下午三点，说服老板」。从「里程碑」到「今天下午三点具体干这件事」，还差最后一次拆解。那是最后一棵树，转变图，要干的活儿。