[分享] 如何讓設計開發更加貼進顧客需求
如何讓設計開發更加貼進顧客需求
有人反應，希望能多看到一些有關專案管理的文章。
這個嘛，小弟管專案大概四、五年經驗，要說熟練或者精通，恐怕言過其實，
剛好曾經讀過一些文章，談的是專案管理（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
推
01/09 21:49, , 1F
01/09 21:49, 1F
→
01/09 22:11, , 2F
01/09 22:11, 2F
→
01/09 22:12, , 3F
01/09 22:12, 3F