UML软件工程组织
如何收集用户需求
作者:不详  来源: Techrepublic.com.com  

收集用户需求(你也可以将它称作启发用户需求,如果你更喜欢这个花哨的名称)一般比较困难,现在让我们考虑一下为什么这个过程如此艰难,当你面对这个问题时你会采取什么办法处理。我想,此时,有两个问题你必须先考虑:即何为用户的隐含需求(即未明确表达出来的需要),何为明确需求,如何在它们之间进行转化,以及这种转化的意义?

任何曾经从头开始开发过应用程序的开发者都知道:在用户陈述需求或主题专家描述代码应解决的问题时,我们很难完全理解他们的目的。大家都知道,需求收集是一种挑战;但是,为何难以收集到合适的需求、该采取什么办法,这些问题就更难以理解了。

其实,用户的隐含需求与明确需求的概念,类似于我们日常所说的默会知识与明确知识的概念,因此弄清楚默会知识与明确知识的涵义以及它们之间的转化关系,对我们研究用户的隐含需求与明确需求很有意义。现在,我们先来了解一下默会知识与明确知识的概念以及相互的转化过程。

默会知识

 默会知识指基于经验和观察的知识。不存在一些由以前传承下来的法则或程序。它只是做事的方式而已。由于它的相关性,它具有非常强大的力量,能够直接应用于将来需要解决的问题上。

默会知识的一个例子来自我的一个靠做零工为生的朋友。由于我们很谈得来,所以他和我喜欢一起做事情。最近,我们正在我的车库里为教堂做鼓架,他不断表现出各种小知识。我们先做好框架,然后再把它与平板连起来;而不是一次一块木块在平板上做框架。为什么这样做呢?答案是那样更加方便简单。他怎么知道这样做呢?他做过许多这类活(做橱柜和讲台),足以知道这些知识。

他知道各种各样的知识,例如,确信木板的顶部,所有木材正常的轻微弯曲部分全部向上。为什么呢?因为当它载重时,它会产生变形,由弯变平,回到中间位置。

另一个例子是我几年前在大学里学到的东西。它与循环结构有关。我的导师建议我使用一个在循环开始之前就执行初始阅读的循环结构。当时我使用的结构在循环开始后才进行阅读,所以循环中包含一个巨大的IF块。

当时她建议我使用一个将阅读语句放在循环前的新结构,我问为什么。她回答道:“因为这是更好的方法。”凭经验,她知道在循环开始之前(和循环结束之后)执行阅读会更好。
在学徒期,主要学习的是默会知识。从一个比你经验更加丰富的人那里,你学会处理事情的方式。通过这种方式,我们学会制造优良产品或加快工作速度的细小而微妙的方法,这些知识是你在正式的教科书中无法学到的。

一些人就是知道凭经验来做事情。你可能很难让他们向别人解释这些知识,或将它们写下来,但他们确实知道这些建立在经验之上的知识。

明确知识

 相对于默会知识,明确知识是指可以被量化的知识。你可以将它们书写下来,在人们之间传达。它是实实在在的,不是获得的经验。它是那种已形成规则的知识。

例如,一个人看到苹果从树上掉下来,并知道摇苹果树来得到苹果——默会知识——并且他可能还知道重力作用使所有物体集合在一起。最初通过观察获得的默会知识,最终转化成一种定律,明确知识。

明确知识是通过文章、书籍、研讨会和视频演示传达的知识。明确知识我们总可以在书本商找到,因此没有必要直接经历某事来获得与其相关的明确知识。这是刚毕业的学生受到的批评的原因之一:他们拥有许多“书本知识”(明确知识)但缺乏实际经验(默会知识)。我们很清楚地知道,不管明确知识有多么重要,它总是无法代替默会知识。

另一方面,由于印刷机的出现,明确知识以更为快捷的速度在传播。由于我能够将默会知识转化成一组你能够应用的规则,所以你正在阅读这些文字,并学会各种不同的知识。

 了解两者的转化过程

 科学哲学家托马斯-库恩认为科学源自“常规科学”、“危机”和“革命性典范转变”这一循环。这种模式涉及新科学的发展,说明了默会知识与明确知识之间的关系。我们从科学方法的核心——默会知识——开始。

科学方法的第一步是观察——换句话说就是积累经验。然后我们再假设我们所观察的事物的运作方式。接下来再对假设进行检测,如果结果不正确,我们再进行测试。

科学方法的结果是明确知识——世界如何运转得到验证的假设或理论的试金石。这种明确知识不必经过广泛的体验,就能轻松迅速地在人们之间传播。

但是,库恩意识到这并非最终结果。最终,假设会出现缺点、差距或错误。这将形成质疑明确知识的危机。这种被对明确知识的关注所验证的默会知识,开始挑战似乎世界按其运行的明确知识。

最终,由新默会知识带来的压力产生一种革命性的典范转变,这一转变建立一种新的明确知识,它成为所有新型默会知识为人所知的基础。

这一过程不断以各种规模反复发生着。量子物理学这一简单的发现从根本上改变了我们对牛顿物理学的看法。因为我们正试图将一个假设——一个经过彻底验证的假设——应用于一个并不适用的领域,所以出现一种危机。

实际结果是,两种知识都是必要的。但是,明确知识更易于传播。

知识转化

 默会知识向明确知识的转化是一种真正的技巧——信念的飞跃。它让具有远见的人观察与经验之外的东西。有点像变戏法,如同需求转化为设计或毛虫转化为蝴蝶。

进行转化可不像进行连接那样简单。我们处理信息的方法存在一些问题,我们的大脑结构也阻碍了我们进行这些连接的能力。

在《瞬间》一书中,马尔科姆?格拉德威尔提出了一些有趣的观点。在第4章“保罗-范-瑞普的巨大成功”中,格拉德威尔提到研究语言阴影的乔纳森-斯库勒的工作。他的研究重要在于了解为何我们在进行描述前就能认出面孔。他的工作探讨了大脑的语言部分如何与心理部分结合,以致于很难以言语形容图画,以及尝试这样处理似乎也降低了原始图像的可信度。

在第5章“肯那的难题”中,格拉德威尔通过与我们分享我们如何调节自己的喜好来适应似是而非的原因,重温了这一主题。乔纳森-斯库勒与蒂莫西-威尔逊做了一个实验。在这个实验中,他们请专家和大学生客观描述他们最喜欢哪种草莓果酱。专家和大学生的喜好大体一致。一旦要求学生量化他们的排名,专家与学生之前的一致就会消失。

这个例子说明了默会知识向明确知识转化的问题。当要求他们对果酱提出明确的观点时,他们为更喜欢某种果酱建立似是而非的原因,并调整自己的感知来适应这些似是而非的原因。换句话说,他们改变他们记忆的方式来匹配他们所做的描述。

乔纳森-斯库勒继续指出,不知什么原因,专家们部分通过建立一种更为精确评价食物的方式,从而克服似乎困扰着少数专家的限制。学生们想出的结构并不具备准确描述他们经历所必需的可信度。

在软件开发领域这个创造性的世界中,有时很难获得顺利进行软件开发的真正最佳实践、规则、指导方针及技巧。无疑会存在各种问题,如不同的语言会微妙地改变最佳实践,使它更难以识别。但从根本上,问题仍未改变;我们必须学会将需求规范方面的知识转化成实际的需求。

进行转化

 如果食物测试专家能够量化果酱的差异,但测试结果却完全一样。那么同样我们也能将如何开发软件的默会知识转化成能够与整个开发团队——或整个组织——交流的明确知识。

在进行评估时,食物测试者拥有十分准确的天平与精确的特征。同样,我们也能清楚定义优秀软件开发中必须存在的典型行为;我们也能明确定义评估那些行为的方式。

除仅仅说你与开发者“保持联络”以外,还可以定义一个能够被测量的“非正式沟通”特征。定义这个特征后,就可以定义那个特征的连续点。由此可建立一个可行的协定。例如,100刻度盘上的0表示你从不与其他团队成员交谈。刻度盘上的100可能表明你与他们分享办公室空间。

你为组织选择的实际价值和特殊特征不一定很重要,但量化能力则至关重要。你可能学会,例如,为了让你的团队团结合作,他们必须进行某种程度的非正式、非结构化的交流。

明确知识成为一组支持基本观察行为的周期性事件。明确知识即每个季度应留出4个小时的时间以便团队成员能够进行无限制的交流。很明显,这忽视了如何形成团队精神的基本知识,以及团体进行有效合作所需的协作水平——但是,多数情况下,这种默会知识都是不必要的。大家需要了解怎么做——建立非正式的交流——而不必了解为什么这样做。

打破规则

 有时我们有必要打破规则——走出明确知识,这是我们从库恩那里得到的有趣结论之一。没有什么比经历有生命的事物更真实的了。有一组规则或指导方针用于建立事物,使它们听起来不错。这些规则对那些没有多少经验的人来说特别有用。它们简化了转化过程,使其易于管理。

然而,经验丰富的人常常打破(或严重违反)规则来满足自己的需要。虽然你决不想在一个吵闹的舞台上使用一个大膜片电容麦克风,但一个有经验的录音工程师恰恰会这样做。他这样做,是因为他不需要已成规则的明确知识,只通过自己的默会知识就了解如何来处理这件事情。

所以去创造一些明确知识——然后再打破规则。


版权所有:UML软件工程组织