上一篇談到一件事：
結果變好，不代表我們已經知道為什麼。
一個 action 做下去，結果真的改善了，還需要再確認：
這個結果，真的是這個 action 造成的嗎？
但事情到了後面，通常還會再多一個步驟。
我們開始替成功解釋原因。
專案成功了。
問題解決了。
數字變好了。
於是大家開始整理：
我們做對了什麼？
哪一個決策最關鍵？
這次成功，可以留下什麼經驗？
這些整理當然有價值。
只是我後來會多問一句：
最後留下來的成功故事，和事情當初真正發生的過程，有多接近？
現實通常沒有故事那麼清楚
事情正在發生的時候，往往很亂。
一開始可能根本不知道問題在哪裡。
不同部門有不同判斷。
幾個方向同時測試。
有些方法做了沒有用。
有些只能暫時壓住問題。
中途又出現新的資訊。
甚至最後真正找到原因，只是因為某個人在現場注意到一個不起眼的異常。
但事情結束之後，我們通常不會這樣說。
我們會重新整理成：
發現問題。
分析原因。
做出決策。
執行改善。
得到成果。
這條路徑沒有錯。
只是它常常是：
事情結束之後，才被畫得這麼清楚。
結果出來之後，我們開始替它找原因
故事一定需要簡化。
幾個月的過程，不可能全部放進一份簡報。
所以最後可能只剩：
「透過跨部門合作與數據分析，我們成功解決問題。」
這句話可能完全是真的。
但真正的過程可能還包括：
工程師測了十幾種可能。
操作員發現一個異常。
主管原本判斷錯了。
幾個部門做了很多小調整。
甚至有些條件，只是剛好同時發生。
等到結果出來之後，我們會開始回頭判斷：
哪一件事情最重要？
誰的決策最關鍵？
哪個方法值得複製？
也就是從：
Result
走到：
Attribution。
真正困難的地方就在這裡。
因為結果是真的，不代表我們對結果的解釋一定是對的。
原本可能是很多小因素共同累積，最後變成一個「關鍵決策」。
原本是現場反覆試出來的結果，最後變成一套「管理方法」。
事情未必被扭曲。
但原因的重要性，可能已經被重新排列。
成功案例最容易留下答案
真正參與解題的人，和最後負責整理成果的人，也不一定完全相同。
這本身沒有問題。
組織本來就需要有人把複雜的事情說清楚。
問題是，當事情被整理成成功案例之後，最容易留下的是：
做了什麼。
得到什麼結果。
最後學到了什麼。
反而最容易消失的是：
當時為什麼選這個方向？
有哪些方向曾經判斷錯？
什麼證據讓大家改變想法？
哪些方案試過之後被放棄？
當時真的有現在看起來這麼確定嗎？
而這些，往往才是最值得學的地方。
因為：
知道最後答案，和在還不知道答案的時候做判斷，是兩件不同的事。
成功案例最容易留下答案。
最容易遺失的，反而是：
答案還不知道時，人是怎麼判斷的。
故事可以幫助理解，但不能取代現實
所以我還是會看成功案例。
也還是會聽別人分享經驗。
故事可以把複雜的事情整理得比較容易理解，也可以讓經驗被留下。
只是我不會太快把故事裡的因果，直接當成事情本身。
因為一件事成功之後，通常還會經過：
Result → Attribution → Story
先有結果。
再替結果找原因。
最後把原因整理成一個可以被理解、傳播與記住的故事。
真正需要小心的，是中間那一步：
我們怎麼知道，自己歸因歸對了？
故事裡的每一件事，都可能是真的。
但如果原因沒有找對，
故事說得越完整，
反而可能讓一個不完整的理解，看起來更像答案。
所以現在看成功故事，我會多問一句：
事情當時，到底是怎麼發生的？
而不是只看：
事情後來，是怎麼被說的。
這也留下下一個問題：
如果成功故事本來就是整理過的版本，我們為什麼還這麼喜歡從別人的成功裡，找可以複製的方法？
上一篇｜結果變好了，就代表做對了嗎？
下一篇｜成功故事，為什麼很難複製？
延伸閱讀：
發表迴響