研发能力持续成长路线图：需求确认与分类方法

众所周知，首先要“做正确的事”，其次才是“把事情做正确”。产品需求决定了是否在“做正确的产品”，其次才是产品开发流程的“把产品做正确”。2010年前后，苹果公司凭借iPhone手机和iPad平板电脑，在业界一骑绝尘，而前几年如日中天的诺基亚和黑莓手机则日薄西山，其根源就在于苹果的乔布斯是一名把握客户需求的高手，他甚至能分析、提炼出客户自己都不能表达的需求，据以开发出令人爱不释手的新产品，获得市场的狂热追捧。而诺基亚等老牌手机企业，虽然有超强的产品开发能力，但是其产品却得不到消费者的欢心，企业陷入市场占有率大幅下降的窘境。

所以，在产品规划和产品开发工作中，做好产品需求工作是至关重要的。如果需求的收集不完整、不准确，就可能造成产品开发过程中频繁的需求变更和设计变更，从而导致开发项目拖延进度。更有甚者，新产品因不满足客户需求而被市场冷落，造成大量研发资源浪费。

需求是对新产品利益相关人的期望、要求所做的明确的、可测试的、可度量的表述，并通过产品包交付予以满足。在产品研发工作中，所有与需求直接相关的活动被通称为需求工程。如图6.5所示，需求工程又可以分解为需求开发和需求管理工作。需求开发的目的是获得含义清晰、格式严谨、内容完整的产品需求，并可作为产品规划、产品设计、技术预研与开发工作的输入。需求管理则是指实现需求的过程管理工作。

 图6.5　需求工程工作示意图

在图6.5中，需求收集关注的是如何高效率地收集到更准确、更完整的产品需求。需求分析是对原始需求的澄清、分类、选择、提炼和升华，而不只是对原始需求的选择。需求确认则是需求开发者、客户、管理层对需求达成共识的过程。

为了实现已确认的产品需求，应将产品需求分发到规划中的各款产品，或开发中的产品模块与组件，或技术研究与开发项目，这就是图6.5中的需求分发。在产品规划工作中，应将产品需求分发到产品系列的各款产品。在产品开发工作中，应将产品需求分发到产品的模块和组件中。

图6.5中的需求跟踪，是指记录和确认从需求到高层设计、详细设计、实现和测试验证的需求转化过程，以确保需求被准确、完整地实现到产品中。需求变更控制则是在产品开发过程中对需求变化进行审批的管理制度和流程，以避免不必要的需求变更，并避免需求变更过程出现混乱。

产品开发各阶段的需求工程工作如图6.6所示。

图6.6　产品开发各阶段的需求工程工作示意图

本小节将围绕需求工程的各项工作内容，讨论分析相关的工作方法和难点问题。

外部需求、内部需求、$APPEALS方法

从产品需求的来源看，产品需求可以划分为外部需求和内部需求两个大类。外部需求是来自企业外部的需求，包括来自客户的需求，以及来自法律法规、技术标准的需求。来自不同客户的需求进行整理汇总后形成的需求，被称为市场需求，来自法律法规、技术标准的需求则被称为标准约束。因此外部需求包括市场需求和标准约束两个小类。

内部需求是来自企业内部的需求，包括来自制造部门的可制造性需求、来自测试部门的可测试性需求、来自销售部门的可销售性需求、来自客服部门的可服务性需求等。在很多企业的产品需求工作中，内部需求经常被忽视，从而对产品质量、制造、售后服务等方面造成负面影响。

关于可测试性需求、可制造性需求的更多信息，请见本书第4.8节。

与客户需求不同，可销售性需求是一种内部需求，例如新产品有突出的卖点，有竞争力，本企业同系列产品之间应有差异性卖点以避免“兄弟相残”，同系列产品上市时间应配合市场节奏，新产品要有配合销售工作的产品资料等，都属于可销售性需求。产品规划要重点关注可销售性需求，产品开发也要关注可销售性需求。

可服务性需求主要包括产品的易维护性、易安装性、易维修性等。

财务类需求也是一种内部需求，例如在销售收入、利润、现金流等财务方面对产品规划和产品开发提出的需求。

作者在此特别提出一个观点，产品内部需求还包括技术共享需求，即产品设计应尽量采用企业已有的系统架构、成熟零部件，并使新零部件设计方便被其他产品开发项目所采用。技术共享需求是来自于研发管理部门的内部需求。对于中、大型企业来说，技术共享需求是很重要的内部需求。

各类内部需求，应由各相关部门负责提供。例如，可测试性需求应由产品测试部门负责收集和整理，交给产品系统工程师PSE整合到产品需求规格中。

$APPEALS是最为常用的需求分类和整理工具，主要针对外部需求。如表6.2所示，$APPEALS的每一个字母都代表一个需求维度，或需求类别，共8个维度。

表6.2　$APPEALS各字母的含义

用户/客户需求收集

首先，需要确定该向谁收集需求——客户是谁？例如，父母掏钱给孩子买了一台新手机，虽然最终使用者是孩子，但是父母是购买者，他（她）们对于买何种手机都有影响力。将最终使用者称为用户，将出资购买者称为客户，在不需要区分时则泛称为客户。所以，用户和客户都是需求收集的对象。

从购买的角度来说，不仅有终端客户，可能还有代理商、分销商等。如果购买产品的客户是企业，情况就更为复杂。客户企业内部有做出购买决策的领导，有与实施采购行为相关的采购部门、财务部门，还有影响决策的产品用户部门。这些不同的部门对于产品的需求各有侧重，例如用户部门更关注功能性能，而采购和财务部门更关注价格。因此，要注意选择收集需求的对象。

其次，要为收集需求选择适当的方法。需求收集的方法是非常多的，主要包括：

1．技术类方法。即以技术人员为主，直接以需求收集为目的的方法。常见的技术类方法包括客户访谈、生产维修和用户返修数据库分析、用户合作开发、联合实验室、委托第三方调研咨询等等。其中，客户访谈是最常用且简单易行的方法。

2．市场类方法。市场类方法中多数不以收集需求为主要目的，属于间接的需求收集方法。常见的市场类方法包括投标、展会、技术推广、用户大会、客户高层交流、客户拜访和接待、市场调查、行业会议等等。

3．客服类方法。也属于间接的需求收集方法。常见的客服类方法包括重大事故经验、用户投诉意见数据库、现场支持、支持热线、客户满意度调查等等。

在收集客户需求的时候，要做好记录，以便于下一步的需求整理和分析工作。需求采集记录内容的要求可参考图6.7。

图6.7　单项需求采集记录

在图6.7中，客户陈述是一种原始需求。所谓原始需求，即站在客户的角度，表达客户的需要、期望，不要求严谨。

需求描述则是在原始需求的基础上，站在产品的角度，表达产品应提供哪些功能性能，以及具备何种特征。需求描述的表达应略为严谨，并尽量做到可验证。例如，针对客户陈述“我总是一不小心就把手机掉到地上了”，初步整理的需求描述可以是“手机应具备从1米左右高度跌落后不损坏的性能”。

对于交互式、流程性需求，则可采用如图6.8的Use Case需求描述方法。

图6.8　Use Case示例——拨出电话

确实有一些需求较难用文字准确描述，例如外观类需求。此时应进行工业设计，以设计草图、效果图或模型来确定需求。

需求分析

需求分析就是对需求进行整理、优化以保证需求质量，并做合理分类、分级排序，为需求分发等后续工作做好准备。高质量需求应具备准确性、规范性、可验证、可行性、普遍性等特征。所谓需求可验证，是说需求是否达成应有明确的判别标准，诸如“外观好”、“速度快”，就是无法验证的需求。所谓需求的普遍性，是说不同的客户对同一需求的感受可能是不相同的。如果差异性很大，则可能需要重新进行市场细分。例如手机游戏，年轻人认为很重要，中老年人可能认为不只要，甚至反对。

本小节前文介绍的$APPEALS方法就是一种常用的需求分类方法，但是还较为粗略，不便于进行深入分析。例如在$APPEALS中的一个P——性能方面，就包括了产品所有的功能性能，还需要进一步细分类别，比如针对智能手机产品，其功能性能需求可以细分通话功能、短信功能、彩信功能、网络功能、照相功能等。如果还没有成熟的需求细分类别方法，可以寻求KJ亲和图方法的帮助。关于KJ亲和图的详细介绍，从网络上很容易搜索到，本书不做介绍。

在完成需求分类之后，要注意识别和解决以下需求问题：

1．对于技术上互相冲突的需求，重新进行优先排序或者采取折衷方案。

2．对含混不清的需求进行澄清。

3．合并重复的需求、删除不需要的需求。

对于分类整理之后的需求，还需要确定优先级，以便于在开发项目资源紧张时放弃低优先级的需求，提高开发资源的利用效率。在确定需求优先级方面，一种可行的做法是，先采用KANO需求分析法将需求划分为B、S、A三个大类，再用AHP层次分析法在每个大类内部划分优先级。AHP层次分析法是一种常用的优先级排序方法，从网络上很容易搜索到，本书不做介绍。以下介绍KANO需求分析法。

日本的卡诺博士提出的KANO需求分析法是非常著名，也很实用的一种需求分析方法。KANO方法根据客户感受，将需求分类为基本需求（Basic）、满意需求（Satisfier）、魅力需求（Attractor）三大类，其他需求都是次要/无关需求，或者说是可以放弃的需求。KANO方法的需求分类又称为BSA分类。

基本需求或B类需求是使客户满意所必须具备的需求，或者说是产品理所应当具备的需求。这类需求，客户常会忘记提醒，但是一旦无法满足则会引起不满。例如，对于手机用户而言，能够随时随地打电话是一种必备的功能。咖啡是热的，客户不会在意，假使是冷的或过烫，则会产生不满。客户往往难以直接提出基本需求，好在通过分析行业标准、同类产品，可以获得大多数基本需求。

满意需求或S类需求是与客户满意度线性相关的需求。这类需求往往是客户能够了解，而且能够清楚描述出来的。例如，对于电脑用户而言，CPU的主频的高低是一种满意需求。快递是越快越满意，反之则越慢越不满意。

对于魅力需求或A类需求，若未满足这类需求时，客户不会不满意，但是若满足这类需求，则会深受客户喜爱。例如，iPhone让大家发现手机是可以没有键盘和触摸笔的，令人惊喜。糖果设计师设计的iMac出现后，人们才认识到电脑外壳原来可以是彩色的、透明的。

不幸的是，当魅力需求被其他产品模仿之后，就会逐步退化为基本需求。因此，魅力需求是学不来的，而且客户也难以直接提出魅力需求。所以，魅力需求需要对市场和技术的深刻洞察，需要极大的勇气和创新。然而，魅力需求是避免产品同质化、提升产品美誉度的“核动力”，值得努力追求！

需求确认、需求规格、产品包需求

完成需求分析之后，需求表达更加严格、准确、可测量，形成初步的需求规格。举例来说，开发一款电脑产品，有一项需求是“提供无线联网功能”，需求规格可以是“提供速率为64Kbit/s的无线联网功能”。(www.chuimin.cn)

为了提高需求的准确性，初步的需求规格还需要进行需求确认，以完成正式的需求规格。需求确认是以易于理解的形式向需求的提出者，包括客户和管理层展示初步的需求规格，由他们判断是否符合其意愿。

向客户进行需求确认的主要方法包括客户评审、模拟或原型演示。客户评审就是邀请客户评审需求文档，模拟或原型演示则是以尽可能逼真的形式向客户展示未来的产品运行情况。从需求收集开始，就可以向客户和管理层逐步进行需求确认工作。向管理层进行正式的需求确认，则是通过技术评审TR和决策检查点DCP。

对于产品开发项目来说，将产品包的需求规格汇总起来，就称为产品包需求，或者产品需求规格书。产品包需求是产品高层设计的输入，是很重要的产品设计文档。建议采用表格形式，对产品包需求逐条记录。产品包需求主要包含以下条目：需求编号/名称、需求描述、BSA分类、优先级等。

产品包需求应具备完整性，即应无重大遗漏，以避免开发项目中后期的需求变更。特别说明，产品包需求应包括全部的外部需求和内部需求。另外，产品包需求还应包含卖点需求，以使产品具有足够的市场竞争力。产品包需求中可以进行竞争分析，说明主要竞争者提供的卖点需求，本产品应提供的卖点需求。

产品包需求汇总完成之后，应通过需求评审TR1和概念决策检查点CDCP，向管理层进行需求确认。

需求分发、分解与分配

需求分发是将已完成分析的需求派发到接收部门，以便安排对需求的实现工作。需求可以被接纳实施，或是拒绝，或是推迟。

如图6.9所示，需求管理流程将中长期需求分发给产品规划流程，未来将在多个产品版本中实现这些需求。产品规划重点关注版本差异性需求，从需求中提炼的概念、卖点、重要需求用于定义各产品版本的核心特性。需要注意的是，来自于需求管理流程的需求是产品规划流程的需求来源之一，但并非全部。产品规划流程中还可以进行专门的需求收集、需求分析工作。

图6.9　需求分发路径示意图

涉及复杂技术问题的需求，则分配给技术项目流程进行预研或技术开发。

短期需求分发给新的产品开发项目，而紧急需求分发给已进入计划阶段之后的产品开发项目，对其产品包需求进行变更。产品开发项目的产品包需求有三个来源，包括来自需求管理流程的需求、来自产品规划和开发项目任务书的需求、来自本项目需求收集工作的需求。

无论是产品开发流程，还是产品规划流程、技术项目流程所接收的需求，为了进一步推进需求实现的工作，都需要进行需求分解和需求分配工作。所谓需求分解，是依据产品系统的技术原理，由产品系统工程师PSE将需求拆分到不同专业技术领域的设计活动。例如，燃油车和电动车的技术原理是不同的，燃油车将从动力需求分解得到加油的需求，电动车则将从动力需求分解得到充电的需求。使用触摸屏加键盘的手机与纯键盘手机，对于用户输入需求的需求分解结果将是不同的。

对于产品开发和技术项目来说，需求分配是PSE将分解后的需求分配到产品各组成部分的设计活动。例如，手机的输入需求被分配给手机键盘硬件模块、键盘监控软件模块、输入法软件模块。需求分配与产品系统架构有密切关系，需求分配活动属于系统总体设计工作的组成部分。

对于产品规划来说，需求分配是将需求分配给规划中的各个产品型号。例如，可以设想，在进行iPhone产品规划时，将配置前后双摄像头的需求分配给iPhone4。

设计需求、设计规格

对于产品开发项目，分配后的产品包需求还应转化为设计需求，以便做为设计工作和测试验证工作的输入。设计需求是从产品包需求转换而来，增加了设计约束，例如可靠性、输入输出范围、环境条件等。

表6.3是本书作者假想的车辆定速巡航设计需求示例，仅用于说明设计需求。表中第4行“环境”以后的各行（包含第4行）都是设计约束。请重点关注表格第1列的设计约束条目，第2列和第3列仅用于帮助理解，请勿在意其内容的正确性和完整性。

表6.3　设计需求示例

将产品包需求转化为设计需求的工作由产品系统工程师PSE负责完成，这项工作属于系统总体设计工作的组成部分。

从表6.3来看，制定设计需求时，确定各项设计约束的工作量大，难度很高，但却是可以适当简化的。对于有标杆产品可以参照的模仿创新来说，设计约束可以做较大简化。对于产品系列来说，可以大量继承上一个老产品型号的设计需求，仅对增加和修改的产品包需求制定设计需求。因此，完善的设计需求文档不是一次完成的，而是需要积累的。

产品设计需求，加上产品的总体结构，就形成产品的设计规格书。也就是说，产品设计规格书包含了产品总体方案。附带说明下，通常所说的产品规格书不是产品设计规格书。产品规格书主要描述产品功能、性能，相当于产品包需求。

需求验证、需求跟踪

在产品开发过程中，历经概要设计、详细设计、实现等各个设计步骤时，都需要关注以下关键问题：我们是在正确地构建产品吗？已定义的需求确实被交付了吗？需求验证就是为了保证各个层次的需求变换被准确实施，每个步骤没有信息被丢失。主要的需求验证活动包括各种设计评审和测试活动。关于测试活动，可参见本书第4.2节。关于评审活动，可参见本书第6.3节。

需求跟踪的目的是建立与维护“需求←→设计←→实现←→测试”之间的一致性，确保所有的工作成果符合产品包需求。需求跟踪的用途包括：

1．确保开发者的关注点始终保持在需求的实现上。

2．评估需求变更的影响。

3．尽早发现被遗漏的需求。

4．尽早发现需求之间的冲突。

需求跟踪包括正向跟踪和逆向跟踪。正向跟踪是检查产品包需求中的每个需求是否都能在后继工作成果中找到对应点。逆向跟踪是检查产品设计和测试用例等工作成果是否都能在产品包需求中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，规范的需求跟踪都需要建立与维护需求跟踪矩阵，或需求跟踪表格。如表6.4所示，需求跟踪矩阵中填写需求、组件和测试用例的编号和名称，以保存需求与后继工作成果之间的对应关系。

表6.4　需求跟踪矩阵格式（示例）

需求变更

在产品开发过程中，需求在需求评审TR1或某种形式确认之后，改变即应受到需求变更流程的控制。需求变更是需求发生变化时的审批流程，以保证需求变化对开发项目的影响在允许范围内，以及受需求变化影响的工作得到同步调整。

需求变更对开发项目有负面影响，尤其是在产品开发项目中后期的需求变更，将引起大量的设计返工，浪费研发资源且延迟新产品开发进度，应尽可能避免。

引起需求变更的原因包括原定需求有遗漏或有缺陷，或者市场、客户等外部环境发生改变。为了减少需求变更，应注意以下要点：

1．加强需求早期确认和验证，尽早完成需求变更。

2．提升需求收集和分析能力，减少纠错性需求变更。

3．版本化产品开发，避免一个开发项目承担过多需求。

4．持续的需求工程能力积累，提升对需求发展变化的预见性。

需求变更管理流程的主要步骤包括需求变更申请、变更评估、变更审批、变更实施、变更验证等。其中，变更评估应评估对项目进度、项目资源的影响程度，变更审批则应根据需求变更影响范围和大小确定审批级别，以提高审批效率。

规范的需求变更管理，需要建立一个变更控制委员会CCB（Change Control Board），由项目相关管理人员组成，包括项目管理、需求、设计、测试、中试、制造、财务、营销、售后、质量等。对开发项目有重大影响的需求变更，应上报CCB审批。是否上报CCB，由开发项目经理评估后确定。

需求管理的组织与实施

对于不同的企业，产品需求工作的复杂程度是不同的。当企业处于实力较弱的初期发展阶段，产品开发基本上是模仿行业标杆产品，此时产品需求显而易见，只需要认真分析标杆产品就可以获得高质量的产品需求，并据以进行产品设计即可。这个时期，由开发项目经理和核心设计人员负责需求工作即可。

然而，企业一旦发展到跟随创新阶段，虽然仍可参考标杆产品，但已有较多自主创新，把握产品需求的难度就大大增加了，就必须加大需求管理工作的投入，逐步在研发相关部门明确需求管理职责，逐步采用专业化的需求工作方法。在集成产品开发体系中，产品经理、系统工程师PSE、产品规划部门都要承担各自的需求管理职责。PSE组织产品包需求的开发和管理工作，业务代表则负责本领域内部需求的开发和管理工作。

当企业发展到领先创新阶段时，产品需求工作将在研发体系中占有非常重要的地位。如果企业设立了负责产品规划工作的专业部门——研发Marketing部门，该部门同时也是专业的需求工程部门，将持续开展需求开发和需求管理工作。当然，专业的需求部门是产品规划项目、产品开发项目、技术项目的重要需求来源，但并非唯一的来源，各项目仍应开展本项目的需求开发和需求管理工作。

对于需求工程工作，可以考核以下KPI：

1．需求转化率。在所有收集和整理的需求中，被预研、开发、规划接受的需求比率。本指标较高为好。

2．紧急需求率。在产品开发项目中，紧急需求所占比率。本指标越低越好。

3．需求变更率。在产品开发项目中，变更需求所占比率。本指标越低越好。