科技猎质量功能展开（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=[t 1 ,t 2 …t n ]。结合需求绝对权重和技术要求绝对权重，我们可以直观判断需求开发的优先级。
6. 产品竞品力评价
为了保证产品在市场中的竞争力，我们还可以要对竞品进行比较研究，竞品至少应该在两个或以上。
产品竞争力评价分为两个维度，一个是对需求的满足程度，对比产品与竞品之间对各个需求的相对优势，我们使用1-5分，分值越高，优势越明显，将竞品填入对应的分数之中。同样的，我们也可以对技术要求进行对比，研究我们与竞品之间的相对技术优势和劣势。
7. 最终评价
通过质量功能展开，我们已经收集了很多的信息，包括用户需求的重要性、用户需求与技术要求之间的关系、与竞品之间的差距。
至此，我们可以建立一个完整的质量屋。通过这个质量屋，我们可以判断需求开发的优先级，以及我们产品与竞品之间的优劣势对比，解决产品设计方向模糊的问题，保证产品设计及后续开发的质量控制。
总结一下，质量功能展开通过构建质量屋，从用户需求、技术要求、竞争力几个方面分析出我们需要设计的核心功能。这里面还包含了一些统计学的知识，包括需求收集分类等，主要难度还是对需求评分的设置，其他就是些基本计算了。以后会补充一个小案例作为参考，至于什么时候？随缘吧，有缘再见！
本文由 @陈键 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash ，基于 CC0 协议
