感謝得到-萬為綱老師搶鮮為我們介紹這本 2020 年一月剛推出，希思兄弟這本的新書，我想中文版大概要一年後才看得到？
看高手寫的書最爽的就是把那種『寶寶心裡苦，但是寶寶不說(or 不知怎麼說)』的狀況總結歸納出來，並且得到一些科學的建議。
然後我就可站在巨人的肩膀上，再透過旁徵博引的萬維鋼老師把本書脈絡整理了出來，最後讓我可以以懶人包和自己的經驗來三次創作😆
在我看來，上游思維用積極的觀點來說就是上醫治未病，但從消極面來看我想到一個問題，「先知除了在本鄉、本族、本家以外，沒有不受尊重的。」
為什麼先知總是辛苦又容易被討厭？原因有三
第一，下游的問題是顯而易見的﹔而上游的問題不容易被看出來。 ( 需要系統思考觀點)
第二，下游問題的責任非常明確，該是誰的事一清二楚﹔但上游問題沒有明確的責任人。 (需要參與比較多跨部門活動的雞婆人🙈)
第三，下游的問題都比較緊急，不解決不行﹔而上游的問題常常是“重要而不緊急”的。 (救火隊英雄總是比較顯眼和討喜😏)
要能當先知有三個先決條件
條件一：眼光
在別人看不見問題的時候，你得能夠發現問題，但是不是那種 I told you so...
條件二：責任感
不是你的事，你也要當做你的事，看到問題會叫誰都會，重點是要跳下去解決...
條件三：資本
這邊的資本不是說出身血統、職位高低和經濟狀況，而更多的是一種精神狀態。這個狀態叫做『自由』。這個資本叫做『余閑』。必須要有余閑的時間和狀態才有可能去處理，如果都處於很忙，瞎忙的狀態，是不會有眼光察覺和力氣去解決
解決上游問題的七大技能
1. 系統思考能力
如何不要只見樹不見林，看得出基模和避免 Delay effective
2. 找到志同道合的小夥伴，聯手解決
獨角獸計畫的神秘組織就是這樣的解法
3. 尋找支點
人的時間和精力有限，找出支點來解決，數據分析和視覺化 Kanban 的重要性，可以參考我之前寫得：如何用看板凸顯插單問題
4. 提前預警系統
但是要如何避免假警報就必須非常小心，此外也必須要建立安全的環境：DevOps HandBooks - 第三章 The Second Way 建立安全的反饋機制
5. 識別假成功
在風口上豬都會飛，如何像高勝算決策這本書提到，一樣要先排除運氣和一些虛榮指標，每次都分析和檢討真正的關鍵成功因素是什麼，才有可能延續下去
6. 反饋
因為要在上游就發現問題，並嘗試解決問題，這時候 TDD 要做好，免得改東壞西，推行新政策很容易產生新的 side effective，我之前就深受其害，發現別人沒注意到的點提出來改善，但是大家可能都還不覺得夠痛 —>回到尋找支點
書中有提到要先問自己幾個問題：
第一，這個政策以前實行過嗎，實行的效果如何？
第二，能不能先在小範圍做個實驗？
第三，執行政策的過程中，是否能夠迅速得到有效的反饋，一邊反饋一邊改進？
第四，如果事實証明這個政策不行，我們還能不能撤回來，回到從前的樣子？
其實就是一種 TDD + Architect review 思維，可以參考 Zen 大的文章~XD
不過 roll back 是最難的最終手段 (通常反彈最大🙈)
7. 讓人買單
這就是最難的，從兩個層面來看
第一：事情可能還沒發生別人為啥要照你說的做，你要怎麼說服別人？(需要去上 一談就贏 )
第二：解決一個可能尚未發生的問題，你的 credit 在那裡？誰會買帳 ( 所以很多人都喜歡看著爛再來救火😏)
結論
沒事找事(找碴！？)，的最大難點就在於大家都認為『沒事』，不痛不癢
不過就跟 Skin in the Game (不對秤陷阱) 這本書提到的一樣，不懂的人最好別輕易談改革。你要跳下來身陷其中，甚至當家作主，就不會知道一個系統有多容易出問題。😂
我們所面對的，是一個複雜的世界。真的很少有那種直接給你答案且黑白分明的簡單問題，通常是書上沒有寫，老師沒有教( or 講清楚)，下課自己想辦法 output 練習(咦)，很多時候不但不能指望功勞，還得有背黑鍋的覺悟。
#這就是人生啊
最後用聖經的話勉勵自己
不要自私自利，也不要貪圖虛榮，只要謙卑，看別人比自己強； 各人不要單顧自己的事，也要顧別人的事。 你們應當有這樣的思想，這也是基督耶穌的思想。 他本來有 神的形象，卻不堅持自己與 神平等的地位， 反而倒空自己，取了奴僕的形象，成為人的樣式； 既然有人的樣子，就自甘卑微，順服至死，而且死在十字架上。腓立比書 2:3-8 CNV
沒有留言:
張貼留言