這是兩碼子事!『犛清問題』與『不是我的問題』!

前一陣子有人寫了文章,以硬體工程師的角度,跳出來罵軟體工程師,因而吵得沸沸揚揚,在各社群網站上也被人重覆轉貼了好一段時間,掀起不少戰文。雖然整篇文章看下來情緒化字眼相當多,在某些部份也有些偏頗甚至太超過。但是不可否認,他的確有提到一個長久以來,許多工程師的通病,無論是軟體工程師還是硬體工程師。

身為工程師或與工程師一同工作的人,應該常聽到或自己本身常說這句話:『不是我的問題。』,就是這經典名句,總是搞得老闆慌、主管氣、工程師們更怒。而對這句話,我特別有感觸,因為過去我身為一個科技業救火員,常跳入火坑滅火,發現很多時候,就是這句話讓什麼問題都解決不了,導致起了大火,又沒人要解決,最後還需要我這外人進去犛清問題。

而在這些救火經歷中,我深刻體會到,證明『不是我的問題』是非常困難的。

一方面,有原罪加身,別人會把你當做在推卸責任。另一方面,因為非常難用『列舉法』去證明自己沒錯,又加上當局者迷,所以,才會有這類『列舉不全』的自我辯解:『我的程式在我的機器上測一點都正常,所以沒問題』、『我測量的電壓和波形都很正常,所以不是我硬體的問題』。其癥結在於,你有在其他電腦環境上測過嗎?你有測過所有工作狀況之下的電壓和波形嗎?大家似乎都忘了高中數學就學過,要找出『向量』以指出方向,要有兩個或更多個點嗎?就算你要用列舉法證明問題不在於你,你也要取樣更多更完整的證據。

所以,很多工程師想盡辦法證明自己沒錯,以為自己是在犛清問題,根本不然。因為『犛清問題』與『不是我的問題』是兩碼子事啊!

我認為,如果你要犛清問題,又證明自己沒錯,『證明是別人的錯』才是最好的方法,並且有助於專案前進和實質意義。

這邊有個自己團隊最近遭遇的小故事與大家分享:
我們與硬體廠 X 合作開發一個產品,其中發生了一個問題,播放影片時常會鈍鈍卡卡的,此外,因為該產品有觸控面板,如果影片播放中,用手去碰觸觸控面板,影片會立即變很鈍。

由於是 ARM 平台,播放影片都藉助晶片解碼(Decode),所以起初是找晶片供應商 Y 來查明真相,但是,晶片商『並不認為是自己的問題』,他們認定自己已經出了不少貨,平台夠穩定,所以應該也不可能會有問題。此外,因為觸控面板也會影響影片播放,所以供應商 Y 認定,問題肯定出在 X 廠商因自己動了手腳,加了其他模組或軟體所導致。所以,廠商 X 只好摸摸鼻子,請自己的 RD 找出問題。當然,X 廠商的軟體工程師也不認為是自己的問題,而硬體的人則測了老半天,也不覺得是自己的問題。互相推拖拉的下場,就是最終還是找不出問題所在。

而事實上,這個嚴重問題從去年底我們還沒合作時,他們就已經發現了,直到不久前都還沒解決,時間最少拖了一季。

重點是,既然都不是大家的問題,那問題到底是誰的呢?

為了解決這個問題,最近有個軟體工程師 A 提議,請硬體工程師 B 花幾個小時幫忙,盡可能把所有與影片播放不相干的線路都手動跳線『閹割掉』,想藉由除去硬體設計,反過來證明可能是工程師 B 的問題。而 B 為了真正徹底去掉所有干擾的因素,甚至連各類 Input 裝置(Key button, Touch panel)也都不放過。如此一來,根本沒有操作介面可以控制軟體,讓 A 必須自己想辦法改軟體,去掉一切軟體干擾的因素,使機器啟動後自動只播影片做測試。此外,為了保險起見,A 還特地去要了一塊公板再做一次做同樣的測試。

經過 A B 兩人的共同合作(或是你可以說是互相證明)後,所得到的結果是:『影片播放依然會鈍。』,所以可以推論問題肯定是出在驅動程式或是晶片上。

這時當所有證據指向同一個人,晶片供應商 Y 才願意承認是自己的問題,願意去試著找出問題。然後在深入了解後,才發現是驅動程式給錯了。而 X 廠商因此當了好多個月的冤大頭。

從這個小故事可以知道,軟體工程師 A 想出方法要證明是 B 的問題,而 B 不但做得相當徹底,也不給軟體後路,讓軟體必需修改成單純的自動播放。A 與 B 相互證明是對方的問題,結果得到了真正的解答。其中過程,雖然晶片供應商 Y,一直不肯承認錯誤,但被 A B 兩人共同證明並指出後,就不得不低頭。

奇妙的是,最後你會發現,當有爭議的雙方,都共同想證明是對方的問題時,兩方居然會提出同樣類似的意見和方法。其實,大家都知道怎麼去找出問題並解決,只是都不願跨出那一步而已。

後記

說來慚愧,過去我自己也常說:『不是我的問題』,也常看到很多自認聰潁的工程師,總是可以講的一口頭頭是道,撇清自己的問題。可是,一旦發生問題時,這些置身事外的人,都不能幫助專案進展,一點都比不上那些看似笨笨不高明,但努力去證明和犛清問題的工程師們。

最後,願大家都能成為一個用『證明是別人問題』來證明自己清白的工程師。共勉之。

留言

  1. 如果大家能FOCUS在專案的進行與解決問題,而非後續的責任問題,人就不會因害怕後續責任問題,而盡力地推卸責任

    回覆刪除
  2. 這跟責任制的制度是不是有關? 在這制度下 "是誰的責任" 比 "解決問題" 還重要

    回覆刪除
    回覆
    1. 我是覺得這樣的問題,其實不只是在業界中出現,而是常見於許多工程師的身上。

      因為工程師是活在不斷累積新技術的世界中,所以很多人當下會覺得承認錯誤是代表否認自己過去的努力,認為自己才是正確的。

      這無可厚非,畢竟一個能夠實戰的工程師,一定擁有一定程度的知識和努力,要自我推翻不是這麼容易。

      所以如果執行模式是要先『承認錯誤』再『解決問題』,這對工程師來說相當困難。更還沒提到人性偷懶的問題。

      此外,先把過去經驗丟一邊,重新檢討的做法,常常也不適用於一些工程師身上,問題的根本是一樣的,因為無法跳脫到框框外。

      因此,在這框框內,能找出解決問題的方法,就更為重要了。

      刪除
  3. 需要到犛清問題的情況.
    大多各持己見.
    所以下手一定要重.
    最好一刀切的乾乾淨淨的.
    不然不會有人承認問題.

    回覆刪除

張貼留言

這個網誌中的熱門文章

有趣的邏輯問題:是誰在說謊

Web 技術中的 Session 是什麼?

淺談 USB 通訊架構之定義(一)

淺談 USB 通訊架構之定義(二)

Reverse SSH Tunnel 反向打洞實錄