质量屋怎么做？用QFD把客户需求转成可检查的产品指标

质量屋用一张关系矩阵，把客户想获得的结果转成产品团队可以设计、测量和验证的特性。左边写客户需求，顶部写技术特性，中间判断它们的关系，屋顶检查特性之间是否冲突，底部记录重点和目标。它是QFD常用的产品规划工具，不是把满意度分数自动换算成开发任务的计算器。

当产品、研发和质量人员对“好用”理解不一致时，可以在Boardmix在线协作白板上一起填写需求、关系与验证条件。下面以通勤水杯为例，展示怎样从“放进包里放心”走到可检查的设计要求。

先保留客户语言，不急着写解决方案

“我要双层硅胶圈”已经包含解决方案，“放进包里不要把物品弄湿”才是要满足的结果。若一开始就把某种结构写进需求，后续矩阵会自然偏向该结构，忽略其他实现方式。

本例限定为携带常温饮水的通勤用户，暂不讨论热饮、儿童使用或极端户外环境。下面的需求和权重是用于说明方法的设计假设；正式使用时，应保留访谈、反馈或调查依据，不能把项目组自己的偏好当成客户结论。

重要度在本例采用1～5的相对等级，5表示更重要。不要拿它推算“漏水需求比清洗重要67%”；等级是讨论输入，不是精密比例。若两组用户关心的事明显不同，先分开建立需求表，避免平均后谁也代表不了。

把“好用”拆成可测特性，同时保留测试条件

质量屋的列不能继续写“质量好”“体验佳”。每一列至少说明测什么、单位是什么、希望向哪个方向改。ASQ的质量屋说明强调，技术目标需要可测量，并与客户需求建立对应关系。

这四项是本次讨论选取的特性，不是水杯的完整质量标准。比如是否容易误开、容量是否够用也可能重要，需要结合真实需求补充；材料、安全或适用法规更不能因为客户没有主动提及，就从产品要求中删除。

目标值应在相同口径的样品测量、用户研究和设计约束基础上确定。没有数据时，可以先写“目标待定，先完成样品测量”，并给负责人和完成日期。空着但有明确验证动作，比编一个看似专业的数值更有用。

关系矩阵怎么填，权重怎么计算

先逐格讨论：改变这一技术特性，是否会影响这一客户需求？本例采用强关系9、中关系3、弱关系1、无明显关系0的简化约定。关系强弱是团队待验证的判断，不是已经测得的相关系数；数字不带正负方向，冲突另放在屋顶讨论。

H1的合计为5×9＋4×1＋3×1＋3×0＝52。其余列同样用“客户需求重要度×关系值”逐项相加。开盖与质量的中关系来自本例对单手握持负担的假设；清洗与漏液的弱关系来自密封结构可能影响拆洗的考虑。这些理由应写在格子旁，后续可以推翻，不能只留下数字。

这张表提示团队先关注密封和开盖之间的设计取舍，不代表H3可以取消。重要要求仍需达标，分数也没有包含成本、风险、依赖或实施难度。若调整一处关系判断就使排序反复变化，应先补证据，而不是给小数位来制造确定感。

还可以做一次结构检查：某个需求整行都是0，可能是没有找到对应设计特性；某个技术特性整列都是0，可能没有客户依据，也可能属于尚未列出的安全或制造约束。两者都需要追问，不能直接删除。

屋顶要写出冲突，不只是画一个三角形

质量屋顶部的相关关系区域，用来检查技术特性彼此怎样影响。比如加强密封可能让开盖所需力变大；增加可拆卸结构可能便于清洗，却增加装回不到位的可能。这里先标为“待验证的取舍”，需要用具体设计和样品检查，不能凭直觉断言所有结构都存在同样冲突。

对密封与开盖这组关系，团队可以提出两种结构方案，在一致条件下分别测量漏液量和开盖力，再请目标用户完成相关任务。若某方案不漏水但难以开启，不能只凭H1得分高就选它。回到用户任务与最低要求，寻找同时满足关键条件的方案。

竞品或现有方案比较也应遵守相同口径。没有实际材料时，不在质量屋右侧编造“本品5分、竞品2分”。可以先比较内部两种样品，记录版本、测量条件和结果；等资料充分，再增加外部对比。

填完质量屋，留下三项能执行的决定

ASQ对QFD的介绍把客户需要的识别、优先级和组织执行联系起来。质量屋只是其中常用的起点，不能把“矩阵填完”当作产品设计已经完成。

本例可以先形成三项决定：第一，统一四项指标的测试口径，取得现有样品基线；第二，把密封与开盖列为联合验证项，不让两个团队分别优化到互相冲突；第三，为清洁与携带保留最低要求，等测量后确定目标值。每项决定都要有负责人、输入材料和交付时间。

在Boardmix中，左侧放客户需求，顶部放H1～H4，中间用表格填写关系；屋顶只标最值得讨论的特性对，右侧留依据与问题卡，底部放“指标—测量口径—目标—负责人”。一次评审只展开几项有争议的关系，避免满屏都变成密密麻麻的说明。

当这些指标成为正式需求后，再进入需求追踪矩阵，连接设计、测试与验收。质量屋回答“为什么选择这些指标”，追踪矩阵回答“这些要求后来怎样落实并被检查”，不要用一种表替代另一种。

可以在Boardmix建立一张自己的质量屋，从四条最关键的客户需求开始。先保证每条需求有来源、每个指标能测量、每项关系能解释，再考虑扩大矩阵。