習慣交出爛品質的產品,你還有人格可言嗎?

    圖片來源:pixabay.com
    「都是你害的啦!教我們什麼Writing Solid Code!都被同事說我太歸毛!不過說真的,你以前要求我們的那些心法,真的是很重要。沒守好這些基礎齁,品質就真的會一直出包,大家就會要一直加班debug!我跟我的那些小leader們說這些,剛開始他們也沒在信道的!後來他們自己吃到苦頭了,才開始體會到這些基礎工的重要!唉,就是不見棺材不掉淚…」

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

    什麼是Gating issue(卡關)?

    我們知道,任何的專案,最終都必須要產出一定的成果,而這些成果則必須符合一定的的品質標準。有些成果的品質要求可能不怎麼嚴苛,有些成果的品質標準卻必須非常嚴苛,一點商量的空間都沒有,像是跟人身安全有關的一些品質要求就是。

    在很多時候,軟體的品質瑕疵是不該被放行而出貨的,不論是看得見的使用者介面,還是看不見的內部程式碼。然而,實際的情況卻不是這樣。怎麼會這樣呢?

    舉個例子來說,如果使用者介面上有一個明顯的錯字,而這個使用者介面,又是用戶會常用的功能,那麼,這個錯字問題就會變成是一個gating issue!所謂的gating issue就是「不解決掉這個問題,專案就不能結案,產品就不能進入量產出貨」。原因是,雖然這不過是個錯字而已,又不會死人,但是,這個錯字對於用戶所造成的印象卻是,「這家公司的產品品質控管怎麼這麼爛,連這麼明顯的問題都沒測試出來,是眼睛都瞎了嗎?那看不見的地方,品質還能相信嗎?」

    這個案例當中,issue對於用戶造成的實際衝擊其實並不大,但是,它對於公司形象的衝擊,卻是極為地嚴重!因此,我們必須將這類issue歸入gating issue來處理。

    第二個例子是,如果有一個APP的新用戶註冊畫面,會在特定的資料輸入之後就會當掉(也就是所謂的閃退),那麼,這個問題也是一個gating issue!理由是,用戶辛辛苦苦輸入的資料,在APP閃退後全部消失,可以想見會有多麼惱怒!這就是一個issue對用戶造成極大衝擊的案例。

    在這個網路無所不在,個人高度地自媒體化的世界,像這樣的壞口碑的傳播速度,會像病毒擴散一般地快速!然後,你的公司的名聲,就立馬跟著毀了!所以說,對用戶造成極大的衝擊之後,緊接而來的,通常就會是對公司形象的嚴重衝擊!這樣的issue怎能不列管為gating issue呢?

    至於另外一種常見的問題,就是APP會莫名其妙地閃退,根本就沒有一個規則!這種隨機當掉的問題,是整個品質控管工作當中,最惱人、最難解決的一種問題,它當然也必須被列為gating issue

    談到這裡,gating issue的定義,和它的解決方案的難易度,其實是完全無關的。Gating與否,應該要視這個issue對於用戶、客戶,以及公司的衝擊來綜合考量!

    如何對付Gating issue?

    俗話說得好,打蛇打七寸,談了這麼多gating issue的例子和定義,不如好好地來想想,為什麼會產生這些gating issues?有沒有一個比較好的管理方法,在源頭就把這些問題消弭於無形呢?

    我們知道,軟體都是靠軟體工程師們,把他們對於產品功能要求的認知,套上自己的思考邏輯,用程式語言的特定格式,一字一句地表達出來,寫成為程式碼的。但是,只要是人,就都有可能會因為疲累而疏漏犯錯,也有可能是因為想偷懶、抄捷徑,而犯錯。根據我20年來帶領軟體研發人員以及管理軟體專案的經驗,絕大多數gating issue的元凶不外乎就是這兩種原因。那麼,要讓軟體專案少一點gating issue,痛苦少一點,結案順利一點,就得從這兩處源頭來下手。

    我們先來談談偷懶這件事。其實工程師們往往也不是因為真的想偷懶,而是常常因為工作量太大,被逼迫著要快還要更快,功能要多還要更多,因此,很多為了預防使用者犯錯的防呆用程式碼(例如,只讓使用者在電話號碼欄位輸入「數字」,禁止輸入其他文字),以及很多為了防止軟體當掉的保護用程式碼,就在這種壓力之下被省略掉了!結果就是,很多該保護的地方沒保護,該防堵的地方沒防堵,問題就層出不窮了!

    好了,問題愈多,工程師們就需要花更多精力去對付這些問題。花愈多精力就愈疲憊,於是就更容易疏漏犯錯,製造出更多的問題。如此,就陷入了一個惡性循環的迴圈當中。

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

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

    Writing Solid Code」其實就是上面所講的「該保護的就要保護,該防堵的就要防堵」的觀念而已,讓軟體變的像銅牆鐵壁一般穩固不當掉。要做到這件事情,可能會需要花費工程師們「把實現功能本身的程式碼寫完」兩三倍以上的時間才能夠達成。說白話一些,就是品保人員會需要等比較久的時間,才能夠拿到一個可以測試的軟體,但是,品質會比較好,好到幾乎沒什麼gating issue!軟體工程師交出來的成果,幾乎就是可以出貨的水準。整體而言,整個專案的時程其實會比較短,團隊也比較不需要常常加班來解決大量的gating issues

    但是要這樣做,就需要先說服老闆或是客戶,好的軟體專案管理,應該是要能夠交付一個幾乎沒有什麼問題的軟體產品(縱使是需要多等待一些時間),而不是逼迫團隊急急忙忙地交付一個問題很多的產品,然後不知道這些問題什麼時候可以被解決完畢,最後迫不得已把還有很多gating issues的產品匆促推出,損人又不利己,得不償失!這也是在解決人性的問題,而非解決技術的問題。

    gating issue的定義,和其數量的多寡來佐證,向上或對外做有力的說服,這才是專案管理的正道。不然,習慣交出爛品質的產品,你的人格品質也就逐漸地廢了!