|
羊的门
7我实实在在地告诉你们，我就是羊的门。
8凡在我以先来的，都是贼，是强盗，羊却不听他们。
9我就是门，凡从我进来的，必然得救，并且出入得草吃。
10盗贼来，无非要偷窃、杀害、毁坏；我来了，是要叫羊得生命，并且得的更丰盛。
12若是雇工，不是牧人，羊也不是他自己的，他看见狼来，就撇下羊逃走。狼抓住羊，赶散了羊群。
13雇工逃走，因他是雇工，并不顾念羊。 ——圣经·新约·约翰福音·第10章 “我从很小就开始对‘人们如何思考’产生了浓厚的兴趣；那时我还是一个小男孩，世界上仅有的计算机被人们称为‘巨型大脑’；我当时就想，如果我搞清楚了这些巨型大脑的‘思想’，我或许就可以更深入地了解人们是如何思考的。”——杰拉尔德·温伯格。 在看到这个题目的时候，读者朋友可能会想起几年前李佩甫的一部同名小说。这里说的和那本小说看起来没什么关联，但是又仿佛有着莫大的联系。在我改写这部分文稿的时候，脑海中总会时不时浮现出盗贼、羊、雇工、狼、牧羊人的图景，我发现，我们在这里讨论的内容所遇到的问题和耶稣所遇到的责难一样难以处理；而我们所做的事业，正是在帮助那些心地善良而又不知天堂之路的迷羊找到正确的回家之路；这就是羊的门。 下面2个小节，介绍一下本文的主要目的和关注点。 《探索需求》是Donald C. Gause和Gerald M. Weinberg合作的一本探索软件开发项目需求部分的书。本文的目的是为了用一种更为适合中国人的方式来表述书中第一部分的观点。在项目管理者的眼里，世界上的一切问题都可以归结为项目。项目从开始到结束一般会有很多阶段，而“需求分析”阶段就是用来搞清楚“我们在这个项目中需要解决什么问题”的。 这本书的关注点就在“需求分析”阶段。虽然这个阶段的书籍和论文已经很多了，但是经验表明，我们还是有必要阅读这本书，因为这本书中还有很多别的书中没有提出过的有用的观点。《探索需求》的第一部分就是要讲清楚为什么需要这本书或这本书中的一些技巧和观点。这也是本文的重点。 简而言之，需求分析阶段需要经历两个步骤： 1、提出问题的人说一些话，以告诉帮助他解决问题的人他要干什么。 2、解决问题的人和提出问题的人进行沟通，以确证这个问题的细节。 第一步就是“问题陈述”，这和法庭上指控方、被指控方的案情陈述有点类似。 第二步就是“探索需求”，这和法庭上的双方律师不断地分析对方以及询问证人有点类似。这里律师就是需求分析员。 只有律师把事情来龙去脉用合乎法律的方法表述清楚之后，法官才能够正确断案。也就是说，只有需求分析员把问题的关键分析清楚之后，开发者才能够做出正确的产品。 下面举出的这个例子说明了一个观点，即：如果你说清楚了你的需要，那么你就很可能得到它；如果你没有说清楚你的需要，那你就很可能得不到它。当然这个观点很简单易懂，也就是说这个例子可以略过不读。 我们要求五个小组甲、乙、丙、丁、戊在几乎相同的“问题陈述”下进行程序开发，说“几乎相同”的意思就是其中有且只有一个句子各不相同，分别如下： 小组 要求 甲 开发时间尽可能少 乙 源代码行数尽可能少 丙 占用内存尽可能少 丁 程序的可读性尽可能高 戊 程序输出尽可能清楚 最后的结果就是，每个小组开发出来的程序都满足了这句特殊的要求，而没有满足那些没有被要求去做的。我们常常听到一些购买软件的人抱怨软件开发商没能开发出他们真正想要的东西，那么这里反过来可以这么认为，并不是开发商不能开发出来，而是他们不知道要开发出什么，这里面的问题就是：开发商没有好好地调查好需求，或者是购买者没有好好地讲清楚需求。这里我们不追究谁的责任，关键是我们确证了“你要你就说，你不说我怎么知道你要呢（参见《大话西游》，唐僧语）”的真理。
经验表明，上述例子在全世界的软件开发商中都有发生。尤其需要指出的是，“问题陈述”和“人们真正想要的东西”之间的差距不仅仅在软件业频频发生；而是，只要有人需要解决别人的问题，只要有人需要别人为他设计和生产产品，只要存在某种供需关系；这种差距就存在，就需要有人来解决这个差距问题。 高斯和温伯格，软件界的两个泰斗级的人物，为了解决这个差距问题，已经花费了60多年的时间了。而这本书中的内容，正是对这些问题的心得。
贼和强盗 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、需要注意的是，需求过程并不完全是瀑布式的。随着过程的深入，我们极有可能会像老牛一样进行反刍。因此，我们的探索也会考虑到如何快捷地执行“撤销”操作。 无非要偷窃、杀害、毁坏 10盗贼来，无非要偷窃、杀害、毁坏；我来了，是要叫羊得生命，并且得的更丰盛。 无论什么时候，如果人们仅仅使用那些忽略了人性因素的自动化工具，就绝不可能完美地描述需求。而且，含混性随之而来，看起来整整齐齐的需求规格说明书可能会带来各种各样的解释。 【节外生枝】
王二注意到世界上的眼疾患者越来越多，于是他跟我们的设计组织说：设计一种保护眼睛的产品。 三个月过去了，王二来要他的产品，但是他发现几乎什么都没有得到。设计人员们还在为产品的各种可能争论不休。典型的产品方向有：各种眼镜、眼罩、眼药水、富含维生素的药丸、眼保健操、挂在显示器前的某种玻璃、视力表、科普小品文、皮尺、催眠曲…… 可惜的是，王二真正的想法是要让他那位种植专业户的王五同志拥有一种新的素菜品种，这种素菜包含和丰富的铁元素和磷元素，多吃的话有利于眼部健康。 ----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、 时刻反省自己，反省自己在需求过程中的含混性，反省自己被这种含混性所带来的困扰。如果你发现产品并不完全如你所想，你可以问问自己：“是什么需求让我们制造了这样垃圾的产品？”
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
