回到那个救火的小组。老板让你「把问题梳理一下」。你摊开纸，写下所有让人头疼的事——这就是种第一棵树的起点。
先把「坏事」摆出来，别急着找原因
约束理论给这些让人头疼的事起了个名字：不良效应（英文 Undesirable Effect，缩写 UDE，直白说就是「大家一致同意这是件坏事」的现象）。注意，是效应，是结果，不是原因。写 UDE 有三条纪律：每条是一句完整、能独立成立的陈述；是明摆着的坏结果，不是你猜的原因；而且得是真事，不是情绪。
小组的 UDE 清单大概长这样：
- 版本几乎每次都延期。
- 上线后线上频繁出 bug。
- 大量时间花在回滚和返工上。
- 团队长期加班。
- 需求在开发途中频繁变更。
- 士气低落，有人在考虑离职。
- 客户和老板对团队的信任在下降。
七条坏事，看着是七个独立的火，七个人分别去扑。现状图（英文 Current Reality Tree，缩写 CRT，就是「把当下这堆坏事的因果关系画成一棵树」）要干的事，是证明这七个火其实是同一根引线点着的。
顺着「如果…那么…」往下挖
怎么挖？拿起任意两条 UDE，问它们之间有没有因果关系，用上一章的充分因果箭头连起来，读成「如果…那么…」。连不上的，就往下补一层更深的原因，直到能连上。全程守住 CLR 那几条——尤其是「原因够不够」和「是不是还有别的原因」，逼自己别漏掉半个因。
挖几铲子就成型了。比如「延期」和「出 bug」看似两码事，往下一挖：
如果「版本已经延期」，那么「团队更不敢再拖，拼命赶上线日期」；
如果「拼命赶上线日期」，那么「留给测试的时间被压掉」并且「代码在压力下赶工」；
如果「测试时间被压掉」并且「代码赶工」，那么「上线频繁出 bug」。
接着，「出 bug」自己又往回咬：
如果「上线频繁出 bug」，那么「大量时间花在回滚和返工上」；
如果「时间花在返工上」，那么「下个版本的活儿被挤占」；
如果「下个版本被挤占」，那么「版本又延期」。
看出来了吗——箭头绕回了起点。延期→赶工→出 bug→返工→挤占→又延期。这是一个恶性循环：坏结果反过来喂养自己的原因，越转越紧。现状图最有价值的时刻，就是它把散落的坏事连成这样一个自我加强的圈——你终于看清，为什么单点用力永远没用，因为你砍的那一刀，圈子转一圈又给补回来了。
一直挖到那个「病根」
循环也不是凭空转的，得有东西先把它踹起来。继续往下问：为什么一开始就延期、就得赶？接着挖：
如果「几乎每个需求都被标成『紧急、现在就要』」，那么「团队同时开着一大堆活儿」；
如果「同时开着一大堆活儿」，那么「每个人的注意力被切成碎片，什么都做不完」；
如果「什么都做不完」，那么「版本从一开始就延期」。
再往下，「需求频繁变更」「客户不信任」这些也能接进来：交付越慢，客户越焦虑，越要中途插队改需求；需求越插队，同时开的活儿越多——又是一个圈。
把所有箭头画完，你会发现一个惊人的事实：七条 UDE，顺着树往下追，绝大多数最后都汇到同一个方框上——「几乎每件事都被当成最高优先级、都要求现在就做」。这个方框，就是核心问题（core problem，那个通过因果链为大部分坏结果负责的根源）。约束理论有个经验判据：如果某个东西能解释掉七成以上的 UDE，它就是核心问题。
这就是「改什么」的答案。不是「测试不严」，不是「员工不努力」，不是「工具不好」——那些都是半路上的枝干。真正的病根是：这个系统拒绝对『先做什么、后做什么』做取舍，什么都要、什么都急。上工具、加卡点、发奖金之所以越治越糟，正因为它们全砍在枝干上，没一个碰到这个根。
找到病根，麻烦才刚开始
你可能想：那还不简单，别什么都急不就行了？可只要你真去跟老板说「以后需求得排队、不能都是紧急」，立刻会有一百个理由怼回来——客户等不了、竞争对手在追、这个大客户得罪不起……
这说明核心问题往往不是一个能一刀砍掉的错误，而是一个谁都松不了手的死结：一边是「必须限制同时开工的活儿，才能真正交付」，另一边是「必须什么都接、都答应现在做，才能让客户满意」。两边听起来都对，于是系统就卡在这儿，年复一年。
这个死结，就是下一棵树——冲突图——要对付的东西。现状图告诉你病在哪，冲突图才告诉你为什么这么难破，以及从哪儿破。