0417 從失敗學 - 最難學的是等待

<接上一篇>

而為什麼我會建立這一條 Rule ?當然是從出包中學來的。尤其是當我跟同事一起共事,然後好不容易找到一個可能的問題點,想轉出去結果被瞬間打回來的這種衝擊,真的是很討厭的事情。

而後來隨著經驗多了,除了把問題打出去外,我後來也學會了反擊技。因為做的是 Power Stability ,不可能全部問題都收,但是也不可能全部問題都不收,為了不讓自己累死,最重要的就是判斷這個問題要不要接。也就是說,判斷他到底是不是 Power Stability 的問題。

舉例來說,我在給一些職場新人的建議中有提到,我跟一位資深同事解決了一個很麻煩的問題。其實那個問題一開始因為無法判斷到底是不是我該接的問題,我是有接的,但是後來我都拒接。為什麼?因為同時發生了很多其他類似的 Stability 的問題,但是就只有這個看起來跟我有關這太奇怪了。

於是我主動去找了有發生類似問題的 function team 問了一些問題,然後我幾乎確定這問題的產生是因為 memory/register/cache corruption,這其實在整個案子中,不屬於 power stability 所屬的。你要真的說無關?那也未必,因為這些 corruption 哪一個跟 power 或 clk src 無關?在程式邏輯沒有明顯的 race condition 或是檢查不出來有問題的情況下?

這個時候我主動做了兩件事,第一個是主動去 Qualcomm 的 document base 查找文件,結果果然被我找到兩個有關的文件,一個在講 chipset 本身的問題,另一個則是 pmic 的問題。於是在跟主管、同事討論過後,我們先把這個情況解決跟排除。然而,就算排除這些東西,問題依然存在。

那接下來呢?就是檢查 power 對不對了。於是在加壓測試、驗波形之後,我們解決了八成的問題,這中間也跟硬體部門合作,請他們幫忙往 clk src 被干擾的情況去想(然後我後來就不小心忘了)。因為我自己、同部門的同事、主管都知道,問題沒有完全解決,加壓其實只是減緩問題的發生機會,不是真正的解法,既然比較容易釐清的都釐清了,那問題就可能在不容易釐清的 clk src 被干擾。然而因為加電壓有幫助,結果八成的問題都解決了,結果其他部門也想靠調電壓來解決問題,所以後來我都一直在被迫幫忙作一些我自己都覺得根本無助於釐清問題的實驗。

這就是 credit 不小心建立太快的副作用,所有人都想來找你問問題,然後如果無法清楚界定問題的話,會被迫幫忙跟著釐清。即使那些理論並無法說服我,只是我也因為無法反駁反論,所以也脫不了身。

然後就在我被迫面對處理日常的一堆雜務有點快撐不下去的時候,硬體部門傳來好消息,他們進了一個設計,最後 clk src 的干擾可以被濾掉大部分。為了慎重起見,我們還擺了三天的實驗確定真的問題都不見了,才動手把所有相關的問題全部一口氣清掉。

而我其實算是一個急性子的人,我其實不太會等待。我在跟長輩打牌的時候就經常因為這樣一直放槍,然後一直被長輩們念不要那麼急。就跟做生意、投機一樣,真正大的機會往往是等來的,而我之前因為不善等待,往往在機會來的時候我把握不了。因為真的機會來的時候,手邊沒有資源,沒有空閒,那就算有機會,也還是跟沒有一樣。

而要建立起一個跟自己天性或早期經驗相違背的習慣,其實是不容易的。以我自己而言,我其實經歷過早期人格崩潰,最後重塑這種自我毀滅的階段。我早期人格絕對不是現在這樣看起來好像很理性理智的樣貌,現在只有跟我很熟十幾年的朋友會還記得或還有機會看到我早期的性格樣貌。當然這樣的經驗最好不要有啦,雖然那是會很深刻的。

而自己經歷過的很多次失敗經驗,除了讓我認清自己目前的界線之外,對於加強我計算、控制風險的能力,其實都是一個很好的經驗。而這也是我回到職場以來建立的第二、第三個 concept:

Rule 2&3: Risk Control, and don't afraid losing chances.

我會盡量控制風險,要控制風險的前提是要「認清楚並界定真正的問題」,不然只是不斷增加風險而已。

而控制風險的另一個意義是,當遇到真正的機會的時候,要有能力去把握這個機會,因此,我也會捨得放棄某些看起來很不錯的機會。當然有些比較好的機會會就這樣溜走了,但是至少那是我自己放棄的,而不是因為自己被其他的機會困住而無法把握;而學會等待、放棄一些看起來不錯但是對我目前目標可能不太有益的機會,雖然有的時候還是會有點不舒坦啦。

而,回顧了一些 lesson learn ,我發現我其實常常分不清楚「問題」跟「手段」。這是為什麼我經常失敗的原因之一。

<接下一篇>

Comments

comments powered by Disqus