从知识转化过程看用户需求挖掘

收集用户需求——或者将它称作启发用户需求也许更加合适——一般比较困难，你总需要考虑用户是不是还有什么事情没有告诉你，以及如何让用户把这些表达出来，因此，这里的真正困难在于：有些时候，你和你的客户谁也不知道真正的需求在哪里。在面对这些困难的时候需要首先考虑两个事情：第一，何为用户的隐含需求（即未明确表达出来的需要），何为明确需求；第二，如何在它们之间进行转化，以及这种转化的意义。

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

其实，用户的隐含需求与明确需求的概念，类似于我们日常所说的默会知识与明确知识的概念，因此弄清楚默会知识与明确知识的涵义以及它们之间的转化关系，对我们研究用户的隐含需求与明确需求很有意义。

默会知识

默会知识指基于经验和观察的知识，不存在一些由以前传承下来的法则或程序——它只是做事的方式而已，能够直接应用于将来需要解决的问题上。

一个靠做木工为生的工作者会在做木匠活的过程中中不断表现出各种经验技能，许多对于我们这些习惯了现代工艺的人来说甚至是不可思议的，但这位木匠怎么知道应该这样做呢？答案很简单，他做过许多类似的活，这使他足以知道这些知识。

每个人都有这样的默会知识——例如我们掌握的驾驶技能，这些经验就是我们的“本能”，凭经验来做事情很便利，却可能很难让将其中的详细步骤逐一向他人解释或将它们写下来，但我们确实知道这些建立在经验之上的知识。

明确知识

相对于默会知识，明确知识是指可以被量化的知识。你可以将它们书写下来，在人们之间传达。它是实实在在的，不是获得的经验。它是那种已形成规则的知识——这些知识本身甚至就是从书本上得来的。例如，一个人看到苹果从树上掉下来，并知道摇苹果树来得到苹果，这是默会知识范畴；进一步他可能还知道重力作用使所有物体集合在一起。最初通过观察获得的默会知识，最终转化成一种定律，形成了明确知识。

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

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

了解两者的转化过程

我们都了解，科学研究方法的第一步是观察——换句话说就是积累经验。然后我们再假设我们所观察的事物的运作方式，并对假设进行检测，如果结果不正确，我们再进行测试。这样得出的结果是明确知识——它不必经过亲身广泛体验，就能轻松迅速地在人们之间传播。

当然，最终假设会出现缺点、差距或错误，总有新的默会知识显示出科学体系的缺陷将形成对明确知识的质疑危机。最终，由新默会知识带来的压力产生一种革命性的转变，这一转变促使建立一种新的明确知识。

事实上，这一过程不断反复发生着，它带来的实际结果是两种知识的相互促进。必须承认的是，两种知识都是必要的，只是明确知识更易于传播。

知识转化

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

进行转化可不像进行连接那样简单。我们处理这两类信息的方法并不一样。乔纳森-斯库勒与蒂莫西-威尔逊做了一个实验，从中可以看出人们在处理经验信息（默会知识）和明确知识时表现是如何的不同：在这个实验中，他们请食物专家和大学生品尝一些果酱，并在事后客观描述他们最喜欢哪种草莓果酱。在这个评价环节中，专家和大学生的喜好大体一致。然而在后来，一旦要求所有人必须给出一个明确的排名，专家与学生之前的一致就会消失。

这个例子说明了默会知识向明确知识转化中存在的问题。当要求学生们对果酱提出明确的观点时，他们为更喜欢的某种果酱建立了一些借口、一些似是而非的原因，甚至调整了自己的感知结果来适应这些似是而非的原因。换句话说，他们改变他们记忆的结论来匹配他们所做的描述。这当然不可能再准确反映那些默会知识。

乔纳森-斯库勒继续指出，专家们则会通过建立一种更为精确评价食物的可操作的方式，从而克服排名无法客观的问题——而学生们想出的评价方法就不具备很高的信度了。

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

进行转化

既然食物测试专家能够量化果酱的差异，从而每个人依此标准都能得到同样的测试结果，那么同样我们也应该可以将如何开发软件的默会知识转化成能够与整个开发团队、或整个组织交流的明确知识。

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

例如在沟通方面，除最基本的与开发者“保持联络”以外，还可以定义一个能够被测量的“非正式沟通”指标。定义这个指标后，就可以根据可操作的定义建立该指标的不同测量值，进而由此可建立协定。例如，满值10分的量表上，0表示你从不与其他团队成员交谈，而10可能表明你与他们分享办公室空间。

在这样的转化过程中，量化能力至关重要，量化的指标就可以成为明确知识在人们之间传播。且这样的明确知识会成为一组考察行为效果的评价体系，并便于观察和调整。

明确知识的问题在于其建立过程中必定会忽略某些内容（否则这样的知识将过于复杂）。例如，考量交流行为的体系指出每个季度应留出4个小时的时间以便团队成员能够进行无限制的沟通。但很明显，这忽视了形成团队精神的基本条件，以及团体有效合作所需的协作水平——当然，多数情况下，这属于默会知识范畴，大家更需要了解怎么做、做多少，而不必了解为什么这样做。

打破规则

明确知识成为体系，成为框架，但有时我们还是有必要打破规则——走出明确知识，没有什么比经历有生命的事物更真实的了。有一组规则摆在那里或许听起来不错，对那些没有多少经验的人来说特别有用。它们简化了转化过程，使其易于管理。然而，真正经验丰富的人却常常打破（或严重违反）规则来满足自己的特别需要。他们这样做，是因为他不需要已成规则的明确知识，只通过自己的默会知识就了解如何来处理这件事情。

所以，面对IT需求也是一样，当你挖掘了用户的默会知识，去创造一些明确知识之后，再打破规则会是另一个局面，用流行语说，叫做“服务创新”。