別再只問我要答案，這次沒有!
這幾年做教育訓練、顧問服務、和系統導入，發現一件有趣的事情。
有幾次碰到一些客戶(有商業公司、非營利組織、學校…都有)，在開會或課程之後私下跟我說，希望我們在提供建議的時候，可以『直接』告訴我們的team member，這件事情該怎麼做，而不用花太多時間告訴我們這些事情的原則，或是背後的邏輯或原理。因為team member只需要快速地得到答案，加上事情很緊迫，他們也沒有時間去學，說多了徒增困擾(這句話有個潛台詞，建議讀者細想，很有趣…)，顧問(講師)直接告知做法之後，我們就可以比較快進入下一個問題(議題)。
可能有人看了上面這段話不明白意思，我舉其中一個比較具體的例子。
有一次碰到一個軟體開發的資安問題，我花了幾個小時解釋為何程式碼這樣寫不行，為何這有可能帶來風險，從這樣的程式碼我們可以得知外包的開發人員應該有哪些問題…，幾個小時下來，我發現，客戶唯一關心的事情只有一個: 那現在這行程式要怎麼改? 直接告訴我就好。
至於其他的，大夥兒絲毫不在意。
這類的例子最近層出不窮。由於樣本數雖然多但我沒徹底研究，因此目前我無從取得確切的證據，證明背後的原因是什麼?
但推敲之後，能猜個大概。
可能是因為這年頭大家都很忙，碰到問題，只想快速知道答案。而網路的便利性讓許多人變成只願意(也似乎可以)迅速的取得結果，久而久之，慢慢地不願意也沒耐心花太多時間深入理解問題背後的成因。
也就是說，大家並不真的在乎(到願意付上代價、例如時間)來面對問題、或學習解決問題的能力。許多人變得只想知道，當下眼前這問題怎麼解決。
『告訴我解法就好，其餘的我不想多知道。』似乎已經是網路速食時代的寫照。
這是最近幾年碰到的，以往，大概十年前，這情況比較不常發生。但不用我說大家應該也知道，長久下來這(對企業、或團隊)會導致什麼結果。
再加上，網路時代很多流傳文章，標題長這樣：『OOO的原因原來是XXX』、『解決XYZ的N種方法』、『想要OOO就得XXX』這類的文章都很紅。標題看似一針見血，但內容往往很武斷。大部分的文章(或課程)中提出的見解或解決方案，其實都隱含著一個假設前提，就是你的環境和他(作者)相同，然而你也知道，真實世界中哪有環境都相同的? 礙於篇幅(也礙於其實讀者也沒興趣知道)，因此大多數文章的作者，也不太會詳細敘述案情的成因與環境的背景，導致部分憨直的讀者以為，我照著做就會有一樣的結果，其實不然。
一個問題的解決方案，依照環境、人員狀況、時空情境…常常會有著不同的解法。我們在客戶端導入開發方法、框架、或Scrum，不同團隊、不同時空碰到的同一個問題，提出的建議往往是南轅北轍，甚至看似彼此互斥。
曾經有助理跟著我，一周內到兩家不同的公司，客戶問出的問題幾乎完全一樣，但我對兩家客戶提供的建議卻整個大不相同，助理一開始很遲疑，久了之後就慢慢理解為何我們會這麼做。
但，外人乍看之下一定很難理解背後的原因。
不過你可能會質疑，那這樣一切豈不都是自由心證，沒有標準可循? 這樣怎麼知道講師或顧問說的是對是錯?
其實不然，你可以分辨，只要你知道為什麼? 顧問給一個建議，你需要問為什麼，講師給一個做法，你也得知道為什麼?
我常說：知道『為什麼(Why)』永遠比知道『怎麼做(How)』還重要!
要知道，我們專注的是『目標』，各種具體的解決方案都只是手段。目標即便完全一樣，但面對不同的情境，就可能會有不同的做法。但如果學員(team member、客戶)只在乎得到一個答案，卻不在意這答案為何出現? 怎麼來的? 背後的思維是什麼? 考慮的重點為何? 有哪些情境上的先決條件? 背後需要配合的技術環節有哪些? 會不會有副作用? … 那獲得的只是『這次的』解答，僅此而已。
要知道整個解決方案出現的思考脈絡和架構，才是真正有價值的重點，這也才是確保你日後能夠獨立面對問題的關鍵。
我明白，我真的不是不知道，對很多人來說，先把問題解決比較重要...
但這就好比我在台上講時間管理的課程，試圖告訴學員如何安排事情的優先順序，但突然間有位學員大聲喊：『 停、停、別講那麼多道理，直接告訴我下禮拜我該先做什麼就好了...』
這…有點怪，不是嗎?
留言