思考是上天賦予人類最大的禮物，但往往矛盾的人類在越小的時候越會善用這份大禮，長大後在工作的職場卻忘記了。要在工作職場，尤其是軟體產業這種高壓的環境生存我想沒有比不斷持續思考更重要的事情，在此我將之簡稱為『Persistence Thinking(持續性思考)』。
在軟體業的領域也待好幾年了，接過的專案也不下數十個，我發現一個有趣的現象，普遍的軟體工程師一開始接獲到問題追蹤清單就會開始一路的一條一條逐項修改，之後修改完後就把問題改成已修正並繼續往下一個問題加以修改。在台灣，專案的開發不難，難的就是在這種專案的反覆調整跟debug反覆出現的時間點，很多事情如果只是『你吩咐、我照辦』的心態下去做，總會有做不完的白工要進行。我總覺得這種工程師真的是『好傻、好天真』，但這卻是大部分的工程師所犯的錯誤。
改debug不是不好，而是不要停止思考的能力，工程師之所以被歸類在知識工作者的頭銜不就是因為能具備思考的能力，但大家往往忘記這一塊了只記得我的程式要寫多快，一天要改多少debug跟釐清多少問題。如果僅止於此那軟體工程師跟加工廠的勞動員工有什麼不一樣，你手一直動著敲鍵盤；他的手也一直動著拿加工物，只是他的東西比較重而已不是嗎？
把問題處理好是件好事，但不要第一個時間點就傻傻的處理，這幾年來我一直跟工程師討論，要不斷思考一直在修改的問題大部分是屬於內部或外部問題在著手處理。內部問題是指問題是自己修改某項目後衍生的問題；而外部問題是指問題是從外部當中不斷增加(也就是使用者的需求一直無法收斂)。為什麼要確認這件事情，主要是因為解問題請解根源，不然根源沒解一切的狀況都不會改變的，如此工程師痛苦的修改人生將持續不斷上演。
自動化測試是解決內部問題的最佳幫手。當問題釐清之後在開始靜下心來想清楚要如何處理，若發現是內部問題居多，也就是常常改了A，B就有問題，改了B之後C又出錯，這種問題在系統越龐大就越容易出現，不可能有測試人員會真的把每個邏輯重頭到尾跑一遍，所以工程師應該趕緊把問題修復之後，接著開始著手處理根源à也就是如何將手邊相關的工作進行自動化測試。一旦有自動化測試那所有惱人的內部修改問題將可以減少大半，工程師也可以獲得比較好的生活品質跟更多的時間來精進能力。
服務至上的蠢口號是培養外部問題的絕佳營養品。若發現是外部問題居多，代表是SA或PM對於問題的收斂掌握度出現問題。如果是一個經驗好的工程師應該可以跟他們反應，或者直接發mail給專案成員跟相管的主管一起開會來討論如何因應。當然，若這些現象是公司想要服務好此客戶的策略，那就另當別論(附帶一提，這種special case實在不應該反覆一直出現在專案當中，否則每個客戶都是特例，那還叫特例嗎。偏偏在台灣的軟體業真的把每個專案都當成特例在處理，總是滿口服務至上所以客戶追加的最好盡量修改，這種把客戶的胃口養大了之後拿不到太多經費，老實講要怪就怪自己吧，幹嘛把客戶養那麼肥…)。
服務是件好事，錯的是不能將服務無限上綱，看看IBM、Oracle…等外商的姿態，國內的姿態已經擺那麼軟了，為什麼人家還是覺得外商好，如果還不知道從這一點思考，那就真的等著被老外砍吧！
持續思考吧，台灣的軟體工程師們，在世界的舞台上，軟體業已經缺席很久了。趕快累積能量，要抱著偉大的夢想：『未來的軟體產業舞台上請世界各國大廠密切注意…Taiwan will coming soon…』
留言列表
