Donald C. Gause、Gerald M. Weinberg 著,章柏幸 译
本书中译本即将由清华大学出版社闻洁编辑室制作,闻洁编辑室曾经为中国读者引进了《人月神话》、《人件》等书。译者章柏幸的译著《你的灯亮着吗》2003年获得大奖。
UMLChina向您推荐本书,并将之作为UMLChina训练的辅助教材。

随便什么时候只要你使用那些忽略了人的因素的工具,你就不可能完美地描述需求,并且还会造成含混性。然后,含混性就会带来对相同需求的不同解释。
例如说,图2-1,2-2和2-3展示了三种完全不同的建筑物,但它们都是按照下述相同的意义含混的问题描述而建造的:
创建一种方案来保护一小组人,使之免受其环境中的不利因素伤害。

图2-1 圆顶建筑——用本地建筑材料建造的土著房屋

图2-2 巴伐利亚城堡——为威慑邻邦而建造的房子

图2-3 太空站——用于观察的可移动房屋
首先,这三种建筑确实提供了所描述问题的有效的解决方案,而且这些解决方案具有令人咂舌的差异。通过考察这些解决方案之间的差异,我们发现线索在于需求中的一些含混性。
2.1.1 缺少的需求
有时候需求是有遗缺的。例如说,没有关于材料属性方面的需求描述,这些属性包括当地可用性、耐用性或成本。因而三种不同的解决方案在其使用材料方面的强烈差异就不会那么令人惊讶了。
对于建筑方式或如何组织这些建筑材料的问题描述同样是含混的。我们不知道所期望的建筑物的大小、形状、重量或者寿命。
这些建筑物内部应该包含的功能几乎什么都没有说,甚至都没有暗示;这样,例如像火炉、仆人间、床和客厅这样的一些详细的功能要素都确定不了。
无论是内部的还是外部的物理环境也什么都没有提到,建筑物可能是在陆地上或大海里;在空气中、在冰层上甚或在外太空。而且,我们也不知道我们需要保护的居住者所面临的详细不利因素。
其社会和文化环境又是什么?这一小群人是一个家庭吗?如果是的话,那么在这种特定文化下的家庭是如何构成的?可能它是一个工作小组,例如猎人或石油勘探工程师;或者可能是一个娱乐小组,例如玩扑克或跳方块舞的人。
2.1.2 含混的词语
即使在需求被明确地说明时,还有可能使用了含混的词语。例如说,词语“小”不能充分地说明人群的大小。注意那些在问题描述中按比较估计的词语,比如说“小的”或“便宜的”。如果我们是在讨论内布拉斯加(Nebraska,美国州名)大学总部比赛的足球迷,那么25000人也只是一个“小的”人群,而这就需要一个新的半球形露天大型运动场才能够满足所描述的需求。
另一个在问题描述中的危险词语是“组”,它暗示这些人将会有相互影响,但不知何故,这里也不清楚其究竟。表演“费加罗的婚礼”的演员们之间的相互影响与在费加罗咖啡馆喝咖啡的一群人之间的关系截然不同。为某个小组设计的建筑物将会和为其他人设计的完全不同。
甚至是术语“建筑物”也带来了一大堆的含混性。有些读者可能会推断“建筑物”意味着某种坚固、耐用、可靠、不透明而且可能是巨大的东西。如果我们在无意中滑入了这种推论,我们潜意识里就断定需求可以通过传统建筑材料来获得满足,而这就限制了那些有可能有效的设计的范围。
2.1.3 无意中引入的假设
当然,我们可以通过小心探索问题描述中的每个单词的多种含义来预防那些含混的词语,但是这样我们还是避免不了另一个问题。术语“建筑物”实际上从未在问题描述中出现,但不知何故它在我们不注意的时候进入了我们的讨论。问题描述实际上说的是“创建一种方案”而不是“设计一种建筑物”。
有些问题的含混性是很明显的,它们能够在实际设计过程开始之前设计者和客户之间长时间交谈的不经意中获得解决。可是更多微妙的含混性,可能需要在设计者脑海里不知不觉地解决。既然这样,一种创新的、无需建筑却又能保护一小组人的“方案”可能被忽略了。例如说,设计者可能会:
1. 为了免受带有静电雨滴的雨的影响,可以通过电场来解决。
2. 为了免受好战分子的影响,可以通过警告语来解决,比如“枪棒无眼,和谈为贵”或“人不犯我,我不犯人”。
3.
为了躲避寒冬可以迁移到南方,为了躲避烈夏可以迁移到北方。
这些需求中的含混性的最基本的例子只能让我们注意其对问题的巨大影响。每年因为生产不符合需求的产品就会浪费数十亿美元,而这些绝大多数是因为没有清楚地理解需求。
例如说,Boehm(原书底注:Barry W. Boehm著《软件工程经济学》,Englewood Cliffs,美国新泽西州:Prentice Hall出版社,1981)分析了诸如IBM、GTE和TRW(GTE:通用电话与电子设备公司,General Telephone and
Electronics Corporation;TRW:汤普森·拉莫·伍尔德里奇公司,T hompson Ramo Wooldrige Inc。)等公司的63个软件开发项目,对于由需求阶段的错误假设所带来的错误,为其在不同的后续阶段发现并改正所需成本确定了一个范围。(参见表2.1和图2-4)
|
表2.1 |
|
|
与修正一个错误相关的代价 |
|
|
发现错误的阶段 |
成本倍数 |
|
需求阶段 |
1 |
|
设计阶段 |
3-6 |
|
编码阶段 |
10 |
|
开发测试阶段 |
15-40 |
|
应用测试阶段 |
30-70 |
|
实际运行阶段 |
40-1000 |

图2-4 Boehm在项目成本上的观察结果
尽管表2.1生动地表明了发现需求含混性的重要性,这些数据实际上可能还十分保守。首先,Boehm研究的仅仅是那些完成的项目,而一些观察者估计大约有三分之一的大型软件项目从未完成。这些流产项目的巨大损失也可归结于其贫乏的需求定义。
在我们考虑基于早期错误假设的错误设计决策带来的灾难性结果,情况看起来更为糟糕。例如说,在二十世纪七十年代生产的福特斑马车(Ford Pinto),在假设没有任何尾部冲撞的条件下,燃油槽座架螺栓的位置是一个极其杰出的设计结果。这一假设被证明是错误的之后,福特汽车公司自己估计已经在诉讼和产品召回维修上花费了1亿美元。更何况还有那些因为这一错误而付出的生命又该怎么来估价呢?
来看另一个案例。由Johns-Manville公司开发、生产并销售的石棉建筑材料所基于的假设是:从环境角度看,在其产品中使用的石棉形态对所有裸露的人们是安全的。在John-Manville产品中的许多优良的观念都是基于这个现在大家都知道的错误假设。在麻省坎布里奇市的流行病研究公司估计这一高级决定最后带来了5万2千起诉讼事件,并给公司带来大约20亿美元的债务。实际上,该公司整个组织、文化和主要投资都投入到石棉材料产品中去了,于是被迫宣告破产,而现在已改组为Manville公司。
在过去的三十年里,我们两个一直从事于帮助避免代价昂贵的错误、失败项目和灾难性项目的工作,这些中的大部分都始于含混的需求。我们写作本书的目的就是为了向大家介绍一些成功用于抑制含混性的探索需求的工具。这是一些综合的方法,并可应用于几乎所有类型的设计项目:无论是在皮奥里亚市盖房子还是在巴伐利亚建城堡,或无论是在线信息系统还是生产型组织,或无论是广告竞争还是在新西兰的自行车旅行。
2.3.1 需求的图片
图2-5是一幅阐明了我们所谓的需求的含义的图片。古人们相信宇宙初期起源于一个巨大的蛋,所以我们使用“蛋”来表示所有可能的事物的总体。我们在蛋的中间画一条线来把我们所需要的内容从不需要的东西中分开。如果我们确实能够画出(或描述清楚)这样的一条线,就表示我们拥有了完美的需求描述。

图 2-5 通过需求来表达我们的意图
|
The Universe of Everything That’s Possible What We Don’t Want What We Want |
所有可能的事物的总体 我们不想要的 我们想要的 |
图2-6是一幅阐明了我们所谓的探索需求的含义的图片。第一个蛋上画了一条波动相当明显的分界线,它表示对需求线的第一次近似。这条线表达了对问题的第一次含糊的描述。第二个蛋展示了在一些早先的探索技巧取得的结果。这条线仍然是波浪型的,它表示仍然描述了一些我们不想要的内容,也还有一些我们想要的没有被描述在内。但是至少有一些最大的潜在错误(离需求线最远的区域)被消除了。

图2-6 探索需求:黑色区域代表那些我们想要的内容却没有要求,或我们要求了并不想要的。通过再三使用需求工具,我们缩小了这部分区域,并越来越接近于我们不多不少想要的内容
每个在需求过程中代表下一阶段的新蛋,都是对真实需求线的一次更好的近似。可惜,这条线将永远不可能和需求线完美重合,因为在现实生活中这几乎是不可能的任务。即便如此,通过探索,开发者应该努力在为其波动支付太昂贵的代价之前让它尽可能地接近笔直。
2.3.2 需求的模型
拉直波浪线的过程是一种探索过程,在这方面,伟大的探险家马可波罗、哥伦布、刘易斯和克拉克(译者注:Marco Polo,马可波罗,1254-1324,意大利旅行家,商人;Columbus哥伦布,1446?-1506,意大利航海家,据传于1492 年发现北美洲;Lewis,刘易斯·梅里韦瑟,1774-1809,美国军人和探险家,曾率领刘易斯和克拉克探险队从圣路易斯出发横贯大陆抵达哥伦比亚河口;Clark,克拉克·威廉,1770-1838,美国探险家,曾参加刘易斯对太平洋的一次探险,他负责仔细标明每条道路)都是我们的榜样。概言之,下列步骤是探索者所要做的:
1. 向某个方向移动。
2. 看看在那里发现了什么。
3. 记录所发现的东西。
4. 有目的地分析所发现的东西。
5. 通过对所发现的东西的分析和记录来选择下一个方向。
6.
跳回到第1步,继续探索。
在本书的后续章节里我们将会看到,在探索需求中使用的过程是一样的。
l 我们的同事Ken de Lavigne建议说,在Deming的著作《逃离险境》(作者底注:W. Edwards Deming著,《逃离险境》,麻省坎布里奇市,麻省理工学院高等工程研究中心,1986。)中描述了一些关于需求含混性的结果的非常重要的例子,在“手术定义”的那个主题下。
l 除了看别人的例子之外,找一些你自己的实例会更好。下次如果你发现产品并不完全如你所想,你可以问问自己:“是什么需求导致了这样地创建一个产品?”
为什么?
攻击含混性是因为含混性需要成本。
什么时候?
尽可能早地攻击含混性,因为即使你最终消除了它,在产品开发的早先阶段改正所需的成本要比以后改正的成本少很多很多。
怎么做?
如何攻击含混性是全书的主题。但首先,一定要记住用一种非常有趣的方法来使用你的智慧——探索应该是一种乐趣。
相关人是谁?
就是你自己。
(本草稿经清华大学出版社同意刊登)
《非程序员》免费下载,仅供学习和交流之用。转载文章需注明出处。不得转载用于商业用途。