為什麼聰明的你，會做出笨決策？

當技術能力很強，決策卻一塌糊塗

有些人明明技術能力很強，寫起 Code 邏輯清晰、效能優化做得很好，但一遇到需要「做決策」的場景，就開始出錯：

• 花了兩週重構一個功能，上線後發現根本沒人用
• 堅持用最新的框架，結果團隊沒人會，專案進度大延遲
• 看到同事的方案有缺陷，但自己提的方案也有同樣的問題

這不是人不夠聰明，而是大腦被「認知偏誤 (Cognitive Bias)」綁架了。

查理·蒙格在《窮查理的普通常識》中花了大量篇幅討論這個主題。
他認為，了解人類的思維缺陷，比學習更多知識更重要。

窮查理的普通常識：巴菲特50年智慧合夥人查理．蒙格的人生哲學

認知偏誤 - 為什麼你只看得見支持自己的證據？

描述：選擇了一個技術方案後，只看得到它的優點，看不見缺點

典型災難場景：

🔧 技術選型會議

工程師A：「我建議用 MongoDB，它很適合我們的需求」

工程師B：「但我們的資料有很強的關聯性，用關聯式資料庫會不會更好？」

工程師A：「MongoDB 也可以做 Join 啊，而且彈性更高」

工程師B：「可是我們團隊都比較熟悉 PostgreSQL」

工程師A：「學習新技術也是一種成長啊」

工程師B：「MongoDB 的 Transaction 支援沒那麼完整」

工程師A：「我們可以在應用層處理」

---

📅 3 個月後

PM：「為什麼這個功能這麼難做？」

工程師A：「因為 MongoDB 的 Transaction 支援不夠完整...」

PM：「那當初為什麼選它？」

工程師A：「......」

為什麼人只聽得進自己想聽的？

人很容易陷入了「確認偏誤 (Confirmation Bias)」：

人類傾向於尋找、詮釋、記憶那些支持自己既有信念的資訊，而忽略反駁的證據。

一旦你心中有了偏好（比如「我想用 MongoDB」），你的大腦就會自動過濾掉不利的資訊，只看到有利的資訊。

書中解方：刻意尋找「反對意見」，建立「Devil's Advocate」機制

蒙格說：

"我從不允許自己對任何事情抱持意見，除非我能比我的對手更好地反駁我自己。"

改變你的決策流程：

錯誤做法：

1. 選定方案 A
2. 尋找支持方案 A 的證據
3. 說服團隊選擇方案 A

正確做法：

1. 列出所有可能的方案（A, B, C）
2. 針對每個方案，刻意尋找「為什麼它不適合」的證據
3. 找一個人扮演「魔鬼代言人 (Devil's Advocate)」，專門挑戰你的選擇
4. 綜合正反意見，做出決策

實際應用案例：技術選型的「紅隊演練」

🎭 角色分工

【藍隊】支持方案 A（MongoDB）
- 工程師 A、B

【紅隊】反對方案 A，支持方案 B（PostgreSQL）
- 工程師 C、D

【評審】中立評估
- Tech Lead

---

🔵 藍隊論點
1. Schema-less，開發彈性高
2. 水平擴展容易
3. JSON 格式原生支援

🔴 紅隊反駁
1. 彈性高 = 資料結構不穩定，容易出錯
2. 我們現在的流量根本不需要水平擴展
3. PostgreSQL 也支援 JSONB，而且效能更好

🔵 藍隊再反駁
1. 我們未來可能需要快速調整資料結構
2. 提前規劃擴展性是好事
3. MongoDB 的開發體驗更好

🔴 紅隊再反駁
1. 「未來可能」是不確定的，不應該為假設的需求過度設計
2. PostgreSQL 也可以水平擴展（Citus）
3. 開發體驗是主觀的，團隊熟悉度更重要

---

⚖️ 評審總結
透過紅藍對抗，我們發現：
- MongoDB 的優勢在「未來可能」，而不是「當前必要」
- 團隊對 PostgreSQL 更熟悉，學習成本更低
- 資料有強關聯性，關聯式資料庫更適合

【決策】選擇 PostgreSQL + JSONB

我的實踐工具：「決策前檢查清單」

## 技術選型前的自我檢查

### 第一步：列出正反證據
- [ ] 我列出了至少 3 個支持這個方案的理由
- [ ] 我列出了至少 3 個反對這個方案的理由
- [ ] 我認真思考過反對理由，而不是隨便找藉口反駁

### 第二步：尋求反對意見
- [ ] 我主動詢問過至少 2 個同事的意見
- [ ] 我問過「這個方案有什麼問題？」而不是「你覺得這個方案好嗎？」
- [ ] 我願意改變自己的想法

### 第三步：測試假設
- [ ] 我的理由是基於「事實」還是「假設」？
- [ ] 我是否過度樂觀地評估了優點？
- [ ] 我是否過度忽略了缺點？

錨定效應 - 為什麼你的估時總是不準？

描述：PM 問「這個功能要多久？」你脫口而出「一週」，結果做了一個月

典型災難場景：

📋 需求討論會議

PM：「這個功能看起來不複雜，大概要多久？」

工程師：「嗯...應該一週就可以了吧」
（心裡想：就是個 CRUD，能有多難？）

PM：「好，那我跟客戶說下週可以交付」

---

📅 一週後

PM：「功能好了嗎？」

工程師：「呃...遇到一些問題」
- 資料庫設計要調整
- 第三方 API 文件不清楚
- 還要加權限控制
- 前端需要改版面

PM：「那還要多久？」

工程師：「再一週...吧？」

---

📅 又一週後

PM：「怎麼還沒好？」

工程師：「系統測試發現效能問題，要優化...」

PM：「客戶已經在催了！」

工程師：「......」

為什麼你的估時總是不準？

你陷入了「錨定效應 (Anchoring Effect)」：

第一個出現的數字，會成為你判斷的「錨點」，影響後續所有的決策。

當 PM 問「大概要多久」時，你腦中浮現的第一個數字（比如「一週」），就成了錨點。之後你會不自覺地圍繞這個數字調整，卻忽略了真實的複雜度。

書中解方：用「基準率」對抗錨定，建立歷史數據庫

蒙格說：

"用統計數據對抗直覺，用歷史經驗對抗樂觀偏誤。"

改變你的估時方式：

錯誤做法：

PM：「這個功能要多久？」
工程師：「嗯...一週吧」（基於直覺）

正確做法：

PM：「這個功能要多久？」
工程師：「讓我先分解任務，並查看類似功能的歷史數據」

【任務分解】
1. 資料庫設計與建立（4 小時）
2. API 開發（8 小時）
3. 前端介面（12 小時）
4. 整合測試（4 小時）
5. Bug 修復與優化（預留 30% buffer）
---
總計：28 小時 × 1.3 = 36 小時 ≈ 5 個工作天

【歷史數據對照】
- 上次類似功能（用戶管理）：預估 3 天，實際 7 天
- 上上次（訂單系統）：預估 5 天,實際 10 天
- 平均膨脹係數：2x

【最終答案】
「保守估計需要 10 個工作天（2 週）」

實際應用工具：「估時公式」

實際所需時間 = 理想時間 × 複雜度係數 × 歷史膨脹係數

【複雜度係數】
- 簡單任務（純 CRUD）：1.0
- 中等任務（需整合第三方）：1.5
- 複雜任務（涉及核心邏輯重構）：2.0
- 超複雜（未知領域）：3.0

【歷史膨脹係數】
- 查看過去 10 個類似任務
- 計算「實際時間 ÷ 預估時間」的平均值
- 我的個人係數是 1.8（我總是太樂觀 😅）

【範例】
理想時間：5 天
複雜度係數：1.5（需要整合第三方 API）
歷史膨脹係數：1.8

實際時間 = 5 × 1.5 × 1.8 = 13.5 天 ≈ 3 週

我的實踐：建立「個人估時資料庫」

我用 Notion 建立了一個簡單的表格：

每次做完一個任務，我會記錄實際時間和遇到的問題。幾個月後，我就能算出自己的「平均膨脹係數」，未來估時就會越來越準。

我的實踐：建立「反偏誤檢查清單」

蒙格說：

"我們要做的，不是變得更聰明，而是變得不那麼愚蠢。"

我為自己建立了一份「決策前檢查清單」，每次做重要決定前都會過一遍：

## 認知偏誤檢查清單

### 確認偏誤檢查
- [ ] 我是否只尋找支持我觀點的證據？
- [ ] 我是否認真考慮過反對意見？
- [ ] 我是否請別人挑戰我的想法？

### 錨定效應檢查
- [ ] 我的估計是否基於第一印象？
- [ ] 我是否查看了歷史數據？
- [ ] 我是否給了足夠的 buffer？

### 其他常見偏誤
- [ ] 過度自信：我是否高估了自己的能力？
- [ ] 從眾效應：我是否因為「大家都這樣做」而跟風？
- [ ] 近因偏誤：我是否被最近的經驗過度影響？

總結：聰明人也會做蠢事，除非你了解自己的大腦

查理·蒙格說：

"我想知道我會死在哪裡，這樣我就不會去那裡。同樣，我想知道我會在哪裡犯錯，這樣我就能避免它。"

認知偏誤不是「性格缺陷」，而是人類大腦的「出廠設定」。

即使是最聰明的人，如果不了解這些思維陷阱，一樣會做出愚蠢的決定。

關鍵實踐：

1. 對抗確認偏誤：主動尋找反對意見，建立「紅隊機制」。
2. 對抗錨定效應：用數據和歷史經驗，而不是直覺估計。

當你開始有意識地對抗這些偏誤，你會發現，你的決策品質會有質的飛躍。

不是變得更聰明，而是變得不那麼愚蠢——這就是蒙格教會我最重要的一課。

#窮查理的普通常識 #認知偏誤 #理性決策 #吳桑泥的升級書單 #工程師思維 #決策能力