图文：群硕软件大中华区软件开发总监邵荣演讲

图为：群硕软件大中华区软件开发总监邵荣演讲(骆磊 摄)

　　2007年12月8-9日，2007中国软件技术大会在北京举行。中国软件技术大会自2003年以来已连续成功举办四届，秉承“弘扬个性、促进创新、引爆争鸣、激发活力”的宗旨，目前已成为国内技术水平高，领域覆盖面广，具有极大影响力的年度交流盛典。

　　图为：群硕软件大中华区软件开发总监邵荣演讲(骆磊 摄)

　　以下为其演讲全文：

　　邵荣：非常荣幸有机会跟在座的同行进行探讨，而且我也觉得特别荣幸，今天能够跟行业里面传奇的前辈倪光南院士同台跟大家分享经验。今天我的演讲 主题，在之前我们收到演讲通知的时候，觉得非常矛盾，因为好多东西可以讲，最终我们换了一个主题，我们想要站在软件开发的另外一个角度，换一种形式跟大家分享一些平时大家关注不是特别多的东西。

　　首先讲一个故事。有一个推销员，刚刚开始进入行业，他是一个推销吸尘器的推销员，他在一开始的时候，非常不成功，为什么？他去拜访客户的时候就敲门说：张太太，你应该买吸尘器，我这个东西非常棒，获得过国际金奖的，你应该买。但是没有人听他的。开始的时候他觉得自己不够努力，他就更努力，从早上六点钟开始推销到晚上十点钟，他找各种各样的推销指南来学习阅读，包括寻找很多的销售工具例如印刷品小册子等来帮助他的销售。过了一阶段之后，他逐步开始发现一些门道，他推销前会去分析最有消费能力的小区是在北京的哪些小区，然后针对这些小区进行推销。推销时候也更有针对性，例如他发现这家人家可能养狗，他可能跟太太聊家常说，你这条狗很可爱，不过我看到它可能会掉毛，张太太也抱怨说狗会掉毛，经常把沙发弄的非常脏，这个时候推销员会说我这有一个工具可以帮助你做清洁，您看要不要。这样他的成功率提高了很多，也就是说他会逐步花时间分析客户的需求来针对客户需求的服务。很多年后，他成为行业里面的销售大师，那时发生了什么事情呢？哪怕那个时候他不再推销吸尘器，他只是在推销其他产品，其他品牌，例如

微波炉，他看到张太太时候，就跟张太太说我有一个微波炉特别适合你，你应该买一个微波炉，张太太可能连什么品牌什么功能都没有问，就直接购买了，为什么？因为和整个推销员认识很长时间以后，这个推销员非常清楚张太太需要什么，张太太对他已经有了长期的信任，知道这个推销员每次都会替她着想，他每次给她带来的东西都应该她需要的东西。

　　这是一个推销员的成长过程，总结一下他的成长，在第一阶段他通过个人修炼来成长。到了第二阶段他开始关注客户，他不再把整个视野放在自己的身上，而是关注用户。另外很多事情，例如作市场分析，客户行为分析等等，他必须依靠集体和团队的力量来一起做。第三阶段，他开始以用户作为核心，总去考虑什么是客户需要的核心价值。最关键是他开始关注长期的和客户之间的信任，而不是做一票就走。

　　这个故事我想要说的是，这个过程跟我们做软件开发过程非常类似，程序员在开始时候关注个人修炼，对于某某某语言、某某某指南、某某某工具特别关注；到了下一个阶段会考虑客户的业务需求；到最后会花时间构建和客户的长期信任。这些回头我会有进一步的阐述，分开来谈。

　　下面我拿一张行业里面非常著名的卡通图做一个细说。第一张图是客户解释说“这是我想要的”(10张小的卡通图，分别指代了10个不同的阶段)：一个三层的木板秋千被吊在一棵大树的右边；项目经理理解的时候已经开始过滤和曲解了一些需求：秋千变成了一层，挂到了大树的中间；接下这个需求被层层传递给下面一个阶段，例如分析员、程序员等。有意思的是，中间的某个阶段，咨询顾问对客户需求进行解释的时候，秋千的三层木板会变成一个沙发，他告诉客户说这个沙发秋千特别的舒服。接下来，我们程序里面的项目文档是怎么映射需求的？是一片空白。软件到安装发布之后，不能用；而向客户收费的帐单好像高速的过山车，呼啸而来。到了支持阶段，客服对用户进行支持的时候，当客户电话过来的时候，他在电话里询问客户“你的机器重启了吗？””，“你的软件有没有重装。” 。而最后一张图没，最终客户真正想要的东西其实没有那么复杂，他只想在树上挂个轮胎作为一个秋千。有意思的是他自己都没有能描述清楚他的需求究竟是什么。

　　我们看到那些卡通图片所代表的阶段，每个阶段向下个阶段过渡时候，都因为那个阶段的人对于上一个阶段的需求信息的误解和丢失而发生偏差，最后导致了用户想要的东西和最后开发出来的软件非常不一致。每个阶段的误解和信息丢失都会导致软件失败率上升。我这里有一份报告，在英国CHAOS的报告跟踪94年、01年、03年的成功率，94年的成功率是16%，01年时候软件项目的成功率是28%，04年的时候项目成功率大概是占31%。

　　如果仔细看一看这些数据，到目前为止，全世界的软件成功率按照每年1.7%的速度做直线上升。按照这个比例，一直要到2014年左右，平均做两个软件项目才有可能有一个项目是真的成功的。也就是说行业里面的软件成功率现在还非常低。

　　现在要问一个问题，究竟是谁的错？从技术人员的角度来讲，绝大多数情况，都会说这是客户的问题。为什么？因为客户需求不断在变化，而客户他也不知道自己想要什么。

　　从软件产业角度来说，我们也大量的花时间和精力来研究方法论：从项目管理方法到软件流程，到新的语言、新的架构、软件模式、软件通用平台，通过不同的手段和方式都希望来解决这个问题。但是到现在为止，每年提高1.7%的软件项目成功率并不能让人满意。

　　我们换一个视角看整个软件开发过程里发生了什么事。前面那张卡通图看起来很搞笑，但是里面包含了一个很严肃的话题，信息的误解和丢失是在不同人和不同阶段的沟通中发生的，而且非常难以避免。回头会就这个话题展开来谈。

　　另外一点，在软件企业里面，做软件项目的时候，我们大概会花超过一半的时间去重复构建行业里面其他人已经构建起来的东西，我们在重新发明轮子。

　　最后一个方面，我们的软件从出生开始，它的内部其实已经构建了低质量的基因。稍后会更进一步来解释这个问题。

　　我们刚才所谈到的，在软件项目开发的每一个阶段，其中沟通过程就是是传递用户体验。为什么这么说？用户在开始想做一个秋千的时候，对他来讲并不知道这是木板、还是钢筋做的，用户只是描述一种体验，用户跟设计师说我想有一个秋千，能够晃来晃去，而且很牢固，他不会说他需要用什么材料或者多粗的绳子。

　　从软件角度来说，用户所面对的软件系统，他并不知道也不关心后台用什么样的语言、中间件、开发平台、软件开发流程。对于用户来说，他只知道电脑一按有一个程序出来；或者手机上可以发一个短消息出去。同样道理，用户认识互联网怎么来感知？例如对你的父母来说，他们是通过家里的电脑、手机和电视等设备来感知互联网是怎么回事的，而不是内部的芯片或者语言。

　　对用户宣传你的技术多先进，用户其实不关心。用户关心的是用户体验。最近几年开始，用户体验作为核心，已经成为一种趋势。现在给大家看的这张图是iPhone，电话的功能并不算强劲，但是全球非常畅销,这就是关于用户体验的一个很好的例子。现在很多企业都意识到了用户体验的重要性，再加上整个产业的技术发展和成熟，这些技术的成熟也使在软件项目中以用户体验作为驱动的沟通方式、开发方式，成为一种可能。

　　既然道理这么简单，为什么软件开发到现在为止，还是有这么多问题呢？为什么每个阶段不同人沟通的时候都出现信息丢失和曲解呢？因为在机器和人之间抽象方式是有差异的。举一个例子来说，用户在使用网上相册的时候， 希望能够共享照片、下载照片，能够做数码照片的打印。而对于程序员要实现这个网上相册网站来说，他们面对的是一段一段的代码。所以尽管程序员想为最终用户构建一个非常完美的世界，但是程序员生活的世界里面，多数时间是面向代码、面向机器的，他们并不是真正的面向用户体验，他们的关注点更多在更底层的实现。

　　另外一个例子，做软件项目的时候，需要跟用户进行需求确认，我们交付给用户一个几百页需求说明书，密密麻麻的文字，让用户签名，这是就是用户所想要的吗。用户可以签字，但是他真的能确认这几百页需求就是真的他需要的东西吗？文字很困难做到精确地传递信息。例如在需求文档里有一行字写到：“界面要求大方美观”，程序员理解的大方美观跟用户所理解的大方美观一定不同，通过这样方式的沟通如果不出错才怪呢。

　　有一种更好的办法，以用户体验作为核心，站在用户的角度、根据用户的理解(而不是程序员的理解)来进行软件开发，中间的一个工具是使用故事板(Story Board)，不断根据用户的反馈进行修正。以用户为中心好像是每个企业所喊的口号，有没有什么落地方法论来指导具体怎么做？有一个基本原则，不能由系统内部的交互来进行设计的主导，而实应该从系统外部的用户与系统之间的交互进行主导。例如 iPhone的设计，是没有办法把一个设计师关在门里面，闭门造车，最后把iPhone推出来的。他必须把时间花在挖掘最终用户的体验需求来完成，然后由这种体验需求来主导整个的设计。

　　在传统的软件开发方式里面，也有通过快速原型来进行设计主导的，和现在所说的以用户体验作为核心的开发方式有什么显著的区别呢？现在有很多的公司已经在使用迭代开发的方式，和迭代式用户体验驱动的开发模式有什么区别呢？传统方式下，用户往往要到软件开发的最后阶段，等到软件真正做出来才知道这个软件怎么回事，才会体会他会怎么来用这个软件系统，但是那个时候已经迟了。

　　而用迭代式的用户体验驱开发模式时候，在一行代码没有写的时候，已经有了完整的故事板来和客户进行沟通，每次用户跟用UX小组进行交互的时候， 不断的在反馈、优化和加深对于软件系统理解。而在使用快速原形开发的过程中，关键点是把很多的细节去掉快速来让用户知道“大概”系统会师什么样子。一个例子，以前在帮俄罗斯的一个客户做软件设计，系统里面有一个触摸屏作为交互屏幕，在俄罗斯冬天特别冷，多数时候在户外都要戴手套。这个细节，不过通过用户体验驱动方式:可能会被忽略，带着手套的手指会比不带手套的时候大很多，在屏幕上点击的时候，屏幕上的按钮如果不够大，带手套的手指触摸界面时候会没有办法精确的操作。这个细节如果用传统的开发方式可能要到很晚会发现，到了软件发布出去之后，再被退回来反工。

　　更高层次的软件重用。我们花很多时间谈重用问题，里面包括数据的重用、逻辑的重用、界面的重用；另外一个重用角度是代码的重用、API的重用、构件库的重用、工具集的重用。这里的问题是这样的重用方式的层次还是太低，从真正的重用角度来讲，最近几年来，成功的企业是已经开始了核心

竞争力的重用，而不是简简单单的代码级的重用。核心竞争力的重用包括了对业务逻辑、业务行为，还有最关键的对于知识的重用。以前的系统设计都是以数据作为核心；把数据按照一定的方式组织起来叫做信息；再把信息真正的利用起来，能够变成帮助你解决问题的信息，这就是知识。目前产业里面对于知识的重用还比较差，就是从全世界软件行业的角度来讲，做的也远远不够。

　　由于开源软件的兴起，使我们上面说的这些更高层次的重用方式成为了可能。

　　第一个例子是Alfresco，企业内容管理(ECM, Enterprise Content Management)，或者是内容管理系统(CMS，Content Management System)。Alfresco的CTO是之前的Documentum公司的CTO，Documentum被EMC以17亿美金的价格收购了。这个开源软件把企业或者网站需要进行内容管理的常用操作都包括了，多数企业或者网站完全可以直接用它来进行数字内容的管理，而无需另外开发一套。

　　Compiere，这是一个开源的ERP软件，全球超过120万次下载。在SAP早期版本里面可以找到Compiere的源代码。它的创始人非常精通ERP和CRM，这个开源ERP软件已经预置很多行业、很多垂直领域的业务逻辑。

　　另外一个例子是Pentaho，开源商务智能软件。它的创始人均来自AppSource，后来被Arbor收购，然后被海波龙收购，最后Oracle花了33亿收购了海波龙。这个开源软件里面包括常用的商务智能各个模块和功能。

　　最后一个开源的例子是网络会议的DIMDIM，它对应的商业公司是WebEx。

　　很多的企业在使用开源软件，是因为它是免费。但是从另外一个角度来说，企业应该从更高的抽象层次来进行考虑和使用开源软件，进行应用级的重用，这样的更大好处是加速软件系统的构建和交付，同时可以让企业更多的时间关注系统的核心价值。

　　说了这么多，大家也许会说你能不能够给我几个落地的例子，关于你说的高效沟通，用户体验驱动和软件重用。那么就以我现在的公司群硕软件作为样本来研究一下，我们团队自己做的来呼应我刚刚说的应该更有参考价值。

　　群硕到现在为止成立了四年多时间，现在90%以上都是北美的高端客户，像微软、英特尔、摩托罗拉、EMC等公司。提供给客户一些完整的开发和测试软件服务。现在在全球员工有1300多人，中国员工1250左右。差不多每12个月到18 个月翻一番。在今年年初刚刚被入选到全球IT百强。在世界的软件产业里面，这个由中国人自己做的这张试卷，这个分数应该说还是不错的。

　　一个群硕内部的案例。在两年前，2005年6月底，我曾经带领一个团队从零开始做了一个基于PHP在先网络广告网站，五个月后，发布Beta版本的时候已经有300万的每日访问量。开始时候是5个技术人员。就在几天前，2007年12月1日，最新的统计是每天18亿次的访问量，做到了全球在开放是广告交易市场的第二名。现在中国团队大概是70人左右，在美国从开始到现在都是0个开发人员，全套系统从架构设计到最后发布，都是由中国团队完成的。我们预计还有三到六个月左右时间，这个网站会成为这个领域的全世界第一名。我们花三年左右时间打造全世界第一名的网站，从零开始，所有东西都是中国团队来做，这个成就还是应该可以让我们自己小小窃喜一下。

　　关于这个案例分享的最关键两点。第一，我们实实在在的通过用户体验驱动的模式来进行了开发。不是通过一个一个很长的周期，比如三个月或者六个月，之后才把软件发布出去，才让市场考验这个系统。我们总是用一个Beta版的方式来发布软件、进行不断更新，差不多每两个礼拜我们有一个产品质量的外部发布，测试后直接在互联网上做发布。第二，这个网站是基于开源软件和工具来构建的。其中除了Linux, MySQL和Apache外，重用了一些应用级的开源软件，其中包括了一个开源的广告引擎。虽然在项目开始八个月之后，我们把当中开源软件的广告引擎全部替换掉了，因为它的性能达不到要求。但是这个过程中，如果开始就是我们自己开发，而没有重用了这个广告引擎的商业逻辑和历史知识经验，这个项目绝对不能这么快的建起来。

　　第三个大的话题是关于软件项目的内建的“低质量”。

　　也通过一个故事来说明这个问题。从前张三和李四去考试，张三花了40分钟把自己的试卷做完以后，一遍都没有检查，直接交卷了；李四做完考卷后来来回回检查了20遍，直到考试结束的最后一分钟才交卷。张三和李四在平时学习态度不一样：张三同学每天在都一丝不苟的完成作业，将需要学习的知识点平时就很好的掌握，而李四同学经常不上课，作业抄抄了事，他也从来不花时间复习。考试结果，显而易见，张三的成绩毫无疑问比李四的成绩好很多，哪怕一遍都没有检查，试卷里面可能有粗心大意的错误，不会改变试卷的总体水平。而李四本来就很多的题目不会做，哪怕全部填满了，检查了20遍，照样是很差的成绩。

　　这个故事想说明了什么呢？在软件行业内部，做软件开发的人都有这样的倾向：首先把整个软件框架搭起来，把程序尽快的走通，以后再做测试。编码的时候，总觉得将来会专门有时间来做测试的，所以对于细节就没有那么关注。不知不觉之间，软件的低质量已经被构建在内部了。这个就好像一个平时不好好学习的学生，寄托希望在考试时候，对于试卷多检查几遍一样最后拿一个好分数，这样做不会改变软件的根本质量。请记住，测试是不能帮助软件项目来提高质量的！

　　举一个例子来说，一个六个月左右的软件项目到快交付了，你去问你的项目经理和开发人员：你们觉得软件系统里面还有什么问题？项目经理和程序员会告诉你说，我也不知道，应该差不多了，就是还有一些小问题。但是修正了了这些小问题后，又发现其他的小问题不断的冒出来，总是差一口气，总是有一些新的问题出现。谁都不知道这个系统里面还存在多少炸弹和问题，我们能够做的事情是把这个软件发布到最终用户那里，让最终用户作为实验品，帮助我们测试，提供给我们反馈，回头再修改。但是那个时候是以牺牲用户的满意度作为代价的。

　　这个问题这么普遍，怎么来解决呢？其实答案很简单，就好像张三考试一样，平时把每一步应该做的事情都做好，那么最后的结果，哪怕没有很多检查，都能够保证一个高质量。做项目的时候，软件内部每一个很小的功能，每个模块和模块连接的时候，都把里面该做的细节做好，这个系统会变得很牢固，哪怕到最后期的测试都不是很多，整体的质量也会远远高于行业产业里面的平均标准。

　　另外一个重要的观念，质量保证不只是QA人员的责任，而是是每一个人的事情，项目经理、分析师、设计人员，每个环节都必须把自己的工作做好，而且必须最大化的精确保留和传递客户的需求。这种方式看上去代价比传统方式代价很大，因为每个步骤都需要额外的力气来做好事情，但到最后，软件项目的开发质量会很高。一个例子来说，在群硕四年多，我们还没有一个案例是因为软件质量的问题导致项目的失败。当然，因为毕竟是软件，我们做项目也不可能总是100%成功，我们碰到过其他的一些原因而导致软件的延迟或着被取消过。例如客户的高层人事变动，对整个产品线进行取消等。

　　最后想总结一些在软件项目开发中里面的更重要的非技术因素。这些资料多数都是群硕内部培训的一些资料。

　　第一点是将个人的修炼提升成团队的修炼。

　　新手往往更关注自身的提高和修炼。而在国内的程序员也花很多时间做个人的修炼，而不是团队的修炼。个人修炼对于个人的成长的确有帮助，但是提高速度有限，因为你在孤军奋战。而且个人修炼对于中国软件产业的提高，贡献不是很大。这里给大家的一个案例， 在群硕内部，在Fix bug的时候，在群硕里面有三重境界。

　　第一重境界，如果发现程序里面有一个bug，工程师一定要修复完这个Bug同时检查过之后才离开公司，这样做好像已经很有责任心了。但是我们说他做到了Fix Bug的第一层境界，只是做到最基本的。

　　第二重境界，这个程序员在修bug的时 候，应该想到程序里面有没有类似的场景，有没有因为以前拷贝粘贴在软件的其他地方也可能有类似的状况，甚至是其他工程师可能在类似场景里面也可能出现这个问题，这个工程师会花时间研究这个Bug，会提醒可能犯同样错误的队友，让他也对这个问题引起注意。这样的话，同样的Bug在被发现出来之后，同类型的Bug都可以被捉出来。

　　第三重境界，项目经理这个层次至少要有这个素质：如果发现同样类型的错误或者bug连续出现三、四次的时候，需要分析一下根本原因是什么，比如说因为写这段代码的人编程水平不够，或者客户对这个功能的需求定义就是不明确。通过根本原因的分析，才有可能去解决真正问题。如果是那个程序员没有足够的编程水平，那他未来写的程序会继续出现这些问题，应该安排一个资深的程序员来教他、来帮他进行代码检查；如果是客户的需求不明确，不管程序员的水平再高，写的东西可能不是客户想要的，需要和客户进行确认。

　　关于Bug fix的三重境界，如果公司里面只有一个人或者几个人才有这样的态度，对于整个软件开发的水平提升有多大的帮助？这个必须成为整个团队的修炼，变成每个人都遵循的一种职业习惯，才可能对软件的开发质量有较大的提高。

　　第二点，关注团队

执行力而不是关注流程的本身。 我个人认为整个软件行业里面流程不是太少，而是太多了，我们花了太多时间关注流程的本身，而不是关注流程的执行上。很多的流程实施下去效果不好，不是因为流程本身，而是在团队的执行力上。

　　我也想通过一个故事来说明，关于猴子的民主。有四个猴子被关在铁笼子里面，笼子外面有一串香蕉，这些猴子都想去拿外面的香蕉吃，但是一爬到笼子边上去伸手拿香蕉，铁笼子就会通电，猴子就会被电击。一段时间之后，猴子养成了习惯，哪怕看到外面挂了香蕉也不会去拿，因为怕被电击。然后把其中一只猴子换出去，把一只没有经过电击的猴子换进笼子，这个猴子在一开始时候看到了笼子外面的香蕉，当然非常想去摘了，但是另外三只猴子就不干，因为那只新进来的猴子的行为会把它们三个猴子拖下水，被电击。所以新进来的猴子去采香蕉的时候，另外三个猴子会把它拖住一顿暴打。每次新的这个猴子有这个企图时候，就被一顿暴打。过了一个阶段，这个新的猴子也知道，去摘笼子外面的香蕉，会被暴打。然后又换了一个猴子进来，把原来三只被电击过的猴子其中一只换出去。同样的事情又发生了，唯一的区别是前面近来的那只猴子不知道为什么不能去摘香蕉，他只知道只要去摘香蕉，就应该暴打那个去摘香蕉的猴子。继续把剩下的两只被电击过的猴子替换出去，笼子里四个猴子都没有被电击过，但是它们之中没有人会去摘笼子外面的香蕉，因为它们知道，只要谁去碰那个香蕉，谁就会被暴打。

　　在我们的企业内部，高层往往有很多的政策都是很好的，很多的流程也是经过了深思熟虑出来的，但是到了最下面执行的时候，团队里面的工程师，是否经常也象那个没有被电击过的猴子，只知道服从，但是不知道为什么要这么做呢？

　　第三点，最核心的也是最困难是构建团队核心文化。同样用一个小故事来说明。某一个五星级酒店的服务员每天打扫房间的时候，会拿客户的脏衣服去洗。你的衬衫上的某个纽扣快掉了。这个服务员根本没有在意这个细节，她直接拿了衣服去洗好烫好放回来，纽扣已经掉了，你问她，她说不知道或者和你争执这个纽扣原来就已经掉了。在另外一个五星级酒店的服务员碰到这个情况就更进一步，她会仔细检查你的衬衫是否有纽扣松动了，如果有，她会让你签字确认说，将来这个纽扣掉下来不关她的事情。到第三个五星级酒店，同样的事情，那个酒店的服务员在拿走衣服去洗之前，会仔细检查纽扣是否会掉下来，如果是的，会把纽扣取下来，洗好衣服后，让裁缝把纽扣在再钉上去。作为客户，甚至不知道自己衣服的纽扣曾经会掉下来这件事情。

　　到了这样细节化的执行，简单的通过流程，通过责任心已经不能做到了，因为酒店培训服务员的时候，不可能把衬衫纽扣掉下来应该怎么办这样的细节事情都写下来让服务员背下来。要做到必须要有一种非常强的团队文化。整个团队对于个客户的满意度都非常在乎，对于团队的成功有高度的荣誉感，团队里面的老人对于新加入的新人会通过一种文化上的感染来影响他，而不是简单的让他跟随流程来做。在软件企业内部，到真正的后期打造与众不同的竞争力，最关键的是构建团队的核心文化。

　　最后用两句话来结束今天的演讲：

　　改变世界的力量，

　　不是来自于技术，

　　而是来自于怎样应用技术。

　　谢谢大家。