> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 衝突解決圖

> 衝突解決圖把共同目標、兩項需求和兩個對立做法放在一張圖上，用來檢驗「只能如此」的假設是否成立。了解其起源、步驟、用法與邊界。

<Info>
  **類別**: 方法<br />
  **類型**: 衝突結構化方法<br />
  **起源**: Eliyahu M. Goldratt，蒸發雲，1990；經《It's Not Luck》（1994）廣泛傳播<br />
  **別名**: 蒸發雲、衝突雲
</Info>

<Note>
  **快速回答** — **衝突解決圖**（Conflict Resolution Diagram）把一場僵持畫成一個共同目標、兩項需求，以及兩個看起來不能並存的做法。Eliyahu M. Goldratt 在 1990 年把它作為蒸發雲，放進約束理論。核心啟示是：衝突常常被一條假設撐住；換上一個新條件，可以讓這條假設失效，同時讓兩項需求都還在。
</Note>

## 什麼是衝突解決圖？

**衝突解決圖**（Conflict Resolution Diagram）是一張邏輯圖：寫明一個共同目標、這個目標所要求的兩項需求，以及兩個看起來無法同時成立的做法。

> 衝突通常落在兩個做法上。共同目標和兩項需求，可以同時成立。

可以把它想成一根綁在樁上的拔河繩。兩邊都在拉，是因為都想讓帳篷立住。這張圖問的是樁子牢不牢。標準畫法有五句話：目標 A；需求 B 和 C，二者都是 A 所必需的；做法 D 和 D′（讀作 D prime，即另一方的做法）。D 是一方認為為了保住 B 必須採取的行動，D′ 是另一方認為為了保住 C 必須採取的行動。不能同時做的，就是這一對做法。語句之間的連線是必要性主張，讀法是：為了得到這個，我們必須得到那個，因為某條假設。

人們通常從做法走進來：錄用或拒絕，大批量或小批量，留下或離開。這張圖把談話從做法挪到需求，再挪到「因為」。這和[力場分析](/zh-hant/methods/force-field-analysis)不同，力場分析列出支持一項改變和反對它的壓力。它也不是給方案打分。這裡要找的，是哪一個「必須」在製造傷害。

### 衝突解決圖的三層理解

* **入門**：寫下兩個要求、每個要求所保護的需求，以及雙方都肯簽字的一個目標。先把五句話讀出來，再爭論誰贏。
* **實踐**：在每條箭頭下把句子補成「因為……」。選一條本週能檢驗的假設。設計一個仍然服務兩項需求的新條件，然後檢查沒有哪一項需求被悄悄砍掉一半。
* **進階**：箭頭聲稱的是必要，比「更喜歡」強得多。長期衝突往往是因為一個有用的做法被升級成了唯一做法。目標若只是「成功」這類空話，任何新主意都會顯得高明，因為沒人能判斷 A 有沒有發生。

## 起源

衝突解決圖來自 Eliyahu M. Goldratt 的[約束理論](/zh-hant/methods/theory-of-constraints)。他用這張圖，為兩難尋找一條簡單的出路。

這張圖在他 1990 年的書《What is this Thing Called Theory of Constraints and how should it be implemented?》（North River Press）裡單獨成章，那一章講的是如何發明簡單解。1994 年的商業小說《It's Not Luck》把這個工具，連同他的其他思維流程，帶給了更廣的管理者讀者。Goldratt 自己的名字是蒸發雲。後世記述跟隨 Lisa Scheinkopf 的《Thinking for a Change》，把這個名字追溯到 Richard Bach 1977 年的小說《Illusions》：書中人物把雲從思考裡拿掉，雲就散了。用意相近。檢查假設，兩難就可能消失。H. William Dettmer 的《The Logical Thinking Process》（2007）是這套工具的標準手冊，並把同一張圖也稱作衝突解決圖。

Goldratt 最著名的例子是批量之爭，共同目標是降低單位成本。一項需求是降低單位換型成本，也就是把機器或流程切換到下一單所需的時間與費用；對應的做法是大批量生產。另一項需求是降低單位持有成本，也就是存貨占用的空間、資金，以及貨品過時的風險；對應的做法是小批量生產。他接著追問「因為」。一條假設是換型成本降不下來，另一條是「批量」只有一個意思。縮短換型，打的是第一條。把兩種批量拆開，打的是第二條。生產批量是兩次換型之間做多少；轉移批量是移到下一工序多少。這兩個數量不必相同。取一個中等批量，只是把兩個做法各砍一刀。

## 核心要點

當每一條箭頭都被當成可能出錯的主張，而且你不肯停在一個讓兩項需求都受傷的折中上，這張圖才有用。

<Steps>
  <Step title="先寫下兩個做法">
    把兩個要求寫成樸素的行動，並排放好。「接受全職實習」和「這學期留在必修課裡」。先不要改成口號，也不要先給任何一方貼上「合理」。如果還說不清每一方究竟提議做什麼，後面的格子就還沒到時候畫。
  </Step>

  <Step title="找回需求與共同目標">
    問每個做法在保護什麼。實習可能保護收入和一封推薦。課程可能保護讓畢業不延期的學分。再命名一個同時需要二者的目標：離開學校時能夠工作，並且仍然能畢業。這是原則式談判熟悉的動作，也是[雙贏](/zh-hant/strategies/win-win)所要求的動作。如果任何一方都不肯在任何一個共同目標上簽字，就停下來。你面對的可能是兩場分開的爭執。
  </Step>

  <Step title="給每條箭頭補上因為">
    把這句話讀出聲：為了按時畢業，我必須這學期留在這門課裡，因為它只在現在開設。Jelena Fedurko 在《Behind the Cloud》（2011）裡建議把這些句子讀出來，讓耳朵和眼睛一起檢查邏輯。每一個「因為」都是候選人。[逆向思維](/zh-hant/thinking/inversion-thinking)在這裡有用：問什麼會讓這個「因為」為假，以及什麼樣的證據能表明這一點。「換型成本降不了」「這門課不能替換」「訓練必須練到晚上八點半」，都是關於世界的主張，不是固定的家具。
  </Step>

  <Step title="拆掉一個必須，再核對兩項需求">
    在這套方法的用語裡，注入是一個新條件，它讓某條假設不再具有約束力。夜間班、替代課程或每週三天的實習，都可以是注入。更短的換型，或小於生產批量的轉移批量，也是。選定一個之後，問兩項需求是否仍然完整。對半拆分常常讓收入太薄、學分也太薄。只有當你還能指著兩項需求、並且仍然認得它們時，才留下這個注入。
  </Step>
</Steps>

## 應用場景

當同樣的兩個提議反覆回來，雙方都能說出一項真實需求，而對半切割會讓這項需求落空時，就用衝突解決圖。

<CardGroup cols={2}>
  <Card title="一個學期裡，別丟掉任何一個目標" icon="graduation-cap">
    把「全職實習」和「必修課」對放。需求是：一份帶薪的推薦，以及守住畢業日期的學分。檢驗三條「因為」：這門課只在這學期開、實習必須全職、任何替代都不算數。夜間班或每週三天值得一試，前提是報酬和學分都仍然真實。
  </Card>

  <Card title="把安全時間從每項任務裡挪出來" icon="clock">
    員工給每項任務加餘量，好讓承諾扛得住意外。專案經理砍掉餘量，好讓計畫看起來能被批准。需求是可靠交付，以及領導層願意支持的進度。檢驗「安全時間必須藏在每一項任務裡」這個想法。Goldratt 在《Critical Chain》（1997）裡提議把安全時間集中到一個專案緩衝，這是可以試的一種注入。改完之後，看誠實的估算和交付承諾是否都還在。
  </Card>

  <Card title="給工作日晚上的爭吵命名需求" icon="house-chimney">
    「九點上床」對著「訓練練到八點半」。需求是夠第二天上課的睡眠，以及隊裡的一個位置。目標是孩子撐得住的一週。可檢驗的假設：每次訓練都必修、七天作息完全相同、唯一的接送是六點下班出發。用兩週試一個可逆的改變，例如共乘，或只在比賽日晚睡。只有睡眠和隊伍都保住時才留下它。
  </Card>

  <Card title="把加工批量與移送批量分開" icon="hospital">
    診所可能因為換型貴，把檢體攢到下午一次做完；病房卻希望晨間查房前看到結果。需求是：實驗室不被換型吃掉，以及用當天的化驗做決定。檢驗「檢體必須按加工時的那一整批來運送」。一邊保持合理的加工批量，一邊分成更小的組運送，就是要試的注入。用從取樣到出結果的時間來判斷，而不是用儀器啟動了幾次。
  </Card>
</CardGroup>

## 經典案例

2014 年的一個案例裡，一家公用事業公司的資訊技術經理，把衝突解決圖用在一個行動應用專案上。這位經理找到了 2.5 萬美元的預備金，並得出結論：專案可以分期上線，延遲不超過 45 天。

路易斯維爾大學的 Mahesh Gupta 與 Sharon Kerrick 在《Journal of International Technology and Information Management》報告了這件事，沒有寫出公司名稱。經理用一個引導式的網頁應用畫出這張圖，把衝突寫成故事，並列出每條箭頭下的假設。隨後的注入，挑戰的是某一條「需求—做法」連線上的兩條假設。

這筆錢和分期計畫就是注入：一個新條件，兩項需求都應當仍然認得出來。作者記下了一條限度。熟悉約束理論的人，可能會把關鍵鏈當作這個專案以及周圍專案更強的注入。決策者沒有走那條路，因為時間緊，而且他們對這套更廣的方法所知不多。公開記錄停在這個決定上，並沒有說明應用後來是否在這 45 天內交付。這個案例說明，這張圖可以把一場卡住的爭論變成一個有經費、有邊界的計畫。交付上是否測到了改進，是下一步的問題。

## 邊界與失效場景

當衝突是真實約束、當雙方並不共享一個目標、或者這張圖只是用來裝飾一個已經做出的選擇時，衝突解決圖會失效。

1. **有些互斥是物理的、法律的，或與安全直接相關。** 同一個人不能在同一小時出現在兩座城市。無菌流程不會因為有人把規定叫成「假設」就變成可選項。你仍然可以畫這張圖，看清規定在保護哪一項需求。你不能靠改名刪掉規定。如果一條「因為」經受住了真正的檢驗，約束就留在原地。[二階思維](/zh-hant/thinking/second-order-thinking)接著問：一個巧妙的變通，下一步會打破什麼。
2. **目標必須是雙方真正願意擁有的那一個。** 如果一方不接受任何包含對方需求的 A，你看到的是兩個目標。「卓越」或「對齊」這類口號會把這件事遮住。[抽象分層](/zh-hant/methods/abstraction-laddering)是一項檢查：如果房間裡沒有人能對 A 採取行動，目標就飄在職權之上。

常見誤用是**起訴式的圖**。你把自己的做法寫成唯一專業的選擇，把對方的需求寫成恐懼、政治或固執。對方不會重複那句話。這張圖於是加固了它本來要打開的爭執。用對方願意簽字的詞寫下他們的需求。Goldratt 勸人不要停在妥協上，因為對半拆分常常讓兩項需求都只滿足一部分；這個立場並不是「每條假設都為假」的證明。當那些「因為」碰到證據仍然成立，又找不到可行的注入時，有邊界的妥協或分先後的選擇，才是誠實的結果。

## 常見誤區

多數失敗的圖來自三個錯誤：把對半拆分叫作勝利，把每條假設都當成有罪，以及把對方的需求畫成漫畫。

<AccordionGroup>
  <Accordion title="誤區：對半分已經算雙贏">
    公平的對半，分的是兩個做法。每一方都放棄自己提議中的一部分。這張圖先問另一個問題：這個做法在服務哪一項需求，有沒有一個條件能讓這項需求完整留下來？半份實習加上一門沒考的課，看起來平衡，兩項需求卻都失敗了。假設成立、時間又用盡時，再用對半。不要把它當成反射動作。
  </Accordion>

  <Accordion title="誤區：找不到假假設，方法就失敗了">
    有些假設今天就是真的。換型確實要四小時。這門課確實一年只開一次。方法仍有下一步。注入可以改變世界，讓一條真假設不再綁住人：縮短換型、加開一個班、給一個階段撥經費。發現沒有假的、也改不了，本身也是結果。它告訴你衝突是真的。下一步是硬約束，或一次因果調查。更聰明的口號移動不了它。
  </Accordion>

  <Accordion title="誤區：對方的需求只是打扮過的要求">
    要求是 D 或 D′。需求是這個要求試圖保護的條件。把二者揉成一個，就回到了爭論方案。虛假兩難是把兩個做法當成僅有的做法。這張圖檢驗的就是這個習慣。它並不保證兩難一定是假的。用對方認得出來的話寫下對方的需求，再檢驗「因為」。一條被你改寫成缺點的需求無法被滿足，衝突就會留在原地。
  </Accordion>
</AccordionGroup>

## 相關概念

旁邊這些頁面分別是：它所屬的系統方法、它要追求的結果，以及回答另一個問題的工具。

<CardGroup cols={3}>
  <Card title="約束理論" icon="link" href="/zh-hant/methods/theory-of-constraints">
    透過管理當前約束來改進系統。衝突解決圖是其中的思維工具，對準的是政策衝突，而不是一台機器的速度。
  </Card>

  <Card title="雙贏" icon="people-carry" href="/zh-hant/strategies/win-win">
    尋找雙方願意再次選擇的結果。這張圖靠挑戰一條必要性去找這個結果，而不是把兩個要求取平均。
  </Card>

  <Card title="力場分析" icon="arrows-alt-h" href="/zh-hant/methods/force-field-analysis">
    列出支持和反對一項改變的力。用它來權衡一個提議。當兩個做法都聲稱對共同目標是必需的，再用衝突解決圖。
  </Card>

  <Card title="二階思維" icon="layer-group" href="/zh-hant/thinking/second-order-thinking">
    追問注入接下來會造成什麼。局部的和平可能在下一步製造新衝突，或保護了並不是真正約束的工作。
  </Card>

  <Card title="虛假兩難" icon="scale-balanced" href="/zh-hant/fallacies/false-dilemma">
    這個謬誤把兩個選項說成僅有的選項。衝突解決圖是對這種說法的檢驗。有時檢驗會確認：兩個做法確實互相排斥。
  </Card>

  <Card title="五問法" icon="question-circle" href="/zh-hant/methods/five-whys">
    沿著因果鏈走向一個可以修好的點。衝突解決圖沿著必要性箭頭，走向一條可以退役的假設。一個問它為什麼壞了，一個問這個做法為什麼是強制的。
  </Card>
</CardGroup>

## 一句話總結

<Tip>
  **寫下兩個要求、各自底下的需求，以及共同目標。然後退役一條「因為」，並檢查兩項需求是否仍然完整。**
</Tip>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.