別再只問我要答案,這次沒有!

這幾年做教育訓練、顧問服務、和系統導入,發現一件有趣的事情。

有幾次碰到一些客戶(有商業公司、非營利組織、學校…都有),在開會或課程之後私下跟我說,希望我們在提供建議的時候,可以『直接』告訴我們的team member,這件事情該怎麼做,而不用花太多時間告訴我們這些事情的原則,或是背後的邏輯或原理。因為team member只需要快速地得到答案,加上事情很緊迫,他們也沒有時間去學,說多了徒增困擾(這句話有個潛台詞,建議讀者細想,很有趣…),顧問(講師)直接告知做法之後,我們就可以比較快進入下一個問題(議題)。

可能有人看了上面這段話不明白意思,我舉其中一個比較具體的例子。

有一次碰到一個軟體開發的資安問題,我花了幾個小時解釋為何程式碼這樣寫不行,為何這有可能帶來風險,從這樣的程式碼我們可以得知外包的開發人員應該有哪些問題…,幾個小時下來,我發現,客戶唯一關心的事情只有一個: 那現在這行程式要怎麼改? 直接告訴我就好。

至於其他的,大夥兒絲毫不在意。

這類的例子最近層出不窮。由於樣本數雖然多但我沒徹底研究,因此目前我無從取得確切的證據,證明背後的原因是什麼?

但推敲之後,能猜個大概。

可能是因為這年頭大家都很忙,碰到問題,只想快速知道答案。而網路的便利性讓許多人變成只願意(也似乎可以)迅速的取得結果,久而久之,慢慢地不願意也沒耐心花太多時間深入理解問題背後的成因。

也就是說,大家並不真的在乎(到願意付上代價、例如時間)來面對問題、或學習解決問題的能力。許多人變得只想知道,當下眼前這問題怎麼解決。

『告訴我解法就好,其餘的我不想多知道。』似乎已經是網路速食時代的寫照。

這是最近幾年碰到的,以往,大概十年前,這情況比較不常發生。但不用我說大家應該也知道,長久下來這(對企業、或團隊)會導致什麼結果。

再加上,網路時代很多流傳文章,標題長這樣:『OOO的原因原來是XXX』、『解決XYZ的N種方法』、『想要OOO就得XXX』這類的文章都很紅。標題看似一針見血,但內容往往很武斷。大部分的文章(或課程)中提出的見解或解決方案,其實都隱含著一個假設前提,就是你的環境和他(作者)相同,然而你也知道,真實世界中哪有環境都相同的? 礙於篇幅(也礙於其實讀者也沒興趣知道),因此大多數文章的作者,也不太會詳細敘述案情的成因與環境的背景,導致部分憨直的讀者以為,我照著做就會有一樣的結果,其實不然。

一個問題的解決方案,依照環境、人員狀況、時空情境…常常會有著不同的解法。我們在客戶端導入開發方法、框架、或Scrum,不同團隊、不同時空碰到的同一個問題,提出的建議往往是南轅北轍,甚至看似彼此互斥。

曾經有助理跟著我,一周內到兩家不同的公司,客戶問出的問題幾乎完全一樣,但我對兩家客戶提供的建議卻整個大不相同,助理一開始很遲疑,久了之後就慢慢理解為何我們會這麼做。

但,外人乍看之下一定很難理解背後的原因。

不過你可能會質疑,那這樣一切豈不都是自由心證,沒有標準可循? 這樣怎麼知道講師或顧問說的是對是錯?

其實不然,你可以分辨,只要你知道為什麼? 顧問給一個建議,你需要問為什麼,講師給一個做法,你也得知道為什麼?

我常說:知道『為什麼(Why)』永遠比知道『怎麼做(How)』還重要!

要知道,我們專注的是『目標』,各種具體的解決方案都只是手段。目標即便完全一樣,但面對不同的情境,就可能會有不同的做法。但如果學員(team member、客戶)只在乎得到一個答案,卻不在意這答案為何出現? 怎麼來的? 背後的思維是什麼? 考慮的重點為何? 有哪些情境上的先決條件? 背後需要配合的技術環節有哪些? 會不會有副作用? … 那獲得的只是『這次的』解答,僅此而已。

要知道整個解決方案出現的思考脈絡和架構,才是真正有價值的重點,這也才是確保你日後能夠獨立面對問題的關鍵。

我明白,我真的不是不知道,對很多人來說,先把問題解決比較重要...

但這就好比我在台上講時間管理的課程,試圖告訴學員如何安排事情的優先順序,但突然間有位學員大聲喊:『 停、停、別講那麼多道理,直接告訴我下禮拜我該先做什麼就好了...』

這…有點怪,不是嗎?

碰到問題,直接要答案,不是不行,只是可惜…

留言

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

使用Semantic Kernel 建立自然語言請假系統

精彩(且驚人)的Semantic Kernel入門範例

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...