Contextualisation 四點法讓 Cynefin 框架從資料中長出來的工作坊方法

一、為什麼需要四點法

大多數人第一次接觸 Cynefin,會把它當成一張四格分類表:牆上先畫好 Clear、Complicated、Complex、Chaotic 四個格子,再把手上的問題一個個丟進去。Dave Snowden 明確反對這種用法。他的理由是,當你拿著現成的格子做分類,你其實只是在確認自己的既有偏見——工程師習慣把所有問題當成 Complicated 來分析,管理者習慣把所有問題當成 Clear 來套流程,分類結果反映的是分類者的思考慣性,而非情境本身的性質。

Contextualisation(情境化)四點法就是為了解決這個問題設計的工作坊流程,最早發表於 Kurtz 與 Snowden 2003 年刊登在 IBM Systems Journal 的論文《The New Dynamics of Strategy》。它的核心設計只有一句話:框架的邊界由參與者根據自己的真實資料畫出來,而非事先畫好格子再塞資料。做完之後,同一組人會對「在我們的脈絡裡,什麼算複雜、什麼算繁雜」形成具體的共同判斷,這比背誦四個領域的抽象定義有用得多。

二、工作坊流程:四個步驟

以下用一個貫穿全文的範例來說明:某軟體開發部門正在導入 AI coding,主管想釐清手上一堆議題各自該用什麼方式處理。參與者包括工程師、QA、PM 共十二人,牆面、六角便利貼(hexies)、筆,大約需要 90 到 120 分鐘。

步驟一:收集真實情境,牆上不畫任何框架

請每位參與者把最近實際遇到的議題、決策、事件寫在便利貼上,一張一件事。重點是「真實發生的具體情境」,而非抽象概念——寫「上週三 CI 連續失敗四次」比寫「建置穩定性」好。這個階段牆面完全空白,不出現任何 Cynefin 字眼,避免參與者一開始就套框架思考。

在我們的範例中,團隊寫出了十二張便利貼:CI 失敗的處理、資料庫效能調校、AI 導入後的團隊協作、正式環境停擺事件、新人入職流程、API 限流演算法選型、跨團隊技術債優先順序、AI code review 規範導入、資安漏洞緊急處理、分支策略調整、客戶對 AI 產出的信任、雲端供應商選擇。

圖一:步驟一——議題先上牆,不做任何分類

步驟二:挑出四個「極端範例」放到四個角落

這是「四點法」名稱的由來。引導者請全體從牆上所有便利貼中,挑出四個最極端的案例,分別放到牆面的四個角落。挑選時不提領域名稱,只問四個問題:

哪一件事的因果關係最明顯,任何人照著做都會得到相同結果?
哪一件事最需要專家分析才能理解?
哪一件事只能事後回顧才看得懂,事前無法預測?
哪一件事發生當下完全失控,連因果都感知不到?

這四張便利貼成為後續所有判斷的「錨點」。範例團隊的選擇如下表:

領域	極端範例(錨點)	挑選時問的問題
Clear	CI 失敗時依 runbook 重跑	哪一件事因果最明顯,任何人照著做都會得到相同結果?
Complicated	資料庫查詢效能調校	哪一件事最需要專家分析?不同專家可能給出不同但都有效的解法?
Complex	AI 導入後的團隊協作變化	哪一件事只能事後回顧才看得懂?事前分析再多也無法預測結果?
Chaotic	正式環境全面停擺	哪一件事發生當下完全失控,連因果都感知不到?

圖二:步驟二——四個極端範例定錨四角,牆上仍然沒有格線

步驟三:其餘項目相對於錨點逐一擺放

接著把剩下的便利貼一張張拿出來,請大家討論:「這件事比較靠近哪個角落?」位置是相對的——「新人入職流程」比 CI runbook 多一點變化,但遠比效能調校單純,所以放在 Clear 錨點附近偏內側;「客戶對 AI 產出的信任」牽涉人的認知與行為,靠近 Complex 錨點。

這個步驟最有價值的部分是爭論本身。範例中,「AI code review 規範導入」引發了最激烈的討論:資深工程師認為這是 Complicated——找對工具、訂好規則就能解決;PM 則認為這是 Complex——規範會改變工程師的行為,而行為變化無法事前預測。這種爭論不需要立刻裁決,先把便利貼放在兩個錨點之間即可。

圖三:步驟三——每張便利貼相對於錨點定位,移動與爭論就是集體判斷的過程

步驟四:群體共同畫出邊界

所有便利貼就定位後,才請參與者拿筆在便利貼之間畫出邊界線。畫得出共識的地方,領域就此「湧現」;畫不出共識的地帶,圈起來標記為 Confused(尚無共識)。範例中,「AI code review 規範導入」正好落在中央爭議區——這個結果本身就是重要產出,它告訴團隊:先別急著制定全面規範,用小範圍試行(probe)來探測,比開會辯論更快得到答案。

圖四:步驟四——邊界由參與者畫出,領域湧現;畫不出共識的中央地帶標記為 Confused

三、如何判讀結果

工作坊結束後,牆上的產出有三層意義:

落點決定行動模式:落在 Clear 的項目交給標準流程與 runbook;Complicated 的項目安排專家分析;Complex 的項目設計 safe-to-fail 實驗;Chaotic 的項目建立緊急應變機制,先止血再說。
邊界位置是團隊的共同校準:兩個團隊做同樣的練習,邊界可能畫在不同位置,這很正常。邊界反映的是這個團隊在這個脈絡下的能力與經驗——對資深 DBA 團隊來說是 Clear 的事,對新手團隊可能是 Complicated。
爭議區是最值得投資的訊號:放不進任何領域的項目,通常代表團隊對它的因果認知還不足,最適合用小成本的 probe 來探測,而非繼續開會分析。

四、引導時的常見狀況與訣竅

有人堅持先問「四個格子是什麼」:引導者可以回答「等一下你們自己會畫出來」。過早引入領域定義,整場工作坊就退化成分類練習。
極端範例挑不出來:通常代表步驟一收集的情境不夠具體或不夠多樣。可以請參與者補寫「最近一次讓你完全措手不及的事」和「最近一次照 SOP 就解決的事」。
一張便利貼被反覆移來移去:不要催促收斂。移動軌跡本身就是資料,可以請當事人說明每次移動背後的理由,這些理由往往揭露團隊內部對同一件事的認知落差。
所有便利貼都擠在同一區:常見於同質性太高的團隊(例如全是工程師)。解法是邀請不同角色參與,或請大家補寫其他角色視角的情境。

五、與 Future Backwards、Estuarine Mapping 的搭配

四點法在 Snowden 的方法體系中扮演「診斷」角色,通常放在最前面。三個方法串起來是一條完整的工作路徑:

Contextualisation 四點法:釐清眼前的議題各自屬於什麼性質的情境,建立團隊的共同判斷基礎。
Future Backwards:針對落在 Complex 域的議題,拓寬團隊對可能未來的認知範圍,鬆動既有敘事。
Estuarine Mapping:盤點 constraints 與 constructors,用能量與時間兩軸決定介入點,產出可執行的行動組合。

換句話說,四點法回答「這是什麼樣的問題」,Future Backwards 回答「未來可能長什麼樣」,Estuarine Mapping 回答「現在該從哪裡動手」。

六、參考資料

Kurtz, C. F., & Snowden, D. J. (2003). The new dynamics of strategy: Sense-making in a complex and complicated world. IBM Systems Journal, 42(3), 462–483.
Snowden, D. J., & Boone, M. E. (2007). A Leader’s Framework for Decision Making. Harvard Business Review, November 2007.
The Cynefin Co. — Cynefin contextualisation 方法說明與工作坊資源(thecynefin.co)。