1.1 软件项目失败的根源
“在中国做软件太难了！客户连自己的需求都说不清楚！”，这种抱怨的话总是在笔者耳边响起。实际上，软件项目失败率居高不下、需求问题层出不穷的现象并不仅仅是中国软件业的困扰，在大洋彼岸的美国软件业也未能幸免。
第三方机构Standish Group每隔几年都会对软件项目实践现状进行分析与统计，其显示的“成绩单”（CHAOS Report）十分令人担忧。正所谓“他山之石可以攻玉”，下面我们分别来看看几次报告中显示的数据，分析失败的原因，以便从中获得一些帮助我们改进工作的思路。
1.1.1 CHAOS Report 1994
1994年度发布的报告显示，美国每年的IT应用开发项目大约有175 000个，总投资高达2 500亿美元，大型、中型、小型企业的软件开发项目的平均成本分别是232.2万美元、133.1万美元和43.4万美元。
而Standish Group的研究显示：高达31.1%的项目彻底失败，高达52.7%的项目进度超期或成本超支，被认为成功的项目仅有可怜的16.2%。
而导致进度超期、成本超支的项目中，最主要的原因之一是项目的重新启动，而每100个项目中就有94个曾经遇到这个问题，甚至在这94个项目中还有许多项目经历了多次的重新启动。
而不同的项目的进度超期、成本超支情况还是有所不同的，下面我们就通过CHAOS报告中总结的表格来了解一下，如表1-1所示。
表1-1 项目超支、超期情况分析
为了帮助软件开发组织找到明确的改进方向，Standish Group还总结出了十大成功保证（针对成功项目的总结）和十大败因（针对彻底失败项目的总结），如表1-2所示。
表1-2 项目成败因素分析
在表1-2中可以看出，十大成功保证中有三个是直接与需求相关的（已加粗显示），累计权重达到37.1%；而十大败因中与需求直接相关的更是高达五个，累计权重高达51.6%，可见需求问题对项目影响程度之高。
而对于那些成本超支、进度超期的项目而言，报告也总结出了导致这一结果出现的十大因素：缺乏用户参与（12.8%）、不完整的需求（12.3%）、需求变更频繁（11.8%）、缺乏执行层的支持（7.5%）、技术能力缺乏（7.0%）、资源不足（6.4%）、不切实际的用户期望（5.9%）、没有清晰的愿景和目标（5.3%）、不切实际的时间限制（4.3%）、新技术风险（3.7%）、其他（23.0%）。
1.1.2 CHAOS Report后续版本
由于CHAOS Report并非免费提供的，因此笔者没有找到报告原文，仅搜索到了各次报告中对项目成功率的数据统计，因此我们只能横向比较一下这些数据（如图1-1所示），以便大家了解近几年的行业发展趋势，无法更新项目十大成功保证和十大败因了。
图1-1 CHAOS报告数据分析
提示：
在我的职业生涯早期，就经常通过引用Standish Group的CHAOS报告向管理层展示，以说明在需求阶段投入时间的必要性。学会采用数据说话是技术人员走向成熟的一个要点。
1.1.3 需求相关败因简要分析
CHAOS报告总结的“软件项目十大败因”中，有五项是与软件需求直接相关的。这些因素在我多年的实践经验中也深有同感，因此针对这些因素我在多次公开课、内训时都进行了一些现场调查和交流，也得到了一些有趣的视角。以下我们就简要地对这些败因做个初步的分析，更多的内容将随着本书的进程继续深入。
1.不完整的需求
根据我在公开课、内训中的小调查显示，该因素的得票率是第二名。大约有一半的听众会认为这个因素对其需求实践产生了很大的影响。而我也总是喜欢问这样的一句话：“什么样的需求是完整的呢？”。
实际上，在我以前的工作实践中，该问题也始终是一个困惑！如果没有一个有效的“完整性评价标准”，那么这个问题也必将是无解的。要破解这个问题，首先应先回答一个铺垫性的问题：“谁更有可能可以对需求的完整性进行评价？”。我想大家一定会认同“用户代表要比开发人员更适合对完整性进行评价”这一观点吧！
而当我们回头去审视“软件需求规格说明书”时，却发现其中充斥着诸如数据字典管理、报表子系统、新增客户之类的以技术动词唱主角的字眼与结构，这样做显然会将技术功底并不深厚的用户代表排除在有效读者群之外。
隐喻：
如果你看到这样两份《家装方案设计书》：第一份的目录中是诸如“客厅”、“厨房”、“卫生间”、“卧室”、“书房”……另一份的目录中是诸如“水路”、“电路”、“家具”……你喜欢哪份？你认为阅读完哪份设计书时能够给出更多的建议？
因此要想让用户代表能够更好地参与到完整性评价中来，就必须采用“业务导向”的组织结构，而不是让用户将一大堆技术动作翻译到自己的业务场景中去。除此之外，在实际的操作过程中还有一个要点，那就是利用树型层次结构将宏观信息与微观信息进行有效的剥离。
案例&场景：
项目经理小王撑开已经熬了一个通宵的双眼，手里捧着一本厚重的《xxx项目软件需求规格说明书》，来到了客户公司的信息主管办公室。
“李总，这是我们通过调研后整理出来的需求，请您签字确认”。
“这个字我可以帮你签，但以后有什么需求的变更，你还是需要及时响应，并且一切将以合同为主”，主管信息的李总直接地表达了他的想法。
“……”（脑子里想：我能怎么办呢？这样签字与不签字又有什么区别呢？），小王最后只能无奈地说：“那……好吧！”
……又一次形式主义的需求验证就在不经意中落幕了。
想必对这样的场景大家都不陌生，但却经常“听之任之”。实际上如果透视该场景前后的深层次原因的话，不难发现其中的根源：
● 验证变成了确认：需求验证本是需求质量关，其目标是暴露出更多的错误，也就是说我们要的不是签字，而是指出潜在的问题与错误！而确认则代表了职责，因此用户代表们经常会在卸下职责的基础上履行形式上的义务。
隐喻：
一位可爱的物理爱好者在一次偶然的机会离开了地球，在太空遨游了一番。回到地球之后就迫不及待地找到牛顿先生，问道“嘿，我怎么不觉得太空里有万有引力呀！”。
“牛”先生说道：“呵呵，那里不归我管！那是爱因斯坦和霍金的世界，你可以找他们问问！”。
● 试图以“以点代面”的形式完成验证：“让一个人看完《需求规格说明书》中的所有内容，并指出错误！”，天呀，这是多么天真的想法呀！企业中怎么可能有人上通宏观战略，下解微观操作呢？因此树型层次结构应该面向不同的层面：决策者（高层）、事务管理层（中层）、操作层（基层），将需求分成不同的部分，让合适的人验证适当的部分，然后再汇总起来才是解决之道。
SERU 诫语1-1：需求规格说明书应该采用业务导向的树型层次结构来组织。
2.缺乏用户参与
在很多的软件项目中，用户都不能有效地参与到项目中来，也许诸如“你们先做，做出来我们试试后再改”之类的话，早已经听得你的耳朵生茧了。实际上这个现象的背后存在几个方面的因素：
● 事不关己，高高挂起：主动参与意识是与获得的利益成正比的。很多软件项目在实施之时，并没有清晰的目标，客户中的许多代表也不知道能通过新系统获得什么好处，因此没有积极性。针对这种情况的主要应对措施是充分研究不同用户代表的关注点、利益点，具体的方法我们将在“第4章 需求定义最佳实践”中展开说明。
隐喻：
试想想，如果为自己装修房子，你一般多久会跑现场一次？
如果装修的是你朋友的房子，只是帮他照看一下呢？
● 逃离无趣区：如果你不喜欢或不熟悉足球，当同事们讨论起足球时你会怎么办？我想选择离开的人不在少数吧！人本性中有一种逃离无趣区的趋向，对于那些自己没兴趣、不够专业的领域就不愿意多介入，一方面无趣，另一方面会丢面子！那么用户对于软件开发项目和你对于足球所遇到的情况不是一样吗？
● 被你赶走：当用户鼓起勇气开始参与需求活动时，难免不被那些“需求分析人员”用深奥的技术语言（也许他们还认为这样才是专业主义）吓走。
好吧，通过业务利益争取用户参与到需求活动中，始终让技术解决方案在冰山之下以使用户不中途离开，也许是缓解该问题的很重要的策略。
SERU 诫语1-2：对于需求分析员而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控力等）的沟通。
3.不切实际的用户期望
隐喻：
楼下的操场上站着一个三岁的小孩，将一个玩具飞机举过了头顶，不断地垫起了双脚……
一会儿，爸爸走了过去，这时小孩暂停了尝试，将满面愁容的小脸转向了爸爸，眨着那双稚气未消且又充分期望的眼睛，说道“给我买一架能够飞到太空的航天飞机吧，我想把月球上的嫦娥姐姐接下来玩……”。
“……”。
很多时候，软件开发从业人员就是那位无奈的爸爸！用户总是很天真地提出了大量的需求，有些是技术上根本无法实现的，有些则是原本就脆弱的费用与时间预算内无法实现的。就像孩子们不知道能够飞上月球的航天飞机要多少钱一样，客户也不知道自己提出的需求真的需要多大的成本。
那么问题的根源是什么呢？其实原因就在于软件的无形和成本的不透明。也许前面这个隐喻最大的失败之处在于不小心传达了“客户就像三岁小孩”这样的潜台词，从而导致我们将“不切实际的需求”归罪于客户。实际上要解决这样的问题，更需要的是从业人员主动地帮助用户更好地理解软件的成本。简单地说，做不到是无效的，要说明为什么做不到才能解决问题。
4.需求变更频繁
这是一项特别有意思的因素，在CHAOS报告中将其列为第四位，但我在各次公开课、内训的课堂小调查中，这一因素得到的票数都是最多的，而且经常是全票支持！这种排名上的问题背后有什么道理呢？
当有人和我探讨解决需求变更频繁问题的方法时，我总会先问一句“你们经常遇到的变更主要是哪种类型？”，但就是这样的一个问题却往往难住了许多人。也就是说，在国内软件行业中，对变更进行分类、统计的做法仍然不是很普遍。但如果只是简单地将所有的需求变更都当作一个问题来看待，那么是无法有效地找出问题的根源的，也无法有针对性地改进需求过程，提高设计的弹性。这也许就是经验和经历之间的区别吧！
另外一方面，用户并没有意识到变更对软件项目的负面影响。而究其原因，其实与绝大多数软件企业一样缺乏统一的变更处理渠道，使得变更相对而言比较散落，没有集中地体现出来。在笔者的实践中，曾经就有用户代表说：“我们的变更不多吧，我总共只提了两个。”，岂不知他这样提两个变更的用户就近百个……
5.提供了不再需要的
案例&场景：
“暨经理，你看这个版本离发布的时间已经很短了，是不是能把功能Feat209
的开发放到下个版本中去呀！毕竟原来已经实现了类似的功能，而且我感觉原来的功能已经够复杂，应该能够满足用户的……”
没等他讲完，产品经理暨xx马上反驳道：“开什么玩笑，Feat209是我们产品的一大卖点，这个新版本必须实现！我要为市场销售负责！是你懂得用户还是我懂得用户呀。”
“……”，无奈的程序员们又开始在“格子”里埋头苦Coding，朝着那个不可能实现的deadline冲去。
到底谁才是知道用户最需要什么功能的人呢？产品经理、开发人员还是用户代表？呵呵，其实最了解用户需求的是软件本身！越经常被使用到的功能，就是越重要的功能，那些根本没有几次访问量的功能模块，一定是那些不再需要的。
笔者曾经尝试过这样一些小技巧，在每个功能模型的入口页暗藏了一个计数器功能，一段时间后只要收集回log记录，一看就知道哪些是“不再需要的”，也就不必再费心去做更多的升级了。当然，这种举动只能起到“马后炮”的效果，无法“防范于未然”，仍然浪费我们大量的开发资源与时间。
是否能够事先预防呢？这必须从另外一个角度来看，那就是能否在最开始有效地划分优先级。也许这样的回答会令你失望，优先级划分经常是“拍脑袋”的产物，没有理由也没有原因，它就是最高优先级。这样的方法显然是不正确的，真正基于业务领域知识来衡量需求的必要性和充分性是解决之道，我们将在“第3章 软件需求与需求工程”中进一步阐述。
1.1.4 一幅漫画带来的思考
关于软件项目存在的问题，互联网上曾经流传着一幅漫画（如图1-2所示），它十分生动地展现了这些问题。也许很多人看完之后只是一笑置之，但如果我们认真剖析后面的东西，还是会给我们的工作带来许多启发的。
图1-2 需求“迷途”
1.沟通失真
这幅漫画给人最深的印象就是沟通严重失真了，从客户的描述到项目经理的理解、分析员的设计、程序员的编码、商业顾问的诠释，每个角色都根据自己的特点和需求对信息进行了不同的加工，从而导致信息的内容有了很大的改变。因此，对于软件需求工程而言，克服沟通失真就成了一个要点。
根据相关的研究显示，在信息的传递过程中，如果没有采取任何措施，那么在沟通过程中信息衰减可能的最大值高达60%。而在软件开发过程中，需求信息通常要经历用户代表、需求人员、设计人员再到开发人员，因此最坏的情况下，开发人员获得的信息仅是原来的8.4%（如图1-3所示），这是一个十分可怕的结果。
图1-3 信息失真
怎样才能够更好地避免这种问题的出现呢？其实关键的手段有两个：
● 文档：如果信息在传递的过程中仅靠口口相授的话，就难免发生遗忘、加工等情况，因此必须在这个过程中有效地利用文档，将达成共识的信息文档化。但这种方法只是用来辅助沟通的，而不是代替沟通，这一点在后面还会提到。
● Review：在此有意使用了英文，因为国内常将其翻译为“评审”，但这一翻译却容易给人误导。评审在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。顾名思义，Review就是再（Re）看（View）一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。而最简单、最有效的Review就是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。
隐喻：
经理叫来了小张，然后就下一阶段的工作做出了一些重要的指示和安排：“$%#^@(*)#@……”。
小张正要扭头走的时候，经理叫住了他，说道：“你简单地说说看，我刚才给你交待的任务有哪些”（看来管理人员早已掌握了这一招）。
SERU 诫语1-3：缓解沟通失真最有效的方法是及时复述。
“沟通失真”高度概括了其中所蕴藏的问题，但如果我们细细地思考图1-2中第1、2、3、4、10幅图（这5幅图中的景象与需求活动有很大的相关性），并将其两两比较就会得到一些有益的启发。下面我们就一起来看看。
2.客户的需求放大
当我们比较图1-2中第1幅和第10幅图时，就会发现用户在描述自己的需求时做了许多“添砖加瓦”的事。“用户要么不会说，要么就会添油加醋”的现象，在我的实践中是屡见不鲜的。而在这种现象的背后有什么潜在的原因呢？我认为至少有两方面关键因素：
● 客户希望支付的成本尽可能少，获得的效益尽可能多。这种思维对于任何一个客户、任何一个人而言都是本能反应。而当用户对开发成本越不了解时，这种心态就会越强烈，更加担心自己“亏损”了；因此在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。要解决该问题并不是件容易的事，一方面需要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高。
● 解决方案的选择权交给了不熟悉技术的客户。许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（What），而不太关心用户提出需求的真正动机（Why）。但是这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而一旦客户代表选择的解决方案不是最合适的，就必将引发后续的需求变更。因为对于一个特定的问题，可能的解决方案会有很多，因此用户可能在使用软件的过程中不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而要缓解这一现象的关键就在于，在需求捕获的过程中多问“为什么”。
3.项目经理的需求控制
当我们比较图1-2中第1幅和第2幅图时，就会发现项目经理在沟通的过程中会导致需求产生偏差。由于国内许多软件项目经理们通常是一身兼多职，项目管理、需求分析、架构设计一肩挑，因此在需求捕获的过程中，总会“及时”地在脑海里勾勒出技术框架和路线，然后尽可能地控制需求的范围。但实际上，有些需求“表面上”是控制下去了，但却在后面以“需求变更”的形式全回来了。
实际上，我的体会是需求分析人员是有必要对需求进行有效的控制的，问题出在控制的策略和方向上。从前面的描述中不难看出，项目经理经常会从技术的角度来对需求进行控制，这样就可能造成无法形成对需求的有效理解。
隐喻
从图1-2中第1幅图看，客户需要的可能是一个“秋千”或者是“上树工具”，但不管真正的需求是什么，第2幅图中的解决方案却都无法有效地满足。如果要做“秋千”，不应该被树干挡住；如果要做“上树工具”，木板的数量显然太少了。
进一步来看，正是由于需求分析、项目管理、架构三位一体，导致其在获取需求时产生了一些控制：从项目管理者的角度出发，将“三层”板的工作量减成“一层”板；从架构的角度出发，将不稳定的“全挂在一个树枝上” 改成“挂在两个树枝上”，结果根本无法使用。
那么要如何才能缓解这一现象呢？笔者认为应该以业务为线索来组织需求，基于“Why”的层面对需求建立高层次的认识。而具体的做法，我们将在后续的章节中逐一详细阐述。
4.分析人员的技术加工
每次看图1-2的第3幅图时，就会想起这样的一幕：
案例&场景：
分析员小张：“嘿，伙伴们！我有个提议，我们研究Hibernate已经有一段时间了，一直没时间真正动手用一用。我看这个项目就不错，不算太大，就用它试试吧！”。
“好主意！”，大家纷纷表示赞同。
……
“约定时间已经过去1个月，现在项目进展到底如何了？什么时候可以交付？”，客户方CIO质问道。
分析员小张：“现在主要困扰我们的是一些需求细节一直存在变化，开发团队又有了一些人离职，所以……”（真正的情况是：由于团队第一次使用Hibernate，有些数据访问层的问题一直没有有效解决，导致进展不断失控。）
现在许多名称中包含“需求分析”、“系统分析”之类的职位，大多是由技术骨干担任的，因此在工作中很少从业务角度进行分析，更多还是追求技术框架、新技术。对于这种现象，究其根源，关键还在于“技术能力”对他们的未来发展更为重要，而“业务能力”却不是那么重要。但为了使需求工作有更好的提高，我会强烈呼吁那些Title上有“分析”之类名称的人们，加强业务分析吧！
SERU 诫语1-4：需求分析的本质在于业务分析，而非技术分析。
5.编码人员的断章取义
对于图1-2中第4幅图，可以用一句生动的话来概括：“你要绳子，我给你了；你要木板，我也给你了；你为什么说这不是你想要的呢？”。我想程序员也有类似的问题想问自己的客户，“你要文本框，我提供了；你要一个表单，我也有了；你为什么说这个程序不是你想要的呢？”。这让我想起了这样一幕：
案例&场景：
叮铃铃……，程序员小赵的电话急促地响起。小赵刚接起电话就听到了对面迫不急待地抱怨声“仓库管理员反应，入库模块没法使用！你马上查一下，尽快解决一下！”。
小赵放下电话就开始Check out、Builder、Run、Debug……一系列操作。经过一番测试之后，小赵没好气地拿起电话回复说：“这些客户真是笨！这哪有问题，肯定是操作上出了问题！我怎么用都是好的，你们客户服务的人也应该加强对用户的培训，别什么事都扔给我们！”。
……
可是，问题仍然没有解决！开发人员到了现场一看，终于发现了问题的所在：这是一套基于B/S的仓库管理系统，在入库时，仓库管理员首先需要录入入库单，然后填入“验收情况”，最后单击“入库”按钮。但当仓库管理员录入完入库单，逐一验过入库货物之后再回到电脑前时，等待他的却是一个令其不知所措的问题，Session超期！
憋了一肚子气的小赵一个电话就打到需求分析员小钱那里：“你们的需求是怎么写的！这么重要的东西也不写明白，我们怎么知道填完入库单后要验货那么长时间，才填写验收情况呀！”。
“哦，这也算是需求吗？如果这也算的话，那我们岂不成了业务人员了！”，小钱很强势地回答道。
这是需求吗？也许很多读者会有不同的看法！但如果缺乏对业务场景的了解，又如何能够真正理解需求呢？断了“业务场景”之章，必将导致取出的“需求”之义有所偏差呀！
SERU 诫语1-5：业务场景是需求之魂。
也许从这幅颇具讽刺意味的漫画中，不同的读者还能够得到更多不同的启发。不过最为重要的一点在于反思这一现象后面的本质因素，构思真正有效的缓解手段，这样才能够有效地避免出现这种“迷途”。这里的分析都比较粗浅，对于这些问题的解决之道的探讨将贯穿全书。