十年开发目睹之怪现状（1）：质量至下

  rel="File-List" href="file:///C:%5CDOCUME%7E1%5Ccn1ww2g0%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml">

时光荏苒，转眼从事软件开发已经十年有余，其中经历过很多的项目开发，有辛酸，也有快乐；有经验，也有教训；总体感觉成功的项目不多，有一次和一位公司的资深工程师聊起来，他说了一句话：一个人一辈子能做成一件事就足够了，一个程序员能做成一个软件就足够了。听着有点心酸，但事实确实如此，有时一个项目成功了，完成了，产品不一定成功；一时成功了，也不代表总是成功。这里我把我所经历的一些教训记下来，供大家参考，讨论，希望能有所帮助，启迪。

 

1 质量至下

注意这里写的是质量至下，而不是质量至上。列位看官可能比较惊讶，怎么会是质量至下呢？大家不是天天叫嚷质量至上吗？初听此话，可能感到有点刺耳，可是，各位看官仔细想一想，你在国内看到过什么质量至上的优秀软件吗？看到过如windows, office这样长盛不衰，保持长久生命力的软件吗？没有，几乎没有，除了早年一些汉字外挂程序，汉字编辑软件这些外国人做不了也不愿做的东西外，似乎目前国内没有什么拿的出手的软件吧。大多数软件如过眼烟云，早已进入了历史的垃圾箱了，这就是软件产业的现状。另外，从你身边讲，如果你恰好是软件开发人员，你认为你所在的组织重视软件质量吗？你所在的组织开发出来的软件质量高吗？估计没有几个敢于拍胸脯说是的吧。软件产业的现状只能说明一个事实，大家都在奉行质量至下的标准。

我所见过的软件组织，很少有人，尤其是软件项目经理，重视软件质量。或者说软件质量只是一个点缀而已，平常经常挂在嘴边说说而已，但是真正在工作中很少有人重视它，执行它。所有的软件经理整天思考的问题是如何向他的老板交差，如何赶上项目进度而不被老板处罚，所以软件经理工作的最高要求是不要耽误进度，进度就是一切。在不耽误进度的情况下，可以顺便考虑一下软件质量，或者其他什么规范流程之类；但是，如果进度可能延误，那么首先牺牲的就是软件质量：流程可以简化，评审可以忽略，文档可以应付，测试可以模拟进行，但是进度不能延误。具有讽刺意味的是，即便如此，开发进度依然不能如经理们所愿按时完成，依然经常延误。因为进度延误变成了经常时，所以牺牲质量也变成了经常时。质量就这样被彻底丢弃了。很少有人考虑这中间的原因，也很少有人会想到质量和进度之间存在的某种联系。

为什么质量成为最先丢弃的对象呢？答案在于业绩考核。和进度比起来，软件质量是一种非常难以测量和考核的东西。软件质量不像传统工业品的质量检测那么简单易行，汽车我开一下就知道好坏，电视机我看一下就能够辨别高下，可是软件呢，软件不是直观可见的东西，软件功能变化多端，软件的一切都隐藏在源代码里，而不是界面上。即使是开发人员自己也不能精确评估自己开发软件的质量，何况每天只看图表和报告的软件经理们呢？和质量这种虚无缥缈的指标比起来，进度的测量一目了然，EXCEL图表和Project甘特图是老板们最爱看的东西，每位经理都不希望自己的项目在老板那里显示为是黄色或者是红色（代表进度延误）。所以，经理们必须首先保证自己不会因为最简单的考核指标进度而受罚，就像官员不想由于GDP指标让自己的乌纱帽受影响一样。至于质量，只要不在实验室出问题就行了，天知道什么时候在用户那里会出问题。即使有问题，只要我的问题比别人的问题出现的晚就行了，就像在遇到老虎的时候，我只要跑的比别人快就行了。况且，出了问题也不一定是我的问题；即便是我的问题，也没有人能够证明确实是我的问题，这个责任无论如何是不会落到我头上的，所以，让质量见鬼去吧。我保证大多数的软件经理们都是抱着这样的心态在开发软件，质量问题就像皇帝的新衣，没有人说破罢了。经理们都是如此，开发人员也就没有必要在质量上花功夫了，毕竟质量保证是一件吃力不讨好的事情。即使有少部分像我这样的人痛心疾首，也是无济于事。

质量低下的软件的一个突出特点就是可维护性差，bug难以修复，新功能特性添加困难，操作繁琐等等；最终都难以逃脱短命的命运。软件虽然开发出来了，但是由于存在着种种bug，所以不得不延期交付给用户使用，甚至在仍然有很多bug没有解决的情况下勉强交付给用户。依然不得不花费大量的人力，物力资源去维护它，直到不堪重负，只好自行宣布了它的死刑；或者是不能及时跟上用户的更新需求，最后难逃被用户替代，抛弃的命运。很多人把一个软件产品的退出归结为市场，销售，开发策略，功能等等的原因。对于中国这样的初级市场来说，我认为最重要的原因是质量问题，并且其实很多上述的原因依然可以归结为质量问题。它的失败可能在产品的早期版本已经是命中注定的。