如何讓設計開發更加貼進顧客需求 有人反應，希望能多看到一些有關專案管理的文章。 這個嘛，小弟管專案大概四、五年經驗，要說熟練或者精通，恐怕言過其實， 剛好曾經讀過一些文章，談的是專案管理（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）. http://cdnet.stpi.org.tw/techroom/analysis/pat_A106.htm [2] Quality function deployment. http://en.wikipedia.org/wiki/Quality_function_deployment --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.132.141.63