对于需求，需要强调的一点是，从表及内，从客户表层提出的要求开始，挖掘需求背后真正的需求。大多数提需求的客户，看似提的是需求，其实给到你的是他根据需求的解决方案。这些个方案主观性大，也未必是最优解。那么如何根据需求框定项目范围呢？

《一》探寻需求，而不是解决方案

所以在和客户聊需求的时候，无论是在那个阶段，要么不聊，聊了就把需求聊透彻。怎么叫聊透彻呢？

这里有一个万能方法——多问为什么。

客户： 我需要在房间里安装9盏灯。

你： 房间只有10平米，为什么要按那么多等呢？

客户： 那样可以照亮整个房间啊。

你： 一般情况 2盏灯的光线在加上窗户进来的光足够啦。为什么要那么多灯呢？

客户：我的客厅是内听，没有窗户，卧室门全关上之后，就非常的暗。

以上对话是装修房子的时候发生的。开始客户提出需要安装就盏灯。这看起来是个需求，其实是他的解决方案。于是你可以问，为什么要那么多灯呢？然后客户的回答是希望整个房间亮亮的。但是这个又和常理违背，根据常理2盏灯加上自然光足以。于是你继续问为什么。从而得到了客户的原始需求，希望自己的暗厅在房间门全关闭的时候也能亮亮的。

于是基于这个原始需求，你可以考虑是要按照客户的想法，布9路电线安装9盏灯。但是这样貌似很耗电啊。于是作为改进，你可以跟客户提，我们把厨房，卧室，卫生间的门，装上磨砂玻璃，即达到了透自然光的目的，又保证了私密性。外加上2站灯的光线补充，整个暗厅也能亮亮的。

《二》通过假设和标注推动估算的进行

上面的例子是基于客户明确知道原因的基础上了。但是不可否认的是另一种情况，你一个为什么问上去，客户懵圈了，没法提供你答案了。这个时候该怎么办？

客户：我希望购买关于XX系统的培训服务。请给我一个报价和培训的时长。

你：您是已经购买了这个产品吗？（为什么需要这个培训）

客户： 还没有，购买产品正在进行中，希望做一个预算。

你： 那您打算购买该产品的哪个版本呢？不同版本培训内容不一样，需要的时间也不一样。

客户： 这个总部还没有决定，能就最普通的情况给与我一个报价吗？

上面那段对话，对于提供培训的企业来说基本是束手无策了。因为客户并没有明确需要培训的系统版本，而不同的版本对应的功能不同，需要的培训时长和价格自然也不同。最后客户希望就最普通的情况得到一个报价。那么你如果是项目经理，你会怎么办？

是根据你理解的最普通的情况做一个估算提供一个报价吗？

如果是，那么客户拿到了你的报价，就会觉得这个是他需要支付的全部费用。如果最终他买的VIP版本，会造成培训内容，培训时长大大增加，此时你再想更新你的报价就很难了。如果是公开唱标的情况下，会更难。此外，另一个值得注意的是，如果开始培训时，系统并没有正确安装，培训所需要的硬件条件不达标，势必造成培训计划落后。

这么看来似乎做不了计划，那么此时如何去竞标呢？

看起来是一个两难的抉择，其实还是有办法的。这里有两个办法推动估算的进行：

a. 通过假设，确定估算基于的条件。

b. 明确标注不在项目范围内的需求。

反映到上面的例子中可以在估算的同时，标明估算基于的假设：

1. 培训的功能范围（最普通的功能是哪几个）

2. 基于系统的版本号。

3. 培训需要的硬件条件。

以及明确标注不在项目范围内的需求：

1. 不在培训范围内的功能 （A，B，C）。

2. 不包含培训环境的搭建等等

明确了以上两块内容后，对于这个培训，你可以进行工作结构的分解和估算。然后提供报价。并且，将以上两点也和报价一并发送竞标。

这样做的好处在于不会因为不明确的内容而使得后续工作止步不前。同时，对于今后一旦客户有进一步信息提供时，做出应对。如：

当竞标完成，获得竞标后，如果客户告知他需要的培训就是你提供的这个范围，版本也和你估算的那个如出一辙，那么就可以开展下一步工作。

如果客户告知他需要VIP功能的培训，并且没有能力搭建培训环境时，由于之前的估算是有假设的，也有明确的假设范围。此时你就可以将这个拿出来告知客户，根据之前的假设，有一部分功能之前是没有在项目范围内的。需要走需求变更流程对于新增需求进行估算。

往往在这个时候，由于前期的估算的透明度很高，有理有据，客户是愿意接受变更引起的报价，工时的变更的。

此时再提供一份基于客户更新信息后的培训计划和报价，显得合情合理。通过需求变更的流程，将原本的项目范围做一个更新。对外，客户明确更新后的成本和进度。对内，团队也不会因为客户需求的更新造成加班赶工却又没有相应预算的支持。从而真正达到通过流程，合理的规范项目范围，进程和成本。

以上是项目范围管理的一个小技巧。