软件项目的敌人

这是文章的出处，希望去原址浏览，有多更多精彩文章！

此处仅供自己和朋友参考！http://champion.ewuxi.com/old/exp/foeinproject.htm

软件项目的敌人

　　做了这么多年的软件项目，有成功的，也有失败的，但心中却没有对一个项目十分的满意。或许我是个完美主义者，总是想着有什么项目能够在项目结束的时候多方都心满意足，总是觉得要是一个项目结束，客户能鼓掌说太好了，这正是我们想要的，老板说，很好，我们赚了，同事说，不错，我们这回干得还算轻松。也许这可能是个梦想，但我常常在深夜中苦思，怎样能做得更好。于是想出了很多做错了的，我想，知道做错了，下会就能努力去改错，也许没有对的，但会有比这些错误要好一些的办法。我把这些称之为敌人，因为我想重视它们，消灭它们。

　　其一、天真的计划。也许计划称之为天真可能不合适，但实实在在碰到太我的这种情况。前几天看了红旗渠的报道，从现在看来，这是一个算得上伟大的工程，以人工征服了太行山。不过这一个实际用了十年才完成的工程，在最初的时候却计划用80天来完成，多数人在看报道的时候，恐怕第一反映是这个计划太天真（事后诸葛亮，谁都会做）。在软件项目中，或者实际与计划相差没有那么大，但确实存在很多这样的项目，可以说，从一开始，这些项目就危机重重了。为什么？我觉得原因在于三方的地位的不平等，软件需要开发人员、客户与老板（或相当于这一级别的人，总之，在国内，开发人员几乎很少有这种级别的权力）共同来完成。但是，计划的制定，往往是客户与老板协商来确定，开发人员是没有权力来过问的（即使能过问也是象征性的）。于是乎，由外行（客户）与半外行（老板）共同商定的计划，多数是不切实际的。并且软件行业并没有任何标准计划或标准人工数用来对比，不切实际可以说是必然。我常常看见，造一座大桥，说我们有多成功，大家干得多好，总有数据，国际标准是多长时间完成这样一座桥，而我们只花了多长时间来完成。还有，比如说深圳速度是几天一层楼。这是很明确的，可是，到目前为止，也很难看到，一个程序员一天完成的标准数是多少。于是客户与老板考虑计划的出发点就几乎忽略了这一要素，而单纯从成本效率、客户的心理等方面考虑。所以我们有时候能看到，在一些接单的过程中，有的软件公司可以报出50万，而另一家可能报出5万。如果这样的项目以5万成交了，给开发人员带来的就是灾难，就是失败。原因很简单，如果开发人员以老板为中心，在如此低的成本下，老板必然要压缩人力成本，结果，客户不满意几乎是必然的，如果以客户为中心，必然会带来成本超支，老板不满意也是必然的，而这两种情况下，开发人员所承受的压力之大，所以开发人员是一定不会满意的。理想的三赢目标从一开始被抹杀了，这样的敌人是开发人员所无法应付的。

　　其二、技术的陷井。有时我们能看到乐观的项目人员这样说，“我们找到了一个新的工具，或者我们将在项目中使用新的技术（JAVA或。NET目前看来是使用最多的），使用这个工具，我们将节省1/3的时间，虽然我们将会使用其中的一些时间来学习如何使用这些技术，不过它们将很有效。”。说这些话的，如果不是高估了自己的能力，就是高估了这项新技术的功能。最后，当项目进行到某一个阶段，发现理想与现实相差太远的时候，我们已经没有退路了，因为时间已经被花掉了。我曾经在一个项目中使用了一个工具，在开始的时候，它是如此的吸引人，看上去只要半个小时就能完成以前一天才能完成的对数据库的维护编码工作，因为它会为你生成大部分的代码。的确，我只花了半个小时就把所有的表格代码生成类了，接下来开发人员要做的事很简单（至少我当时是这样认为的），然后我花了一天的时候教会其他人员使用。然后，问题慢慢开始发生，先是开发人员不停的抱怨对其内部的类之间事件的触发机制不了解，我告诉他们不必关心这些事件，只要关心接口就可以了。但是麻烦的确存在，开发人员不能象以往一样直接面对数据库编码，而要通过一些类，这使他们怀疑所写的程序是否能真的工作。接着，开始发现这些生成的类只能针对主键进行数据的修改，而有时我们需要的是不通过主键对一批数据进行修改，于是我们不得不在这些类中增加一些代码来实现这个功能，同时，它不能处理二进制字段，于是，我们又修改了一些代码。一个星期一的早晨，根据客户的意见，我们修改了一些数据库的结构，然后我使用这个工具对现有的类进行更新，以保持跟数据库一致。这时灾难发生了，我发现它在更新的时候产生了一些bug，首先，它在主键的字段类型修改中有bug，虽然它能正确的修改类中的属性类型，却错误的修改了update的参数类型，更可怕的是，它居然完全覆盖了原来的文件，我们在这些类中所作的修改并没有被保留下来。于是我不得不找出备份文件，并对这些文件一一进行比较，然后进行更新。这一部分工作，花费了我两天时间，同时，其他人员的工作也被延误了。从此，每次进行这样的修改，都要比较一番。等到项目完成了，回过头来比较，它所花费的时间比它所能节省的时间要多，并且多数开发人员直到项目完成，仍对这些生成的代码的正确性表示怀疑。所以，如果是一个重要的项目，开发人员要使用新的工具，就必须也它也加入到风险栏目中的。事实上，我的第一个JAVA的Web应用，也因为中文的问题而花去了一周的时间，而这样的时间，如果用我所熟悉ASP或PHP，是完全可以节省的。对未知的东西保持乐观的态度是危险的，事实上到目前为止，没有什么工具真的能大大提高工作效率，如果真有的话，也许我们已经失业了，：）。

　　其三、研发方式。须知，项目区别于研究最大的特点是项目要求的是能在限定的时间内达到一定的目的。作为开发人员，往往在潜意识中对技术希望追根究底，研究技术可能成为他们的最大兴趣所在，而不是其他。有一个例子，说美国有人在一次程序员的聚会上作了一次调查，问有多少人在9岁以前拆过闹钟，有90%以上的人都举了手，当问到有多少人把钟装好，并能正常的工作时，只有不到10%的人举手。由些可见，多数人关心的研究的过程，并非是结果。可怕的是在多数开发小组中，越是高手，越容易产生这样的问题。高手的定义常常是其他人干不了的事，他能干，或者其他人干一星期的事，他两天就能做完。当这样的人员在项目中因为突然对一个技术产细节感兴趣而开小差的时候，项目受到的损失有多大？技术的研究与储备是重要的，但在项目的开发过程中，这样的事情，最好还是能避免。微软提倡的是"good enough" ，如果不是这样，或许到现在windows 95还没有上市呢。到了中国，也有对应的一句话“再完美的系统，如果没有用户使用，那就是废物”，可惜，有时候，人们偏偏会忘记它。

　　其四、埋头苦干。有的项目小组，调研一结束，所有人员都关在公司里埋头编程序，直到完成一个阶段，或者客户来催了，才与客户进行交流。或许你的系统的这一段时间内从内部版本1升级到了内部版本3，速度提高了，画面美观了，操作方便了。但客户什么也不知道。所以，重要的是对客户交流，最少每个星期都要有交流。有时候，客户并不关心你在做什么，重要的是他需要知道项目一直在进行。而在这一交流过程中，要培养客户来理解软件开发，如果客户能理解软件开发，那么，将来要争取时间，或者更改需求的时候，双方能更有一致的想法。比如我在一个项目中，客户理解了，只要有适当的数据，出报表是相对容易的。然后再客户在考虑数据的组成时就会更加全面，同时也能理解开发人员对时间的要求。相对的，在这一过程中，开发人员对业务将会有更好的理解，也就能够提供建设性的意见，给客户及开发工作带来很多的节省。

　　其五、不当的压力。开发人员多数性格内向，不善于争辩，但这并不表明他们没有想法。如果只是简单的增加工作压力，要求赶时间，要求加快速度，最后的结果是适得其反，一组失去活力的开发人员就象打了败仗的兵。分配合适的任务，并在明确的时间内完成，这样，开发人员会觉得一切尽在掌握中，而有效的休息使他们能工作得更长久。

在项目的进行过程中，存在着种种的因素导致项目走向失败，需要有人来控制，你的项目组中有风险控制人员吗？如果没有，快找一个，这并不会费很多时间，但确实有效，他会帮助你一起找出敌人并一起消灭掉。

紫龙，2002年8月

蓝色天空版权所有