程序员故事：没有免费的午餐

我们总想着花最少的钱办最多的事情，这本是一件很正确的观念，但如果花的钱明显少到不合理，那办出的事情也就有可能会狠打几个折扣。

所谓没有免费的午餐，或许就是如此了。

那是刚参加工作的前几个年头，公司用户的需求越来越多，软件要求也越来越复杂，我们那几个内部程序员已经明显不够用，花钱请外面的软件公司来帮忙做软件已经成为刻不容缓的一件事情。很荣幸，我成为部门成立以来第一个真正意义上的项目经理。

那是公司生产部的一个软件项目，主要用来对制造产品所需的一些材料和配件信息进行管理，生产部的李部长和我们信息部的赵部长关系很熟，再加上这个项目的规模比较适中，所以两位领导一拍即合，决定拿它试水软件外包。外请的软件公司在我们业内口碑不错，带队的周经理也帮其他单位做过类似软件，所以大家也都觉得这是一个注定要成功的项目。

周经理是个技术型的程序员，戴着一副黑框眼镜，每天上下班都会背着一个双肩包，里面装着笔记本电脑，非常典型的程序员形象。而我也是刚从程序员向项目经理的方向转变。初步了解用户的需求之后，我们两个人从技术角度分析了一下，觉得和之前在其他单位做的软件相比，只是一些流程细节上的不同，其他都是类似，没有什么难点，便信心满满的做了一份为期6个月的计划方案。

两位领导对这个计划也很满意，尤其是李部长还把手下不同专业组的几个业务骨干也调派了过来，要求他们每天要抽出一定的时间参与软件需求访谈和测试验证的一些工作。

看起来是一个不错的开端。

在对各个专业组进行深入访谈后，感觉遇到了点小麻烦。因为与之前简单了解的情况相比，实际的业务要比我们想象的更为复杂一点，并且和之前周经理做过的那款软件的差异点也不是想象的那么简单。

后来软件项目做的多了，也就慢慢的习惯了这种现象。平时用户的生产和工作任务都很繁忙，软件项目没有正式启动时，用户也不会投入那么多的精力和我们进行深入的交流。等到项目正式开始后，用户会作为项目组成员加入团队，大家每天在一起沟通和交流，问题越讨论越细致，之前很多没有想到的一些需求会在这个时候显露出来。

不过当时我还是没有完全适应这种情况，周经理毕竟是在外面见过世面的，告诉我其实他在制定方案的时候也预留了一些工作量，增加的这些需求都在意料之中了，所以也不用太过担心会延期。

两个多月后，项目组完成了设计说明书的编制，我和周经理便约李部长进行了一次阶段性的工作汇报。看了我们展示的成果和设计方案，李部长表示很满意。

会中李部长问周经理：“小周，我这边还有一两个简单的流程，你看好做不。”

听完李部长的简单功能介绍之后，周经理很爽快地说：“这个简单，我们可以顺便帮一起做一下。”

我也觉得就几天的工作量，问题不大。

这种单纯从技术角度考虑问题的方法，其实在后来的日子里也继续影响了我很久。因为技术出身，听到需求后便立马会去考虑解决方案，然后脑海中就会浮现出数据库怎么设计，流程怎么走，怎么部署之类的想法，其实这是非常错误的。现实世界的具体任务，永远比想象的要复杂的很多。

同样是技术出身的周经理显然也犯了类似错误，和我一样只看到了表面简单的功能，至于背后还有什么其他复杂的罗辑，则完全没有意识到。

领导有吩咐，属下的几个参与项目组的关键用户自然就要很尽心尽力。领会到李部长的精神之后，他们便对那几个简单的流程进行了分析。很多事情就是这样，一旦深入考虑，就会能发现更多的东西。

后来几个关键用户拿出了一份详细的需求书，不得不说这些业务骨干还是很有一些水平的，几个看似简单的流程经过分析之后，不但功能更加强大，还和之前的设计的那些功能关联了起来，相当于形成了一个闭环。

新的需求摆在那里，我心里犯了难。虽然我并没有很多项目经理的经验，但从技术角度来看，新增的内容的确是太庞大了，甚至都可以单独再做一个类似的项目，这么大的投入软件公司愿不愿意免费帮我们去做，这是个很大的疑问。

李部长也没有想到需求会变得这么复杂，但看起来的确比之前更具有吸引力，但公司预算考核的比较严，合同变更的路谁都不想走。该怎么办?坐在赵部长的办公室里，看着他们吞云吐雾的抽了一根又一根的香烟后，赵部长觉得，我们应该逼软件公司一下，激发一下他们的潜力。

“告诉他们，公司后面还会有好多软件项目可以做，不愁没有钱赚的。再说了，既然我们的钱已经花出去了，当然是要让乙方能做多少做多少。”赵部长对我说。

过程倒也不曲折，考虑到我们这这家软件公司的母公司在其他领域有着很多合作，软件公司的老总亲自来和赵部长交流了一次之后，新的需求便加到了项目中。

因为没有更多的经费，虽然工作量增加了一倍，但人员却没有增加那么多。我和周经理有点焦头烂额了，之前只要把核心的业务做好就行，而现在每天我们都要和好几个专业组的人交流，讨论各种细节，之前做好的设计还要因为新的因素重新考虑。

本来6个月完成的软件，做了满满一年才勉强上线。但由于中间的反复波折太多，整个软件做的算是千疮百孔，用户使用的时候也常常是怨声载道。甚至有几个当时考虑地很完美的功能，实际却由于设计的过于复杂而没有用起来。

总体来说，这是一个失败的项目。周经理由于天天被关键用户折磨，反而把用户的业务罗辑搞得很透彻，后来去了一家更大的软件公司做了咨询顾问，工资翻了一番。我也痛下决心，考取了项目管理的高级认证，建立了项目管理制度。

范围管理是影响软件项目管理的核心要素之一。

翻看一下失败软件项目的案例，就会发现很多原因就是因为范围管理失控，有的甚至是完全没有范围管理。