04
If a problem is too abstract, ask what. If it’s too specific, ask why.
當問題過於抽象，去問「是什麼」；當問題過於具體，去問「為什麼」。
《好產品的設計法則》
1. 問題過於抽象
你是乙方，獲得一個新任務：縮短客服的回覆時間。
但甲方並未並未被告知你是要去改善哪個規範、哪個程序，或哪個設備的環節。此時，你應該先去問「是什麼」的問題：
- → 這個問題最明確的證據是什麼？
- → 甲方曾做了哪些嘗試去處理問題？
- → 客服人員有哪些行為？
- → 這些行為是為了達成哪些特定目標？
- → 現場所使用的 SoP 與設備有哪些？
- → 哪些東西是必要的，哪些又是不必要的？
2. 問題過於具體
你是乙方，獲得一個新任務：設計一組自行車車燈。
不管有沒有預定規格，你都應該先問「為什麼」的問題：
- → 為什麼需要設計新的頭燈？
- → 是為了讓騎乘者看清前方道路嗎？
- → 還是要讓騎乘者可以更容易被注意到？
- → 這款頭燈是針對某項特定車款？還是特定的騎乘環境設計？
- → 是因為有更新的電池科技問世嗎？
- → 還是甲方公司現有的頭燈設計已經過時？
我的經驗
流程改善的問題通常很抽象，準確一點來說，是「剛開始很抽象」。
所以不管是用 Six Sigma 的 DMAIC 步驟的第一步或第二步，先定義 (Define) 後量測 (Measure)，或是設計思考的 4D 步驟的第一步或第二步，先探索 (Discover) 後定義 (Define)，都是為了搞清楚「是什麼 (What)」和 「有多少 (How Much)」。
一旦弄清定義，且有證據支持，之後要提解決方案才有施力點。
企業設計案或教育訓練課程需求卻是相反，往往都是很明確地提出：
- → 「史蒂芬先生，我想請你來教我們的高階主管『設計思考』，希望他們能應用在日常工作中，並且帶團隊創新。」
- → 「史蒂芬先生，我想請你來看看我們公司的 OO 產品的技術行銷方案。」
- → 「史蒂芬先生，我想請你來教我們的中階主管團隊引導』，希望主管能在公司發揮承上啟下的溝通功能。」
當然，事前訪談很重要，這時候就應該問「為什麼 (Why)」的問題。
之前有幾次接觸的公司，我給的這樣的建議：
「你們現在應該需要先做 □□□□，然後再來做你們想要叫我做的這個。」
然後，就沒有後續了。有些是停了先不做，有些是找其他人繼續完成他們的「初衷」，因為我不認為這對他們有效益。
作為乙方，我必須承受問了 Why 最後被丟包的後果。
不過這樣也好，彼此甘心樂意：
有緣就合作，無緣就謝謝再聯絡。
