前言
這本書個人覺得非常精彩，書中舉了非常大量讓我意想不到的範例去闡述作者想表達的事情，這篇紀錄以個人理解和覺得不錯的例子來提醒自己未來要注意的事情，書中太多精華很難在短短文章表達出來，很推薦大家閱讀。
何謂上游思維
講到上游思維之前，先來看看一個情境。
書中舉的第一個例子就是旅遊網中的客服來電問題，在購買訂單後卻有 58% 的人打電話來尋求協助，無論是訂什麼類型的東西都是，那因為客服部門致力於效率和顧客滿意度，所以會希望越快解決客戶問題越好，但卻都沒有人問過『為什麼有那麼多人打客服電話給我們』？最後把問題鎖定變成『讓客戶不必打電話到公司客服』，後續就是原本打電話的人數從 58% 下降到 15%，這就是上游思維，透過上游行動，避免問題發生所採取的手段。
但要注意，上游行動和下游行動並不是擇一就好，有時是兩者都是需要，舉例來說拯救溺水的人，配置救生員和救生圈是一種下游做法，而上游作法則是教會當地小鎮人如何游泳，而書中強調的重點是要如何往上游去思考去預防問題發生。
剛剛客服的例子也是受困於下游思維的一個例子，而被受困於下游思維通常會有三個因素。
- 對問題盲目
- 缺乏負責人
- 隧道效應
接著會簡單帶出這三個所表達的意思
對問題盲目
我們舉天氣來說，我們知道天氣很糟，但也無法做什麼，最後就接受了這個事實，對應到筆者職業上也可以這樣說，覺得寫程式一定會有很多 bug，這類型的認知就是屬於對問題盲目。當對問題盲目時，你會覺得『事情就樣啊，沒辦法』，這樣思維就很難往上游去以制高點看到真正的問題出在哪裡。在很多組織中一定會有『現況就是這樣，所以沒有人會質疑』的情況出現，所以需要的是把『看似正常的現象問題化』，才會跳脫出對問題盲目。
以工程師角度來說，之前從朋友聽過有一個例子很神奇，某間公司的 QA 工程師比開發工程師還要多，在詢問之下才發現原來他們的開發工程師都沒有在進行測試，甚至也不寫單元測試，而造成的後果就是需要更多更多的 QA 工程師來幫他們測試，但在那間的工程師我相信會覺得這件事情很正常，心想『開發工程師幹嘛測試？』，而這也是因為體制設計 (開發工程師可以不測試) 的關係，所以最終反映在結果上 (一堆 QA 幫忙擦屁股)，進而導致徵了大量的人員，但都沒有用，會不會反而把這錢花在教他們寫單元測試上還比較好？
書中提到另一個很有趣的例子，有兩隻年輕小魚從魚缸一邊游到另一邊，途中有一隻老魚面對著他們游過去，就問了『今天的水如何』？兩隻小魚沒有回答，而是到了魚缸另一邊後，其中一隻問到『他說的水是什麼？』。這水其實就是對應到了體制，有時候我們會身在體制中卻感覺不到，因為我們會感覺到非常自然，一切都看似非常正常，而這後果就是對問題盲目。
缺乏負責人
有些時候我們發現了真正問題，但卻不敢遲遲下手解決，一部分是因為自身利益，另一部分是認為自己缺乏採取行動的正當性，會覺得自己的身份不太適合，也就是心理資格不符合。
書中提到一個例子我覺得蠻有趣的，在校園的有些男大學生對於約會強暴事件感到非常震驚，但對於想加入由女性主導的示威活動卻感覺到是不是不恰當，接著有另一個小實驗說明了，組織名稱原本為『普林斯頓反一七四提案陣線』改為『普林斯頓男性與女性反一七四提案陣線』，男女方的請願書數量遠比一開始的高出許多。
所以要把思維想成並不是因為我必須解決這問題，而是我有能力解決這問題，加上這問題有需要被解決的必要，所以我才決定要面對這問題，不然會受限於心理資格有沒有符合，而導致不敢踏出那一步。
隧道效應
當因為各種問題而分身乏術時，通常會放棄解決全部的問題，視野變得狹隘，只專注在眼睛看到的到事情上，不會思考更上游的行動，而做出的選擇就僅限於下游，就像在一個隧道中，通常你要做的事情就是面對那個光一直前進到出口為止。
這也就代表了光是緊急的問題可能就處理不完，可能就無法想到要問自己，為什麼這個狀況會一再出現呢？這也帶出另一個問題，書中提到說『親愛的團隊，我們必須給 XXX 掌聲，因為他即時滅火，如果不是他我們就慘了』的例子，這必須思考萬一這是一種行為循環，一直不斷在滅火，那麼是不是體制有問題？
而要跳出這個隧道，必須製造『空閒』出來，代表的是預先保留時間或是資源用來解決問題，當你把焦點放在一直前進上面，其實就無法暫停一下確認是否正在對的方向，所以適當的停下來思考並取得回饋是非常重要的。
中間各種例子
書中經典例子想表達的想法太多了，我選擇列出覺得很不錯一個很有趣的例子和三個看到的共通點
眼鏡蛇問題
這個案例是英國殖民印度的時候，英國官網對於德里出現太多眼鏡蛇感到憂心，所以發出了眼鏡蛇懸賞，只要帶著眼鏡蛇屍體來就可以換獎金，原本是想要滅絕眼鏡蛇的，但沒想到結果就是一部分人開始養起眼鏡蛇來，完全跌破官員的預想，這是一個設計新的制度，但卻根本沒有解決本質問題的案例。
讓資料說話
在書中各種案例中，是有各種資料去把問題給說明出來，所以如何收集資料和快速得到資料是非常重要。舉例來說，有個案例是要預防社區妻子因家暴被殺死的情況，作法則是列出幾項類似『這個人是否曾經毆打你』等等問題，最後做一個統計分數，再根據統計分數決定要安排是不是需要有人定期巡邏等等對應策略。除此之外，也會有各種指標來衡量改善於否。
以系統角度俯瞰問題全貌
裡面提到一個關於在島上生物鏈的問題，因為解決問題的人不是從系統面去看待問題，而是單一解決問題。例如因為 A 太多，導致 B 面臨滅絕問題，而打算滅掉 A，結果卻導致 C 因為吃不到 A，轉而吃 B。但如果以系統面，把整個島上的食物鏈畫出來，也許就能夠發現滅掉 A 的空缺後，可能會造成問題出現。
這個思考方式可以套用在所有職業上面，以工程師來說，大家最怕的是改 A 壞 B、改 B 壞 C、改 C 壞 A，但如果以全面性去思考，這個東西會影響哪幾個地方，會不會有一連串關係下去？把這個脈絡圖出來，一層一層去解析，也許就能根本性解決連鎖問題。
預先模擬操弄行為
因為上游行動往往是制度面的改變，所以要先預想在這個制度下面會不會又有人鑽漏洞，書中給出五個測試方式，但我選擇最有感的測試分享在這，就是『懶惰官測試』，代表如果有人想用最取巧的方式讓新制度下需要達到的指標變得好看，可以怎麼做？
這個測試就可以拿來測試剛剛提到眼鏡蛇問題的情況，若我們只看眼鏡蛇數量的話，我要怎麼用取巧的方式增加這個指標，讓他變得好看呢？透過預先模擬，也能對問題的了解更加全面
上游行動的三項建議
而要如何往上游行動，書中在最後給出三項建議
- 迅速行動，耐心等待結果
上游行動往往帶來的效益是巨大的，但是發酵時間卻是非常漫長，因為上游行動改變的往往是制度層面，而下游行動則是反過來。這也是為什麼多數人選擇下游行動，因為更快見效比較有感，但就是解決問題表面而已。
千里之行，始於足下
當面對一個問題的時候，投身到這個問題之中，實際去面對和解決問題，只有當近距離觀察問題，才會有辦法察覺到問題的核心在哪裡，且先想著了解如何幫助一個人，再去想怎麼幫助數百人。若有人都沒實際去訪談了解一個無家者，就想直接解決遊民問題，我是不信他能解決，這也呼應到我在 StackOverflow 那篇提到的 X-Y 問題。計分板比解藥還重要
書中其實很大量提到數字統計的重要性，也有提到資料應該是要以學習為目的，而不是鑑定為目的。以鑑定為目的，通常是『業績沒有達到 XXX 是有什麼問題發生嗎？』的思維方式，而以學習為目的，是提出假設去實驗看看結果會增加或是減少，而要能得到這些數字就是要建立回饋循環，有快速的回饋才有辦法即時調整自己的站位。
後記
這本書非常建議大家閱讀，內容真的很有趣，也可以從不同例子中看到原來有很多不同思維模式。