项目那点儿事(八) ---焦油坑[需求变更]之站得高未必看得远

   文章来源:项目那点儿事                                                              作者: 羽之


   “欲穷千里目,更上一层楼” ——王之涣


   从站得高的角度来看,我们最先找到了项目的发起者——集团。

   但是集团不处理的实际业务,于是需求提供的责任便转移到总公司了。对于我来说只要有人提需求就行了,无所谓集团还是总公司。


   当老子的队伍开到总公司,总公司同志还是十分热情的接待了我们。

   之后双方在热烈友好的氛围下,进行了会晤。

   这种业务我们没有,也不用考虑”——这是对于业务中是否应该存在货代公司时客户说出的话
   我认为按长远考虑,应该把货代公司纳入系统,而客户不同意。客户的观定很清楚,现在没有这个业务,我也说不清未来的情况,你当我是诺查丹马斯(当然这个家伙说话也是没准的)啊。


   而我的出发点有两个。一是因为合同上的要求“系统必须适应未来3到5年的业务”。一般来说这句话基本上在做项目时可以认为是废话。我看过这么多业务系统的合同基本上都写上这句话,已经变成合同中标准句式存在了。本着“存在就有理由”的原则,关于未来的事还是想一想吧。

   还有个原因是那天接项目时,老板说了一句话“通过这个项目,我们要得到一个产品”。也就是说,我除了要完成项目目标外,还要提供一个产品化的系统,既然是产品必须在市场上有一定的竞争力,其流程和技术都应该是现代的先进的。我估计很多老板会给项目经理这个要求,其实这个要求不算过分,但当产品的现代化流程与项目需求发生冲突时问题就出来了,这就是我的问题:我是维护领导还是要拿验收表。

   当然两者兼顾是最好了,先搬出合同的条款和客户讨论,以期答成共识。客户的发挥总是相当稳定,一如既往的,不同意。看来领导未必能看得多远,短视的人比比皆是。

   既然说不通,那就拖啊。非常遗憾,这个部分不能拖啊,因为这个不是独立模块,是参与整个系统的,这个不定下来,其他的无法开工。要是拖最后拖死的只能是自己。


   现在我的计划就按照我的想法来做,增加了货代公司,但在界面上不体现。

   结果刚过了半个月,客户来电话了。

   “业务里加上货代公司吧,从长远考虑这还是必要的”
   “是啊,那我加是可以啊,不过原来是没有加的,做个变更吧”其实只要把visible的值改一下,货代公司就有了。
   “行啊。”

   这次变更实际花费0.5个人日,我上报10个人日,这里偷出来的时间都是我的。

   这种改过来,之后又改回去的变更,还是不少的。客户经常说,把这个界改成什么什么样,等你改完了,他又说,还是原来的好看改回来吧。因此这里提到一个新的需求变更的控制概念——预估需求。


   所说预估需求,就是你能通过客户提出现有需求,预先估出他未来可能的变更,并在变更前留好余地,那预估需求的能力是怎么炼成的?

   要学会预估需求,除了我们前面提到的行业经验外,还有就是分析这个需求未来扩展的情况。

   如客户说,他要一个用户管理的功能,那你就要想到用户管理包括那些,这是行业经验告诉你的。你还要想,这个功能可以扩展出什么,比如权限管理,字典选择,人事档案接口等。根据麦肯锡的方法,就是“相互独立,极尽穷举”的来想出需求的扩展。并根据你对这个企业和行业了解的事实,提出最可能的需求变更。


   说到这里大家看出来了,其实预估需求的目的是防止需求扩张这种变更,对项目带来的影响。

   其实这种估算方法,说起来容易,做起来还挺难的。就像火烧赤壁一样,大家都知道是用火烧的,那你知道当时黄盖,为了烧曹操准备了多少火船,每艘火船要用多少硫磺焰硝,这个估算除了要对放火这一工程学的了解,还要对当时天气、曹军人数、战船位置的全面分析才能得到的结果。估少了,达不到火攻的目的,估多了,老曹一看这么多船,你黄盖不是将军是都督啊,带这么多人来投降。


   那非扩展的需求可以预估吗?答案是可以的。但你必须有足够事实来证明你的想法是正确,而且客户肯定会选择到你这个正确的想法上来。像刘备临死时向诸葛亮说马谡不可重用。虽然诸葛亮这个客户比较自负,没有听刘经理的话,但后来的结果,导致诸葛亮必须承认刘备的正确的。
   “时间是检验真理的唯一标准”,问题是这个时间有多长,很多伟大的人是死后才平反的、追认的,像袁督师、刘少奇等。因此相对扩展需求的预估是比较容易,而风险也较小的。不建议大家对非扩展的需求进行预估。

   搞了一溜十三招,总算是上线(项目是分模块上线的),在第一次培训时(之所以说第一次是指后面还有好多次),客户的热情也被点燃了,带着全副家当(项目相关人员还有无关人员)来参加。而我也挺兴奋,毕竟是展示成果的时候。就在我口沫四飞的时候,我发现听课的人热情不是很高。在讲完后和他们沟通了一下,终于找到他们热情不高的原因了。

   理由很简单,他们听不懂。而听不懂的原因是我讲的东西和他们业务根本不是一回事。这时我才发现,原来站得高的人,不光看得不一定远,还一定是看不清的。


   你站在山头上,看是看得高了,但肯定是看不清的。除非你有望远镜这种高科技设备(现代望远镜可真是高科技)。正巧我这些站在山头的客户都没带望远镜。

   既然下面认为业务和系统需求不同,那结果就是这个系统无法满足他们业务的要求,这下问题大了。赶紧找客户吧,客户倒是很沉稳,说了一个字——“改”。

   现在我们考虑不改会怎么样。如果不改,系统无法满足下面业务需求,即系统基本无法使用,未来验收更是没有希望,还造就了一大批输家客户。

   如果改,那工作量肯定要增加。现是没办法了,只能改了。那就找客户做需求变更吧。

   变更单倒是挺容易的,客户很快就批下来。变更是变更了,但是客户不同意增加项目时间和项目资金。这种事是经常遇到的,客户承认变更,但不肯加钱加时间,对于我们来说,这种变更单就变得几乎无意义了。

   由于这次变更是客户失误造成的,这种事,要抢先和公司领导汇报。领导听到这种事当然是十分重视,首辅皇帝都开始忙了。这种商务的事超出了我们项目管理的范围,本次就不说了,总之忙三火四的把时间要到了,钱是没戏了,把眼睛想瞎吧。


   首辅赶紧在第一时间找到我,和我说时间可以延长了,我很开心啊,但我马上就会为自己的开心把肠子悔青。因为只申请出1个月的时间。这种业务变更怎么可能是1个月就搞定啊(我们这次变更的业务较多而且有点复杂)。这个时间是没法改了,我先把话和领导说清楚,活我会努力做,时间上我不保证。做为首辅兼泥瓦匠(和稀泥)当然同意了,一把稀泥飞过来“你努力做就行了,我们相信你的能力”。少带高帽,我又不是法国总统,戴个高帽我就乐。可是活还是要干啊。

   可怜我那五万丘八。天天夜行军不说,还吃不饱(公司不管晚饭)。

   变更后最倒霉的是程序员,毕竟活在他们身上。所以说一个死亡式的项目过后,整个公司地板上都是血,这些血不是领导,不是客户,不是项目经理而是程序员的。

   如果做为直接领导再不心疼他们,程序员就太可怜了。所以我不断的控制变更,不光是为了项目进度,我还要考虑手下人的工作量,除了这次,我没有让他们再加过班。


   做为真正的项目经理,之所以你不用参加实际的开发测试工作,而你的报酬要比程序员高很多,原因就是你的一句话可以抵上他们工作一个月,能否真正有效的控制需求,决定了这个项目的成败。

   至此关于需求的调研和变更我都讲完了,有网友说,我有很多办法控制需求、控制客户,但是我也有没办法的时候,当我没有办法时,我的团队就是我能胜利的唯一保障。


篇后话:

   今天关于项目的需求我们就说完了,需求我是分为调研和变更两部分来讲的。大家看到了,需求对于项目成败的结果,所以需求部分的名字是,胜负在此一举。而变更我借用了《人月》里的名词焦油坑。在项目的所有变更中,最终我也失败了一回,我没有能控制全部的变更,毕竟我不是上帝。
   我写这些内容,只是希望大家在工作中遇到与我类似的问题可以避免犯错,并不指望大家天天和客户PK,与客户PK是没有好处的。和客户关系要做好,我们毕竟是对事不对人。

   后面的一章,我将讲一下在项目中建立标准化的相关情况。希望大家喜欢。


本文链接:http://www.hihubs.com/article/30

关键字:项目那点儿事(八) ---焦油坑[需求变更]之站得高未必看得远

若无特别注明,文章皆为Hubs'm原创,转载请注明出处...O(∩_∩)O

ToolFK 公众号