專案成果的爛品質到底是怎麼形成的?正本清源的解決之道又是什麼?

    圖片來源:pixabay.com

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

    「啊是花生了什麼事?」

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

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

    什麼是 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)的轉譯,變成硬體機器看得懂的動作指令。整個過程,創意的發揮,自由度非常高,這也是為什麼我會投入軟體開發工作的原因之一。

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

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

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

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

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

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

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

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

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

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

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

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

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

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