真伪需求

记得之前做过一个外包项目，甲方是一家大型的国有企业。项目负责人从甲方那里采集需求，将需求整理成文档，然后做出软件原型界面给甲方负责人看，最后就在甲方的同意之下，集中开发了一年左右。 弄个出了一个我们认为可以用的版本。随后我被派去用户现场部署试用（用户不是我们的甲方，是甲方的甲方），才发现一个难过的事实：我们开发的版本离用户期望的差得太远，甚至被断定为不能使用。当然，最终我们交给了用户一个能接受的版本使用，当然这是在付出很高的代价后得到的结果。

随后多个项目中，我发现这样的问题普遍存在。甚至有项目因此流产。而普遍的补救方式就是我刚刚所说的“高代价”->去用户现场长期开发。也就是说，之前努力干的活大部分都没用，最后在用户现场长期（数月）驻场开发，用户怎么用就怎么改。

这种现象本不应该存在。不过却一贯如此，我无力改变这一切，只能在此分析分析，希望以后出现类似问题，可引以为戒。

弊端

弊端太多，影响较大的有以下几点。

一、成本 

这里的“成本”包括几个方面：
时间成本：项目本身的时间节点被推后，给用户、客户、以及研发单位均增加了时间上的消耗；
人力成本：对研发单位来讲，必须要有人现场开发，那么这个人力是不可少的，而且长期在用户现场开发，对开发人员的心理素质也是一种考验，这种“折磨”可能会引起技术力量的流失；
这些成本也直接或间接导致了用户、甲方、以及 研发单位的经济投入。

二、软件质量

现场开发人员可能需要根据客户的要求修改界面、业务逻辑、甚至是架构设计。相信长期下去没有多少人有耐性去做单元测试，更别说深层次地考虑这些修改对软件系统可能带来的影响。软件的质量可能会因此降低，软件的可维护性同样会大打折扣。由此导致的副作用可能在驻场开发期间不会很明显或者不会出现。但是随着时间的增长，系统维护人员的负担会越来越重。

三、商业影响

对用户或客户来讲，系统不好用，最终的责任都会被推到研发这一方。研发单位的口碑于是乎顺其自然就被传开了。。。

问题根源

一、领域知识匮乏

对乙方来说，这是很重要的一点。一个项目组至少有一位熟悉其领域专业人员或是业务专家。而事实上，我们项目组内的人员几乎均为初涉该领域，所有的需求理解都源于甲方，而甲方却很少能拧清真实的需求。所以最终的需求，必为伪需求。

二、作坊式软件开发 

首先是项目的计划安排，几乎是一纸空套，与其说我们的项目组是一个软件研发团队，不如说是软件编码小作坊，现在回想当时无论是从开发方式、编码风格、代码规范、项目管理等诸多方面看，我们都是一个不折不扣的软件作坊。 开发人员天天加班，最后也说不出来那么多时间到底做了些什么事情。反正时间节点把控无从谈起。只要甲方催严一点，我们就加班多一点。

三、甲乙双方的“态度”

甲方的“态度”：我相信世界上没有无可挑剔的甲方。甲方只要结果，但如果软件项目，甲方不积极参与过程，最终的结果也是可想而知的。恰好我们的甲方，还有个甲方，与真实的项目组是隔离状态。

乙方的“态度”：这里乙方“态度”并非项目组的态度。而是乙方在当时那个复杂形势下的领导层态度。这个态度决定了，乙方仅是人力外包的形式做项目。这样的意识形态传到下层工作人员，最终的一些努力也仅是有心无力的挣扎。

解决方案

 上面说的这些，我觉得有些事情是靠我自己能解决的。比如领域知识能够在项目之中积累。比如作坊式的软件开发与管理过程可以使用敏捷开发替换。但有些事情却也是无能为力的。就这样吧... 未来，希望能摆脱某些未能为力的事情。

 一口气打了折说多不多的话。其实只是把真实的想法写这里。如果有认识我的人， 千万不要对号入座，谢谢！