《真正的問題是什麼，你想通了嗎？》讀後心得
問對問題是獲得好答案的必要條件。問錯問題，永遠得不到好答案。書中舉了一些例子，說明理解真正問題的要點。
以下借用書裡第一個例子說明。
問題
- 辦公大樓的電梯無法負擔現有辦公人潮。
- 上班時間集中在 9:00 ~ 17:00。
- 用戶平均分散在 73 層大樓的每一層。
- 共有四台電梯。
請問你會怎麼解決電梯使用超量的問題？
可能解法
改善電梯:
- 加快電梯速度。
- 大樓內裝新電梯。
- 大樓外裝新電梯。
管制人潮:
- 錯開各樓層上下班時間。
- 限制進入大樓人數。
- 管制不同電梯停的樓層。
你偏好那一種思路呢？
若你選擇改善電梯，可能是偏工程師思維，認為電梯使用超量，就改善電梯。若選擇管制人潮，可能是偏管理者思維。改善電梯會提升硬體成本，管制人潮相對省錢。但管制人潮可能會引起更多反彈。各樓層不同公司有不同需求，喬到大家買單不是容易的事。
重新定義問題
書中提到，要先理解這是「誰」的問題。同一個事件，不同擁有者，有不同的問題。像大樓擁有者人不會來這棟大樓，這不是他的問題。這也不是各樓層公司老闆的問題，畢竟他們可能不常進大樓，或是不常在尖峰時段進出。
所以，這是「員工」的問題。必須讓有能力解決問題的人也感到困擾，才能解決問題。所以各家公司員工們聯合抗議，因為抗議影響到生產力，老闆們就有誘因解決員工們的問題。
理解是員工的問題後，接著要理解的是: 這是什麼樣的問題？問題是我們的期望和感受有落差。從這角度來看，如果讓電梯使用者不會有等待的感覺，即使速度不變、運量不變，問題也不存在了。
於是可以得出簡單省錢的作法:
- 公告欄。
- 鏡子。
- 塗鴉區。
- 播放廣告影片。
雖然最後一個建置成本較高，但大樓擁有者有誘因這麼作，於是問題可被解決。
現實生活的類似案例: App 進度表
使用者抱怨 App 反應速度太慢時，工程師思維就會開始想如何加機器、調校 App 效能。套用電梯大樓學到的事: 問題是使用者期望的反應速度和感受有落差，讓使用者感覺沒等那麼久，也可解決問題。
Visual tricks can make downloads seem quicker 這篇說明用不同進度表 (progress bar) 動畫讓使用者覺得進度變快，推薦點進去看影片感受一下。
下圖是原始論文 “Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations” 其中一個實驗的數據:
可看出「加速版進度條」的 5.6s 對使用者來說等同於「一般進度條」的 5s。想像你已經調校效能到極限，再也榨不出效能時，改善動畫就能有感地省 0.6s！
其它要點
書裡有許多要點值得反覆咀嚼內化成反射動作，寫在這裡備忘。
關於問題定義:
- 問題來自期望和感受的落差。
- 別把別人的解法當成問題的定義。
- 人們得到後才會知道他們要的是什麼。
關於解法:
- 我們會用「忽略」解決多數問題。
- 不要 Solution Probleming (手裡拿的是槌子，眼中看到的都是釘子)。
- 每個解決方案都是下個問題的根源。或著換個我喜歡的說法: 系統設計是一連串的取捨。
- 如果想不出三個可能出錯的地方，表示沒有真的理解問題 (畢竟每個解法都會產生新的問題)。
- 對自己真誠，先思考道德立場。
關於問題參與者:
- 這是誰的問題？每個擁有者的觀點不同。
- 問題轉到別人身上，自己就不用處理了。
- 如果你很輕易解決別人的問題，別人不會相信你解決他們真正的問題。
- 若別人自己可以解決問題時，不要急著幫別人解決。
- 不只是當事人對問題有更多了解和感受，自己提出的解決方案，更有意願執行和確認有解決問題。
- 讓別人因為職位被迫處理和他個人無關的問題的方法：讓他和問題產生關聯。
- 各個擊破是反制「這是我們共同問題」的策略。
問題從何而來？
- 了解問題由誰出的，他期望得到什麼答案。
- 問題的源頭通常和自己有關。例如服務人員沒有耐性，可能是我們自己臉也很臭 → 主動釋出善意。
真的需要解決問題嗎？
- 別急著找答案，思考是否真的需要。
- 即使人們明白自己的問題，有時他們並不希望解決問題。
結語
八年前第一次看這本書時很有收獲，如今累積更多經驗後重讀，體會更深。
別急著跳入思考和討論解法，最重要的是定義清楚這是誰的問題、是什麼樣的問題、是需要被解決的問題嗎？問對問題後，好的解法自然就出來了。
接著，要明白解法衍生的問題是否比原有問題小，重新審視新的問題，如此循環到剩下的問題不需解決為止。
