需求管理是大部分研发型企业十分重视的一项管理活动，但在实际的执行运作过程中，仍然会出现一些问题，影响管理的效果，导致项目偏离预期。

Q1：需求锁定偏晚，该如何解决？

问：需求管理可能是一些公司的通病，目前我司流程比较完善，问题主要在执行层面上。比如需求的锁定偏晚，该如何解决？

答：需求确定比较晚一般情况下是由于以下几方面原因引起的，针对不同病因应对症下药，以下基于三种不同原因进行分析并解答。

1．公司不重视需求开发与管理过程，项目经常“裸奔”，立项后不进行充分的需求开发与分析，经常在需求相对模糊的状态下就进入设计过程。

解决办法：系统地梳理产品需求开发与管理流程，对负责需求开发与管理的几个关键角色（市场人员、产品经理、系统工程师）进行合理的分工与集成，把需求调研与收集、需求整理与分析、需求定义与分配、需求转化与跟踪、需求实现几个过程进行端到端串联，同步引入需求评审机制，每个节点进行有效评审。一方面是确保前后分解的需求一一对应，另一方面是确保每一个过程的需求符合该过程的要求时，才能进入下一环节，以此来保证需求锁定及时、准确、有效。

2．需求开发过程中覆盖不全面，没有围绕产品包进行需求开发，往往只关注了产品的功能/性能需求，却忽略了其他方面的需求。

解决方法：首先，产品需求定义一定要有“包需求”的概念，从产品价值需求（满足用户的哪些核心价值）、实际产品需求（功能、性能、包装、质量、品牌等）、产品附加需求（可制造、可服务、可运输安装、用户体验等）三个层次自内向外地进行需求分析，可以确保需求的覆盖度相对完整，不会有重大遗漏。其次，在“包需求”开发过程中一定要覆盖到能提供需求信息的所有领域，比如客户、终端用户、电商平台、竞争对手、行业分析报告、各种大会、展会、公司的客服及运维窗口，内部产品开发团队渠道均要有效覆盖。收集和汇总相应领域的产品需求反馈，进行综合分析，以保证需求来源的全面。有时候，并不是我们无法锁定需求，而是没有考虑到某些需求的来源和渠道，尽可能地覆盖需求开发的来源可以有效帮助我们提升需求开发的效率。

3．如果以上两点都没有问题，但需求转化过程不清晰，产品需求定义颗粒度不够，为开发过程中的需求增减和变更埋下隐患。

解决方法：完整的需求开发过程根据需求在不同过程中的形态和要求把需求分为“初始需求、原始需求、特性需求、系统需求”四个阶段形态。但很多企业并不清楚这些需求的对应和转换关系，很多只简单地定义了初始需求，例如“产品需要更加便携、易携带”。这个需求实际上是客户或者用户的一个诉求，看似需求明确，实则非常模糊，我们一般叫做初始需求。“便携”的标准是什么？是轻、是小、还是可以移动？没有说清楚。随着产品开发的进行，试验了无数次把产品做小，但效果不佳，最后加了两个轮子实现了便携移动的功能。但实际上在初始需求描述的基础上继续分析，是可以定义出“产品安装4个移动轮，实现推行”这样的特性需求的，再往下如何在产品上安装4个轮子，大小、规格、位置的定义是系统需求的定义。按照这个逻辑，一个客户诉求（初始需求）可能会衍生出多个特性、系统需求，只有逐一地向下分解和分析，才能得到更全面、更有价值的产品需求。这个传递过程一来可以帮助我们清晰完整的定义产品，二来也可以把最初的初始需求与最后的产品设计元素建立起一一对应关系，更有助于过程中对需求的跟踪、评审和验收管理。

Q2：如何减少需求变更？

问：需求变更较多，比例较大，如何减少需求变更，并进行有效的变更管理？

答：如何减少需求变更这个话题一定要从变更的源头上谈起，不同的变更原因有不同的改进办法，追本溯源，一般一起大量需求变更现场的产生不外乎两个原因：

1．需求定义不足、漏洞百出，后期当然要增加对所遗漏定义的需求。

解决办法:首先就是项目概念阶段就把需求定义全面，具体做法可以参考上一个问题中所述的解决办法；其次就是为需求定义的角色（市场或产品经理）分配需求稳定度的指标，在项目过程的不同阶段，定义出允许需求变更的类别和范围是什么，超出范围的变更一旦执行，就要反馈到需求定义角色的绩效中，通过这种方法促使需求定义人员一开始就把需求定义工作做好。

2．需求定义不准，严谨度不足，导致后期经常调整，比如需求中本来定义了“通过蓝牙进行信息传输”的功能，但在开发进程中又提出客户更希望通过“Wifi传输”,导致需求随之变更。

解决办法:类似这种现象，要么是需求定义过程缺陷或者人员能力问题，可以根据企业能力对需求开发与管理过程进行优化，并对需求分析人员能力进行提升；要么就是需求定义人员的态度问题，因为变更很简单，没有约束，那为什么要花很大心思在前面做那么多功课呢？反正错了可以改。如果是这种原因，就必须制定行之有效的措施加以改进和纠正：

第一，改进变更申请流程，所有申请需求变更的来源必须经过主管领导的审核和批准才能提交到项目组，从源头上正视变更这件事，告诉所有人这是一件很严肃的事情；

第二，严格按照变更流程执行，进行充分的变更影响分析（时间延期、成本增加、质量风险，产生的浪费等），把这些数据都反馈给变更申请者，如果执行变更，申请者就需要对上述的变化负责。事实经验说明，一旦对变更进行了充分的数据分析，再把数据反馈给变更申请者，很多变更就会取消，因为大家不愿意接受大的变化、影响或者风险。之所以原来肆无忌惮，是因为变更申请者和项目团队都没有认真分析过变更影响，都以为任何变更都很简单。所以数据分析很重要；

第三，建立变更控制委员会（CCB），变更交由CCB裁决，同步按照第一点的要求进行记录和统计变更原因，影响变更责任者绩效。

通过以上三个措施改进可以大幅减少无效的变更，同时可以促使上游（需求分析和需求定义）过程做的更加精确。

同时也要注意，需求变更的目的是把产品做好，所以不要认为有变更就一定是错的，因为即使你再牛，也不可能一开始就把所有需求都百分百定义全面和准确，只是通过以上方法尽可能地让这个数据逼近100%，剩余的按照变更流程正常执行即可。

Q3：需求管理过程中，如何减少“扯皮”现象？

问：在实际执行中，困难在于需求的多头管理和下发，出问题的时候互相推责任。怎样能够解决这些问题，实现有效的需求管理？

答：产品需求从“初始需求、原始需求、特性需求、系统需求”几个过程逐级向下分解，在系统需求层面，把每个需求点分配给不同的开发者，并通过需求跟踪矩阵进行实时的跟踪与验收，每个阶段评审都需要对需求的满足度进行评估，而不是等到产品验收时才返回来讲说这个需求没满足，那个需求没满足，这个时候“扯皮”现象就会屡禁不止。所以总结下来做到以下三点，可很大程度上缓解上述问题：

1.需求细化到系统设计规格，可以落实到具体责任人；

2.建立需求跟踪矩阵进行需求跟踪；

3.每个阶段实施验收，未满足的需求当下分析责任。

Q4：产品定义中如何融入客户需求与用户需求？

问：客户需求与用户需求的区别？在产品定义中如何将二者的需求进行合理融入？

答：用户一般是指产品的最终使用者，客户一般是指品牌商、运营商、代理商等产品链中与产品运营相关的机构或个人。通常来讲，广义的客户包含了终端用户，产品本质上是要满足终端用户的需求，唯有如此，产品才具备价值，才能让产品运作的整个链条获得利益。从这个角度来看，我们和客户的立场是一致的，用户需求分析时更多的考虑产品包需求中的价值需求与实际产品需求，客户需求分析时更多的考虑外围需求。但往往用户期望价格更便宜，客户期望能够多赚钱，所以要卖的贵一些，这时出现的用户需求与客户需求的冲突，实际上是一个商业运作和平衡的问题。平衡这个问题既要考虑用户与客户的利益，还要考虑自身的品牌价值以及客户的粘性等诸多因素。建议可以在产品需求定义中，单独对客户的需求进行说明定义，重点考虑价格、利润、维护、运输、安装和服务、以及品牌合作等方面，以确保产品的商业运作符合客户的基本需求。

产品定义的目的是确保产品是满足开发者、客户、用户及其他利益相关者的利益诉求，所以产品定义过程实际上是在做需求平衡的工作，核心思想就是每个利益相关者都能够获得自己的价值和利益。