在《软件专家的对话模式》系列文章的前两部分中，我们重点讨论了业务需求发现。你已经了解到，在每个期望的功能背后都有一个隐藏的需求，它的形式要么是需要避免的问题，要么是希望获得的利益。我们还介绍了在为收集用户故事而开展的对话中发现并详细描述这些需求的方法。接下来，我们将以一个团队提出可选解决方案为例，用图示说明需求挖掘模式。

你见过包含应用程序服务器诊断信息的文件吗（简言之，日志文件）？（图1）展示了这样一个文件：

（点击图片查看大图）

图1.清晰易读的应用程序服务器日志

对许多人而言，它只是大量的、没有任何意义的文本。不过，经常使用这类文件的人会从中发现许多有用的信息。他们知道如何查看这些表面看来不可理解的数据，找出最重要的信息（例如：[ERROR]、[FATAL]记录，或者具体的数据库查询）。这同样适用于关于新特性、现有功能变更或者我们为之开发软件的业务人员的操作规则变化的对话。在这样的对话过程中，人们谈得很多——“夹带”不同的信息片段。它们基本准确。为了找出软件交付不可或缺的内容，你需要以一种恰当的方式倾听和看待对话。

对话结构

既然源代码可以结构化（以设计模式的形式），使它更容易开发和维护，为什么不能以此类推将其应用到对话呢？当我们以结构化和有序的方式看待对话时，可能会有助于我们更有效地引导对话。我们这里的意思与主持会议的模式没有关系，其中每位参与者都有自己特定的角色。我们谈的是一些更基础的东西——是关于人们在对话过程中如何交换信息（尤其是业务人员与IT人员）。我们假设，你的谈话对象不需要具备任何有关信息收集或会议主持的技术。我们只能假设，他/她愿意说出他/她所知道的。

让我们假设你正在开发面向医疗卫生行业的软件，你正在就新软件中一个写处方的功能与其中一位关键用户（一位医生）做面对面的交流。对话像下面这样进行：

• [你]你将如何使用这个工具？
• [用户]嗯，对我而言，最重要的是输入药物剂量要跟我在纸质处方上所做的一样快。你见过纸质处方吗？
• [你]当然。
• [用户]你知道的，纸质处方非常灵活。我可以写任何想写的东西。这项新功能应该同样灵活。顺便说一下，我们的员工对新系统有一些疑问……
• [你]好的，那么你是想使用普通文本写处方。还有什么？
• [用户]处方必须与药柜关联。药柜是一个相当复杂的问题。关键是满足Legal Act XYZ的要求。就处方来说，我们还有义务遵守一些规章制度……

现在想象一下，上述对话的结构与（图2）所示的结构类似：

图2.对话结构

你所能获得的所有信息都是受同一个需求或者说原因支配，就是为什么业务人员将这项功能说成是一项必须提供的功能。接下来，想象一下，你可以将那些对你而言非常关键的信息组织到一个树结构上：顶部是概括信息，底部是具体信息。

让我以一个树结构的形式排列这个示例对话，并按照不同信息出现的次序进行排序（图3）。

第一个信息是关于“剂量”，另一个是关于“纸质处方”。两个信息都是在谈论“处方”的语境下给出的。接下来，关键用户谈论了纸质处方的“灵活性”以及“新系统”的“一些问题”。然后，关键用户提到了“药柜”以及管理其使用的“XYZ Law”。最后，他还提到处方受“一些规章制度”约束。

图3.信息顺序

对话过程

一旦将对话可视化，你就会注意到对话过程（图4）。该对话很“混乱（chaotic）”！我们使用了“混乱”这个词不是进行意义上的评判，而是标注这一特定对话的特有属性，以便将其与结构化对话相区别。在该示例对话中，说话者的言语不由自主地从具体转到概括，并且改变了话题。这就是人们彼此交谈的方式，那几乎是自然的事情。

图4.对话过程

从目标的角度来看，例如，确定业务人员愿意为什么付钱，这种与人交谈的准自然的方式并不总是有效。如果你以混乱的方式开展对话，则可能会：

• 你收集了许多消息，但几乎没有知识；
• 你只是稍微了解了业务上正在发生的事；
• 你的笔记混乱；
• 你觉得应该做些事情，但又不确定究竟需要做什么。

控制对话过程

通过对话结构，我们可以辨别出三个基本的对话开展方向（图5）：

• “向上”，总结——目标是找出隐藏在谈话对象期望背后的需求；
• “向下”，具体化——目标是针对谈话对象的期望制定验收标准；
• “向一侧”，创建类比——目标是在一个不同的语境中确定一个特别困难的主题，然后将结论放回到原语境中。

图5.对话过程方向导航

控制对话“向上”的方法在本系列文章先前的部分中已经介绍过。现在，我们将重点介绍具体化，也就是在对话结构中向下。首先，我们必须阐明的是具体化的目标。那么，具体化是指……获取具体信息。在软件开发方面，具体信息涉及到：验收标准、验收测试、功能测试、用例场景、用户故事场景、界面草图、输出数据示例。

概括信息与具体信息的边界相当传统。通常，我们认为具体的东西是那些可测量的东西，也就是可以归结为一个数字。从这个角度来讲，“用户界面直观”这样的标准并不具体，而“屏幕包含不多于五个控制组件”这样的信息则是具体的。具体化的另一项标准是已命名对象的数量。出现在对话过程中的大部分概念都有它们的已命名对象，也就是说在现实中存在的、已被赋予特定名称的对象。已命名对象越少，给出的概念就越具体。因此，像“主要的问题是测试不充分”这样的说法就不具体，而像“我们主要关注的是，在测试getters和setters时，我们要达到百分之百的代码覆盖率”这样的说法就更具体。

当然，你可以将任何信息具体化到像素甚至是原子的水平，但有时候可能会陷入“为艺术而艺术”的境地。出于这个原因，具体化的重要性要看对话语境——该语境是由参与对话的人所做出的先验假设。对于有些人而言，“标准登录页面”的概念相当清晰，因为他们具备特定语境的知识，这使他们可以正确地了解这样一种简洁的描述。

你最重要的任务之一是判断你在对话期间所做的语境假设与现实一致——还是不一致。例如，一个明显且很少变化的假设是，我与之交谈的人知道这是关于什么的对话，而且他/她已经为此做好了准备。这经常被证明是一个错误的假设。一个好的办法是，开始的时候尽可能少的假设，然后为方便对话开展逐渐增加。

我们已经大概介绍了概括和具体的差别，是时候考虑细节了。通常，我们将收集需求看作收集详细信息。详细信息不同于具体信息。“具体”的意思是“定义明确、准确、精确”，而“详细”的意思是“包含许多细节”。具体信息通常是详细的，但详细信息不一定是具体的。

由逆向工程工具基于源代码生成的文档就是一个很好的例子。通过这种方式生成的（大型）文档包含了大量的细节——因此它是详细的。然而，它很少是具体的。与业务人员面对面交谈的目的是收集具体信息，而不是详细信息。当然，你会获得许多细节——通常大部分都是作为寻找具体信息的副产物——但你应该首先关注具体信息。请谨记。

如何探问具体信息？

同需求调查的情况一样，关键是以恰当的方式提出恰当的问题。下列问题将概念进行了具体化，可以引导谈话对象引沿着对话结构向下：

• 怎么办？究竟怎么办？究竟是什么？
• 它包含什么……？
• 如何衡量它？
• 多少？什么时候？在哪里？和谁？
• 你是如何知道……？
• 请举一个……例子
• 按什么顺序……？

通过这些问题，你可以诱导谈话对象将概括信息分解成更具体的信息。这样，你就可以用（图6）所示的两种方式遍历对话结构：广度和深度。

图6.遍历对话结构

深度遍历对话结构等于是说专注于一个话题，并进行彻底挖掘。对于这种方法，最常见的结果是你会了解到许多关于某个话题的信息，而很少或者了解不到其它可能重要的问题。以这种方式开展对话的人经常说，他们“淹没（floated）”在一个特定的话题里。

广度遍历对话结构通常会获得更好的结果，因为这种方法能够使你熟悉全部问题——而不只是其中的一小部分。当然，由于时间限制，你必须在具体问题中穿插关于优先级的问题，像“我们现在要谈及哪一个话题？”

如果使用具体问题广度遍历对话结构，让我们看一个该如何就编写一个新软件同用户开展对话（表 1）：

为了练习，请试着画出（表 1）的对话结构和对话过程。

现在，你可能想知道，如何提出一个问题，可以促使谈话对象恰恰提供你想要的那种类型的信息，或者如果他/她偏离主题，如何巧妙地打断谈话对象，或者如何确保你正确地理解业务人员给出的业务概念。在《软件专家的对话模式》系列文章的下一部分中，我们将重点探讨那些切中要害的不同类型的问题。

关于作者

Michal Bartyzel——目前为止，我从事解决开发团队效率问题已经有十年的时间了。我致力于改进应用程序的架构和重构应用程序，以及改进我们所说的业务人员与开发团队之间的合作关系。目前为止，我已经对波兰最好的开发团队提供了500多天的培训和咨询。我得出这样一个结论，语言技巧是软件工艺的关键。这既适用于与业务人员的合作，也适用于开发人员的工作，我在我设计的、侧重于重构、代码及架构修改的培训中对此进行过阐释。我在这里对我目前为止研究得出的许多技术进行了描述。在众多会议期间，我还在我的博客和Programista杂志上分享了我目前正在研究的一些新技术。

查看英文原文：Conversation Patterns for Software Professionals. Part 3