转自Liu Hang

软件产品开发，为什么失败？在做了四年的软件开发，亲身经历了几个失败案例之后，我不得不对这个问题进行反思。我所接触到的朋友多半是做软件开发的，他们和我一样，经历失败的例子比成功的要多得多。从网上的各种文章、论坛得来的信息也一样充满着悲观。为什么这么多的失败？对于这个问题，有着各种各样的答案。诸如需求不明，不断改变；项目管理混乱，时间一拖再拖；技术方案出错，技术难题解决不了；人员流动频繁；产品出来后没有市场、没有竞争力等等问题，不一而足。正是失败的原因各种各样，在产品开发的过程中要面临一个又一个的险滩与暗礁，而每一个都有可能是致命的威胁。如何面对这些危险，绕过这些险滩？以下一些是我个人的思考。把软件开发看作一个整体的流程，本文试图从产品开发的整个流程来阐述我们会遇到的种种问题已及提出一些自己的见解。

一、软件产品的立项

一个软件产品的开发和项目有着许多不同，一般来说，软件项目(project)都是因为有了明确的客户，或者已经有了合同或意向而开始启动的。软件产品(product)则完全不一样了。在一个产品没有开发出来之前，基本上没有客户。当然也有人仅仅凭着一套大脑中的想法或概念就能找到客户，对这些人我只有佩服。当然大多数公司只能先拿出一套自己的产品去推销，才有可能找到定单。所以就有了做产品的想法。

在这些软件公司中又可以分两种情况。一种是在某个行业做了多个项目，也积累了一些行业、技术等经验。每一个新的项目都要重复很多同样的工作，效率自然不高了。这时公司很自然的想到要有自己的产品。于是开始产品的立项了。

另外一种公司则完全不是这样。他们不是在某个行业做过多少项目，甚至根本没有做过一个项目，就要雄心勃勃的去做产品。这种情况每天都在发生。他们以前可能做系统集成的，可能卖硬件的，或许根本就不是IT行业的，或者恰好做了一个项目，现在他们要进军软件行业了，所以急切的要做出自己的产品去打市场。于是他们在一番调查论证后，开始了产品的立项。

在这两种情况下，可以明显的看得出前一种公司的基础要好得多，成功的几率也要大多多。但这并不表明后一种就会失败。在目前阶段关键是看他有没有全面的调查论证，进入这个软件行业，做这个产品是否可行。很多产品的失败，从一开始就注定的了。公司没做过多少认真的论证就匆匆开始了。软件行业，产品开发都有着自身的很多规律，如果公司的决策层、领导层没有经验，也没有去学习，拿着别的行业的经验去套用它，那失败也就不远了。举个简单的例子，软件开发中人力资源是最重要的。软件开发人员的薪水在各个行业中是算非常高的了，特别对于有丰富经验的人才更是与此。从传统行业过来的领导层如果不明白这点，也就找不到优秀的人才了。

无论哪种公司，他们在做产品立项时都要做好以下的心里准备：

?       软件产品开发投资是很大的，特别是对哪些想做大型的、优秀产品的公司。

?       软件产品开发周期也是比较长的。两、三年做一个产品是很常见的。不要认为半年就可以做一个很好的产品

?       软件产品是很容易失败的。既有可能产品开发不出来，也有可能没有市场。

如果一个公司没有这些心里准备，那结果就很可能失败。为什么这么说，以我的亲身经历来说吧。我曾经做过的一家公司，主要业务是做系统集成的。后来开始了一个物流软件的产品开发。在2000年左右，物流行业软件刚刚兴起，也算是一个比较好的方向。公司组建了一个开发团队，开始了长达两年的曲折的研发过程。由于在研发过程中遇到的种种问题，无法给公司领导层一个明确的结果，在研发开始初见曙光的时候，公司高层终止了这个产品。公司的高层忍受不了大量的投资和过长的时间。任何想做产品的公司都一定要有这些心里准备，要充分估计投资额和研发周期。

假设公司经过了充分的论证，也有了一定的投资和时间预算，产品立项了。但这只是一个良好的开端，因为下面的任何一个过程的失败，都有可能导致全盘皆输。

二、团队构建

产品立项后，就要开始组建研发团队了。软件开发是一个既要高度协作、又有独立创造的智力活动。所以人的因素是关系到产品开发能否成功的一个重要方面。应该说产品能否研发成功，研发团队的合理构建是关键性的。一个公司的领导层或许没有多少软件研发的经验，但必须要保证能构建一个合理的研发团队。就点很容易理解，就是让合适的人去做合适的事。不过反过来说，如果领导层没有软件研发的经验，那也很难构建一个合理的团队。那怎样构建一个好的团队呢？这个问题没有一个非常普遍的答案。各个产品的规模、技术难度都不相同，答案也不一样。

我们时常看到的情况是，公司会任命一个研发经理或叫PM,负责整个研发过程。于是问题就出来了。这个PM是负责管理工作还是技术工作，或者两个都一起负责？怎样规定PM的职责权限？如果没有对这个问题的明确答案，那危险就随之而来的。就来我的经历过的来说吧。

在离开上一家公司后，我来到另一家软件公司做网上教育平台的产品研发。前期阶段可以说没有一个专职的项目经理，管理工作基本上由一个做技术的Team Leader（架构师）负责，虽说也有不少问题，但大家基本上还是团结在一起安步就班的工作。后来公司为我们团队招来一个PM，此君是海龟派，在国外、学习工作好几年，也有技术背景。我们对他也充满期待。没想到过了不久，他居然把我们的Team Leader给开了，找了一些大家都不认可的理由。并自任技术负责人，对我们的大部分的技术方案都持否定态度，并严厉要求我们服从他的技术领导。如果他精通技术也就罢了，关键是他的技术一点也不怎样，还自我感觉良好。那最终的结果可想而知了。产品基本上失败，技术人员纷纷跳槽，最后，这个 PM也只得走人了。

这样的故事每天都在发生，大量的技术人员在抱怨领导不懂技术，瞎指挥。在我的案例中，可以明显的感觉到，公司对这个PM没有明确的职责划分，或者这个PM没有摆正自己的位置。这个PM应该做做管理工作，而不是负责技术。

做软件开发的都知道，一个团队中一般都有一个技术领导，或者叫架构师（Architect）。 那他和PM怎样划分职责？

如果要开发的产品规模比较大，比如人员数达到10人以上。这时面临的管理、组织工作比较多，公司应该考虑起用一位专职的PM来负责这方面的工作。他的主要工作包括人员招聘，提供开发团队所需资源，制定计划，监督实施等，同时，他应该是一个能够鼓动士气，懂得调动员工积极性的亲善的领导人，对作为一个PM的职位来说，个人的素质和性格应该具有更决定性的意义，他主要工作是为研发团队提供一切必要的服务，监督的作用应该包含其中。在这样的团队里，必须存在一位架构师来全面负责技术工作，他有权独立决定技术方案，他与PM的关系是团结与合作，而不是领导和被领导，架构师应该得到PM应有的尊重，而这点在中国很难做到。很多PM干涉架构师的技术工作，甚至起而代之，造成团队之间的混乱。上面的案例正是说明了这一点。架构师一般都是有一点完美主义，他总是希望看到产品做得更加出色，但这是否让产品开发走向不可控制的地步？事实上，架构师要对现实情况作出妥协（如时间、资金的限制），也就是对PM作出妥协。如果说PM代表时间、资源的现实主义，那么架构师就代表着完美的理想主义，他们就是在不断的合作、妥协中共同推动产品的发展。

对于开发的产品规模较小，也可以完全不设置专职的PM。设置一位Team Leader，他既负责整个技术、也同时负责团队的管理工作。如果认为负担较重的话，可以为Team Leader配置一位秘书（项目管理人员），他的主要功能是辅助Team Leader做一些管理方便的工作。如人员招聘的准备工作、开发计划的监督等等。

当团队合理的构建之后，下面的就进入了产品研发的核心流程了。

三、业务建模&需求分析

前面的过程更多的是由企业领导层决定的，当我们技术人员进入这个团队时，只能祈讨已经有了一个好的开始：公司下定决心要研发这个产品，有一个优秀的、明白自己职责的PM。现在已及下面的所有流程都和技术人员（包括需求人员）密切相关，是技术人员决定着产品成败与否的时候了。

无论做产品还是项目，第一步做需求分析，这一点无须置疑。几乎每一个做软件的都知道，需求的重要性。可是为什么那么多的产品或项目最后失败的主要原因是需求问题呢？

在软件研发中，产品的业务需求比项目的业务需求更难以确定。产品一般面对的是某个行业的通用需求，涉及的客户面更广，合理的提取这些需求以形成更通用的产品本身就是一件很困难的工作。对于一些以前没有这些行业经验的软件公司来说，这就更困难了。很多公司真因为没有很好去做需求分析的工作而导致产品的失败。在我以前做物流的那家公司里，也是犯了这样严重的错误。我们当时对物流行业并不熟悉，也不能很好的把握业务需求，产品研发在来回反复的过程中消耗了大量的时间与精力。

对于这个问题的解决，几乎所有的软件工程方法都提出了好的方案：引入领域业务专家（Domain Expert）。我们的研发团队中，一定要有这样的角色，即使我们没有这样一个专职人员，但一定要有人扮演类似的角色（例如架构师）。业务专家可以和架构师一起进行业务建模的工作，而架构师则偏重于技术方面，把业务模型转化成系统需求，按照RUP的流程来说，就是最终变成一个个Use Case。而一个好的业务专家是非常难得的，这就是为什么很多公司有这个意识而没有做好需求工作的重要原因：由于资金、时间等各方面的限制，他们最终放弃了这一步，而把希望寄托在架构师或其他开发人员身上，而这其中的风险就可想而知了。

也有很多公司没有业务专家，而把这个角色附加给架构师了。他们要求架构师既要精通业务，也要精通技术。而现实中，这样的人凤毛麟角，属于可遇而不可求的那一类。所以在这类角色没有很明确分开的产品研发中，得到的东西要么是需求方面做得不够好，要么在软件架构方面不令人满意。

怎样最大程度保证需求的合理？我个人认为做一个产品的界面原型是一个好的方法。这一点在做一个基于browser的应用系统时更可行：根据业务需求做出整个的页面原型，这样的页面也许很粗糙，后台也不需要任何的程序运行，但可以根据这些页面元素及之间的流程来验证业务需求是否合理、正确。这种方法应用到项目开发（相对于产品）中，可以和客户一起验证需求，经过几次反复，可以比较准确的理解、把握客户的真实需求。这样的工作耗费时间不多，但却能起到很大的作用。

四、架构设计

如果需求做好的话，可以说这个产品基本上能够得以出笼，但是否称得上品质优秀，则看架构设计工作做的怎样了。一个好的产品除了满足客户的业务功能外，还要满足一些非功能性的需求：系统性能、可用性、可管理性、可靠性、可扩展性、安全性等等。

正是因为面对这些众多问题，在这一过程中，架构师很容易走向极端。最常见的两种极端情况：（1）过分追求完美。（2）做出来就行，不考虑软件品质。

作为一个系统架构师，很多人具有完美主义的倾向。他们不断的考虑系统的性能、可扩展性、安全性，技术的先进性等等。他们最喜欢说的的词：组件性、通用性、扩展性等等。所以他们不断的修改架构，不断的冒出新的思想，采用新的技术。而这一切走向极端就会让研发陷入不可控制的地步。在我做物流和教育平台产品的时候，都遇到了这样的问题。架构师希望产品做得更大，满足更多的业务需求，同时又希望几乎每个业务模块组件化，具有更多的通用性，采用尽可能新的技术。最终造成计划的一拖再拖，让公司领导层丧失信心。

第二种情况在一些规模较小的产品研发中也很常见。技术领导人在时间、资金或PM的压力下基本上放弃了软件品质的追求。他们只希望在规定的时间内尽快做出一个东西就行。他们基本上不太考虑组件性、扩展性等等。这样做出来的产品和项目也就差不多了，因为他的通用性、扩充性太差。

可以看出，这两种情况都可能导致产品的失败。第一种总是想一口吃成一个胖子，他们忽略了软件开发的跌代性，软件总是在不断的跌代、更新中，螺旋式上升发展的。而第二种则是技术人员的悲哀，他们没有条件去追求软件的品质，只能寄希望于产品的下一个版本。事实上，没有前一个版本良好的框架，新的版本要想做好，几乎是重新开发。

所以一个优秀的架构师，既要不放弃心中的完美主义的理想，又要对现实做一定程度的妥协，在这种平衡中，领导团队进行技术开发。事实上，在中国软件产业的现阶段，急功近利的公司太多了，他们不会提供更多的条件、更多的空间让架构师去实现一个优秀的产品。这是我们所有做软件技术人员的悲哀，这是所有想走向、或正在架构师岗位上的人员的悲哀。

在软件产品开发的这一阶段，除了以上的情况，还有许多问题同样会导致产品的失败。

例如公司对软件工程的理解和掌握。软件工程强调使用过程来保证项目的成功，一般都会提出一整套的理论，如一些核心流程、步骤、方法、规则等等，例如RUP,XP。有很多项目经理、架构师和软件公司的高层都希望去使用这些方法，以保证项目、产品的成功。特别是公司的上层领导，他们只能通过这种方法来保证对项目的控制，所以特别热衷于实施这些方法。然而事实上呢？。大家都常有这样的经历：为了文档而写文档，写出来的文档基本上可以扔进垃圾箱，没有任何作用了。我这样说，并不认为软件工程有什么不好，关键在于你怎么去使用它。软件工程是一门实践性很强的学科，需要我们根据不同的现实情况不断的调整、实施，而不是照本宣科的一些教条。最怕遇到这种情况：一些领导或项目经理读了几本软件工程的书，自以为找到了灵丹妙药，就开始在项目中强力实施。比如制订一些步骤、计划，在什么什么时间，达到什么什么成果，要写什么什么样的文档等等。在我以前做教育软件产品中就充满了这种倾向。了在某为一时间交出架构设计文档，我们大部分时间不是去考虑、验证架构，而是为了写出这份文档。结果是，到我们要去实现时，发现根本行不通，整个架构存在严重的问题，到这个时候再回头重做设计，代价太大了。个人感觉是，要合理的使用一些软件工程理论，需要项目经理、架构师有丰富的实践经验，能够根据不同的产品研发情况，制订自己的一些确实可行的方法。软件工程是一些通用的理论，从来而且应该是可以灵活裁减的。

四、其他步骤

  如果说上面的步骤都很好的做到了，那产品应该说基本上成功了。有了一个合理的的架构设计，那么详细设计和编码应该不是一个问题，这只需要我们的软件工程师的努力就可以了。当然测试是很重要的，但基本上不会导致产品的研发失败。

作者后记：在做过几个项目，经历过一些失败之后，我把自己的一些想法写下来。这篇文章文字比较乱，基本上想到哪写到哪。我所碰到的问题，很多做软件的朋友也时常碰到，在抱怨了太多之后，我决定把它写下来。在国内做软件太困难了，如果你对软件还有一些理想主义的话，那你就太痛苦了。

设计模式之Factory

定义:提供创建对象的接口.

为何使用?
工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说是随处可见。

为什么工厂模式是如此常用？因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A() 工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑实用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。

我们以类Sample为例， 如果我们要创建Sample的实例对象:

Sample sample=new Sample();

可是，实际情况是，通常我们都要在创建sample实例时做点初始化的工作,比如赋值 查询数据库等。

首先，我们想到的是，可以使用Sample的构造函数，这样生成实例就写成:

Sample sample=new Sample(参数);

但是，如果创建sample实例时所做的初始化工作不是象赋值这样简单的事，可能是很长一段代码，如果也写入构造函数中，那你的代码很难看了（就需要Refactor重整）。

为什么说代码很难看，初学者可能没有这种感觉，我们分析如下，初始化工作如果是很长一段代码，说明要做的工作很多，将很多工作装入一个方法中，相当于将很多鸡蛋放在一个篮子里，是很危险的，这也是有背于Java面向对象的原则，面向对象的封装(Encapsulation)和分派(Delegation)告诉我们，尽量将长的代码分派“切割”成每段，将每段再“封装”起来(减少段和段之间偶合联系性)，这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。

在本例中，首先，我们需要将创建实例的工作与使用实例的工作分开, 也就是说，让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。

这时我们就需要Factory工厂模式来生成对象了，不能再用上面简单new Sample(参数)。还有,如果Sample有个继承如MySample, 按照面向接口编程,我们需要将Sample抽象成一个接口.现在Sample是接口,有两个子类MySample 和HisSample .我们要实例化他们时,如下:

Sample mysample=new MySample();
Sample hissample=new HisSample();

随着项目的深入,Sample可能还会"生出很多儿子出来", 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的.

但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.

工厂方法
你会建立一个专门生产Sample实例的工厂:

那么在你的程序中,如果要实例化Sample时.就使用

Sample sampleA=Factory.creator(1);

这样,在整个就不涉及到Sample的具体子类,达到封装效果,也就减少错误修改的机会,这个原理可以用很通俗的话来比喻:就是具体事情做得越多,越容易范错误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,范错误可能性就越少.好象我们从编程序中也能悟出人生道理?呵呵.

使用工厂方法 要注意几个角色，首先你要定义产品接口，如上面的Sample,产品接口下有Sample接口的实现类,如SampleA,其次要有一个factory类，用来生成产品Sample，如下图，最右边是生产的对象Sample：

进一步稍微复杂一点，就是在工厂类上进行拓展，工厂类也有继承它的实现类concreteFactory了。

抽象工厂
工厂模式中有: 工厂方法(Factory Method) 抽象工厂(Abstract Factory).

这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象Sample,如果我们还有新的产品接口Sample2.

这里假设：Sample有两个concrete类SampleA和SamleB，而Sample2也有两个concrete类Sample2A和SampleB2

那么，我们就将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现，下面就是将上例中的Factory拓展成抽象工厂:

从上面看到两个工厂各自生产出一套Sample和Sample2,也许你会疑问，为什么我不可以使用两个工厂方法来分别生产Sample和Sample2?

抽象工厂还有另外一个关键要点，是因为 SimpleFactory内，生产Sample和生产Sample2的方法之间有一定联系，所以才要将这两个方法捆绑在一个类中，这个工厂类有其本身特征，也许制造过程是统一的，比如：制造工艺比较简单，所以名称叫SimpleFactory。

在实际应用中，工厂方法用得比较多一些，而且是和动态类装入器组合在一起应用，

举例

我们以Jive的ForumFactory为例，这个例子在前面的Singleton模式中我们讨论过，现在再讨论其工厂模式:

因为现在的Jive是通过数据库系统存放论坛帖子等内容数据,如果希望更改为通过文件系统实现,这个工厂方法ForumFactory就提供了提供动态接口:

private static String className = "com.jivesoftware.forum.database.DbForumFactory";

你可以使用自己开发的创建forum的方法代替com.jivesoftware.forum.database.DbForumFactory就可以.

在上面的一段代码中一共用了三种模式,除了工厂模式外,还有Singleton单态模式,以及proxy模式,proxy模式主要用来授权用户对forum的访问,因为访问forum有两种人:一个是注册用户 一个是游客guest,那么那么相应的权限就不一样,而且这个权限是贯穿整个系统的,因此建立一个proxy,类似网关的概念,可以很好的达到这个效果.  

看看Java宠物店中的CatalogDAOFactory:

CatalogDAOFactory是典型的工厂方法，catDao是通过动态类装入器className获得CatalogDAOFactory具体实现子类，这个实现子类在Java宠物店是用来操作catalog数据库，用户可以根据数据库的类型不同，定制自己的具体实现子类，将自己的子类名给与CATALOG_DAO_CLASS变量就可以。

由此可见，工厂方法确实为系统结构提供了非常灵活强大的动态扩展机制，只要我们更换一下具体的工厂方法，系统其他地方无需一点变换，就有可能将系统功能进行改头换面的变化。

设计模式之Singleton(单态)

定义:
Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。

在很多操作中，比如建立目录 数据库连接都需要这样的单线程操作。

还有, singleton能够被状态化; 这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能synchronize的安全自动加1，如果你要把这个数字永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。

另外方面，Singleton也能够被无状态化。提供工具性质的功能，

Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbage collection）。

我们常常看到工厂模式中类装入器(class loader)中也用Singleton模式实现的,因为被装入的类实际也属于资源。

如何使用?
一般Singleton模式通常有几种形式:

第二种形式:

使用Singleton.getInstance()可以访问单态类。

上面第二中形式是lazy initialization，也就是说第一次调用时初始Singleton，以后就不用再生成了。

注意到lazy initialization形式中的synchronized，这个synchronized很重要，如果没有synchronized，那么使用getInstance()是有可能得到多个Singleton实例。关于lazy initialization的Singleton有很多涉及double-checked locking (DCL)的讨论，有兴趣者进一步研究。

一般认为第一种形式要更加安全些。

使用Singleton注意事项：
有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的。

我们以SUN公司的宠物店源码(Pet Store 1.3.1)的ServiceLocator为例稍微分析一下：

在Pet Store中ServiceLocator有两种，一个是EJB目录下；一个是WEB目录下，我们检查这两个ServiceLocator会发现内容差不多，都是提供EJB的查询定位服务，可是为什么要分开呢？仔细研究对这两种ServiceLocator才发现区别：在WEB中的ServiceLocator的采取Singleton模式，ServiceLocator属于资源定位，理所当然应该使用Singleton模式。但是在EJB中，Singleton模式已经失去作用，所以ServiceLocator才分成两种，一种面向WEB服务的，一种是面向EJB服务的。

Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类 线程 内存等概念有相当的了解。

进一步深入可参考：

Double-checked locking and the Singleton pattern

When is a singleton not a singleton?