Cynefin 決策框架 Cynefin Framework

什麼時候該用它？

Cynefin（發音近似「可涅文」，威爾斯語「棲地」的意思）最適合在你覺得「我們好像用錯方法在解這個問題」的時候拿出來。它的威力不在於告訴你怎麼解決問題，而是幫你先判斷「這個問題屬於哪種類型」——然後用對應的決策方式。

• 團隊決策方式不一致：工程師想要數據分析、設計師想要使用者訪談、老闆想要快速行動——先用 Cynefin 判斷問題類型，再決定方法
• 新專案啟動：不確定該用瀑布式還是敏捷，Cynefin 幫你根據問題性質選擇
• 危機處理：系統崩潰或市場突變時，避免團隊陷入「分析癱瘓」或「盲目行動」
• 流程設計：決定哪些工作該標準化（SOP）、哪些該給團隊自由度
• 跨部門衝突：不同部門對同一問題有不同看法，可能是因為他們各自面對的情境屬於不同 domain

框架結構

Cynefin 把所有問題情境分成五個 domain，每個 domain 對應不同的因果關係和最佳決策模式。

五個 Domain

1. Clear（明確）— 已知的已知

因果關係明確，有最佳實踐可循。

• 特徵：問題有標準答案，做 A 就會得到 B
• 決策模式：感知 → 分類 → 回應（Sense → Categorize → Respond）
• 實例：訂單處理流程、退貨政策執行、基本客服 FAQ
• 做法：直接套用最佳實踐（Best Practice），用 SOP 和自動化處理

2. Complicated（繁雜）— 已知的未知

因果關係存在但不明顯，需要專家分析。

• 特徵：有正確答案，但需要專業知識才能找到
• 決策模式：感知 → 分析 → 回應（Sense → Analyze → Respond）
• 實例：效能優化、搜尋演算法調整、供應鏈重新設計
• 做法：找專家、做分析、考慮多種「好的實踐」（Good Practice，注意不是「最佳」）

3. Complex（複雜）— 未知的未知

因果關係只能事後回顧才看得出來。

• 特徵：沒有可預測的正確答案，結果會因環境而異
• 決策模式：探測 → 感知 → 回應（Probe → Sense → Respond）
• 實例：新市場進入、使用者行為預測、組織文化變革
• 做法：設計安全的實驗、觀察結果、放大有效的做法、抑制無效的

4. Chaotic（混亂）— 沒有因果關係可辨識

緊急狀態，沒時間分析。

• 特徵：情況在快速變化，等著分析只會更糟
• 決策模式：行動 → 感知 → 回應（Act → Sense → Respond）
• 實例：重大系統事故、資安漏洞爆發、突發公關危機
• 做法：先穩住局面（止血），再把情境從混亂拉回複雜或繁雜

5. Disorder（失序）— 不知道自己在哪個 domain

最危險的狀態——你不知道問題屬於哪種類型。

• 特徵：團隊各自用自己習慣的方法處理，沒有共識
• 做法：把問題拆小，分別歸入其他四個 domain

Domain 之間的轉移

問題不會永遠待在同一個 domain。關鍵的轉移：

• Clear → Chaotic（懸崖）：過度自滿、忽略變化訊號，突然崩潰。這是 Cynefin 最重要的警告
• Chaotic → Complex：危機穩定後，進入實驗探索階段
• Complex → Complicated：找到有效模式後，可以開始系統化
• Complicated → Clear：完全理解後，建立 SOP

來源與歷史

• 1999：Dave Snowden 在 IBM Global Services 的知識管理部門開始發展 Cynefin，作為組織決策的分類框架
• 2003：Snowden 離開 IBM，創立 Cognitive Edge，將 Cynefin 發展為完整的複雜性管理方法論
• 2007：Snowden 與 Mary Boone 在《Harvard Business Review》發表〈A Leader’s Framework for Decision Making〉，讓 Cynefin 進入主流管理學
• 2014：敏捷社群大量採用 Cynefin 來判斷何時該用 Scrum、何時該用 Kanban、何時該用別的方法
• 2020：COVID 疫情讓 Cynefin 的「混亂域」和「複雜域」概念被廣泛引用，各國政府和企業用它來理解為什麼標準的危機管理框架失效

真實案例：Spotify 的工程文化

Spotify 的工程組織設計是 Cynefin 思維的經典應用（雖然他們沒有明確說在用 Cynefin）：

1. Clear 域：部署流程高度自動化。CI/CD pipeline 處理所有標準部署，一天超過 100 次部署，零人工介入——這是 SOP 的領域
2. Complicated 域：效能優化和系統架構。由 Chapter Lead（技術專家）主導分析和決策，用 Guild 跨團隊分享知識——這是專家的領域
3. Complex 域：產品功能開發。每個 Squad（小隊）自治，用 A/B 測試探索什麼有效。2019 年他們同時跑超過 500 個 A/B 測試——這是實驗的領域
4. Chaotic 域：重大事故。有明確的 Incident Commander 流程，先止血再分析——這是行動優先的領域

結果：Spotify 從 2012 年的 1,500 萬用戶成長到 2024 年的 6.4 億用戶，同時維持了工程團隊的高產出和低離職率。關鍵不是他們的組織架構多聰明，而是他們對不同類型的問題用了不同的管理方式。

使用步驟

Step 1：描述當前情境

把團隊面對的問題用白話說出來。不要急著解決，先把情境攤在桌上。問：「我們現在面對的是什麼狀況？」

Step 2：判斷問題屬於哪個 Domain

用這個快速檢測：

• 有 SOP 可以照做嗎？→ Clear
• 需要找專家分析嗎？→ Complicated
• 沒有人知道正確答案、需要實驗嗎？→ Complex
• 情況緊急、正在惡化嗎？→ Chaotic
• 團隊意見完全分歧、連問題是什麼都不確定？→ Disorder

Step 3：選擇對應的決策模式

Clear → 直接執行 SOP。Complicated → 召集專家分析。Complex → 設計小實驗。Chaotic → 立刻行動止血。Disorder → 先把問題拆小。

Step 4：設計具體行動

根據所在 domain 設計行動方案。最關鍵的：Complex 域不要試圖做完美計畫，設計「安全失敗的實驗」（safe-to-fail probes）；Chaotic 域不要開會討論，先動手穩住局面。

Step 5：持續觀察 Domain 轉移

問題不會永遠待在同一個 domain。定期回來確認：情境有變嗎？該切換決策模式了嗎？特別注意 Clear 域的「懸崖效應」——當你太久沒質疑 SOP，小心突然掉進 Chaotic。

這樣做 vs 避免這些

這樣做

• 先分類再行動——花 10 分鐘判斷問題類型，可以省掉幾週的錯誤方向
• 接受 Complex 域沒有「正確答案」——實驗和觀察就是最好的策略
• 團隊一起做分類——不同角色看到的 domain 可能不同，這本身就是有價值的對話
• 注意 domain 邊界——很多問題是「一部分 Complicated、一部分 Complex」，要拆開處理

避免這些

• 不要把所有問題都當成 Complicated（「找個專家來分析就好」）——Complex 域的問題專家也不知道答案
• 不要在 Chaotic 域開冗長的會議——先止血，分析的事情等穩定了再說
• 不要把 Cynefin 當成固定分類系統——問題會在 domain 之間移動，這是正常的
• 不要忽略 Disorder——當團隊對問題類型沒有共識時，這才是最需要先解決的