改变世界的力量，不是来自于技术，而是来自于怎样应用技术。因此，众多非技术因素对于改变软件项目成功率低下的现状有着极为重要的作用。它们或许会在未来成为大多数软件企业关注的重点。
在软件开发领域，有一张非常著名的卡通图，如下页图所示，它被分成了10个小图，第一张图显示的是客户希望得到的产品，即一个三层的木板秋千被吊在一棵大树的右边。
而在后面项目经理理解用户意图的时候已经开始过滤和曲解了一些需求信息: 秋千变成了一层，挂到了大树的中间; 接下来，这个需求被层层传递下去，例如分析员、程序员等。有意思的是，中间的某个阶段，咨询顾问对客户需求进行解释的时候，秋千的三层木板会变成一个沙 发，他告诉客户说这个沙发秋千特别地舒服。而最后一张图描述了最终客户真正想要的东西其实没有那么复杂，他只想在树上挂个轮胎作为一个秋千，也就是说他自 己都没有能描述清楚他的需求究竟是什么。
这里，每张卡通图片都代表了一个阶段，每个阶段向下一个阶段过渡的时候，都因为那个阶段的人对于上一个阶段的需求信息的误解而发生偏差，最后导致了用户想要的东西和最后开发出来的软件非常不一致。每个阶段的误解和信息丢失都会导致软件失败率上升。
项目成功率每年仅增长1.7%
英国有关机构在跟踪1994年、2001年、2003年的全球软件项目成功率的时候发现，1994年的成功率是 16%，2001年是28%，2003年的时候，成功率大概是占31%。如果仔细看一看这些数据，到目前为止，全世界的软件成功率按照每年平均1.7%的 速度上升。按照这个比例，一直要到2014年左右，平均做两个软件项目才有可能有一个项目是真的成功的。也就是说，整个行业的软件成功率现在还非常低。
现在要问一个问题，究竟是谁的错，从而导致了项目成功率如此之低？从技术人员的角度来讲，绝大多数情况下，都会说这是客户的问题。因为“客户的需求总是在不断变化”，而且“客户也不知道自己想要什么”等等。
从软件产业角度来说，我们也花了大量的时间和精力来研究方法论，从项目管理方法到软件流程，到新的语言、新的架构、软件模式、软件通用平台，希望通过不同的手段和方式来解决这个问题。但是到现在为止，每年提高1.7%的软件项目成功率并不能让我们满意。
让我们换一个视角来看整个软件开发过程里究竟发生了什么事。
前文提到的那张卡通图看起来很有意思，但是里面却包含了一个很严肃的话题，信息的误解和丢失是在不同人和不同阶段的沟通中发生的，而且非常难以避免。
而另外还有一点，在软件企业里面，做软件项目的时候，我们大概会花超过一半的时间去重复构建行业里面其他人已经构建起来的东西，也就是说，我们在重新发明轮子。
以用户体验为核心
其实，软件项目开发每一个阶段中的沟通过程都是传递用户体验的过程。为什么这么说？用户在一开始想做一个秋千的时 候，对他来讲，他并不在乎，也不知道是用木板做还是用钢筋做。用户只是描述一种体验，用户跟设计师说我想有一个秋千，能够晃来晃去，而且很牢固，这就够 了，他不会说他需要用什么材料或者多粗的绳子。
因此，我们应该以用户体验作为核心，站在用户的角度、根据用户的理解(而不是程序员的理解)来进行软件开发。其 实，以用户为中心已经是每个企业都在喊的口号，但有没有什么方法论来指导具体怎么让这种理念落地呢？这里有一个基本原则，就是不能由系统内部的交互来主导 设计，而应该由系统外部的用户与系统之间的交互进行主导。
核心竞争力的重用
下面我们再谈一下更高层次的软件重用问题。整个软件行业花了很多时间谈重用问题，里面包括数据的重用、逻辑的重 用、界面的重用等等。但是这种重用方式的层次还是太低，从真正的重用角度来讲，最近几年来，成功的是那些已经开始了核心竞争力的重用，而不是简简单单的代 码级重用的企业。核心竞争力的重用包括了对业务逻辑、业务行为的重用，还有最关键的，就是对于知识的重用。
开源软件的兴起，使上面说的这些更高层次的重用方式成为了可能。
很多企业在使用开源软件，因为它是免费的。但是从另外一个角度来说，企业应该从更高的抽象层次来进行考虑和使用开源软件，进行应用级的重用，这样做更大的好处是加速软件系统的构建和交付，同时可以让企业有更多的时间关注系统的核心价值。
软件质量不能只靠测试
软件项目的低成功率还与软件建设过程中的质量控制有密切关系。这里首先看一个小故事。张三和李四去考试，张三花了 40分钟把自己的试卷做完以后，一遍都没有检查，直接交卷了; 而李四做完考卷后来来回回检查了20遍，直到考试结束的最后一分钟才交卷。张三和李四在平时学习态度不一样: 张三同学每天都一丝不苟地完成作业，平时就将需要学习的知识点很好地掌握了; 而李四同学经常不上课，作业“抄抄”了事，而且也从来不花时间复习。考试结果，显而易见，张三的成绩毫无疑问比李四的成绩好很多，哪怕一遍都没有检查，试 卷里面可能有粗心大意造成的错误，但不会改变试卷的总体水平。而李四本来就有很多题目不会做，哪怕全部填满了，检查了20遍，照样是很差的成绩。
这个故事说明了什么呢？在软件行业内部，做软件开发的人都有这样的倾向: 首先把整个软件框架搭起来，把程序尽快地走通，以后再做测试。编码的时候，总觉得将来会专门有时间来做测试的，所以对于细节就没有那么关注。不知不觉之 间，软件的低质量已经被构建在内部了。这就像一个平时不好好学习的学生，寄希望于考试的时候，把试卷多检查几遍最后拿一个好分数。其实，这样做不会改变软 件的根本质量，仅仅依靠测试是不能帮助软件项目提高质量的！
例如，当一个六个月左右的软件项目到快交付的时候，如果去问项目经理和开发人员: “你们觉得软件系统里面还有什么问题？”项目经理和程序员大多数时候都会说: “我也不知道，应该差不多了，就是还有一些小问题。”
但是修正了这些小问题后，又发现其他的小问题不断地冒出来，总是差一口气，总是有一些新的问题出现。谁都不知道这 个系统里面还存在多少炸弹和问题，我们能够做的事情就是把这个软件发布到最终用户那里，让最终用户作为实验品，帮助我们测试，提供给我们反馈，回头再修 改。但是那个时候是以牺牲用户的满意度作为代价的。
这个问题这么普遍，怎么来解决呢？其实答案很简单，就好像张三考试一样，平时把每一步应该做的事情都做好，那么最 后的结果，哪怕没有很多检查，都能够保证高质量。做项目的时候，软件内部每一个很小的功能，每个模块和模块连接的时候，都把里面该做的细节做好，这个系统 就会变得很牢固，哪怕到最后，测试不是很多，整体的质量也会远远高于行业的平均水平。
另外一个重要的观念是，质量保证不只是QA人员的责任，也是每一个人的事情，项目经理、分析师、设计人员，每个环节都必须把自己的工作做好，而且必须最大化地精确保留、传递和实现客户的需求。
非技术因素
最后，我们总结一下在软件项目开发中更重要的非技术因素。
第一点是将个人的修炼提升到团队的修炼。
在国内，较为普遍的一个现象是，程序员花很多时间做个人的修炼，而不是团队的修炼。个人修炼对于个人的成长的确有帮助，但是提高速度有限，因为他在孤军奋战。而且个人修炼对于中国软件产业的提升也没有太大贡献。例如在修复程序中的“bug”时，一般有三重境界。
第一重境界是，如果发现程序里面有一个bug，工程师一定要修复完这个bug，同时检查过之后才离开公司，这样做好像已经很有责任心了。但是他只做到了bug修复的第一层境界，这只是最基本的层次。
第二重境界是，当这个程序员在修复bug时，应该想到程序里面有没有类似的场景，有没有因为以前的拷贝粘贴操作， 在软件的其他地方也可能有类似的状况，甚至是其他工程师可能在类似场景里面也可能会出现这个问题。所以，这个工程师会花时间研究这个bug，会提醒可能犯 同样错误的队友，让他们也对这个问题引起注意。这样的话，一个bug在被发现之后，同类型的bug都可以被捉出来。
第三重境界是，项目经理这个层次至少要有这样一个素质: 如果发现同样类型的bug连续出现三、四次的时候，就需要分析一下根本原因是什么。如果是那个程序员没有足够的编程水平，那他未来写的程序会继续出现这些 问题，应该安排一个资深的程序员来教他、来帮他进行代码检查; 如果是客户的需求不明确，即使程序员的水平再高，写的东西也可能不是客户想要的，那就需要和客户进行确认。
关于修复bug的三重境界，如果公司里面只有一个人或者几个人才有这样的态度，对于整个软件开发的水平提升是没有多大帮助的。这必须成为整个团队的修炼，变成每个人都遵循的一种职业习惯，只有这样可能使软件的开发质量有较大的提高。
第二点，关注团队执行力而不是流程本身。
笔者认为，软件行业的流程不是太少了，而是太多了，我们花了太多时间关注流程本身，而不是关注流程的执行。很多流程实施下去效果不好，不是因为流程本身，而是在团队的执行力上。
在企业内部，高层管理者往往有很多政策都是很好的，很多流程的制定也是经过了深思熟虑的，但是到下面执行的时候，团队里面的工程师，是否只知道服从，但是不知道为什么要这么做呢？
第三点，最核心的也是最困难的是构建团队核心文化。
这里同样再用一个小故事来说明。某个酒店的优秀服务员在拿走客人的衣服去洗之前，会仔细检查纽扣是否会掉下来，如果是的，会把纽扣取下来，洗好衣服后，让裁缝把纽扣再钉上去。而客户，甚至都不知道自己衣服的纽扣曾经会掉下来这件事情。
要做到这么细节化的执行，简单地通过流程、通过责任心已经不能做到了，因为酒店培训服务员的时候，不可能把衬衫纽 扣掉下来应该怎么办这样的细节事情都写下来，让服务员背下来。要做到这点必须要有一种非常强的团队文化，整个团队对于客户的满意度都非常在乎，对于团队的 成功有高度的荣誉感和渴望。在软件企业内部，要打造与众不同的竞争力，最关键的是构建团队的核心文化核心观点: 应该以用户体验为核心，站在用户的角度、根据用户的理解(而不是程序员的理解)来进行软件开发。
核心竞争力的重用包括了对业务逻辑、业务行为的重用，还有最关键的，就是对于知识的重用。
质量保证不只是QA人员的责任，它是每一个人的事情，项目经理、分析师、设计人员，每个环节都必须把自己的工作做好，而且必须最大化地精确保留、传递和实现客户的需求。
