谈项目需求范围管理

 

谈项目需求范围管理

                                  傅立  2006-8-16

 

在项目的整个生命周期，如何进行范围管理？很多人会认为：当然是严格控制用户需求，将用户的需求控制在最小的范围内。

 

这样做固然有这样做的好处：项目开发相对轻松，需求少了当然工作量也就少了；进一步想，工作量少了，开发周期也就会相应缩短；开发周期缩短了，项目成本也就相应下降；看起来一切似乎非常完美。

但事实果真如此吗？

我以为不然：控制需求范围应该有策略、有方法、有限度。

能够驾驭项目的人是能读懂人的心思的人。客户都有自己的心思。根据客户的心思，针对不同的项目，项目经理应该有自己的一套范围管理的策略、方法、限度把握。

但从不同客户的共性来说，大多数的客户应该都是希望项目的实施能够产生一定的影响，当然这种影响可能是对于他个人仕途上的推进，也可能是对于工作效益上的提升，甚至可能是希望能从中获取部分经济利益等；而在上述几种心思中，政府客户更多的是希望借助系统的实施对个人仕途上有所裨益，对于工作效益上有所提升；针对这两种心思，如果从消极的方面考虑，就是系统实施完毕后至少能够让客户相关人员对各自上级、对机关单位、对政府有所交待。

先说第一种心思：希望借助项目实施，增加政绩。一般是客户相关负责人、负责人的领导等。这类客户十分典型。他们提出的需求一般是类似于：增加一些亮点、总结一些经验、探索一些模式、创立一些理念。而这些一般不会在前期项目的需求范围（标书及合同）之内。

对于第二种心思：希望借助项目实施，提高工作效率。一般是客户项目经理（或负责人）、负责人的下属（系统实际使用人）。这类客户提出的需求一般是：这个功能能否再实用一点，改进一下输入的顺序、调整一下工作流程等具体需求。而这些需求一般也不会包括在前期的需求范围（标书及合同）之内。

那对于这些需求，都不便拒绝，当然如果全部答应，也会产生严重的后果。那如何处理呢？怎么样才算是控制在最小的范围之内呢？

首先，从公司的角度出发，管理者也许会觉得，项目经理要是能够说服用户这些需求全部都不要做，当然是最理想的。但现实往往是残酷的。

项目经理不仅要从公司的角度出发，还要从客户的立场考虑。所以，他不可能按照公司理想的要求去缩小需求范围，也不可能按照客户理想的要求去扩大需求范围。

客户在想什么呢？其实很简单：在标书及合同基础上，增加内容的实用性，增加项目的亮点。

 

既不可能按照公司的理想的要求去最小化需求范围，也不可能按照客户理想的要求去无限扩大需求范围，那到底如何控制需求范围？有人会采用这种办法：尽量隐瞒。不论是标书里提到的、还是用户以前提出过的、或者是项目团队想到的，用户不提或者暂时忘记了的，就装作不知道，不去考虑如何实现，不去面对潜在的困难。

 

这种做法固然可以瞒过一时，终究会爆发，谁来收拾残局？

客户是十分聪明的。作为项目经理，不为客户着想，客户也不会为你着想。项目尽管看似做完，隐藏的问题却十分巨大，只能导致项目迟迟不能验收，一拖再拖。

结果的产生很大程度上源于项目经理在需求范围控制策略上的巨大失误。前期隐瞒，当然就不会在系统设计上去考虑如何实现这些被隐瞒的功能，后期连改过自新的机会也丧失了，因为除非系统重新来过。

 

也许有人会觉得：用户之所以提这么多需求，这么多问题，肯定是由于商务上客户关系做的不够好，所以自然而然把责任归结在商务经理身上。

 

其实也不然。客户关系再好，提出新的需求也是在所难免的。主要在于这些需求是否合理，是不是客户真正需要的。反而，如若在需求范围界定上与客户产生摩擦，久而久之，再好的客户关系也会产生间隙。

 

在此，也推荐一种做法，个人觉得十分奏效。希望有助于其他项目经理有效管理项目需求范围。以下方法是多个步骤：

1、 把客户当朋友，建议一定的信任关系

2、 多替客户着想，主动提出一些需求建议（注意：这些需求建议一定要是比较容易实现的）

3、 主动替客户着想，如果提出的需求具有实用性、针对性、贴合实际会让客户十分感动，并容易让客户产生信任感和依赖情绪

4、 主动替客户承担一些项目相关的文档、申请（譬如域名，线路等，注意不宜介入太深）

使客户产生依赖思想，信任关系逐步确立

5、 针对客户提出的需求，一定不要严辞拒绝，先应承较易实现的需求并逐步实现，对于不太可能实现的或者难度较大的，在一段时间后，直接与客户讲清楚

6、 鉴于以上的依赖情绪及信任关系，对于这些较难实现的需求（其实，一般客户是很难区分需求的难易程度的），客户更加容易不坚持自己的观点（即相比直接拒绝客户需求来说，你答应了并实现部分需求之后，他更容易放弃那些实现较难的需求）

7、 与客户领导进行沟通时，一定要注意策略，尽量满足领导的宏图伟略，事后再与客户进行协商解决，这样也容易让客户项目负责人与你统一阵线

8、 到了这个程度，我想已经不存在需求范围控制的难题了。

 

以上方法具有较强的主动性，需要慎用，不然，结果可能是你提出的需求做了，客户提出的需求也全做了，舍了孩子也没套着狼就不好了。