起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識質量功能展開（QFD）在產品設計中的應用——基本理論模型
編輯導語：在產品落地前，團隊除了需要依據市場情況、用戶需求等方面做好產品設計方案，對產品做好質量管理也是其中重要一環。有效的產品質量管理有助于降低問題風險，進而降低企業潛在生產成本。本文作者對質量管理中、針對產品設計環節的工具——質量功能展開（QFD）進行了詳細介紹，一起來看一下。
在介紹質量功能展開之前，先問大家一個問題：在生產過程中持續提升產品質量，將會增加企業成本，還是降低企業成本？
如果你未接觸過質量管理，按照第一直覺，當然會增加成本！畢竟提升質量是需要耗費時間和精力的。
但是，有一個人，偏偏不這么認為，他就是愛德華茲·戴明，一位質量管理大師。
他早年一直在美國推崇質量管理理念和方法，可是正如前面所說，我們的第一直覺都認為質量管理會提升生產成本，于是大多數美國企業都是拒絕的。而在太平洋彼岸，有一個叫日本的小國家，天天盯著美國老大哥有什么新的生產理論，好去學習學習。于是，在美國沒有得到重視的質量管理理論，在日本反而是遍地開花。
后來我們都知道，80、90年代的日本制造一直是高品質的代名詞，從電器到汽車樣樣結實耐用，逐漸占據了世界市場。美國老大哥也傻了眼，以前的小弟怎么突然那么猛了？一研究發現日本企業幾乎都是戴明質量管理理論的門徒，于是質量管理開始名揚天下。
話說回來，開頭提到企業成本的問題，作為統計學家的戴明，經過大量統計學計算，認為質量管理是可以降低生產成本的。
其實也不難理解，當生產中的每個環節都保證生產質量，從整條生產鏈來看，當然節省了不少“補鍋”的功夫。
有個理論叫“1-10-100”，當上游發現問題，處理成本是1；上游的問題沒處理好就交到下游，解決成本是10；上下游都沒有把問題處理好，產品到了客戶手上，解決成本就成為100了！
想想是不是這個道理？一個產品經理的設計有問題，本來產品組本身可以解決的，但是趕時間嘛，就先安排開發了；開發發現了問題，也趕時間，就照做了；到了用戶手上，這個小問題或許就成大問題了，各種危機公關事件不都是這樣來的嗎？
產品設計作為生產環節最初的一環，當然需要進行質量管理，在質量管理理論當中也有工具是專門針對產品設計的，其中，質量功能展開（Quality Function Deployment，即QFD）就是非常實用的一個工具。
一、質量功能展開與質量屋
質量功能展開是一種將產品需求、技術、競爭力進行全面分析的方法，其目標是要找到最有價值的功能（價值=功能/成本）。質量功能展開是可以利用多種工具，包括親和圖、關系圖、樹圖、流程圖等，其中最核心的工具是質量屋（Hose of Quality，即HOQ）。
質量屋是1988年由兩位美國學者提出的，這是一種將用戶需求和產品或服務的性能進行關聯的視圖表達形式。由于形狀與房屋酷似，因此稱之為質量屋。質量屋分為幾個部分：
- 左墻：WHATS輸入矩陣，表示客戶需求，以及客戶需求的重要度。其中需求是用戶希望實現的產品或服務特性，重要程度則由客戶定量評分得出。
- 天花板：HOWS矩陣，展示解決客戶需求所需要用到的技術手段，即“怎么做”，將客戶需求轉化為可執行、可度量的技術方案。
- 房間：相關關系舉證，主要展示客戶需求和技術要求之間的關系。
- 屋頂：HOWS相互關系矩陣，主要展示技術要求之間的相關關系。
- 右墻：評價矩陣，主要與市場競品進行各種競爭要素的比較，作出產品在該領域競爭優劣勢的評價。
- 地下室：HOWS輸出矩陣，對技術要求的成本進行計算，包括考慮技術特性的重要度、目標值、競爭優勢等，進行綜合的計算，最終確定優先開發的需求和優先滿足的需求。
整個小房子大概就是下面這樣，當你把它填滿之后，你需要優先設計的、價值最大的功能，就呼之欲出了，大大降低了設計出垃圾功能的風險。
二、質量功能展開步驟
QDF的總體架構分為幾個部分：
- 用戶需求分析；
- 技術要求分析；
- 建立需求——技術關系矩陣；
- 需求競爭性評價；
- 需求優先級與技術難度——最終評價。
下面，一步步地介紹。
1. 用戶需求分析
1）需求收集
產品設計的第一步，需要盡可能多地收集用戶需求。這個過程中，我們首先需要識別產品的客戶是誰。
軟件產品的特性是，用戶和客戶可能是分離的，如大部分面向個人的App的用戶是個人，但客戶是廣告投放商家。在B端產品，還有可能有多種用戶的情況，如CRM系統的用戶可能是普通客服、客服管理員、寄件管理員甚至是企業高管。
識別產品目標用戶后，我們需要通過各種渠道收集用戶需求，包括與用戶進行面對面的訪談、問卷調查，或者通過用戶歷史使用數據分析，甚至是了解行業新聞等渠道。收集各種信息后，我們需要對其進行管理和歸納，過濾掉無效信息，使用表格將用戶需求羅列出來。
2）需求層次化
需求收集完成之后，我們需要對需求進行整理，各種需求有可能出現類似、包含、相互交叉等關系。在這個階段，我們可以使用親和圖法（KJ法）對需求進行整理。
首先，將內容相近的需求歸納到一起，只保留其中一個需求，并記錄需求出現次數。
然后，將剩下的需求再進行分組，并重命名新的分組，重復這個步驟繼續進一步分組，一般情況下，只需要分2-3個層次即可，已經可將用戶需求進行大概的劃分。
最終，畫出代表各個需求關系的親和圖。
3）需求重要度評價
需求整理完成之后，我們需要對用戶進行進一步的調研，使用問卷調查法，了解我們所整理的需求，在客戶心目中的重要程度。
可以采用1-10分的分值代表每個需求的相對重要程度，盡可能覆蓋不同類型的用戶，每個需求取其平均值作為該需求的重要度。
2. 技術要求分析
明確用戶需求之后，我們下一步需要考慮開發成本的問題。
這里首先需要列出實現用戶需求需要配備的技術要求。
這一階段的工作需要開發人員參與評估，技術要求不只是程序開發的技術手段，包括了整個產品的開發周期，如設計要求、開發技術、后期維護等，這些方面都會涉及到開發成本的計算。
由于技術要求本身具有相關性，為了更準確地評估開發成本，我們需要分析技術要求之間的相關關系，并建立關系矩陣，使用“◎、○、△”符號表示強相關、中等相關和弱相關，用“◎=9，○=3，△=1”的標準進行打分，就此構建了質量屋的屋頂部分，如下圖：
3. 客戶需求與技術要求之間的關系矩陣
客戶需求與技術要求之間的關系矩陣是整個質量屋的核心部分。根據客戶需求與技術要求之間的相關度計算，我們可以確定需求的優先級和開發成本。
兩者的關系我們同樣可以用“◎、○、△”符號表示強相關、中等相關和弱相關，用“◎=9，○=5，△=1”的標準進行打分，利用得分描述用戶需求和技術要求之間的關系。
這一步需要技術人員與設計人員共同評估，根據團隊以往的項目經驗，推斷出需求與技術之間的關系，構建一個矩陣，如下表。
表4-2 需求-技術矩陣
根據以上矩陣，我們可以得到用戶需求和技術要求之間的對應關系矩陣R：
4. 決定需求優先級排序
1）設定需求目標值
在需求分析階段，我們已經了解了用戶對各個需求的重要程度的評分，結合需求的重要程度，團隊需要為需求進行一個目標值評價。
根據KANO模型，顧客對產品滿意度可以分為三個級別：基本型需求、期望型需求、興奮型需求，我們的目標值可以結合KANO模型，設為1-5分，1代表基本滿足需求、3代表滿足用戶期望、5代表超出用戶預期，其他數字在兩者之間。
2）選出產品賣點
在眾多需求中，并不是每個需求都是我們主打的，要在市場上建立競爭優勢，必須有自己突出的賣點，對產品進行差異化設計。這里我們可以簡單使用1和2兩個分值，2代表賣點、1代表非賣點。至此，我們可以計算各個需求的相對權重了。
3）計算客戶需求的絕對權重
在質量功能展開中，我們首先從需求的角度出發，通過上述提到的三個指標：重要度、目標值、賣點進行需求絕對權重的計算。
計算公式為：絕對權重（J）=顧客重要度（Z）×目標值（M）×賣點（S）。
在質量屋中顯示如下圖：
由此，我們可以得出了用戶需求絕對權重矩陣J=[J1，J2……Jn]。通過絕對權重的對比，我們可以得出各個需求的重要程度，找出關鍵需求。
5. 技術要求的絕對權重
分析需求的權重后，我們還不能直接按照需求權重進行開發，還需要考慮客戶需求和技術要求之間的關系。
因此，我們需要計算技術要求的絕對權重，以技術要求的權重作為產品開發的考慮因素。
技術要求的絕對權重，與客戶需求絕對權重和客戶需求與技術要求之間的關系有關，技術要求的絕對權重（T）為客戶需求與技術要求關系矩陣（R）與需求絕對權重（J）的乘積之和，公式為：
由此，我們可以得出技術要求的絕對權重T=[t1,t2…tn]。結合需求絕對權重和技術要求絕對權重，我們可以直觀判斷需求開發的優先級。
6. 產品競品力評價
為了保證產品在市場中的競爭力，我們還可以要對競品進行比較研究，競品至少應該在兩個或以上。
產品競爭力評價分為兩個維度，一個是對需求的滿足程度，對比產品與競品之間對各個需求的相對優勢，我們使用1-5分，分值越高，優勢越明顯，將競品填入對應的分數之中。同樣的，我們也可以對技術要求進行對比，研究我們與競品之間的相對技術優勢和劣勢。
7. 最終評價
通過質量功能展開，我們已經收集了很多的信息，包括用戶需求的重要性、用戶需求與技術要求之間的關系、與競品之間的差距。
至此，我們可以建立一個完整的質量屋。通過這個質量屋，我們可以判斷需求開發的優先級，以及我們產品與競品之間的優劣勢對比，解決產品設計方向模糊的問題，保證產品設計及后續開發的質量控制。
總結一下，質量功能展開通過構建質量屋，從用戶需求、技術要求、競爭力幾個方面分析出我們需要設計的核心功能。這里面還包含了一些統計學的知識，包括需求收集分類等，主要難度還是對需求評分的設置，其他就是些基本計算了。以后會補充一個小案例作為參考，至于什么時候？隨緣吧，有緣再見！
本文由 @陳鍵 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
- 目前還沒評論，等你發揮！
