1. 产品需求文件
产品需求文件(Product Requirement Document,PRD)是需求管理过程中的核心文件,描述了产品开发的所有需求。该文件是开发团队实际用于产品开发的目标导向性文件,也可以认为是产品开发的最高标准。
需求管理将客户或市场的需求进行统一且标准化的管理,是为了确保产品开发的需求被准确地捕捉并传递到企业内部。与此同时,产品开发团队也需要一份可以作为(唯一)目标的开发标准。产品需求文件就是承载这个目标的载体。
一份简单的产品需求文件可以被理解为产品开发需求的简单集合。为了确保需求很好地被传递,在该文件中还会添加一些特殊的属性分类,并通过这些属性把产品需求文件与开发过程中的其他重要文件关联起来。这些属性包括需求编号、需求来源和需求域等。
1)需求编号
需求编号(Requirement ID)是将所有需求通过某个规则进行编号,每个需求编号都是唯一的。该编号非常重要。按需求管理的理念,产品后续的开发与测试都应与该编号一一对应。该编号也就成为需求追溯的重要标志。有些企业在产品开发过程中,将需求编号与项目管理的工作分解结构中的编号相结合,这是合理的。但工作分解结构中也存在底层任务的编号,该编号不应与需求编号相混淆。
2)需求来源
最常见的需求来源分为客户需求、市场需求和内部需求,这是需求分类中的高阶分类。尽管需求分类的方式有很多,但这是最基本的分类方式。被定义为客户需求的,都是必须被满足的需求,因为这些都是客户明示的需求。被定义为市场需求的,都是需要被细化的需求。其中,如果有客户未提出的一般市场需求(或客户隐含需求),则这些需求也应被满足;如果仅是市场所期望(并非强制)的需求,开发团队则可将其作为可选项。被定义为内部需求的,多数是需求本身受到企业内部资源或能力等方面的限制导致的。产品开发团队需要进行内部评估,以确认是否要满足这类需求。
3)需求域
需求域主要分成客户域、功能域、物理域和过程域。这个属性分类的诉求来自公理设计(见第10章)。公理设计是实现产品从抽象需求到产品具体化的重要桥梁。在项目早期的需求收集和确认阶段就将需求如此分类,是为了帮助开发团队尽早建立需求与实际产品特征之间的联系。
4)其他属性
企业可以在产品需求文件中添加各种有助于开发过程的属性分类,如测试验证、体系要求、产品家族或平台等。这些属性分类有利于产品在企业的产品库或开发过程中准确定位,以便企业科学且理性地开发产品。
以上这些属性与产品需求列表共同组成了产品需求文件。有的企业还会增加客户确认区域,以确保客户认同产品开发的实际需求。客户在产品需求文件上的签字确认,将大大提升产品开发的准确性。但根据经验,仅有少数客户愿意在项目早期进行需求确认,所以开发团队需要想方设法以其他形式(如非正式沟通、客户拜访等)获取客户认可。表6-1是一款钢笔的产品需求文件的部分示例,在实际的需求分类中还会包括安全、法律法规等更多内容。
表6-1 产品需求文件示例
续表
2. 质量功能展开
质量功能展开(Quality Function Deployment,QFD)是需求管理过程中的重要工具,是连接产品需求文件与企业内部开发团队的重要桥梁。该工具由日本的两位专家赤尾洋二和水野滋创建,并经过多年发展和演化。目前,QFD有固定的模块,但企业在使用时并没有统一的量化标准和评价方式,所以相应的展现形式和风格也存在较大差异。QFD是为了减少需求在企业内部分解和传递过程中产生的差异性,并形成有效的需求链,连接企业各个职能团队并达成最终目标。QFD通过一系列连续的转置矩阵来传递需求,这些矩阵相互关联,构成了QFD的不同阶段版本。图6-5显示了QFD不同阶段中转置矩阵的变化过程。
图6-5 QFD的不同阶段
典型的QFD分成四个阶段(各个企业在实际应用时可能存在差异性)。各阶段名称使用小数点的原因是在分解传递需求的过程中,可能存在过渡版本,如1.5版本用来帮助企业分解产品系统功能到子系统/组件功能,这里不再展开。
· QFD1.0:从客户需求到产品功能。
· QFD2.0:从产品功能到设计细节,也有图书把设计细节描述成零件特征,两者本质上没有差异。对于非实物类新产品开发,设计细节的通用性更高。
· QFD3.0:从设计细节到过程细节。
· QFD4.0:控制计划或等同的文件,该阶段的文件不以QFD4.0的名称出现,而直接使用控制计划等名称,因为该阶段的内容形式与之前阶段的矩阵有较大差异。
图6-6是一个以电脑鼠标产品为对象的QFD1.0示例。在产品开发过程中的QFD文件往往都非常庞大,开发团队直接手绘的效率可能更高。
通常,QFD1.0的模块被分成以下部分,各部分的评分或符号可由企业自行定制。
(1)客户需求:通常是被整理或翻译后的需求,常用亲和图或等同工具的输出作为原始输入
(2)需求重要度:企业对客户需求重要程度的理解,也可理解为需求权重,通常打分以1~10分居多,10分为最重要。建议打分时拉开分值,否则最终方案的评分可能无法拉开差距,无法实现排定优先级的功能。
(3)产品功能与特征:通过客户需求分解获得,通常建议每个客户需求至少被分解成3~5条对应的可实施的功能与特征。
(4)特征期望:根据被分解的特征类型,可以做出的产品特性的最终期望。通常分成望大(目标最大化)、望小(目标最小化)和望目(实现目标)。例如,材料成本最小化(望小),实现无线控制(望目)等。
图6-6 QFD1.0示例与模块分布
(5)质量屋顶:功能与特征的关系矩阵。功能与特征之间可能存在某些关联,包括相互促进、相互排斥或互不相关。这些判断可以帮助产品开发团队更好地设计产品,避免出现功能互斥或系统性问题。通常,两个功能之间的关联被分成五类:强烈正相关(相辅相成)、正相关(一定程度上相互促进)、负相关(轻微矛盾)、强烈负相关(功能互斥无法共存)、不相关(两者不关联或关系不明显)。例如,车辆的自重和油耗在不改变原理的情况下,车辆越重,油耗越高,成强烈负相关关系。
(6)评价矩阵:评价客户需求与产品特征之间的影响度,这种影响可能是正面的,也可能是负面的。为拉开分差,通常打分以0、1、3、9分居多。其中,9分代表存在强烈的影响;3分为一般影响;1分为轻微影响;0分无影响,可以不填写。通常,每行(每个需求)至少应具备一个9分,否则代表该需求没有很好的实施方案或对应的功能与特征。
(7)重要度评价:每个功能与特征都与客户需求进行关联评价,所以该评价的分值等于矩阵内每个值与该需求的权重相乘后的纵向累加。可以认为该分值就是该特征与功能对客户需求的响应程度。通常,产品开发团队会对该分值进行排序。分值越高的功能与特征代表影响程度越高,因此产品开发团队应对其优先处理。
(8)外部竞争力矩阵:该模块为附加矩阵,比较依赖于市场研究的数据。通常,该矩阵会罗列关键的竞争对手,仅考虑当前竞争对手和企业自身关于客户满意度的打分。每个需求都单独打分,通常以1-5分最常见。分值越高代表满意度越高,也有企业使用图形来表示。最终评分与重要度评价类似。该矩阵对比了竞争对手和企业自身的当前情况,能够帮助企业完成自我定位与调整。
(9)内外部功能对比:该模块不仅依赖于市场研究的数据,也涉及竞争对手产品的相似度。该模块依然以竞争对手为参考对象,同时罗列企业自身当前规划的特征与功能参数。如果竞争对手的产品与企业的新产品差异不大,则该矩阵的充盈度较高。如果两者差异巨大,如更新换代的传统能源汽车和新能源汽车,则很可能有相当多的数据空缺(因为功能与特征不存在可比性)。
(10)参数优化:该模块罗列了产品特征与功能的参数期望值。在经过与竞争对手的功能参数对比之后,企业可能要对当前参数进行调整。此处应合理规划功能参数,因为该参数将成为后续设计产品规格的重要依据。注意,对于企业自身强于竞争对手的,也应进行优化;对于企业自身弱于竞争对手的,不应简单以竞争对手的参数为目标,而应平衡企业资源和战略意图,合理规划功能参数。
QFD其他版本的各个模块也大致依据以上的设定进行。在QFD的各个版本中,1.0版是模块相对较多且较完整的版本,也是客户需求管理实现的源头。其他阶段的QFD模块会根据实际情况被删减,最常被删减的模块包括质量屋顶、外部竞争力矩阵和内外部功能对比。
QFD在传递需求的过程中扮演着重要角色,但其也存在某些适用性问题。对于需求较多的产品开发,功能与特征也会非常多,导致评价矩阵过于复杂。所以产品开发团队应平衡企业资源,适当地使用该工具,同时不要在小型产品开发项目上使用该工具。QFD的适用性很强,无论在传统行业还是服务行业都有非常好的应用。
产品需求文件和QFD并不是孤立的工具,产品开发团队在需求管理过程中还可以应用其他很多工具来与之匹配。例如:
· 亲和图(Affinity Diagrams):挖掘具有层次结构特征的客户需求。
· 关系图(Relations Diagrams):用以确定需求重要程度,并发现沉默客户的需求。
· 结构树图(Hierarchy Trees):用来寻找需求列表中的缺陷和遗漏。
· 流程决策程序图(Process Decision Program Diagrams):用以分析可能造成新产品失败的潜在因素。
· 层级分析法(Analytic Hierarchy Process):确定客户需求的优先级,并选出满足这些需求的设计与实现方案。
· 价值流图(Value Stream Mapping):提供产品实现过程的增值分析。