用户需求的问题

“满足用户需求”有一个大前提：真的了解客户的真实需求吗？客户给我们的反馈真的是他们想要的吗？答案是否定的，因为客户表面上的“需求”有几个特点：

1、用户表达情绪，而不是需求

满意是一种主观的心理状态，即使是同一拨客户，自相矛盾的反馈也经常出现。我们常常会面对某个新功能上线后，“有的用户反馈很不好，但有的用户又反馈新功不错”的情况。

2、用户需求存在自相矛盾的情况

百度曾做过一个用户调研，问：你希望百度搜索每页显示多少个搜索结果？结果有超过90%的用户选择了每页显示20个或更多

但当百度真的做了一个每页显示20个搜索结果的版本，测试发布后，用户开始抱怨。原来，因为用户网速等原因，每页显示20个结果时，页面的加载需要更长的时间，造成了不好的体验。所以，又改回了每页10个结果的设计。

3、用户喜欢把解决方案当成需求

“客户要一匹更快的马，但是产品设计者用一辆车让客户更满意”这个梗大家应该都知道。

俞军有这么一句话：用户的反馈，我每条都读；用户的建议，我一概不理。讲的是同样一个道理。

如果一个企业只是无脑地响应客户的呼吁，最终必定一事无成。

需求管理=需求边界管理

当项目进入到需求阶段时候，往往会遇到客户不断的扩大需求范围，刚开始负责产品需求管理里，遇到最大的问题常常是如何控制需求范围？如何界定需求边界？

相信这是很多产品经理都很惆怅的事情，良好的需求定义应该包括对产品边界的描述。产品边界是指明确产品做什么需求和产品不做什么需求的界定。

从系统角度看，需求边界定义了系统内部和系统外部的分界线。这个界定过程是在需求分析过程中完成的。边界描述是需求规格说明书的重要组成部分，清晰描述系统“做”什么，也清晰指出系统“不做”什么。

这个边界，就像孙悟空用金箍棒画的圈，圈起来的需求应保持一段时间内是稳定的，如果在开发时，还在入开圈内加需求，那么需求蔓延就发生了。

需求边界蔓延，在项目管理（PMP）中叫范围蔓延（scope creep）。

百度百科中，项目范围蔓延的定义如下：

范围蔓延和特征蔓延是项目失败的原因。项目超出计划的目标，通常被称为范围蔓延。

范围蔓延是：在系统项目进行期间不期望的需求缓慢增加。

特征蔓延是：不受控制地增加技术特征到一个项目中。你本来想更好更出色的完成项目，但你不断增加新的想法...可能会失去宏观上对项目的把握，反而失败。

在产品开发中，常见的场景是这样的：

业务总监在电话里斩钉截铁的对产品经理说：”这个功能一定要做”。

这是非常经典的桥段，就是边界蔓延即将发生的场景，产品经理这时有责任清楚、准确地定义范围变更，评估"范围蔓延"对项目造成的影响，推进或拒绝这种变更时所产生的后果。

项目范围管理是项目管理的基础，范围发生变更，进度、成本、质量乃至人力资源都有可能跟着变更，只有确定了项目范围，才能合理确定项目的进度、成本和质量要求。

从这个意义上说，项目范围的确定和管理是项目成功的基础。相对于特征蔓延，范围蔓延更常见，更普遍。

因此，对于需求管理，我们首先应确认项目边界及其需求边界，这块主要分为两部分：

1、项目制的项目有标书范围

此部分项目主要是项目来源招投标项目，有标书作为依据，因此我们需要根据标书整理出来项目范围说明书及其sow（工作说明书），同时与客户召开需求范围评审会议，明确好整个项目范围。会议完成需要确认做好会议记录及其签字确认；

2、改造项目

此部分为对以前老系统进行改造，因此需要产品经理先整理老系统功能清单及其收集客户要新增部分。整理完成之后与客户召开需求范围评审会议，明确好整个项目范围。会议完成需要确认做好会议记录及其签字确认；

对应边界确认还一种极端情况就是客户完成没有范围，就是想简单做一个系统；这个时候就需要产品经理根据公司产品或者个人经验整理一个需求范围在和客户进行确认；

其次，需求讨论和分析过程，客户常常会扩大需求范围：

1、产品经理提前做好相关需求讨论资料，提前演示给客户看；将客户思维框定在自己掌控的范围内；如果出现先的范围和功能，需要产品经理尽量去引导客户在可控的范围内；

2、如果客户非要加入此部分，将需要产品经理将风险汇报给公司高层领导，由领导来觉得是否可以加入到本次项目范围内；如果领导不同意将可以安排销售人员来和客户沟通并给出一个折中的办法（是否可以放到下一期中做等）；

如何应对需求蔓延

大家在工作中有没有遇到过类似情况：

需求总是不能很好的得到买方的认可，或者各个团队之间对需求的理解不能达成一致，再或者项目范围总是在变，导致项目不能够按时交付？

根据项目管理三角理论，项目的范围、成本与质量相互制约。如果不能在项目中使用合理的手段和方法去确定项目范围，不能在项目过程中有效的控制范围，不能让项目范围在各相关方之间达成一致，那么会对项目造成严重的伤害。

案例：当一群人同时向你提需求……

这个项目是给一个区的几个小学做家校系统。因为涉及的需求方众多，所以在获取项目范围的时候，遇到了难以想象的困难。甚至，在很多个关键需求上，有几方表达的观点是冲突的。

不仅如此，需求收集的战线拉的也特别长，消耗了大量的时间。

各种波折后最终终于勉强收集了一个基本涵盖了所有相关方诉求的一份需求文件，虽然根据这份文件签订了合同和开发协议。

但在项目过程中，不断有新的需求或变更提出，项目团队对此也感觉到非常苦恼。

做不包含在合同范围中的事情，肯定会影响项目的进度和质量；不做呢，就不能获得客户的验收，陷入左右为难的局面。

相信这也是众多产品经理经常遇到的情况，面对这样的情况，我们该怎么办呢？

控制范围的具体方法

通常我们会将控制范围理解成，在项目进行中要对项目的范围做一个限制，甚至试图去取得客户的承诺，尽量保持稳定性。其实不然，控制范围的真实意义在于：让项目范围的变更及时被识别到，而且要用正确的方法去处理这些变更的发生。

回到刚才那个案例中，我们在项目过程中就会收到许多变更的要求，且被告知都是必要的。

但是其实是不是必要的这件事，是需要评估和调查的，然后要执行一个固定的变更流程才能在项目中执行。

有必要的时候，还要对项目的其他内容，比如说合同，做一些变更才能够执行。

作为产品经理，应该在前期收集需求的时候就告知客户做变更的程序和方法，也作为一种交流和沟通的手段，让客户与项目团队能够在一定的程度上尽量在同一个标准下开展工作。

在项目进行的过程中，尽可能多的与用户做演示和交流，及早的发现项目范围的变化。

对于项目团队来说，用尽量小的可运行产品甚至原型去与客户进行确认需求，也是业界中最佳实践的一种，这样有利于将变更的成本和对项目的影响降到最低。

经常有人讲，当今的软件会在市场的作用下频繁的变化需求，所以，软件团队要学会“拥抱变化”。

但拥抱变化不等于范围蔓延，作为产品经理，在多变的需求环境中，要有意识的去管理需求变更对团队产生的影响，而不是阻止或者放任需求的变化。而且，在项目团队中，要尽早的识别这种变化，越早识别对项目的健康越有利，另外，在研发领域也尽量用灵活的框架，使变更的代价降到最小。

项目正常进展产生破坏性影响的蔓延，应对的常用手段是：

1、改变功能集合（可否下一版本实现）；

2、增加研发时间（可否项目延期）；

3、增加项目经费（可否外购或增加人员）；

4、清晰的告知并描述后果（可否共同承担后果）。

产品经理必须明白，边界蔓延是常态，心平气和的让管理层明白项目组的困境是非常重要的。产品经理的个人素养和领导者的办事风格、组织的工作模式会在这种情形下都会有充分的展示。