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

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

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

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

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

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

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

這邊有個自己團隊最近遭遇的小故事與大家分享：

我們與硬體廠 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 兩人共同證明並指出後，就不得不低頭。

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

後記

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

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