「在沒有現成地圖的領域，如何自己開發新地圖」的原則：

• 先找現象，不急著找答案：先確認到底發生了什麼，不要一開始就套既有理論。
• 從失敗案例開始：成功原因常很多，失敗反而容易暴露系統真正的邊界、限制與瓶頸。
• 找反覆出現的模式：不同事件裡如果一直出現相同變數、衝突或結果，那通常就是重要結構。
• 區分現象、原因、解法：不要把「我看到什麼」、「為什麼發生」、「該怎麼處理」混成一件事。
• 持續問「這在解什麼問題？」：每遇到一個新名詞、新方法、新制度，都先找它存在的理由。
• 畫出角色、資源與關係：誰影響誰、誰依賴誰、資訊從哪裡來、資源由誰控制。
• 找因果鏈，而不是只收集相關性：不要只知道 A 和 B 一起發生，要追問 A 透過什麼機制影響 B。
• 特別注意時間維度：短期有效的策略，長期可能失效；一次正常，不代表重複一萬次仍然正常。
• 尋找 trade-off：只要存在長期爭論，通常不是誰笨，而是雙方在交換不同價值。
• 找極端案例與邊界條件：問「什麼情況下這套說法會失效？」比一直找支持案例更有價值。
• 主動找反例：好的地圖不是能解釋所有事情，而是知道自己不能解釋哪些事情。
• 把假設明寫出來：例如「假設資訊透明」、「假設參與者理性」、「假設資源有限」，否則很容易偷偷更換前提。
• 暫時模型先求可用，不求完美：沒有地圖時，第一版地圖本來就一定是錯的；重點是它能不能幫你提出下一個更好的問題。
• 用新案例反覆測試模型：能解釋案例 A 不代表成立，要拿 B、C、D，甚至不同產業測試。
• 區分局部最佳與整體最佳：某角色做對自己最有利的事情，不代表整個系統會變好。
• 觀察 incentive：如果人的行為很奇怪，先問制度實際獎勵什麼，而不是先判斷人的品格。
• 尋找不變量：不同案例表面差很多時，問「有什麼結構始終沒有改變？」這通常是抽象化的入口。
• 逐步提高抽象層級：先從案例 → pattern → mechanism → principle，不要一開始就跳成宏大理論。
• 保留模型版本：不是「以前錯、現在對」，而是知道 Model v1 能解什麼、v2 多加入了什麼變數。
• 永遠保留「未知區」：地圖最危險的時候，不是空白很多，而是你誤以為已經沒有空白。

研究流程:

現象 → 異常／失敗 → 重複模式 → 關鍵變數 → 關係 → 因果機制 → trade-off → 邊界條件 → 暫時模型 → 反例驗證 → 修正地圖。

案例應用: 研究「為什麼某個團隊一直跨部門合作失敗」

你不用一開始就跑完整條：

現象 → 異常 → pattern → variable → mechanism…

你只需要用工程師最熟悉的方式開始：

「系統現在出了什麼 bug？」

例如：

明明所有 team 都完成自己的 KPI，產品整體卻一直延期。

很好，這就是異常。

接著問：

哪些 component 參與？

可能是：

App Team
Backend Team
Device Team
PM
主管
績效制度

再問：

dependency 怎麼走？

App
 ↓
Backend
 ↓
Device
但績效：
App → App主管
Backend → Backend主管
Device → Device主管

你突然看到：

Delivery dependency 是橫向的，
incentive dependency 卻是縱向的。

這時一張新地圖就開始長出來了，你甚至不需要先懂「組織行為學」。