现状图把病根逼到了一个死结上：团队一边觉得「客户要什么都得马上接」，一边又觉得「得限制同时开工的活儿才交付得好」。两边都松不了手，年复一年地卡着。这一章，我们要给这个死结画一张精确的结构图，看清它到底卡在哪。这张图叫冲突图（英文 Evaporating Cloud，直译「蒸发云」，也叫云图——因为一个长期冲突就像头顶一片赶不走的乌云）。
冲突不是「好人对坏人」
先破一个直觉。我们一想到冲突，脑子里就是两方在抢：销售想接单，技术想拒单，谁赢谁输。可真正卡住系统的冲突，几乎从不是这种。它是两个都对的目标，各自要求你做相反的动作。销售要接单，是为了公司活下去；技术要控量，也是为了公司活下去。两边要的东西你都反驳不了——这才是它蒸发不掉的原因。
冲突图就是把这个结构原原本本摆出来，一共五个方框。它用的是上一章说的必要条件逻辑——「要想…就必须…」，不是「如果…那么…」。别读错了。
五个方框，两条腿站在一个目标上
五个方框这么排：最左边一个共同目标（A），中间上下两个需求（B 和 C），最右边上下两个行动（D 和 D′）。给救火小组填进去：
A 目标：让团队做出既被客户信任、又能长期干下去的交付。
B 需求（上）：客户觉得自己被重视、诉求被及时响应。
C 需求（下）：交付质量稳定、进度可预期，不延期不出 bug。
D 行动（上）：客户提的需求都马上接下来、都插进来现在做。
D′ 行动（下）：限制同时开工的数量，需求排队、按序做。
现在把它读出声，这是用云图的关键动作。从右往左，每根箭头都是一句「要想……就必须……」：
- 要想让团队交付被信任又能长久（A），就必须让客户觉得被重视（B）；要想让客户觉得被重视（B），就必须把需求都马上接下来现在做（D）。
- 要想让团队交付被信任又能长久（A），也必须让质量和进度可预期（C）；要想质量进度可预期（C），就必须限制同时开工、让需求排队（D′）。
- 但是 D 和 D′ 直接打架：你不可能既「全都现在做」，又「排队慢慢做」。
读一遍你就明白这死结妙在哪：B 和 C 是同一个目标 A 的两条腿，缺一条 A 就站不住。所以你没法说「B 不重要，砍了」——砍掉客户满意，公司照样完；也没法说「C 不重要」——砍掉质量，公司也完。两条腿都得留，可两条腿又要求你迈向相反的方向。这就是为什么单靠「决心」「态度」永远解不开：它不是意志问题，是结构问题。
为什么「各退一步」是个陷阱
面对这种死结，人的第二反应是折中（compromise，各让一步、取个中间值）。既然不能全接也不能全排队，那就……接一半、排一半？紧急的插队，不急的排队？
约束理论对折中的态度非常鲜明：折中几乎总是烂方案。道理很简单——B 需要 D「全都马上做」，你只做一半，客户的「被重视感」就只满足了一半，B 没吃饱；C 需要 D′「严格控量」，你只控一半，质量和进度还是保不住，C 也没吃饱。结果两个需求都半死不活，共同目标 A 自然也只剩半条命。折中不是解，是两头都得罪的休战。你在真实世界里见过的绝大多数「平衡」「兼顾」，其实都是这种谁也没喂饱的折中，所以那片乌云过几个月又飘回来了。
那到底怎么办？云图的目标名字已经剧透了——让冲突「蒸发」，而不是让谁赢、也不是各退一步。蒸发的意思是：找到一个新做法，让 B 和 C 两个需求同时被完全满足，那片乌云就凭空散了，压根不存在了。这种做法，约束理论叫双赢（win-win，两边的需求都吃饱，不是各让一步的双输）。
缝在哪里
可 D 和 D′ 明明水火不容，双赢的口子从哪撕开？答案藏在那几根「要想…就必须…」的箭头里。每一根箭头看着天经地义，其实底下都压着一个没说出口的假设——一个「因为……所以才必须」的隐含理由。比如「要想客户觉得被重视（B），就必须马上都做（D）」这根箭头，底下压着的假设是：「客户觉得被重视」只能靠『立刻动手做』来实现。
只要这个假设不是铁律——只要「被重视」还有别的实现方式——这根箭头就断了，D 就不再是 B 的唯一出路，冲突的一条腿当场松开。
所以云图真正的战场，不在五个方框上，而在箭头底下那些没人明说的假设。把它们一条条挖出来、一条条挑战，直到找到那个一戳就破的——那就是让整片乌云蒸发的注入（injection，一个能打破假设、让双赢成立的新做法）。这正是下一章要动的手术。