转载

软件专家的对话模式（第一部分）

如果你觉得你所面对的业务人员不知道他们想要什么，那么这篇文章适合你。

在该系列文章中，你可以了解到与业务人员共事的方法。你将学到如何管理对话、挖掘需求及明确期望。让我们开始吧！

在本文的开头，请先想一下，现在提出下列哪一个问题会帮助你最大限度地领会本文的实际内容：

我想知道，这篇文章是关于什么内容的？
在我最近与客户的对话中，困难最大的一部分是什么？
当与客户交谈时，我为什么总是犯同样的错误？
在与客户的对话中，如果他们从我希望的角度看问题，那么会出现什么新机会？

你选择哪一个问题？如果你不是非常确定，我还是支持你阅读这篇文章。稍后，我们会回到这些问题。

任何软件都是为某些人创建的——有人会为它付钱，有人会使用它。创建软件的主要目的是为了改善其他人的工作。虽然严格说来所有受其影响的人都称为 干系人 ，但软件开发团队通常使用术语—— 业务人员 ，甚或选用一个更简短的称呼—— 业务。

要做什么？

如果要编写恰当的（换句话说，有用的）软件，就需要以某种方式从业务人员那里获取做什么的信息。难点在于，所获取的信息五花八门。例如，你可能会听到：

关于当前状况的信息—— 报表不起作用 。
业务规则片段—— 如果一个月有31天，那么我希望能在下个月开始的时候收到通知，而如果是假期，我不希望收到任何通知 。
一个故事—— 我曾经看到过一个类似的软件，它有这样一个不错的功能，可以自行从销售单据中读取数量 。
一个关于功能的想法—— 插入一些来自先前版本的列，但除了ID之外，还要从数据字典中增加两列——用波兰语和匈牙利语 。

虽然从客户的角度来说，这些东西都指出了重点。但要创建有用的软件，我们确实需要更多信息。首先，需要知道更多的细节和具体的内容。

多年的行业经验已经告诉我们，要从业务人员那里获取具体和详细的知识，最好的方法是对所了解到的内容进行结构化。结构化可以定义为将所获得的知识根据预先定义的标准进行组织，例如， 功能需求、非功能需求、领域特有规则、架构及实施局限性 。这样一个有条理的信息集合是一个供信息收集者使用的检查清单，可以帮助他们回答下列问题—— 我已经了解了什么？我还需要了解什么？我必须说明什么 ？

用户故事和用例并不是全部

对于用户将来能够在系统中执行的任务，要结构化当前相关信息，有两个流行的工具，分别是 用例（UC） 和 用户故事（US） 。现在，让我们跳过对UC和US之间差异以及何时使用它们 ¹ 的讨论，继续探讨一些关于用例和 用户故事 的“你知道吗（did-you-know-thats）”。

在我同各种团队共事的过程中，我经常遇到一些形成US的反模式。下面是几个例子：

作为 一名 操作者 ，为了登录系统，我想要注册。
作为 一名 推销员 ，为了查看销售月报，我想要生成一个月度报告。
作为 一名顾问，我想要提供一项新服务， 因为产品经理 需要。

再次，为了简单起见，我们不讨论是否上述每个US表述实际上都源于系统用户。重要地是，这些例子缺少一个明确的、公式化的用户故事目标。稍后你会看到，这会对财务产生一些非常严重的影响。

类似的反模式也用在了用例中。专家指出了以下几个不足：

UC太宽泛；
UC与特定技术关联太紧密；
没有替代方案；
UC太复杂。

UC和US都是设计用来为业务人员和IT人员协作提供支持的工具。它们的主要用途有时候并没有体现出来。下面是我对于这个问题的一些观察：

US 和UC被当作目的本身。 通常，任何编程项目的最终目标是以软件的形式创建一种产品或服务。终极目标 ² 是以任何形式控制期望清单的范围。不过，当UC或US创建脱离软件交付过程，变得“为艺术而艺术”，这会很危险。

UC 和US被用作免打扰防护罩。 在某些情况下，文档数量与业务人员和IT人员之间协作关系的主观感知质量成反比。我见过一些情况，大量详细的UC被创建出来，主要是为了 使开发人员停止抱怨 。

不是协作，而是侧重于完成表单。 我们往往会做出不合理的假设，认为写出优秀的UC和US就可以保证项目成功。我们经常会经历被称为 社会认同 ³ 的认知错误。令人奇怪的是，虽然认同敏捷宣言的第一条规则——个体和交互胜过过程和工具，但我们还是会优先考虑工具。可能这是因为这时工具是“敏捷的”。

方案的最终业务目标不够明确。 这导致的一种结果是，我们的故事和案例与业务目标不一致。在那种情况下，所要求的特性变成只是一堆某些部分永远都不会使用的软件功能。

即使写好了UC或US，也可能误解业务需求。 有那样一个笑话：曾经，有一个小镇建了三座桥，因为……只有第三次建造者遇到了一条河。如果不了解项目真正是关于什么的，那可能会做许多很棒且成本很高的工作。

为了更好地了解业务人员有什么期望，可以使用 用户故事、用例 和其它方法具体描述后续所需的软件功能或领域专属知识。也有一些方法能够让你更好地为业务现状建模。至此，下面的问题出现了—— 业务知识、领域专属知识、期望都在哪里？ 答案很明确：在业务人员的心里！

如果明确地、具体地知道要做什么，以任意形式把它保存下来：用户故事、用例、提纲、模型，或者其它任意非常简单的方式。就像ABC一样简单——而且你甚至可以写一个手稿来做这件事。难点在于，从业务人员那里获取业务知识，提炼期望，以及将那些必要的事情与那些有吸引力但没必要的事情区分开。这就是 对话模式 要处理的问题。

对话模式 是管理对话、提出问题、发现需求和明确期望的方法。这无非是那些从业务人员那里成功获取到知识的人们所使用的有效技术。这些技术被命名、组织，并以算法方式描述，使任何IT专家都可以直接使用它们。

需要什么？

首先，让我们探讨一些对所有对话模式而言都很重要的东西。就是需求。需求是什么呢？请阅读下面两种描述：

我负责将支持合同的数量增加到六百，因此，我希望看到一个月度合同列表。
如果每个月支持合同的数量停留在二百的水平，他们会解散我们部门，因此，我希望看到一个月度合同列表。

这些描述来自不同的客户，他们想用同样的功能—— 查看月度合同列表 ——这两种描述的不同点是为什么提供这项功能的原因。这个原因就称为 业务需求 。

既然在这些例子中期望功能是完全相同的，那么其中所表达出的业务需求有什么不同呢？如果再仔细研究下就会发现，第一个需求是关于实现更大的支持合同数量，而第二个需求则谈到了避免部门被解散。这些例子说明了两种业务需求—— 获得利益 和 避免问题 。

在每个功能的背后，要么有一个期望的利益，要么有一个需要解决的问题。如果业务人员没有看到借助新实现的功能获得利益或避免问题的可能，那么实现这样的功能是没有意义的。为它花钱也就是没有意义的！

如果能够了解隐藏在期望功能背后的业务需求，那么就能了解业务人员最看重什么。这就是功能的业务价值。

谈论功能很简单，因为它们是具体的。你可以绘制用户界面或者控制流。对于 后台运行 的软件，你可以绘制一张组件图，或者列举模块的API。这些东西非常容易命名和定义。发现和命名需求就要困难许多了，因为它们通常是隐藏的。

当与业务人员交谈时，首先他们会说出 他们想要什么 。他们通常不会用一个简单的词语命名他们的需求。也就是说，业务人员的职责是决定要实现什么，而IT人员的职责是决定如何实现。我个人认为，这种界限可以进一步引申。业务人员的任务是决定“ 为什么（why） ”和“ 为了什么（for what） ”创建软件，而IT人员会处理“ 什么 ”和“ 如何 ”。

在编写故事或用例之前……

在我看来，在软件开发方面，其中一个最大的好处是什么都是可能的。每一项功能经过一些努力都可以实现。这种好处同时也是一种缺点——团队甚至可能会交付无用的功能。如果你要一个电子邮件客户端——你会得到，如果你要一个条码扫描器——你会得到，如果你希望通过拍拍手选择一个菜单选项——没问题，团队会提供这项特性。软件开发没有限制，什么都是可能的！

方案的业务目标是关键，它让所有想要的特性与唯一目标保持一致。这就是为什么每个参与人员必须首先明确、理解和共享主要业务目标（产品、项目）。

让我们跳过那个我们试图确定市场预期及假定新产品为潜在客户所需的部分。量化是设定方案业务目标的最简单但有效的方法。在上面的例子中，我们可以识别出两类需求：

我负责将支持合同的数量增加到六百……
如果每个月支持合同的数量停留在二百的水平……

这些需求已经在合同的维度上进行了量化，但怎么样呢： 时间边界、合同类型、参与人员、现状核实 ？所有这些问题将有助于量化业务目标，使开发人员对预期结果有更好地理解。在本篇及本系列后续文章中，你将会看到明确业务人员期望的技术。

业务人员什么时候在谈论问题？

需求接下来的部分是避免问题和获得利益。我们假设你正在与一名业务人员交谈，比如，在计划会议期间。你正设法明确地描述一个新的 用户故事 ，你的谈话对象说： 作为一名用户，我想要功能X，因为……

……我担心保证金计算不正确；
……GUI不直观；
……我不希望用户形成（……）印象。

如果仔细听，你会在这些描述中听到一些非常具体的短语： 我担心这不是、我不希望 。类似的例子包括：

……它太慢了，它没有发挥应用的作用；
……它太……
……问题在于……
……这不可能，因为……
……这很难，因为……

这些短语基本可以明确地表达出你正在与之交谈的人试图描述一些他/她希望避免的事情。因此，他/她以需要避免的问题这样一种形式描述了他/她的需求。

一旦有信号表明问题已经识别出来，那么就必须将问题命名。通常，这符合以下模式：

我希望避免……
我不希望……
这很难，因为……
如果我们不……，那么……

当把省略号替换成描述问题的短语时，句子就有意义了。例如：

我希望避免保证金计算不正确；
我不希望GUI不直观；
我不希望用户形成……印象。

业务人员什么时候在谈论利益？

在一次关于新功能的对话中，你的谈话对象说， 作为一名用户，我想用功能X，因为……

……我们将能够自行设计报表；
……我们将尽快使用工资计算器；
……我们将以更好的方式测试这个模块。

正如有问题需要解决的情况，在特定的陈述中，你会听到这些特征短语： 我们将能够、我们将尽快使用它、我们将更好地测试一些东西。类似的短语包括：

…我期望…
…借助它…
…它应该/必须/可以…
…那会很棒，如果…

这里，利益很容易识别，因为在大多数情况下，它符合以下其中一种模式：

我想要实现……
它将使……
这意味着……

对于上面给出的例子，我们有：

它将使我们能够自行设计报表；
这意味着我们将尽快使用工资计算器；
我想要实现更好的测试。

用户故事 vs. 需求

考虑这两个经常使用的 用户故事 模式：

作为<角色>我想要<功能>，为了<目标>？
为了<目标>，作为<角色>我想要<功能>？

在你看来，使用它们中的每一种模式会产生什么样的结果？使用第一种模式，对话从一项功能开始。因为谈论功能非常简单和自然，可以花许多时间在上面：绘制界面、模型或流程。很明显，这些都是非常重要的东西，但是一天下来，你会想要写下整个 用户故事 。然后，你会试图使用一种非常宽泛的陈述，而不是真正的目标——但只有真正的目标才能促使业务人员订制一项特定的功能。

第二种模式会取得更好的效果，因为对话始于搜索目标，也就是业务需求。当使用第二种模板的时候，只有在首先明确定义了需求的条件下，你才可以开始关于功能的对话。

请注意，你可以使用关于需求的知识改进 用户故事 模板。你会有两个更精确的模式，而不是一个：

为了避免<需要避免的问题>，作为<角色>我想要<功能>；
为了实现<希望获得的收益>，作为<角色>我想要<功能>。

就自己而言，我使用双面打印的卡片。一面是获取利益的模式，另一面是与业务问题相关的模式。借助这个模板，就更容易注意到业务人员要求背后的需求。而且，对你而言，管理对话将更容易，你将因此能够准确地提供一项功能。

你选择了哪个问题？

让我们回到第一段。你选择了哪个已提出的问题？ 我想知道，这篇文章是关于什么内容的？ 这个问题是关于“功能”的。如果你选择了这个问题，那么你已经读过这篇文章，你已经了解了它的内容，并会很快把它忘记。

在我最近与客户的对话中，困难最大的一部分是什么？ 这是一个非常有价值的问题，因为那可以突出你所面临的困难（问题）。如果你选择了这个问题，那么你可以把这篇文章作为解决这个问题的一个潜在解决方案的来源。

当与客户交谈时，我为什么总是犯同样的错误？ 这也是一个关于问题的问题，但如果你不断地问自己这个问题，你会觉得越来越糟糕。当然，经受困难情绪的能力非常有用，但在这个问题所述的情况下，没有涉及预期结果。

在与客户的对话中，如果他们从我希望的角度看问题，那么会出现什么新机会？ 这也是一个有价值的问题，因为它关系到潜在利益。如果你选择了这个问题，那么你可以把这篇文章作为获取这些利益的灵感来源。

总之，问题二和问题四是推荐问题。

在这篇文章中，我描述了需求发现技术的基本原理。你了解了如何在一次对话中识别类似需求的表述。但是，如果你仔细阅读了，你就会问自己： 我如何知道谈话对象表述的哪一项需求才是真正的需求？ 接下来我们将深入研究：提出可以明确需求的好问题。

对于那些不知道他们想要什么的客户，如果你希望了解更多关于与他们交谈的技巧，请阅读本系列的下一篇文章。

关于作者

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