软件产品开发，为什么失败
转自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。有很多项目经理、架构师和软件公司的高层都希望去使用这些方法，以保证项目、产品的成功。特别是公司的上层领导，他们只能通过这种方法来保证对项目的控制，所以特别热衷于实施这些方法。然而事实上呢？。大家都常有这样的经历：为了文档而写文档，写出来的文档基本上可以扔进垃圾箱，没有任何作用了。我这样说，并不认为软件工程有什么不好，关键在于你怎么去使用它。软件工程是一门实践性很强的学科，需要我们根据不同的现实情况不断的调整、实施，而不是照本宣科的一些教条。最怕遇到这种情况：一些领导或项目经理读了几本软件工程的书，自以为找到了灵丹妙药，就开始在项目中强力实施。比如制订一些步骤、计划，在什么什么时间，达到什么什么成果，要写什么什么样的文档等等。在我以前做教育软件产品中就充满了这种倾向。了在某为一时间交出架构设计文档，我们大部分时间不是去考虑、验证架构，而是为了写出这份文档。结果是，到我们要去实现时，发现根本行不通，整个架构存在严重的问题，到这个时候再回头重做设计，代价太大了。个人感觉是，要合理的使用一些软件工程理论，需要项目经理、架构师有丰富的实践经验，能够根据不同的产品研发情况，制订自己的一些确实可行的方法。软件工程是一些通用的理论，从来而且应该是可以灵活裁减的。
四、其他步骤
如果说上面的步骤都很好的做到了，那产品应该说基本上成功了。有了一个合理的的架构设计，那么详细设计和编码应该不是一个问题，这只需要我们的软件工程师的努力就可以了。当然测试是很重要的，但基本上不会导致产品的研发失败。
作者后记：在做过几个项目，经历过一些失败之后，我把自己的一些想法写下来。这篇文章文字比较乱，基本上想到哪写到哪。我所碰到的问题，很多做软件的朋友也时常碰到，在抱怨了太多之后，我决定把它写下来。在国内做软件太困难了，如果你对软件还有一些理想主义的话，那你就太痛苦了。