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

在软件专家对话模式系列文章的第一部分中，你已经了解到业务人员需要什么以及如何在收集用户故事的过程中识别需求。在那篇文章里，我还描述了用户故事模板：

• 为了避免_<_需要解决的问题 >，作为< 角色 >我想要< 功能 >；
• 为了获得_<_预期的利益 >，作为< 角色 >我想要< 功能 >。

这两种模板可以使开发人员能够注意到预期功能背后的需求。第一部分的其中一个主要观点就是，在收集 _ 用户故事 _ 的过程中，谈论业务人员想要什么或者预期功能是什么更容易，但确定目标，即这些预期背后的业务需求，要困难许多。

当你开启一次 _ 用户故事会话 _ 并开始谈论功能时，你一定会注意到，你的谈话对象经常使用“类似需求”的词语。在这些需求里，哪些才是真正的需求？

寻找需求的问题

问题是寻找恰当的业务需求的第一个工具。如果你提出了一个高明的问题，那么它会让你获得相关信息。我深信，如果正在同你交谈的业务人员没有提供你正在寻找的信息，那意味着你在错误的时间提出了一个错误的问题。

请把前面那句话再读一遍。这揭示了支撑软件专家对话模式的其中一个关键假设。假设你应该完全负责对话的展开，你是将要提供软件的专家，你就是知道需要什么信息的那个人。如果没有这种假设，就很容易由业务人员承担对话失败的责任——并认为他们无法有效交流。在业务人员身上寻找这些问题的原因并不能通向任何有意义的解决方案——而是要明白，这是你自身的不足！这就是为什么这项假设如此重要。

因为有两种不同层次的业务需求：需要避免的问题和希望获得的利益，所以也有两组问题来帮助你发现这些需求。

在以你的谈话对象试图避免的问题这样一个形式进行需求挖掘时，基本问题是“为什么”。试图回答“为什么”的问题，我们通常侧重于过去的问题。类似的结果可以通过使用一些更具体的问题来探索需要解决的问题领域得以实现：

• 它为什么重要？
• 它的难点在哪里？
• 你要预防什么？
• 你会损失什么？
• 你试图避免什么？
• 如果你得不到这项功能会怎样？
• 你会损失多少钱？

这类问题的主要目的在于，弄清楚你的谈话对象想要这项功能的动机，或者，换句话说：他们为这项功能赋予了什么样的价值。或者，简单来说，这项功能有什么业务价值。

要找出可以获得的利益，基本问题是“为了什么”。当我们回答这个问题的时候，我们通常关注未来的利益，正如下面这些更具体的问题，它们就属于这一类：

• 它会带给你什么？
• ……的用途是什么？
• 你想要获得什么 / 多少利益？
• 如果我们实现了它会怎样？
• 然后什么将成为可能？
• 可以实现什么？
• 有什么与其相关的新机遇？
• 它有什么真正的新东西？

现在，你可能想知道，如何知道在哪里寻找需求。这是避免问题的方向，还是获得利益的方向？答案非常简单：听听你的谈话对象说什么。你可以借助一些中立问题开始对话：

• 是什么使你想要这项功能？
• 在这项功能里，重要的是什么？

然后，仔细听听答案，并寻找表明特定类型业务需求的表达（见本系列第一部分）。然后，你的谈话对象在哪个方向说得更多，你就可以开始提出与之相关的问题。

寻找具体需求

——是什么使你想要这项功能？

——噢, 感觉有那项功能会很酷！

好吧，它可能确实“会很酷”，但跟业务需求没有一点关系。这时，一组精确问题会很有用：

• 你是如何知道……？
• 你将如何衡量……？
• 如何？以什么方式？
• 有什么特别的东西让你……？
• 什么人？什么地方？什么时间？和什么人？多少？
• 请举一个例子……

精确问题的语境有助于鼓励谈话对象根据所谓的“语义具体化（ semantical concretism ）”规则明确地进行表述。“具体化（Concretism）”是由 Tadeusz Kotarbiński 开拓出的哲学领域之一。根据该规则，句子中包含的名称要能够指代现实世界中存在的东西，只有这样的句子才是正确的。因此，句子“它会很酷”从语义具体化的意义上讲是不正确的，而句子“人员 X 将会把订货单发送给我们”是正确的。

寻找与具体业务相关的需求

“增加月度收入”、“减少隐性成本”基本就是具体需求了，同时它们几乎适应于任何现有业务。寻找与你正在开发的软件所面向的业务相关的需求。例如，作为一名在线书店的用户，我有如下需求：

• 不能创建一个新账户（问题）；
• 不能每次购买都输入所有的数据（问题）；
• 购买一天后拿到书（利益）；
• 不能针对每一本书的递送单独支付（问题）。

这个简短列表中的部分条目将会转化成一项功能，但不是全部，因为它们中部分条目已经超出了 IT 系统的范围。

寻找有启发作用的需求

寻找那些让你的业务谈话对象想站起来大喊的需求，“是的！那就是我想要的!”。这些需求才是应该写进 _ 用户故事 _ 的需求。要决定哪个需求最接近业务人员真正想要传达的东西，你可以使用下列问题：

• 如果避免了它，会有什么影响？
• 如果实现了它，会有什么影响？
• 如果现在你不得不同一个问题妥协，那么你会选择哪一个？
• 如果现在你只能获得其中一项利益，那么你会选择哪一项？
• 如果现在你不得不剔除一项利益，那么你会选择哪一项？

一方面，这些问题能够帮助我们得到满足这些业务需求的结果；另一方面，帮助我们设定优先级，确定最重要的需求。

需求发现实战

现在，让我们综合所有关于需求发现的信息。我们将以业务人员和开发人员之间的对话为例。这样的对话经常发生，而且一般说来，遵循同样的模式：

• [**** 业务人员]：请注意，我想要在这个页面上增加一个可以生成部分报告的按钮……
• [**** 团队]：应该展示哪些数据？如果没有数据，展示什么？这个需求与流程的整体设想一致吗？你想过部分数据聚合的影响吗？这可能需要更多重构……
• [**** 业务人员]：嗯，我得问问……

团队提出的问题似乎没什么特别的——它们只是一些深入的精确问题。通常，情景语境是关键。在像上面这样的情况下，为了说“不！”，团队使用了大量详细的问题，有时还是技术问题。

当与团队中的某个成员交谈时，这个列表中的问题相当不错，因为你的谈话对象完全有能力回答它们。当使用同样的问题与没有准备好回答它们的人交谈时，因为他或她没有该领域的适当知识，团队的反应可能被视为故意带有攻击性。因此，如果你想说“不！”，就直接说“不”。这样当然更果断，而不是用许多不可理解的问题折磨你的谈话对象。此外，这样的对话经常出现的结局是，双方互相说服对方，一项特定的交互功能有用还是没用。

那是不是说同业务人员接触的时候通常应该避免这种类型的问题呢？当然不是！在某些时候，你最终还是不得不问他们。重要的是，首先发现需求，然后提一些更具体的或更偏技术的问题。

我在这里描述的对话会如何进行下去呢？

• [业务人员]：请注意，我想要在这个页面上增加一个可以生成部分报告的按钮……
• 现在停一下。即使你确信这项需求不合理或者根本没有意义，也要停一下。不要争论，不要说服，而要发现需求。
• [团队]：你希望通过这个部分报告获得什么？
• [业务人员]：我不想在月底等待销售图表。
• 正如你所看到的，团队的问题是关于希望获得的潜在利益，但业务人员指出了一个需要避免的问题。是的，这可能发生。在这样情况下，要跟随谈话对象。
• [团队]：所以关键是等待销售图表的时间？
• [业务人员]：是的！

这时，一项业务需求已经被列为一个需要避免的问题：“我想要避免在月底等待销售图表”。

有了这项需求，就可以继续定义验收标准了。换句话说，必须确定你的谈话对象如何知道问题已经解决或者利益已经获得。为什么制订验收标准如此重要？稍后我们会谈论这个问题。

• [团队]：为了保持最新，你想要看到什么特定的图表，以什么频率？
• [业务人员]：实际上，我需要关键客户的图表，一周两次即可。

如果团队想要总结他们刚刚从客户那里了解到的内容，那会是像这样的东西：“我想要避免在月底等待销售图表。如果我能够一周两次看到关键客户的销售图表，那么我就能避免这一点。”有了这些知识，团队就可以继续对话了。

• [团队]：哦！所以我们可以这样做……或者这样做……或者那样做……在你看来，这些解决方案中的哪一个最好？
• [业务人员]：那看上去很有趣……

为了能够提供可选的方案建议，团队努力识别需求，并确定验收标准。这就是需求背后的秘密。针对新功能不“符合”架构的情况，最常用的策略是：提出证据，说服，并竭力提出自己的想法。当你把关注需求放在第一位时，你就能找到一个可选的解决方案。一方面，它能让业务人员满意；另一方面，团队也能接受。

在 _ 软件专家对话模式 _ 系列文章的第三篇，我们将重点讨论如何自觉地运用词语以及如何管理对话流程。

关于作者

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

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