「都是你害的啦！教我們什麼 Writing Solid Code！害我被同事說我太歸毛！」

「啊是花生了什麼事？」

「不過說真的，你以前要求我們的那些做事的心法，真的是蠻重要的，沒守好這些基礎和紀律，品質真的會一直出大包，大家就會被迫一直加班去 debug！我跟我的那些小 leader 們說這些，剛開始他們也是沒在『信道（台語）』的！後來他們自己吃到苦頭，才開始體會到這些基本功的重要！唉，人就是不見棺材不掉淚…」

這是前一陣子我和一位還在 H 公司的老同事，聊起軟體品質議題時的對話。這麼多年以後，我們彼此，對於軟體品質控管的想法仍然是如此地一致。

什麼是 Gating issue

我們知道，任何專案，最終都有一定的成果得產出，而這些成果必須符合一定的品質標準。有些成果的品質要求較寬鬆，有些則必須極為嚴苛，沒有一點商量的餘地，像與人身安全相關的品質要求就是一例。

照道理，軟體有品質瑕疵是不該被放行出貨的，不論是看得見的使用者介面（User Interface），還是看不見的內部程式碼的瑕疵都一樣。然而，實際的商業運作情況，卻不是這樣。為什麼會這樣呢？

舉個例子，如果使用者畫面上有個明顯的錯字，而這個畫面又是用戶常用的功能，那麼，這個錯字的問題就是一個 gating issue，不解決掉專案就不能結案，產品就不能量產出貨。

你也許會認為，啊不就是個錯字而已嗎？又不會死人，幹嘛這麼機車、龜毛呢？

要解決這個錯字問題，的確很簡單，工程師改程式碼以及品保人員測試檢查畫面的 effort 都很小，但問題不在於解決此 issue 的 effort 大小，而是在於它對用戶／客戶所造成的印象和感受，以及後續對公司所造成的衝擊！

當用戶看到這類問題的時候，用戶心裡會不會這樣想，「這家公司的產品品質控管怎麼這麼爛，連這麼顯而易見的問題都沒測試攔截到！那看不見的地方的品質還能信嗎？」

此例中，issue 本身對用戶的實際功能使用，影響其實並不大，但是它對於企業形象的傷害卻極為嚴重！因此，我們必須將這類 issue 視為 gating issue 來處置，沒有修正就不可出貨。

我們再來看看另外一個例子。

如果有個新用戶，在 APP 的註冊畫面上輸入資料，在即將完成之際，APP 卻突然就閃退掉，這也是一個 gating issue，沒有修正絕不可出貨！

理由很簡單，用戶辛辛苦苦輸入資料，結果卻因為 APP 閃退而必須全部重來，可以想見，用戶心中會有多麼惱怒！如果用戶還願意重新輸入，這還算是幸運的，絕大多數的用戶可能都是直接移除這個 APP，並為這個 APP 送上極差的負評。

負評加上網路的迅速推波助瀾，壞口碑會像武漢病毒一般快速擴散，一傳十，十傳百，然後重傷公司的名聲，如果這類問題發生次數多了，企業也就完了。

Gating issue 的成因

我們來思考一下，為什麼我們會造出這些 gating issues？為什麼我們又會視若無睹，允許它們就這樣跟著產品流入市面？有沒有什麼好方法能防範於未然呢？

軟體開發有個特性，即軟體工程師對 SPEC 自行做出詮釋，然後依據自己的喜好和技能去設計架構（大公司也許有人專門做系統架構設計），最後再用程式設計專用語言，一字一句地寫出程式碼（像寫作文一樣，只是會稍受該程式設計語言的規矩所限制），最後經過編譯器（compiler）的轉譯，變成硬體機器看得懂的動作指令。整個過程，創意的發揮，自由度非常高，這也是為什麼我會投入軟體開發工作的原因之一。

不過，在這個過程當中，有個極大的問題，亦即，只要是人，就有可能會犯錯，可能是因為疲累，也可能是因為想搶快而抄捷徑，更有可能是因為受到壓力而犧牲掉該把關的品質。

像軟體開發這種具高度創意自由的工作，其實更需要有一絲不苟的工作紀律，否則往往會造成重大災難，像各種交通工具的控制系統軟體瑕疵，就有可能會造成無法挽回的悲劇。而要長期、有自覺地維繫自己的工作紀律，卻不是一件簡單的事情。

我們再來看一個常見的例子。軟體工程師們常常因為專案時程被壓縮而被迫要「加快寫程式的創意」，也常常因為客戶不斷要求加功能卻不給時間，而被迫「晚上與假日加班」。但是，創意是無法加快的，加班是會疲累的，在心靈上和體力上都是。因此，工程師們會怎麼辦呢？

很簡單，也很合理，就是犧牲成果品質來換時間，也就是用空間換取時間的概念。只要被犧牲掉的品質部分不要這麼早被發現，就等於幫自己爭取到時間，最好是這些被犧牲掉的品質部分永遠都不要被人（ＱＡ或用戶）發現。

一個例子就是，省掉操作時必要的防呆措施，（例如，只需數字的欄位，根本就不該讓用戶輸入文字），再不然就是寫死一些原本該依用戶不同輸入而展現不同行為的部分（hard-code），造成軟體功能錯誤等！

這樣下來，工程師們時間壓力愈大，被犧牲的品質部分就愈多，造成的問題就愈多，工程師們就愈疲於奔命。於是，工程師們就愈容易疏漏犯錯，製造出更多問題，陷入惡性循環。

這樣的問題其實根本就不是一個技術問題，而是一個人性管理的問題。要解決它，就要從這裡著手。

對付 Gating issue，其實是在挑戰人性

「Writing Solid Code」其實很像軟體開發時的防疫措施，該防的要防，該堵的要堵，盡力做到滴水不漏，不但要讓軟體能正常運行，還得銅牆鐵壁，耐操不當機，這樣用戶才會對軟體放心。

如同該居家隔離卻趴趴走者會被重罰，甚至會被強制隔離一樣，凡是不守此「Writing Solid Code」紀律者，皆應重罰，因為，其所造成的後果，成本實在是過於巨大，甚至是無法彌補！

但想讓軟體達到如此穩若泰山的境界，工程師們可能得花比現行做法多兩三倍的時間，品保人員也會需要等久一點的時間，才能拿到可測試的軟體。不過，等到的品質一定會好很多，好到幾乎沒什麼 gating issue，幾乎可以直接出貨的程度，這樣，品保工作才叫做「品質保證（Quality Assurance）」，是「確認品質沒有問題」，而不是「負責測出所有問題」的錯誤觀念。

整體而言，這樣的做法，專案的時程其實會較短，專案的成果品質會較佳，專案團隊較不需加班，士氣當然也就會比較好。但問題是，老闆或客戶，了解這個道理嗎？願意支持嗎？這才是關鍵。

好的軟體專案管理，是交付一個幾乎沒有什麼 gating issue 的產品，而不是不斷地加功能、砍時間，逼團隊狗急跳牆地犧牲品質，急忙交付一個漏洞百出的產品，然後陷入不知何時才能解決完 gating issue 的惡性循環。更不可硬幹推出產品，陷公司於市場信譽盡失的巨大風險。這一切的一切，都是人性管理的議題，而非技術上的議題。

正確理解 gating issue 的定義，在專案管理的流程上，守住團隊合作紀律，在人員的心態上，加強「工作品質等於自身品格」的觀念教育，說服老闆或客戶埋單，這才是專案管理的正道。否則，不斷習慣交出爛品質的產品，自己的品格品質也就慢慢地廢了。

原文轉貼自：威廉網紙（原文連結）