“欲穷千里目，更上一层楼” ——王之涣
从站得高的角度来看，我们最先找到了项目的发起者——集团。
但是集团不处理的实际业务，于是需求提供的责任便转移到总公司了。对于我来说只要有人提需求就行了，无所谓集团还是总公司。
当老子的队伍开到总公司，总公司同志还是十分热情的接待了我们。
之后双方在热烈友好的氛围下，进行了会晤。
“这种业务我们没有，也不用考虑”——这是对于业务中是否应该存在货代公司时客户说出的话
我认为按长远考虑，应该把货代公司纳入系统，而客户不同意。客户的观定很清楚，现在没有这个业务，我也说不清未来的情况，你当我是诺查丹马斯（当然这个家伙说话也是没准的）啊。
而我的出发点有两个。一是因为合同上的要求“系统必须适应未来3到5年的业务”。一般来说这句话基本上在做项目时可以认为是废话。我看过这么多业务系统的合同基本上都写上这句话，已经变成合同中标准句式存在了。本着“存在就有理由”的原则，关于未来的事还是想一想吧。
还有个原因是那天接项目时，老板说了一句话“通过这个项目，我们要得到一个产品”。也就是说，我除了要完成项目目标外，还要提供一个产品化的系统，既然是产品必须在市场上有一定的竞争力，其流程和技术都应该是现代的先进的。我估计很多老板会给项目经理这个要求，其实这个要求不算过分，但当产品的现代化流程与项目需求发生冲突时问题就出来了，这就是我的问题：我是维护领导还是要拿验收表。
当然两者兼顾是最好了，先搬出合同的条款和客户讨论，以期答成共识。客户的发挥总是相当稳定，一如既往的，不同意。看来领导未必能看得多远，短视的人比比皆是。
既然说不通，那就拖啊。非常遗憾，这个部分不能拖啊，因为这个不是独立模块，是参与整个系统的，这个不定下来，其他的无法开工。要是拖最后拖死的只能是自己。
现在我的计划就按照我的想法来做，增加了货代公司，但在界面上不体现。
结果刚过了半个月，客户来电话了。
“业务里加上货代公司吧，从长远考虑这还是必要的”
“是啊，那我加是可以啊，不过原来是没有加的，做个变更吧”其实只要把visible的值改一下，货代公司就有了。
“行啊。”
这次变更实际花费0.5个人日，我上报10个人日，这里偷出来的时间都是我的。
这种改过来，之后又改回去的变更，还是不*的。客户经常说，把这个界改成什么什么样，等你改完了，他又说，还是原来的好看改回来吧。因此这里提到一个新的需求变更的控制概念——预估需求。
所说预估需求，就是你能通过客户提出现有需求，预先估出他未来可能的变更，并在变更前留好余地，那预估需求的能力是怎么炼成的？
要学会预估需求，除了我们前面提到的行业经验外，还有就是分析这个需求未来扩展的情况。
如客户说，他要一个用户管理的功能，那你就要想到用户管理包括那些，这是行业经验告诉你的。你还要想，这个功能可以扩展出什么，比如权限管理，字典选择，人事档案接口等。根据麦肯锡的方法，就是“相互独立，极尽穷举”的来想出需求的扩展。并根据你对这个企业和行业了解的事实，提出最可能的需求变更。
说到这里大家看出来了，其实预估需求的目的是防止需求扩张这种变更，对项目带来的影响。
其实这种估算方法，说起来容易，做起来还挺难的。就像火烧赤壁一样，大家都知道是用火烧的，那你知道当时黄盖，为了烧曹操准备了多*火船，每艘火船要用多*硫磺焰硝，这个估算除了要对放火这一工程学的了解，还要对当时天气、曹军人数、战船位置的全面分析才能得到的结果。估*了，达不到火攻的目的，估多了，老曹一看这么多船，你黄盖不是将军是都督啊，带这么多人来投降。
那非扩展的需求可以预估吗？答案是可以的。但你必须有足够事实来证明你的想法是正确，而且客户肯定会选择到你这个正确的想法上来。像*备临死时向诸葛亮说马谡不可重用。虽然诸葛亮这个客户比较自负，没有听*经理的话，但后来的结果，导致诸葛亮必须承认*备的正确的。
“时间是检验真理的唯一标准”，问题是这个时间有多长，很多伟大的人是死后才平反的、追认的，像袁督师、***等。因此相对扩展需求的预估是比较容易，而风险也较小的。不建议大家对非扩展的需求进行预估。
搞了一溜十三招，总算是上线（项目是分模块上线的），在第一次培训时（之所以说第一次是指后面还有好多次），客户的热情也被点燃了，带着全副家当（项目相关人员还有无关人员）来参加。而我也挺兴奋，毕竟是展示成果的时候。就在我口沫四飞的时候，我发现听课的人热情不是很高。在讲完后和他们沟通了一下，终于找到他们热情不高的原因了。
理由很简单，他们听不懂。而听不懂的原因是我讲的东西和他们业务根本不是一回事。这时我才发现，原来站得高的人，不光看得不一定远，还一定是看不清的。
你站在山头上，看是看得高了，但肯定是看不清的。除非你有望远镜这种高科技设备（现代望远镜可真是高科技）。正巧我这些站在山头的客户都没带望远镜。
既然下面认为业务和系统需求不同，那结果就是这个系统无法满足他们业务的要求，这下问题大了。赶紧找客户吧，客户倒是很沉稳，说了一个字——“改”。
现在我们考虑不改会怎么样。如果不改，系统无法满足下面业务需求，即系统基本无法使用，未来验收更是没有希望，还造就了一大批输家客户。
如果改，那工作量肯定要增加。现是没办法了，只能改了。那就找客户做需求变更吧。
变更单倒是挺容易的，客户很快就批下来。变更是变更了，但是客户不同意增加项目时间和项目资金。这种事是经常遇到的，客户承认变更，但不肯加钱加时间，对于我们来说，这种变更单就变得几乎无意义了。
由于这次变更是客户失误造成的，这种事，要抢先和公司领导汇报。领导听到这种事当然是十分重视，首辅皇帝都开始忙了。这种商务的事超出了我们项目管理的范围，本次就不说了，总之忙三火四的把时间要到了，钱是没戏了，把眼睛想瞎吧。
首辅赶紧在第一时间找到我，和我说时间可以延长了，我很开心啊，但我马上就会为自己的开心把肠子悔青。因为只申请出1个月的时间。这种业务变更怎么可能是1个月就搞定啊（我们这次变更的业务较多而且有点复杂）。这个时间是没法改了，我先把话和领导说清楚，活我会努力做，时间上我不保证。做为首辅兼泥瓦匠（和稀泥）当然同意了，一把稀泥飞过来“你努力做就行了，我们相信你的能力”。*带高帽，我又不是法国总统，戴个高帽我就乐。可是活还是要干啊。
可怜我那五万丘八。天天夜行军不说，还吃不饱（公司不管晚饭）。
变更后最倒霉的是程序员，毕竟活在他们身上。所以说一个死亡式的项目过后，整个公司地板上都是血，这些血不是领导，不是客户，不是项目经理而是程序员的。
如果做为直接领导再不心疼他们，程序员就太可怜了。所以我不断的控制变更，不光是为了项目进度，我还要考虑手下人的工作量，除了这次，我没有让他们再加过班。
做为真正的项目经理，之所以你不用参加实际的开发测试工作，而你的报酬要比程序员高很多，原因就是你的一句话可以抵上他们工作一个月，能否真正有效的控制需求，决定了这个项目的成败。
至此关于需求的调研和变更我都讲完了，有网友说，我有很多办法控制需求、控制客户，但是我也有没办法的时候，当我没有办法时，我的团队就是我能胜利的唯一保障。
篇后话：
今天关于项目的需求我们就说完了，需求我是分为调研和变更两部分来讲的。大家看到了，需求对于项目成败的结果，所以需求部分的名字是，胜负在此一举。而变更我借用了《人月》里的名词焦油坑。在项目的所有变更中，最终我也失败了一回，我没有能控制全部的变更，毕竟我不是上帝。
我写这些内容，只是希望大家在工作中遇到与我类似的问题可以避免犯错，并不指望大家天天和客户PK，与客户PK是没有好处的。和客户关系要做好，我们毕竟是对事不对人。
后面的一章，我将讲一下在项目中建立标准化的相关情况。希望大家喜欢。
