這個嘛，小弟管專案大概四、五年經驗，要說熟練或者精通，恐怕言過其實，剛好曾經讀過一些文章，談的是專案管理（Project Management）和品質機能展開（QFD），雖然有點冷門，如果大夥不怕被寒流來襲冷到，就且聽小弟一點經驗談，當作小品故事，權作經驗分享。
---
專案Review會議，專案經理Eson、設計部門主管Will和產品經理Mendy一起討論產品品質的問題。
產品經理Mendy：「不是我在說，我們產品部門辛辛苦苦將客戶需求找出來，功能規格也訂出來了，怎麼回事，做出來的東西，功能還是輸給其他同業，完全沒有高品質的樣子，這種東西，客戶能接受嗎？」
專案經理Eson：「你怎麼這樣說，功能規格也只是說需求是什麼，實際上要怎麼做，也沒有說清楚啊～況且我們在時間截止就完成了，也沒有延誤到。」
設計部門主管Will：「就是說啊，我們的人，可是每一樣功能都做出來了，完全符合產品開出來的規格，沒有漏到哪一項，客戶不能接受，跟我們有什麼關係，如果說功能有Bug，當然是我們的問題，但是功能沒有任何問題，客戶不接受，當然就是規格有問題。」
產品經理Mendy：「這還需要我們說嗎？功能就算做出來了，和客戶的需求還差那麼多，反應速度和方便性都不如競爭對手，這樣的產品怎麼賣？能說我們做出高品質的產品嗎？」
設計部門主管Will：「那就是產品開的規格，沒有足夠明確的說明，當初產品只有說要盡快開發出來，可沒有說倒底要哪一種品質，是要比同業快，還是要更容易使用，現在做出來，才說不符合品質要求，這太過分了吧！」
一陣鬧哄哄的會議，在沒有共識的情況下，草草的結束了。產品經理Mendy向Boss反應狀況以後，Boss非常困擾，又找來Conic，討論專案開發的品質問題。
Boss：「唉，Conic，我知道你很久不接專案了，不過你有經驗，這種事該怎麼處理比較好？」
Conic：「嗯～這是『專案品質認知落差』，算是老掉牙的問題了，不過總是會不斷的發生。」
Boss：「其實我也知道，專案經理非常努力了，在這麼趕的壓力，總算是在Deadline前完成，只是品質不如預期，推出市場也只是被打槍的份，這該怎麼和大老闆交代呢？」
Conic：「在專案啟動（Initiating）和規劃（Planing）時期，有沒有做過品質機能展開呢？」
Boss：「品質機能什麼的，那是甚麼東西？」
Conic：「品質機能展開，指的是將客戶的需求，轉換成開發技術需求的一種專案發展工具。」
Boss：「竟然有這種東西，我怎麼都不曉得？真有那麼神奇？」
Conic：「其實也沒那麼神奇啦，只是一種工具，通常我們會用『品質屋[1][2]』規劃出客戶的需求，和技術開發的關聯性，然後給予權重以及評估，用來讓專案經理和開發部門更加清楚了解，客戶需求的來龍去脈。」
Boss：「品質屋？那又是什麼？」
Conic：「所謂的品質屋其實是一種表格，經過設計，可以用圖像表達的方式，一眼看出顧客需求和技術需求之間的關係。」
Conic：「您稍等一下，我上網列印一張範本給您看。」
Conic：「報告Boss，這就是品質屋的範本」
Boss：「這個表格還真有趣，確實長得有點像是個屋子。」
Conic：「是啊，這個屋子裡面，主要有六個項目，按照順序分別是(1)客戶需求、(2)需求評估、(3)技術需求、(4)關係矩陣、(5)技術需求關連矩陣以及(6)技術目標。」
Boss：「這六個項目是怎樣讓客戶需求和技術需求產生關聯呢？」
Conic：「是，很簡單，只要按照(1)到(6)的順序，走訪一次就行了，但是思考的範圍要盡量全面性。」
Conic：「我舉個例子，(1)客戶需求就是產品部門訪談客戶之後，認為客戶所需要的功能，也許有幾十項，經過分門別類以後，整理下來，例如針對效能的需求，可能就會有一項需求是反應速度要在50ms完成。」
Conic：「接著是(2)需求評估，也就是對客戶需求內容的分析，有些需求其實沒有必要理會，而有些是非常重要的，在這邊可以用分數寫出來。」
Conic：「(3)技術需求就是我們能夠提供的各種技術方法，例如針對效能部分，可以提供快取功能，用來加速反應，當然還有其它的技術方法可供參考。」
Conic：「第(4)關係矩陣就很重要了，這個地方要寫下，客戶需求和技術需求的關係，例如是非常相關，還是一點都沒有關係，有些是強相關，而有些是弱相關，這裡就可以讓我們決定，我們提出的技術需求，是不是都有滿足客戶需求，或者是在做白工。」
Conic：「然後是(5)技術需求關聯矩陣，技術本身可能存在矛盾現象，例如要加速，但是會造成運算負擔加重，這樣會和降低運算的技術需求衝突，我們就寫在屋頂，用一個減號表示，到時候開發部門就會注意到這個問題。」
Conic：「最後是(6)技術目標，是將前面的分析，加總之後的結果，用來找出最重要的幾個需求，顯示出要讓客戶滿意，應該先完成的項目，同時，我們可以和競爭對手比較，看看是不是具有競爭力，如果需求的優先權很高，但是我們的功能卻遠低於對手，那就必須趕快提醒設計部門，應該要加強這些功能的改善，讓客戶獲得最大的滿意。」
Boss：「哇～這看起來還滿複雜的，不過你這樣講解以後，我可以理解，確實可以從一張圖表中，就發現產品應該發展的目標，和該注意的地方，而且要解釋給設計開發部門也相對容易得多。」
Conic：「是，這就是品質機能展開最主要的目的。」
Boss：「那只要在專案初始的時候完成就行了嗎？」
Conic：「當然不是，品質這種事，是隨著專案的發展，必須不斷的進行監控（Monitoring），然後適當的調整。」
Boss：「所以，在EVT（Engineering Verification Test）的時候也要檢查一次的意思嗎？」
Conic：「不只是EVT，最好在DVT（Design Verification Test）也檢查，確保開發出來的產品，有按照品質規劃在走，才不會大家辛苦一場，結果只是做白工，最後還賣不出去。」
Boss：「你這樣說也有道理，我這就叫產品和專案經理試著做一份品質機能展開，讓他們好好有個共識，再趕快將品質調整回來。」
---
我們真的瞭解顧客的需求嗎？不只是專案經理或設計部門的問題，有時候就連產品部門都沒辦法很明確定義，一樣的客戶需求，可能會有幾十種不同實做的方法，哪一種方法稱得上是高品質，其實是很難界定的，市場面上就已經很難決定了，更何況實際施工的專案團隊，要弄清楚品質目標，更是不容易。
品質機能展開是專案管理工具的應用，這類型的工具還有很多，像是Triz或是DOE等，都是有助於專案管理開發的有用工具。但工具畢竟只是輔助的道具，重點還是專案管理的主事者有沒有用心在經營，尤其成功專案的定義，仍在「如期、如質、如成本」這三角打轉，即使專案努力趕工在時間內完成，但做出一個品質讓客戶無法接受的成果，這個專案仍然是失敗的。
因為先天上，客戶和開發部門本來就是講著兩種不同的語言，除非必要，老死不相往來。客戶說的，通常是很功能性的，模糊不清，而且灰色地帶很多；而開發部門講究精確，凡事都要可以衡量，死板板硬梆梆。沒有誰對誰錯的問題，卡在中間的產品和專案經理，就必須負擔起溝通的責任，讓大家能在相同的共識下通力合作，利用工具可以讓生活好過一些，至於什麼時候該用，該怎麼用，沒有一定的答案，只能說是「存乎一心」而已。
Reference:
[1] 品質機能展開（QFD）與品質屋（HOQ）.
[2] Quality function deployment.
沒有留言:
張貼留言