含混性的形式和来源

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

    我们认为，含混性有多种形式，比如：

    （1）表意不全。也就是说，这种需求陈述缺少很多必要的产品性质描述。例如，对于某种方案的使用方法、耐用性、成本，对这种产品的大小、形状、重量、寿命，以及对于这种东西可能应该包含的功能、所处的物理环境、文化氛围等等都是需求陈述中非常重要的组成部分。

    （2）表意不清。用词含糊是含混性的重要来源。尤其要注意一些模糊概念的词汇运用，比如说，大、小、多、少、非常、很，等词汇都非常难以度量。

    （3）理解者自以为是。几乎世界上所有的人都拥有他们对某些认识上的成见，而视那些不同看法为偏激或是钻牛角尖。人性的弱点让他们自以为是地代表了大部分人的意见，从而把自己的偏见当成了共识，最终陷入真正的误解。

    需求中的含混性，在有经验的开发人员眼里，无疑就是开发过程中需求不断扩展、进度不断延期、质量不断下降、可控性不断落空的罪魁祸首。

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

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

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

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

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

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

    需求探索过程就象是“历险”。为了避免含混性，我们要随时提醒自己：

    我们不喜欢含混性的原因是含混性需要成本；我们认为含混性发现得越早越好，是因为越早发现成本越低。
 
    时刻反省自己，反省自己在需求过程中的含混性，反省自己被这种含混性所带来的困扰。如果你发现产品并不完全如你所想，你可以问问自己：“是什么需求让我们制造了这样垃圾的产品？”

    在需求工作中，会有若干种含混性产生，主要表现为：１）观察错误和回忆错误，因为我们每个人的观察能力和关注点都会有所差异，因此，任意两个人都不一定会看到完全一致的东西（观察错误），或者完全一致地记住他们所看见的东西（回忆错误）。２）理解错误。３）问题描述的含混性。

    其中观察、回忆和理解错误，都与观察者自己有关；而问题描述的含混性，则与表述者有关。这就牵涉到我们前面说过的符号系统。

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

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

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

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

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

    通过对观察、回忆、解释错误的分析，找出问题描述中易犯上述错误的地方，修改它，或者做一些详细的注记。
 
    善用工具来降低需求中的含混性

    人往往如此；当你了解、学会、掌握、熟练了一种工具之后，就很难接受别的类似工具；而对于那些本质上并不类似的工具，人们也会自然地产生排斥心理。我们知道，每一种工具都有它的针对性和局限性。那么，为了很好地完成需求开发，我们一样需要有专门的工具和技术；针对于需求分析中的某些关键点，我们还需要对之进行更深入的研究。目前市面上有很多很多的项目管理的工具、方法以及软件，是否只要使用好它们我们就能一路顺风了呢？

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

    我们常常通过问问题，根据回答建立目标产品的各个属性，以构建产品的决策树。

    理想主义者认为只要每一个选择都由用户判断，每一个决策都经过用户签字，那么他们的决策树很快就能找到真正需要的产品。其实我们就算是能够作到每个判断的正确性和明确性，也会给我们的决策带来了严重的压力，每一个分枝的地方都会有明确的用户配合吗？另一方面，我们不可避免会加入我们自己的“经验”，实际上是我们的假设。

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

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

    在降低含混性方面，我们需要注意以下内容：

    分歧无处不在，设计者最容易自以为是地认为他们心目中的解决方案就是客户想要的，而实际上这往往给客户强加了很多假设。即使我们发现我们的解决方案远超过客户所知，千万不要过度自满，要么去说服他们，要么去寻找能接受你的方案的新客户。
直接提问时，可以使用决策树。但是千万注意对每一个问题的回答进行一次口头的和书面的确认，即把客户的回答写出来给他们看，这可以锻炼你的文字表达力，也是降低含混性的技巧。

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

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