羊的门

http://dev.csdn.net/article/26/26988.shtm
http://dev.csdn.net/article/26/26992.shtm
http://dev.csdn.net/article/27/27354.shtm
http://dev.csdn.net/article/27/27376.shtm
http://dev.csdn.net/article/27/27380.shtm
http://dev.csdn.net/article/27/27601.shtm

羊的门

作者：章柏幸
[e-mail]

7我实实在在地告诉你们，我就是羊的门。

8凡在我以先来的，都是贼，是强盗，羊却不听他们。

9我就是门，凡从我进来的，必然得救，并且出入得草吃。

10盗贼来，无非要偷窃、杀害、毁坏；我来了，是要叫羊得生命，并且得的更丰盛。

12若是雇工，不是牧人，羊也不是他自己的，他看见狼来，就撇下羊逃走。狼抓住羊，赶散了羊群。

13雇工逃走，因他是雇工，并不顾念羊。

——圣经·新约·约翰福音·第10章

 

 

“我从很小就开始对‘人们如何思考’产生了浓厚的兴趣；那时我还是一个小男孩，世界上仅有的计算机被人们称为‘巨型大脑’；我当时就想，如果我搞清楚了这些巨型大脑的‘思想’，我或许就可以更深入地了解人们是如何思考的。”——杰拉尔德·温伯格。

 

在看到这个题目的时候，读者朋友可能会想起几年前李佩甫的一部同名小说。这里说的和那本小说看起来没什么关联，但是又仿佛有着莫大的联系。在我改写这部分文稿的时候，脑海中总会时不时浮现出盗贼、羊、雇工、狼、牧羊人的图景，我发现，我们在这里讨论的内容所遇到的问题和耶稣所遇到的责难一样难以处理；而我们所做的事业，正是在帮助那些心地善良而又不知天堂之路的迷羊找到正确的回家之路；这就是羊的门。

 

下面2个小节，介绍一下本文的主要目的和关注点。

《探索需求》是Donald C. Gause和Gerald M. Weinberg合作的一本探索软件开发项目需求部分的书。本文的目的是为了用一种更为适合中国人的方式来表述书中第一部分的观点。在项目管理者的眼里，世界上的一切问题都可以归结为项目。项目从开始到结束一般会有很多阶段，而“需求分析”阶段就是用来搞清楚“我们在这个项目中需要解决什么问题”的。

这本书的关注点就在“需求分析”阶段。虽然这个阶段的书籍和论文已经很多了，但是经验表明，我们还是有必要阅读这本书，因为这本书中还有很多别的书中没有提出过的有用的观点。《探索需求》的第一部分就是要讲清楚为什么需要这本书或这本书中的一些技巧和观点。这也是本文的重点。

 

简而言之，需求分析阶段需要经历两个步骤：

1、提出问题的人说一些话，以告诉帮助他解决问题的人他要干什么。

2、解决问题的人和提出问题的人进行沟通，以确证这个问题的细节。

第一步就是“问题陈述”，这和法庭上指控方、被指控方的案情陈述有点类似。

第二步就是“探索需求”，这和法庭上的双方律师不断地分析对方以及询问证人有点类似。这里律师就是需求分析员。

只有律师把事情来龙去脉用合乎法律的方法表述清楚之后，法官才能够正确断案。也就是说，只有需求分析员把问题的关键分析清楚之后，开发者才能够做出正确的产品。

 

下面举出的这个例子说明了一个观点，即：如果你说清楚了你的需要，那么你就很可能得到它；如果你没有说清楚你的需要，那你就很可能得不到它。当然这个观点很简单易懂，也就是说这个例子可以略过不读。

我们要求五个小组甲、乙、丙、丁、戊在几乎相同的“问题陈述”下进行程序开发，说“几乎相同”的意思就是其中有且只有一个句子各不相同，分别如下：

小组     要求

甲       开发时间尽可能少

乙       源代码行数尽可能少

丙       占用内存尽可能少

丁       程序的可读性尽可能高

戊       程序输出尽可能清楚

最后的结果就是，每个小组开发出来的程序都满足了这句特殊的要求，而没有满足那些没有被要求去做的。我们常常听到一些购买软件的人抱怨软件开发商没能开发出他们真正想要的东西，那么这里反过来可以这么认为，并不是开发商不能开发出来，而是他们不知道要开发出什么，这里面的问题就是：开发商没有好好地调查好需求，或者是购买者没有好好地讲清楚需求。这里我们不追究谁的责任，关键是我们确证了“你要你就说，你不说我怎么知道你要呢（参见《大话西游》，唐僧语）”的真理。

经验表明，上述例子在全世界的软件开发商中都有发生。尤其需要指出的是，“问题陈述”和“人们真正想要的东西”之间的差距不仅仅在软件业频频发生；而是，只要有人需要解决别人的问题，只要有人需要别人为他设计和生产产品，只要存在某种供需关系；这种差距就存在，就需要有人来解决这个差距问题。

高斯和温伯格，软件界的两个泰斗级的人物，为了解决这个差距问题，已经花费了60多年的时间了。而这本书中的内容，正是对这些问题的心得。

 

 

1 贼和强盗

作者：章柏幸

[e-mail]

8凡在我以先来的，都是贼，是强盗，羊却不听他们。

我们已经知道了需求分析的必要性，这也就意味着我们认为现今的需求过程尚不完善。这种不完善很大程度上体现在“问题陈述”和“人们真正想要的东西”之间的差距上，或者说，“问题陈述”没有能够陈述清楚“人们真正想要的东西”。

这里我们引进2个词语：歧义、含混性。

此处，歧义的意思是指我们得到的“问题陈述”导致了多种理解，以至于我们不能确定哪一种理解才能够真正说明“问题”。含混性是一种更为晦涩的表述，它的意思是“问题陈述”含混不清，甚至无法表达明确的意义。

在过去几年，软件过程和软件工程流行的时代，很多人已经被时尚所左右，言必称自动化，开口即软件工程，仿佛所有的开发问题都已经解决。更有甚者，有人还认为需求分析中的歧义的根源是因为“人”的参与。他们宣称“人”的不确定性导致了“陈述”的不确定性，由此导致了“人”提出的“问题陈述”的歧义。并且，他们认为只要排除掉需求分析过程中的人的因素，然后用一种严格论证、高度自动化的、规范的方法论来进行分析，就能够消除这种歧义了。那么，或许我们可以反问一下，这种分析是否也应该“剔除”具有严重不确定性的“顾客”呢，因为我们实在不能不把顾客当人看待的。

实际上，上节中比较极端的观点是对CASE、CAD等工具的一种病态的理解。工具能够帮助人们工作，但是却不能够完全替代人。我们不妨来考察一个如何杀死蟑螂的项目。

不听使唤的蟑螂

有人提出可以用一种自动化的方式杀死蟑螂，步骤如下：

1、   让蟑螂静止站立在砧板中间

2、   用蟑螂拍对准蟑螂猛拍一下

3、   把砧板、蟑螂拍上的脏东西洗干净

这种自动化方式和CASE或CAD工具所谓的自动化过程同出一辙，在一个CASE文档中，CASE工具也由三个步骤组成：

1、   分析并设计出明确的需求规格说明书

2、   建立功能点和源代码（及文档）一一对应的数据字典

3、   将需求规格说明书转化为源代码和文档

于是有人会说，自动化杀死蟑螂的方式纯粹是搞笑，因为没有哪一只蟑螂会乖乖地待在砧板中间，就算它碰巧站在了砧板中间，它也不会乖乖地一动不动等待你的拍子。这个理由恰好也是我们认为的CASE之类的自动化工具离不开“人”的因素的理由。因为我们没有办法用自动化工具分析出明确的需求规格说明书，也不能用它来保证这一需求规格说明书永不改变。

【拾人牙慧】

自动化方法干的是“大事情”。40年前需要很多个星期才能完成的工作量，今天只需要一个小时就能够搞定。而且，由于自动化工具的发展，我们还开始挑战那些在以前想都不敢想的系统。然而，随着工具的进步，软件产品在可用性方面的口碑却并没有多少提高。

对于那些需求明确、陈述无歧义、一定程度上模式化了的内容，自动化方法非常擅长；但是也还有一些涉及到人性心理方面的棘手问题却无法用这些方法来解决。换句话说，只要是有规律的、统一的开发过程，自动化方法非常擅长；而在不同项目或产品之间的差异和个性化，则需要更细致的分析。

我们不妨做一个简单的计算。

规模为S的项目中有P%的问题为公共问题，有Q%（Q＋P＝100）的问题为个性问题。

在时间T1时，我们每解决一个公共问题需要投入T，每解决一个个性问题需要投入M。解决个性问题在整个项目中所占的投入为：R1＝M×Q／（T×P＋M×Q）。

在时间T2时，我们每解决一个公共问题需要投入t，每解决一个个性问题需要投入m。解决个性问题在整个项目中所占的投入为：R2＝m×Q／（t×P＋m×Q）。

从T1到T2，自动化水平提高了，于是有T>>t，公共问题和个性问题的比例变化很小，而且对于每个个性问题的投入也变化很小，即有M≈m。从而可以得到R1<

这表明，随着自动化水平的急剧提高，我们在个性问题方面的投入比例也急剧提高。

个性问题，亦即是人性方面的因素反而随着自动化程度提高而愈显得重要了。这一特征在那些具有多年开发经验的人们当中早已成为了共识。也就是说，经验丰富的专家们在技术任务上的投入少了，而在人性因素方面的投入更多了。在那些小型的显而易见的问题上，他们完全放心交给别人去做了；而在那些看起来永远不会结束的问题上，他们被深深地吸引了。

 

【呀呀学语】

语言是我们表达思想的工具，也是某种文化的载体。在开发系统方法中，我们也有语言，那就是符号系统。相信所有人都遇到过因为语言不通而产生的交流障碍；同样，在符号系统上，我们也遇到了交流障碍。

语言文字所传递的信息包括“内涵”和“外延”两部分。人们在说话传递信息时，往往会附加上各种语态、表情、动作作为对其所说语音的外延；甚至我们可以认为，因为我们来自各个不同的省份县市，各种不同的方言乡音也传递了丰富的外延。

于是，对于同样的事件或需求，我相信没有任何两个人的描述是完全一致的。承认这一点对于我们直面需求分析的困难会有很大的帮助。

我们这里给出优秀符号系统的两个重要要求（当然这仅仅是众多要求中的两个），以帮助我们将来使用这些符号。例如说，首先符号系统要能够比较全面地表述我们所遇到的绝大部分问题；其次为了适合产品开发的过程化，符号系统的表述结果要比较容易保存和修订。这也是对一个优秀的CASE和CAD工具的基本要求：在任何时候都可以保留并修改我们当前的结果。

 

【大同世界】

在未来的大同世界里，人们都操两种语言，一种是代表本民族特色的方言，另一种是所有人都能听懂的世界语。这个世界语和现在语言界所谓的世界语大大不同，虽然后者的目标是成为前者，这差距就像是共产主义和社会主义之间一样大。

虽然大多数人都会认为自己的母语是美妙而完美的，但不可否认每一种语言都有其优缺点。类似的，每一种符号系统也都有其自己的利弊。这里我们引进一个概念：映射图。

我们把用符号系统的基本符号组合而成的信息集合称为映射图。这里的“映射”取自于逻辑上的对应关系。大家可以把之近似地联想成通过某种约定而建立的“需要表达的信息”和“符号单元”之间的对应关系。映射分为1-1对应、1-n对应、n-1对应三种。由于自然界所存在的信息是高阶的不可列无穷大，因此严格意义上的1-1对应是不存在的；反过来，严格意义上的1-1映射甚至可以说是毫无价值的。

在这里，我们用映射图来表示我们的符号系统的结果，映射图可以是一种语音，也可以是一幅地图，或者是图文并茂的VCD；只要它满足可再现、可修改、可保存，就可以。

质量好的映射图必须是能够让所有相关人员都能够理解的，就像是未来大同世界的世界语一样。当然这仅仅是一种理想的奢望。实际上，每种语言或符号系统的支持者都会声称他们的东西是最好的，听起来有点像是“王婆卖瓜”。这个时候人们一般会把其“瓜”的卖点放在“直观性”或“易读性”上，显而易见，这是一种好的符号系统应该具备的条件。

但是，对于从小在北京长大的孩子，很自然会认为普通话是直观而易读的；而对于在美国长大的孩子，则会认为美式英语是最美最简洁的。也就是说，对语言的培训能够增加在使用者角度上的“直观性”和“易读性”。这就像我们看技术文献一样，由于我们熟悉了大量的软件最新词汇，于是不会感到ISO、CMM之类的缩写艰涩难懂；而第一次上网的人可能会认为OICQ是“我爱重庆”的缩写。

简言之，前面说的意思就是符号系统本身是不可能完全“直观”和“易读”的。

 

如果，要让所有相关人员都能够理解某种符号系统，那么，最直接的办法就是培训这些相关人员。下面的步骤可以测试一下当前的映射图到底有多直观：

1、把每一幅映射图展示给那些不知道这种符号系统的人来看。这种方法能够揭示出符号系统中不直观的地方。当然，也有可能揭示的是这个映射图中需要表达的那部分信息本身的不直观。（对应到不同的语言，就相当于让一个讲闽南语的老乡在上海某个论坛用家乡话发言。）

2、让每个人用自己熟悉的符号系统重新描述一遍对映射图的理解，然后再让一个理解这两种符号系统的人来核对。这样可以揭示映射图中的一些人为的假设。（对应到不同的语言，就相当于每个人把所需要表达的意思用方言各自表达一遍，然后再让通晓两地方言的翻译来纠正其中的偏差）

3、使用某种能够把别的符号系统自动转换成某种“标准”的符号系统的自动化工具。（对应到不同的语言，就相当于让所有人都在发言之前学好普通话，再用普通话发言。）

 

上面讲到了因为不同的符号系统导致的对映射图的理解的分歧，这就相当于由于语言不通而导致了交流障碍。最直接最常见的办法就是推迟需求工作的进度，先让大家都来学习这种语言（或符号系统）。但是，这也是不切合实际的，因为这样有可能还会让大家失去对需求过程的兴趣和冲动。经验表明，把这些学习时间安排为需求阶段的一部分会好一些，因为这时候我们可以一边学习语言，一边解决问题。

 

【鸡同鸭讲】

学过信息论的人都知道，完全的全通系统是不存在的。换句话说，就像我们前面说的，在需求工作中，严格意义上的1-1映射是不存在的。这一点对于务实的人们来说感触最多。务实一词适合用来形容军人作战时的状态，这就像是某条军规中所说：“在地图和实际地形有出入的时候，要相信实际地形”。对于这一点，成语“纸上谈兵”已经概括得很好了。

但是我们相信这个世界上还是有很多很多热衷于“纸上谈兵”的人。特别是在使用那些所谓先进的自动化工具的时候，他们往往会忘记人们实际所需而开始相信他们的所画的诸如工作流图之类的是真正的问题所在。下面这个例子是我在这个月遇到的一个真实案例，目的是说明“纸上谈兵”的态度会带来需求的偏差和歧义。

我们在几个月前参与了一次投标，当然我们中标了。

作为一个工程项目，涉及到投标内容的相关方包括甲方（买家）、乙方（卖方）和设计方。设计方在设计方案的草图中选用了型号BX的产品，这一选型并没有在招标过程中写入技术说明书中，这是因为设计方只关注型号BX的产品技术指标能够满足设计要求。

中标之后的正式合同中，考虑到性价比问题，乙方和设计方就产品技术指标问题进行了磋商，并达成了一致，最终选用了型号BY的产品，BY产品完全能够满足BX产品在该项目中设计需求，因此，而在正式的技术协议书并没有出现BX和BY的任意字样。

随着项目的开展，甲方在验收的那一天突然提出了乙方所供产品型号不符合要求的反馈，并表示要拒收产品。其理由是，这一投标是甲方整体项目中的一部分，而甲方对其它部分的招标和实施都是按照BX型号的产品设计的。

那么，这份技术设计中的草图是否应该作为产品供货的限制呢？其中作为示意方式标注的产品型号是否具有合法的效力呢？或者说，设计方在写上型号BX时是否已经使设计中“所表达的本意”与“设计图纸”产生偏差了呢？

――citizen2yy

我这里要说的是，例子中的问题很大程度上与设计方所采用的符号系统有关，而且如果我们三方能够对“真正的要求”达成一个共识，事情就不会费那么多的周折。

 

【诫条】

1、  在生活（或开发项目）当中，我们往往会遇到一些不明是由的旁人（非专业人员）横加职责，这让我们很郁闷。很显然，每个人都不可能和我们设计者一样全盘投入到产品中来，但是他们却不愿意错过每一丝繁华。当非专业人员不愿意或者不屑于花时间来了解设计过程的时候，雇用一个明白事理而又口齿伶俐的调解人会比较有效，而符号系统及其产生的映射图在产品设计中就扮演了这个调解人的角色。

2、  人们不愿意参与设计过程的一个重要原因是现在的所谓“专业设计人员”的高高在上的姿态。千万要注意顾客和旁人（实际上是决定事态结果的裁决者）仅仅是对开发过程不了解，他们在别的方面（比如说法律、业务等）却是专家，这也是需要他们参与的原因。如果能够建立一个大家融洽交流的环境，相信世界会更美好。

3、  一部分自动化过程的固执而忠实的拥趸认为他们的“直观”的符号系统很容易被别人看懂，就像一个在北京胡同里长大的5岁孩童坚信“普通话是最容易学懂的语言”一样。改变这个孩子的简单方法，是让他去教一位外国小朋友怎么说普通话；改变这些固执的家伙的方法，是让他们把符号系统向100个不同学历、不同民族的听众解释清楚。

4、  对于同一个需求过程中的两批不同背景的专家，常常会倾向于说两种不同的符号系统。那么最好的办法就是用两种不同的符号系统都表述一遍。

5、  用一种大家都能听懂的语言来作为正式文档的语言会比较有效，那么在需求过程中也最好事先指定一种“大家都能理解的”符号系统作为正式文档。如果谁不懂的话，就让他去学好了。

6、  不同母语之间的翻译会有优劣之分，同样不同符号系统之间的翻译也有优劣。优劣的背后就是分歧，也就是歧义。需求过程经历了从真正最终用户——用户代表——需求分析员——需求规格说明书这么一长串的步骤，每一步都是一种翻译，因此保证每一个步骤都是最优的就显得格外重要了。

7、需要注意的是，需求过程并不完全是瀑布式的。随着过程的深入，我们极有可能会像老牛一样进行反刍。因此，我们的探索也会考虑到如何快捷地执行“撤销”操作。

 

2 无非要偷窃、杀害、毁坏

作者：章柏幸

[e-mail]

¹⁰盗贼来，无非要偷窃、杀害、毁坏；我来了，是要叫羊得生命，并且得的更丰盛。

无论什么时候，如果人们仅仅使用那些忽略了人性因素的自动化工具，就绝不可能完美地描述需求。而且，含混性随之而来，看起来整整齐齐的需求规格说明书可能会带来各种各样的解释。 

【节外生枝】

王二注意到世界上的眼疾患者越来越多，于是他跟我们的设计组织说：设计一种保护眼睛的产品。

三个月过去了，王二来要他的产品，但是他发现几乎什么都没有得到。设计人员们还在为产品的各种可能争论不休。典型的产品方向有：各种眼镜、眼罩、眼药水、富含维生素的药丸、眼保健操、挂在显示器前的某种玻璃、视力表、科普小品文、皮尺、催眠曲……

可惜的是，王二真正的想法是要让他那位种植专业户的王五同志拥有一种新的素菜品种，这种素菜包含和丰富的铁元素和磷元素，多吃的话有利于眼部健康。

----citizen2yy

 

如果王二仅仅把他的需求陈述局限在“设计一种保护眼睛的产品”，估计是会错过素菜的种植季节的。

另一个例子，有人说“设计一种方案，用于保护一小群居民不受环境侵扰”。 《探索需求》中给出了三种不同的方案：

方案1：小土房

方案2：城堡

方案3：太空站

 

很显然，这三种方案确实提供了对需求陈述的有效的解决方案，但是这种天马行空的发挥也让我们大吃了一惊。不用说，这种差异都根源于需求陈述的含混性。

含混性的意思前面已经解释过，这里我们做一点稍深入的分析。我们认为，含混性有多种形式，就刚才的例子来看，我们至少找到了3个不得要领的地方。

（1）表意不全。也就是说，这种需求陈述缺少很多必要的产品性质描述。例如，对于这种方案的使用方法、耐用性、成本等都没有提到；对这种产品的大小、形状、重量、寿命等也没有提到；对于这种东西可能应该包含的功能、所处的物理环境、文化氛围等等等等都没有提到；我们甚至连里面的“一小群居民”到底是一小群人还是几只狗，或者是一大窝小白鼠都不清楚。

（2）表意不清。用词含糊是含混性的重要来源。比如说，“小”是一个含糊的词语，对姚明来说，2米高的家伙都是小个子；而对日本人来说，1米70的男子都已经是他们中的大个子了。还有，“群”也是含糊的词语，它暗示这些居民之间有某种关系，但是我们还是搞不灵清到底是什么关系。甚至“建筑物”一词也含糊不清，因此有了前面的几种方案。

（3）理解者自以为是。几乎世界上所有的人都拥有他们对某些认识上的成见，而视那些不同看法为偏激或是钻牛角尖。人性的弱点让他们自以为是地代表了大部分人的意见，从而把自己的偏见当成了共识，最终陷入真正的误解。例如在陈述中我们根本没有看到 “建筑物”一词，但是在不经意之中进入了我们的讨论，甚至还成为设计的基本条件了。于是，我们天马行空的想象力被局促在一个小盒子里面，再也想不出什么创新的、无需建筑而又能保护他们的方案了。你看，我们可以用屏蔽罩来防止辐射侵扰，可以用画着骷髅头的警告来防止外人误入，甚至可以用锻炼来保持身体不受病菌侵扰，用迁徙来躲避气候变迁。

需求中的含混性，在“有过去的开发人员”（参见周华健《有过去的人》）眼里，无疑就是开发过程中需求不断扩展、进度不断延期、质量不断下降、可控性不断落空的罪魁祸首。它是魔鬼，来自地狱，欲知更多分析，参见第3章《地狱》。

【殃及池鱼】

前面我们总是在稀里糊涂地向你介绍一些我们认为的真理，这里给出一点经验数据，也好证明我们不是空口白话。

《软件工程经济学》的作者Barry W. Beohm同志通过对63个软件开发项目的研究，得出了下面的表格，不妨一读，右边的是表格对应的柱状图，不妨一看。

 

发现错误的阶段

成本倍数

需求阶段

1

设计阶段

3-6

编码阶段

10

开发测试阶段

15-40

应用测试阶段

30-70

实际运行阶段

40-1000

为了修正一个错误，所要付出的成本

尽管上面的表格已经能够生动地说明：对于任何一个错误，如果能够在需求阶段发现它，那将是多么地节约成本啊！但是，专家说了，这些数字还是很保守的，因为Beohm同志研究的项目都已经完成了，也就是说这些数据中还没有包括至少1/3的没有完成的项目，而这些夭折的项目很大程度上都应该“归功于”需求分析。

20世纪70年代生产的Ford Pinto车，没有考虑任何追尾事件（需求表意不全），把燃油槽座架螺栓放在屁股上，这一设计非常“科学”。结果呢？现实中频频发生的追尾事件，这给Pinto带来巨大的威胁，于是，Ford汽车公司花了1亿美金来打官司和召回已售出的汽车。别看1亿元还不会让Ford汽车倒闭，可是又有多少家庭因为这该死的Pinto而倒闭呢？

Johns-Manville公司本来是Johns和Manville合伙的公司，他们在新产品开发中发现石棉非常适合做建材。当该公司把所有资源都投入到石棉建材，准备大发横财的时候，却引发了大量的客户起诉，据一家流行病研究公司统计，这样的起诉大约有5万多起，大多数是因为石棉会对人类裸露的皮肤带来流行病（需求表意不全、理解者自以为是）。最后，公司为此背上了20亿美元的债务，破产了。Johns也逃跑了，现在公司改名为Manville公司。

    这２个故事告诉我们，如果需求工作没做好，有可能损失１亿美金，也有可能损失20亿美金，而且破产。

【混沌初开】

几十年来的经验表明，那些错误的、失败的或灾难性的项目让投资者付出了巨大的代价，而这些项目中的大部分都起源于含混的需求。本书的目的就是为了向读者介绍一些成功应用于抑制含混性的探索需求的工具。多数持有某种信仰的人或理想主义者会认为，这个世界上存在着完全确定的东西；当他们筹建一个项目的时候，就把项目要求看成了确实存在的标准。现在，我们接下来他们提出的项目，那么，这一项目要求就成为了我们获得的需求陈述；不幸的是，这一需求陈述在绝大多数情况下是含混的。

世界上最伟大的两个物理学家，牛顿和爱因斯坦，在他们人生的最后阶段不约而同地转向了对第一推动的研究。第一推动对于深究“科学”意义的思想家尤为重要。科学本身，是一种无法自圆其说的学说；这不同于信仰，根本就无需自圆其说。于是与信仰相关的传说，比如盘古开天辟地、比如上帝造人，都将创世之初解释为一种确定的过程。而科学不然，他们需要有逐步论证的依据、可以证伪的预测、以及看起来有些道理的假设。

――citizen2yy

虽然我们在很多时候祈祷上苍的保佑，但在具体实践和委托别人做事的时候，我们总会希望所用的方法是科学的。于是，对于那个存在于理想主义者心中（或者是天堂）的需求陈述，也最好遵守一些科学的准则。

这里我们就要说明，需求探索过程是一个渐进的、可以逐步测量的过程。而我们的假设就是，我们的所有相关人员当中，的确相信存在着某种明确的需求，并且大家愿意一起来找到它们。

 

古人观察到宇宙起源于一个巨大的蛋，所谓太初之时，混沌未开；古今中外的人们都叫这个初始状态为“混沌”。我们不妨来看一下盘古先生是怎么来找到开天辟地的这道分界线的。天地有别，我们要把天从地分离出去。如果我们确实找到了地平线，就表示我们拥有了完美的需求描述。

天和地之间的这条线就是我们所需要的需求描述。

 

左边的图说明了对需求的探索过程，这其实是很简单的迭代和逐步逼近，却往往被我们的需求分析员所忽视。盘古开辟天地是一板斧一板斧来的，需求探索也是从含糊不清的描述逐步走向详尽明确的表达的。

左边图中黑色区域代表那些我们想要的内容却没有要求，或我们要求了并不想要的。通过再三使用需求工具，我们缩小了这部分区域，并越来越接近于我们不多不少想要的内容。

每一个新蛋都代表需求过程中的一个阶段，每一次中间的切分都是对真实需求线的一次更好的近似，可惜的是，这种过程永远都是近似。我们的探索，就是努力使的这种近似误差尽可能地小。

前面说了好几次“探索”了，这种探索就象是“历险”，这里给出探索的步骤，以清楚我们今后的过程：

1.         向某个方向移动。

2.         看看在那里发现了什么。

3.         记录所发现的东西。

4.         有目的地分析所发现的东西。

5.         通过对所发现的东西的分析和记录来选择下一个方向。

6.         跳回到第1步，继续探索。

【诫条】

1、  我们不喜欢含混性的原因是含混性需要成本；我们认为含混性发现得越早越好，是因为越早发现成本越低。

2、  时刻反省自己，反省自己在需求过程中的含混性，反省自己被这种含混性所带来的困扰。如果你发现产品并不完全如你所想，你可以问问自己：“是什么需求让我们制造了这样垃圾的产品？”

 

 

3 地狱

作者：章柏幸

[e-mail]

 

9我就是门，凡从我进来的，必然得救，并且出入得草吃。

如是我闻，罪恶各不相同，其来源也各不相同。为了找出含混性的来源，我们需要经过一次含混性的实验。所谓天机不可泄漏，所以敬请读者循序阅读本章。

下面，就让我们到人间走一遭。

【撒旦的诱惑】

有这么一个研讨会，演讲者是Donald C. Gause教授。主题是：“收敛设计过程，对含混性的思考”。

Gause仔细地检查了幻灯片放映机调节装置，接着他头也不抬地开始其独特的分析，说：“这个时候，它当然是好的。”然后他轻轻弹开他的第一页幻灯片直接把它放在演讲台背后的放映屏上。

这个时候荧屏上的图像并没有右边的图片那么清楚，Gause看也不看幻灯片就说：“呵呵，这张幻灯片是用来聚焦的。”

一会儿工夫，Gause就换上了下一张幻灯片，这张幻灯片是下面这个样子。

然后，演讲就正式开始了。Gause说，“今天我们来讨论收敛设计的问题，这是一个过程，通过这次研讨会，我们能够明显地有意识地识别、定义并尽可能有效地消除含混性。”

这个时候，Gause才注意到幻灯片焦距有点儿没对准。他熟练地把幻灯片调得非常清楚。然后继续开始他的演讲。演讲中的例子我们在这里不作描述，因为那是我们在下一章中将要介绍的，这个例子的确非常有趣而又具有针对性；美国大学中传统的Seminar式交流使这后续的讨论非常愉快。

说着说着，Gause引进了一些设计的模糊理论，论题开始变得有点艰涩，这时，中间休息时间到了。

【定力】

在开始这一小节之前，我们希望读者能够想象自己正在那个Seminar中沉浸于对设计过程的讨论，以及对那个模糊设计理论的思考。

然后，我们各就各位，开始加入了下一半的讨论。这时候，Gause先生说：

 

“下面的问题，请大家独立回答，并在自己的记事本上记下你们的最精确的、最严格的、最负责的估计，同时提醒大家一定要根据自己的第一印象独立回答！”

 

读者朋友，我们也不妨静下心来看看屏幕上到底是什么问题。幻灯片上的问题是：

How many points were in the star that was used as a focus slide for this representation?

考虑到这个例子的特殊意义，我们保留Gause先生在真正的演讲中所用的英语，看不懂英语的读者，可以把问题理解为：“这次讲演中用于聚焦的幻灯片中的星星有多少个点？”

这似乎是在考验我们的定力，让我们想起那个“说遍了公交车每一站上站下站人数而最后问总共停靠了几站”的问题。

不过这时候Gause又翻开了一张新的幻灯片，并说：

 

“这一问题包含了世界上需要设计的全部内容。例如说，你的回答可能会影响到某个关键的设计问题。或者说，某件重要事件发生了，但你却没有在它发生的时候意识到它的重要性。于是所有人都必须尽可能详细地再现那些重要信息。现在，请写下你对刚才屏幕上提出的问题的回答。”

 

好的，真正的定力考验到了。为了亲身体验这一过程的全貌，请大家不要回头看前面的图片以及本页中的那个英文问题，仅仅是根据记忆，按顺序每次回答一个问题。

 

千万注意，回答时一定要注意逐个回答，答完第一个再去回答第二个……

 

1.         你认为刚才那个英文问题的答案是什么？

 

 

 

2.         如果有100个人和你一样来回答第1个问题，大家可能会写下多少种不同的答案？

 

 

 

3.         如果你认为可能有多个答案，可能会有哪些大致的答案呢？

 

 

 

4.         发挥你的回忆能力，逐字写下在问题1中你认为你所回答的问题。

 

 

 

5.         有100个人和你一样会回到第4个问题，即写下他们所认为的那个英文问题，你认为他们所写下问题的有些什么差别，也把它记下来。

 

 

 

    当您回答完这5个题目的时候，我们的定力测验到此结束。这好像是已经过了一个非常漫长的过程，或许您已经迫不及待地想要看下一章中的那个关于收敛设计过程的实际案例，或者你很想回头看一下前面的幻灯片或问题。那就不妨向后或向前看一下。然后再来看我们的人间正道。

 

3 地狱-2

作者：章柏幸

[e-mail]

【人间道】

上述5个问题同样被发给了参加研讨会的人们。

本节我们讨论前3个问题。请思考这3个问题的共同特性。

我们知道，每个人都会对事物产生某种第一感觉，有时候也称为是直觉，这种直觉一方面来自于观察，另一方面则是来自于经验。经验对于我们判断的影响很大程度上是不自觉的。而这3个问题，实际上是强化了你对自己直觉的信任；也就是说，这3个问题的答案使你确信你自己的答案，就像是一再地在向你询问：确定吗？真的确定了？不再改了？（中国中央电视台，《开心词典》栏目，王小丫语）

经过3个问题的定力考验，我们能够相信你的判断是发自内心的。如果我们根据你和研讨会成员的回答把你们分成几组，你一定会认为你自己是站在正确答案这一组的。

问题1：对于那个在屏幕上提出的问题你认为答案是什么？

答案只有你知道。

 

问题2：如果有100个人和你一样来回答第1个问题，大家可能会写下多少种不同的答案？

问题3：如果你认为可能有多个答案，可能会有哪些大致的答案呢？

你的答案也只有你知道。但是，根据100个真实参与者的实际回答，我们得到了18种不同的答案。这时候，你可能就迷糊了，而且你开始怀疑对第3个问题的回答了。

参与者的答案 回答该答案的人数 1 3 2 1 5 16 6 11 7 18 8 17 9 13 11 1 13 2 14 5 15 1 16 4 21 1 24 1 29 1 30 1 32 1 +∝ 3

实际回答如左表所示，一共是从1开始到正无穷大共18种答案。

我们观察得到，对于左边的答案，可以划分成几个区间，每个区间都有一定人数的支持者，因此我们做了一个简单的整理，变成了如下的列表：

参与者的答案（类） 回答该答案的人数 0~2 4 5~9 75 10~12 1 13~16 12 21~24 2 29~32 3 >32 3

很明显，我们整理之后出现了几类大致的答案。而你一定和现场的参与者一样，会惊讶于这之中的某些答案。我们的经验告诉我们，这些重大的差异来自四种可能：观察错误、回忆错误、理解错误、问题描述的含混性。

 

下面简单分析一下这些差异的来源，以能让读者能够接受这种差异存在的合理性。

观察错误和回忆错误。不可否认，每个人的观察能力和关注点都会有所差异，因此，任意两个人都不一定会看到完全一致的东西（观察错误），或者完全一致地记住他们所看见的东西（回忆错误）。如果我们意识到这2类错误，我们就能理解和我们处于同一类但是稍有误差的其它观察者了。毕竟那张幻灯片才放了不超过1分钟，而且在这之前从未被强调过，几乎没有人会认为那个破星星会是本次研讨会的主角。

理解错误。刚才说到，我们可能会惊讶于那些与我们的回答截然不同的答案，这很大程度上是因为彼此对问题含义的理解不同。我们询问了回答这些答案的一部分参与者，分析如下：认为答案是0～2的回答者认为Gause先生问的是那个7角星星里面的两个黑点。认为答案是5～9的回答者认为Gause先生问的是那个大7角星有几个角顶点。认为答案是13～16的回答者则把7角星的内外角顶点都算在内了。认为答案是正无穷大的回答者则认为每条线段上都包含了无穷多个点。

问题描述的含混性。还有两类人好像无法用理解错误来解释，实际上认为答案是21～32的回答者认为Gause先生问的是第二张幻灯片中的星星个数。很显然，他们认为那个聚焦幻灯片是第二张。

 

不仅如此，由于作弊、参与者之间的交流、对上述分类结果思考之后再对答案的修改等等因素，还会改变回答者的答案。这些改变应该是来自于对问题的理解，而不是改变了回忆或提高了观察力。

【道可道，非常道】

按照我们前面的说法，与会者的答案的差异大致有4中可能来源。而且看起来我们都能够理解前面三种来源，即观察、回忆和理解错误，因为这三项来源都与观察者自己有关，本着严于待人、宽于待人的原则，我们的确需要着重地强调第四个含混性来源，也就是：

 

问题描述的含混性

 

这一来源在上节中被一笔带过了，因为这实在不是凡人所能够搞明白的。我们这里也仅仅是根据研讨会的现场结果，给大家展示这一来源的五花八门。第4、5个问题如下：

问题4、发挥你的回忆能力，逐字写下在问题1中你认为你所回答的问题。

答案只有你知道。不过现在要把这个答案拿出来，以作它用。

 

问题5、有100个人和你一样会回到第4个问题，即写下他们所认为的那个英文问题，你认为他们所写下问题的有些什么差别，也把它记下来。

很显然，由于我们在回答问题的时候，已经看不到幻灯片上的问题，也看不到那张所谓用于聚焦的幻灯片，因此我们的回答很大程度上会依赖于问题本身的明确程度。如果我们看到的问题是“What’s your mother’s name?”或是“你妈贵姓？”之类的问题，我相信除非是你完完全全心不在焉，否则即使是过了1个星期，你一样能够清楚地回忆起这个问题。但是现在地结果却并不那么明确了。

前面说过，我们中的大多数总是把自己定位在掌握了真理那一群人里面的。也就是说，我们相信我们自己的判断和记忆。因此，我们很容易会认为我们自己和别的参与者一样，都是在讨论同一个问题。这个时候，我们会很自信地写下问题4和问题5的回答，并相信自己最多会记错两个单词。

然而结果却让我们大吃一惊。我们列出了实际收集的问题4的一共24种回答：

序号

答案

（英文）

答案

（中文）

1

How many points did the star have?

这个星星有多少个点（顶点）？

2

How many points were there in the first slide?

第一张幻灯片中有多少个点？

3

How many points did the star have in the first slide?

第一张幻灯片中的星星有多少个点（顶点）？

4

How many points were on the star that was used as a focus slide?

在那个用作聚焦幻灯片的星星上有多少个点？

5

How many points were on the star in the first slide of this presentation?

在这次展示中的第一张幻灯片中的星星上有多少个点？

6

How many points were in the focus star at the beginning of this presentation?

在这次展示开始的聚焦星星中有多少个点（顶点）？

7

How many points were on the star that was used for focusing?

用于聚焦的星星上有多少个点？

8

How many points did the star used for focusing at the beginning of the presentation have?

在展示开始的时候用于聚焦的星星有多少个点（顶点）？

9

How many points (external) are on the star I used to focus?

我用于聚焦的星星上（外部）有多少个点？

10

How many points were there on each star on the slide used for focusing?

在用于聚焦的幻灯片上的每个星星上有多少个点？

11

How many points did the star have that was used as a focus slide?

用作聚焦幻灯片的星星有多少个点（顶点）？

12

How many points were on the star that was used to focus at the start of the class?

在课程开始时用于聚焦的星星上有多少个点（顶点）？

13

What was the number of points on the star slide that was used to focus on?

用于聚焦的星星幻灯片上点的数目是什么？

14

How many points were in the focus slide star?

在聚焦幻灯片星星中有多少个点？

15

How many points in the picture of the star, used as a slide?

用作幻灯片的那张星星图片中有多少个点？

16

How many points were there in the star on the slide?

在幻灯片上的星星中有多少个点（顶点）？

17

How many points were shown on the test star?

在测试星星上出示了多少个点？

18

How many points are on the star slide used to focus at the beginning of the slide presentation?

在幻灯片展示开始时用于聚焦的星星幻灯片上有多少个点（顶点）？

19

How many points did the star shown at the start of the presentation have?

在展示开始时展示的星星有多少个点（顶点）？

20

Determine how many points were present in the star shown earlier in the slide presentation?

确定在幻灯片展示的早期出示的星星中呈现的点数？

21

How many points were there in the original foil which was used to focus the foil?

用于聚焦叶形图的原始叶形图中有多少个点？

22

How many points were on the star that was shown at the beginning of the lecture?

在演讲开始时出示的星星上有多少个点？

23

How many points were on the focus slide?

在聚焦幻灯片上有多少个点？

24

How many points were on the star shown as the first slide?

在第一张幻灯片中出示的星星上有多少个点？

How many points were in the star that was used as a focus slide for this representation?

我们在上表的最后一行重新写上了幻灯片上真正的问题，很显然，这一个真正的问题已经让100多个参与者摸不着头脑了。如果，这样的问题描述出现在需求规格说明书当中；如果，我们的设计人员、客户、编程人员、销售人员在实际工作中不是一词一句地记熟了所有条款，这样的24个答案随时会出现在真实的项目中。

我们在这个问题上找到了很多含混不清的词语，而且确实是这些看起来非常琐细的细节，给问题带来了截然不同的理解、回忆等等；这种问题描述的含混性实际上已成为成功项目和灾难性项目之间的分水岭。

【诫条】

1、  撒旦总是在你最不留神的时候诱惑你。含混性也总是在你最不留神的时候出现，并且，这种含混性最不容易被发现，也会给设计开发带来最大的灾难。

2、  观察错误、回忆错误、理解错误是最常见的含混性来源。我们有很多种找到它们的方法，实际上，更重要的是意识到它们存在的风险，并采取行动。

3、  问题描述中的含混性是最难于处理的来源，它也是前述3种错误的诱因。由于这些含混性将是开发成败的关键，因此给我们的需求工作提出了非常苛刻的要求，而本文后续介绍的经验和工具，正是为这一工作所设计的。

4、  找出含混性来源的办法推荐如下：

a)         对参与者进行需求文档某些部分的解释进行提问，并把相近结果归成一类。

b)        通过询问每一类中的人们的想法来分析对每一类的理解。

c)        同一类内部的差异来自于观察错误和回忆错误。

d)        为了辨识各类之间的差别，可以请参与者回忆那个他们认为的被问的问题，当然不能给他们再看一遍。这个种方法能够找出解释错误。

e)         通过对观察、回忆、解释错误的分析，找出问题描述中易犯上述错误的地方，修改它，或者做一些详细的注记。

 

4 逃跑的雇工

作者：章柏幸
[e-mail] 

12若是雇工，不是牧人，羊也不是他自己的，他看见狼来，就撇下羊逃走。狼抓住羊，赶散了羊群。

13雇工逃走，因他是雇工，并不顾念羊。

人往往如此；当你了解、学会、掌握、熟练了一种工具之后，就很难接受别的类似工具；而对于那些本质上并不类似的工具，人们也会自然地产生排斥心理，会说，“你的功能我们的工具一样可以实现。”

有头脑的人，是不会仅仅局限于一两种工具的，因为他们知道，每一种工具都有它的针对性和局限性。古话“术业有专攻”也是这个道理。那么，为了很好地搞定我们的项目（产品）开发，我们一样需要有专门的工具和技术；针对于需求分析中的某些关键点，我们还需要对之进行更深入的研究。目前市面上有很多很多的项目管理的工具、方法以及软件，是否只要使用好它们我们就能一路顺风了呢？

我们认为，掌握各种各样的工具是很不错的主意；而且，如果你想很好地做好需求工作，最好能很好地把握直接的提问、面对面的观察和谈判技巧。但是，出于对工具局限性的担心，我不得不提醒读者再次注意人类思想的复杂性和含混性。我们常常会看到一些理想主义的需求分析员编制各种各样的表格和调查问卷，然后根据表格里面的文字和数据来撰写他们的需求规格说明书；这一节就是要说明这种死板的方法是不能够完全正确地获得需求的。

【尽心尽责】

《探索需求》一书中提出探索过程是对决策树从根节点到叶子节点的一次遍历，我在这里做一个简单的解释，在后面我们将作一个简单的拓广。

数学模型是一种对现实世界的抽象。比如，现实生活中的树从树根开始，在阳光的照耀下，按照主干、分支、细枝、树叶这么一级一级地成长。由于数学家和程序员的工具的局限性，即我们的打印纸和书写习惯都是从左到右和从上到下的，于是我们得到的树的数学模型变成了树根在上，叶子在下的样子了。这个样子虽然很难看，但我相信读者已经都能够接受这种模型的，理由是我们从中学到大学已经对这种符号系统接受了一些培训，这一点反过来说明了我们在第1章《贼和强盗》中关于符号系统和映射需要培训的论点。

决策树模型是对线性决策理论的一种数学模型，我们借来作为对直接提问方式的辅助工具：它的根节点是对问题的第一个模糊的描述。每一个节点表示一次提问或决策，而到达的叶子节点则是最后的解决方案。很显然，一棵正常的树不会一根枝丫长到底；同样，我们的直接提问也不可能一帆风顺。每一个分枝的地方，都会出现多种分岔的选择，而每一种选择，都意味着放弃了另一个更为广阔的含混空间。

理想主义者认为只要每一个选择都由用户判断，每一个决策都经过用户签字，那么他们的决策树很快就能安全抵达叶子节点。（这种想法是要不得的，但这是后话，暂时不提。）我们暂且认同每个判断的正确性和明确性，这于是给我们的决策带来了严重的压力，每一个分枝的地方都会有明确的用户配合吗？这是天真的想法。我们不可避免会加入我们自己的“经验”，实际上是我们的假设。

首先需要说明的是，决策的次序非常重要。比如，如果客户想要一辆绿色自行车，那么如果给他一辆橙色自行车可能会比一个绿色卡车来得比较容易接受。因此，问题“它是什么颜色的？”和问题“它是自行车还是卡车？”相比较而言应该问得较晚。次序的重要性还体现在它能够减少我们为错误决策减少修复误差。

如果您学过信息理论，那么我们就可以量化这种问题次序的价值。解决方案是一种逆天而行的行为，它试图通过人类的智慧，在局部地区实现反热力学第二定律的走向。

我们的信息度量是这样的：最初，含混的问题具有无穷多种可能性，其信息量为零，其含混性为无穷大，其信息熵也为无穷大。每一个问题的回答，都能够减少可能性，降低含混性，提高信息量，降低信息熵。针对每一个问题的重要程度，我们可以通过经验或是客户联席会议来确定其量化的加权值，该加权值就是这个问题的价值，也可以看做是问题的信息量。根据最优编码定理，我们可以得到每一个问题对应的Huffman码值，这一Huffman码值的长度就是我们应该对该问题的重视程度的度量。

 

下表列出了一个典型的设计案例中的直接问题问答，根据客户对10个问题的回答，读者心里是否已经对需要解决的问题有了一个方案了呢？

序号

问题

回答

1

需要我们干什么？

设计一个运输设备

2

有什么时间限制？

在18个月之内完成

3

运输什么东西？

人

4

每次可以运输多少人？

每次一个

5

动力来源是什么？

乘客自己提供动力

6

在什么样的表面上运输？

它应该在很硬的平坦地表上提供运输

7

人应该被运输到多远？

超过2千米。

8

设备的行进速度？

至少每小时能行进400米。

9

故障率方面的指标怎样？

每三千里的里程最多有一次故障。

故障发生时不能危及乘客的生命安全。

10

大概要多少成本？

分摊到每次使用的成本不超过200元。

【迷途羔羊】

经超过1000名专业系统设计者证实，上表中的对话是一个优秀的问题系列。我们很快可以作出我们需要产品的可能选择：

1、  溜冰鞋。

2、  自行车。

3、  三轮车。

本来我们是很愿意想到电瓶车的，但是由于问题5的答案让我们放弃了这种安全绿色而快捷的交通工具。因此我们选择了自行车作为备选。

本来我们也是很愿意想到滑翔机的，但是由于问题6的答案让我们放弃了这种天空中翱翔的念头。

很显然，上述三种选择都能够满足上述10个条件，我们注意到这三种运输设备都有一个共同点，那就是都有轮子。为了保证我们的设计能够被客户接受，我们把设计人员分成两组：小轮子组和大轮子组。两组设计人员都完成了创意精彩的解决方案。

小轮子组递交了一种多功能溜溜鞋，它可以采用便捷的即插即用技术，溜溜鞋的底部安装了一个牢固的插槽，它可以装上冰刀、滚轮以及撬板等多种标准接口附加配件。设计人员还公布了溜溜鞋标准插槽接入标准方案，拟在业界推广。另外，额外的销栓装置能够大大降低故障率。大轮子组递交了一个紧凑的、不重的、可折叠的三轮车，它可以放在步行者的旅行包中带走。

下面是我们在客户那里展示样品时的场景：

两个客户来观看我们的样品，他们对我们的创造赞不绝口，尤其是那个三轮车的轻便性。可是，其中一个问道：“请诸位解释一下这种设备如何在艾格尔上的北坡用于救援登山者。”

我们呆在那里了。你是否也呆在那里了？

客户解释说：

在他们的脑海里那是一个登山者救援设备，他们两人分别是梅隆镇和比斯镇的镇长，由于两镇的经济主要依赖于旅游和特殊登山。为了保持旅游业的增长并确保登山的回头客，村庄的正式导游必须去救助那些被困在山坡上的登山者。然而，随着人们对生命的重视，导游们越来越不愿意为救助粗心的登山者而冒生命危险了，因此他们的队伍越来越小。镇长们认为，除非有一个解决方案出现，否则村庄的经济将会受到威胁。

因此，镇长们需要一个营救设备，这样他们就能让所有登山者都可以尝试去攀登垂直高度为1500米高山峰北面。登山者不论在什么时候因为恶劣的天气、精疲力竭、受伤、害怕或是供给不足等原因必须返回时，这个设备就可以投入使用，以着陆到硬的平坦地面上。这一设备可以在任何村庄租用，每次租用缴纳一定押金，租用费用为每次400元，这样每次租用村庄就能获得大约200元的毛利；当然，是用于挽救生命的。

 

很显然，我们迷路已经很远很远了。

我们不妨回头看看我们的道路，客户很客观很配合地回答了我们的直接提问，而我们在构建决策树、探索解决方案时给方案添加了大量的假设。例如：

1．  有轮子的。

2．  在硬的表面运输的水平运输装置。

3．  不会飞的。

4．  这种设备是紧凑的。

5．  设备的高轻便性。

6．  产品的销量很大，因此单位生产成本很小。

 

或许我们可以记住：

仅凭经验，并不能说明我们就能很好地把握“知识”与“需求”之间的关系。

【恶在人间】

前面的例子似乎有点刁难，但它能够很好地模拟那些喜欢在一个小房间里面设计项目中的含混性；这种情况往往会在刚从理想主义象牙塔里面出来的人们中发生。许多实际案例中，含混性程度并不那么明显，但是分布之广却有过之而无不及。

有一次，我们在对一个在线银行系统的需求规格说明书的复审中，光在第8页就发现了121个地方可以被不同的复审者用至少2种方法解释的含混点。这仅仅是886页需求规格说明书中的一页。我们可以估计一下，这种需求中含混点大概会有886*121=107206个。如果我们的设计人员遵从这份需求来进行设计，那么这些含混点都需要它们通过猜测来决策。那么，我们每次猜中正确含义的概率又有多少呢？

――温伯格&高斯

 

我们说，我们需要一些额外的工具和技巧来降低含混性；这是因为“我们常人并不擅长于发现我们已经忽略的东西”。这种心理学上的观察结果实际上严重地困扰了我们这些设计者。例如说，我们无法用肉眼看到X射线，我们无法用自己的耳朵听到超声波，我们无法步行漫游世界。

自然，我们不会因此为上述不足感到不安；那么，我们为什么要为自己未能够发现那些自然忽略的内容而内疚呢？正是因为上述不足，人们发明了各种各样的工具来获得成功；同样地，我们不妨也可以接受这些用于需求分析中降低含混性的工具和技术了。

这些工具和技术，我们可以在《探索需求》中找到；当然，如果我们愿意的话，不妨关注一下这个系列文章的续集。

【诫条】

1、  分歧无处不在，设计者最容易自以为是地认为他们心目中的解决方案就是客户想要的，而实际上这往往给客户强加了很多假设。即使我们发现我们的解决方案远超过客户所知，千万不要过度自满，要么去说服他们，要么去寻找能接受你的方案的新客户。

2、  直接提问时，可以使用决策树。但是千万注意对每一个问题的回答进行一次口头的和书面的确认，即把客户的回答写出来给他们看，这可以锻炼你的文字表达力，也是降低含混性的技巧。

3、  有责任的需求工作者接受我们的思想，但是他们开展工作的困难不止来自于客户，也会来自于他们的那些守旧的同事。我们必须说服这些人，最好的方法就是举一些你们共有的失败的例子。不过千万注意不要让对方难堪。

4、  理解并接受自己的局限性，同样也理解并接受客户和同事的局限性。