聚餐也談品質流程

本周一同人在新公司 on board,公司事先訂好餐廳為我舉行迎新聚餐。在這場聚餐當中的一道菜,讓大家開啟談論品質流程的話題。

某同事甲指著一道菜,跟負責點菜的同事乙說:下次就別再點這道菜了。他說那道菜的肉,咬下去裡面是白的,顯見豬肉並沒有先醃過,吃起來就不夠味。這時候,有些同事表示認同,紛紛也附和同事甲的意見來評論這道菜。

同人對同事甲的看法沒有什麼意見,因為說實在的,我也吃不出這道菜有什麼不好。不過,如果精於美食的同事甲說得是正確的,那麼就代表這家店的這道菜品質有問題。於是我說:這其實代表他們 QA 沒做好。

這時候,大家好奇的眼光看著同事丙,也就是公司 QA Leader。他說 QA 沒有辦法提昇產品的品質,它只能確保有問題的產品不會送到客戶的手中。

顯然同事丙和同人對 QA 的定義有顯著的不同,他所說的 QA 是針對產品本身的控制流程,而非針對產出保證產品品質的執行過程,我認為那是 QC 而非 QA。但同人並不想挑戰對方對 QA 的定義,以免把吃飯的氣氛弄得太嚴肅,於是我用另一種方式來表達我的觀點:

我的意思是作這道菜的流程出了問題,導致產出無法符合顧客對品質的要求。所以他們應該設法改善這道菜的製作流程,讓它更完整並且可以符合客戶的需求。

終於,同事丙沒有再質疑同人的說法。不過,這也讓人看到一個現象,就是在台灣,品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外,以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」,讓開發人員認為品質是品質部門的責任,而品質部門則認為提昇品質不是他們的責任,以為最多只能做到知道產品有問題,而不知道如何改善它們,只能退回到開發人員那邊來解決。

在一個重視品質文化的公司,QA 人員對產品的意見當然可以擲地有聲,善盡到品質管制的責任。然而,在台灣軟體開發的環境,尤其是大部分以專案型態的軟體開發,品質往往是時間或成本不足第一個被犧牲的對象。同人想到我過去在一個大型政府公共建設委外 BOT 專案中,因為業主對文件要求嚴格,使開發團隊要花費相當多的心力來寫文件。想不到上層負責監督的 VP 卻說:沒有時間,品質目標只要設定為達到 30% 就夠了。

同人很清楚那位 VP 的說法是不會 work 的,因為品質不能妥協,否則你必將付出更大的代價。果然那個因為延誤而讓公司損失慘重的專案,在我離開那個專案兩三年後才勉強結案驗收。不幸地,這種不重視品質文化的開發方式,在今天卻還在台灣各地持續上演之中。

因此,與其將品質寄望在強大的 QA 人員或嚴謹的品質流程,還不如在開發過程中織入品質的面向,形成品質保證的全像圖。高品質是全員參與的必然結果,在分析、設計過程就加入如何提昇品質的思維,以達到符合顧客的需求,並且創造他們的價值,這便是執行所謂的 QA,也就是真正的品質保證。

當然,能夠為客戶創造價值的品質流程並非絕對的,就像負責點菜的同事乙後來表示,她不覺得那道菜難吃呀。其實同人也覺得那道菜也還好,品質和你的客戶是誰有很大的關係,事實上,並不是每一個人都對吃很講究,所以那道菜的品質,其實是因人而異呀。

後記:

本篇文章已刊登於 ZDNet Taiwan 部落格文章專區

Please follow and like us:
分類: CNet/ZDNet, 利害關係人, 品質文化, 問題解決, 專案監控, 專案規劃, 思考, 生活感觸, 職場, 開發流程。這篇內容的永久連結

在〈聚餐也談品質流程〉中有 10 則留言

  1. 自動引用通知: 絕對支持品質流程的宣稱 « 同人的生活派對

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *