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

_ 软件专家的对话模式 _ 系列文章的前三部分主要探讨了业务需求挖掘。在那些文章中，我们介绍了一些技术，帮助定义和澄清隐藏在预期功能和 _ 用户故事 _ 背后的真正的业务需求。

这一部分是关于如何提出切中要害的问题。

请看下面三段发生在产品经理和团队之间的对话：

• 对话 1 团队：下个冲刺会有什么变化吗？

  产品经理：我认为没什么变化…… ……

• 对话 2 团队：你希望在下个冲刺中做什么改变？

  产品经理：唔……我还没有考虑呢。 ……

• 对话 3 团队：待办事项列表中的哪个故事还与下个冲刺的目标有关？

  产品经理：我们探讨过目标……？ ……

实际上，上面列出的每一部分对话都是讨论同一件事，就是关于团队接下来要做什么的信息。然而，根据对团队问题的应答，对话可能沿着不同的方向进行：

• 在对话 1 中，对话会立即结束，不会发生冲刺范围分析；一旦 _ 用户故事 _ 被分解成多个任务，或者在工作或产品演示的过程中，可能还会回到这个话题。
• 在对话 2 中，很可能会额外进行一次 _“待办事项梳理（backlog grooming）”_；可能会将用户故事或场景添加到下个冲刺。
• 在对话 3 中，可能整个团队都会了解到下个冲刺的目标，并参与到以该目标为依据的 _ 待办事项梳理 _ 中。

团队和产品经理的对话会沿着三个方向进行，导致这种情况出现的直接原因是团队提出的问题。在倾听项目过程中的协作故事时，我们经常会听到类似这样的陈述：产品经理没那样说过……，团队没有通知……，需求描述含糊，不知道他想要什么，等等。我们的谈话对象经常会抱怨，他们获得的有关计划任务的信息不够。由谈话对象为不准确的对话负责，这一普遍习惯已经变成了我们的衡量标准——所获得的信息的质量显示了所提问题的质量。

这难道不是一个改进协作的很棒的工具？从现在开始，不要再说“产品经理没那样说……”，而应该说“关于……我没有问过产品经理”，不要再说“团队没有通知……，而应该肯定地说“关于……，我从来没有同团队谈过”，不要再说“需求描述含糊”，而只要承认“关于……，我提的问题不够”，不是断定“他不知道想要什么”，而是应该承认，你只是“无法获得需求信息”。只有当你能够提出有效的问题时，你才能利用这些问题，并借此提高项目过程中的协作水平。

问题要切中要害

研究下人与人之间的沟通，我们就会发现，每个人都有一个“模块”，可以称之为“无用答案缓冲区”。缓冲区是一个存放答案的地方，当你向谈话对象提出不准确或凌乱的问题时，他会从中获取答案。缓冲区就是缓冲区——它可以包含任何东西：

• 最后使用的应答：好的，好的
• 对话片段：好，就用 EJB 吧
• 不相关的记忆：就像在旧系统中所做的那样吗
• 标准的对话结束语：我会考虑的，我们下次再谈吧，问下约翰

如果你希望在对话期间从谈话对象那里获得有用的信息，你最重要的工作是提出可以绕过无用答案缓冲区的问题。

有意识地选择方向

假如你想了解更多有关旅行社运作的信息。你会问哪一类问题？你在旅行社如何开展工作？旅行社如何运作？旅行社里会发生什么？抑或是其它一些问题？其中的每个问题都会获得一个略有不同的答案。让我们看看这是为什么。

• 你在旅行社如何开展工作？——谈话对象可能会认为“工作”一词指的是他自己的工作，然后就谈论他在旅行社中的工作；他可能会谈论他在对话过程中想到的日常活动。
• 旅行社如何运作？——这个问题将迫使谈话对象将旅行社看作一个整体；因此，他会谈论办公室运作、与外部供应商合作等等的一些基本原则。
• 旅行社里会发生什么？——这个问题强调日常交流，因此，你会了解到许多关于个人任务和问题的信息，也可能只有很少一点关于个别员工的信息。

其中哪个问题最恰当？那取决于你想知道什么。如果你对旅行社的业务流程感兴趣：

• 不要问它看起来像……？——因为“它看上去的样子”对你而言并不重要。
• 不要问它如何工作……？——因为这个问题并不能暗示谈话对象你关注的是流程。
• 不要问发生了什么……？——因为这个问题为谈话对象提供了谈论任何内容的机会。
• 不要询问业务流程——因为这是分析师创造的一个术语；那可能听上去很专业，但对大多数客户而言，它并没有什么意义。
• 问：在旅行社中，有什么活动一个接一个的进行？——因为这个问题决定了流程的本质。
• 问：从一个客户进入办公室的时刻起，到他拿到飞机票的时刻止，发生了什么？——因为这个问题指向了一个非常具体的流程，有明确的开始和结束标记。

在收集到的需求中，许多含糊不定的地方都是源于对话过程中提出的不恰当的问题。问题太宽泛了，不涉及事实真相，或者无意间诱导说话者谈了一些并非真正重要的事。

“是”还是“应该是”？

在客户访谈的过程中，我注意到，当我问他们所参与的业务流程时，几乎每个人都告诉我它应该如何运转，而不是告诉我它现在如何运转。为此，我一次又一次的问下列问题：它实际上是像你描述的那样运作吗？它在日常实践中运作的如何？通常，听到这样的问题后，谈话对象开始谈论问题。

记住“它怎样”与“它应该怎样”之间的差别。因为你创建的软件要支撑业务流程，所以这些流程必须是真实的。另外，结果可能证明，业务流程并不是最优的，必须修改，但是，这只有在弄清楚他们到底如何工作后你才能察觉。

可能、可以、应该或必须完成？

注意客户的用词，是可能、可以、应该，还是必须。这些词中的每一个都体现了不同的优先级。于是，必须的优先级最高，其次是应该，然后是可以，最后是可能。但是它们之间有一些细微的差别。出于礼貌的原因（至少在波兰是如此），你经常会使用应该来表达（代替）必须的意思。这就是为什么你必须弄清楚需求的重要程度，其中哪些需求应该完成。要做到这一点，你可以问类似这样的问题：那么，这项必须完成？如果没有这项功能，系统的存在是否有意义？

时态：过去、将来和现在

提与某一特定时刻相关的问题，你可以通过这种方式同时控制谈话对象的注意力和 _ 活动 _。

• 使用过去时——谈话对象会回顾他的日常活动。过去时是一种很好的获取真实场景的方式。提类似这样的问题：它以前是如何工作的？这种方法收到过成效吗？那时候，在使用了……之后，你感觉如何？，通过这些问题，你可以将谈话对象的注意力集中在他过去的实际经历上。这种方式让你可以了解到事务当前的真实状态，而不是事情应该怎么样。
• 使用现在时——谈话对象会想象他正在参加一项活动。你应该使用现在时来讨论用例、场景和用户界面。提类似这样的问题：_ 这个界面现在看上去是什么样子？现在，当你点击 OK 按钮时会出现什么？即使表达的不够自然或者语法上有错误（比如，当点击选项菜单，你现在会看到什么窗口？)，也要使用现在时。问“你现在会看到什么窗口？”，可以让谈话对象从系统用户的视角回答问题——他会想象自己 _ 正在操作，他看到了操作过程，而且 _ 现在 _ 就看到了。这种视角使他可以准确地定义自己的期望。如果问题的第二部分是：你将会看到什么窗口？，情况会有所不同。这是个关于未来的问题，它把谈话对象置于一个面对多种可选场景的观察者位置上。在这样一种语境中，他可能会专注于东西 _ 看上去可能 _ 会是什么样，并考虑多个选项，从中做出选择。
• 使用将来时——专注于收益和目标。提类似这样的问题：你将获得什么？你将实现什么？

使用过去时 使用现在时 使用将来时 - 当你想要识别谈话对象面临的问题。

• 当你想要从谈话对象那里收集有关真实情况的信息。

• 当你想要定义用例和场景。

• 当你想同谈话对象一起设计用户界面。

• 当你想了解应用程序该如何运转。

• 当你想要识别客户的业务目标。

• 当你想要确定软件一定可以带来的收益。

（表 1：你应该使用哪种时态提问？）

你可以在同一表达中兼用多种时态来引导谈话对象的注意力，并使自己可以彻底地了解需求，例如……到目前为止，你会从多级菜单中选择员工，这很麻烦。现在，你点击图标就可以立即看到添加员工的表单。这真得将会改善你的工作吗？

提问题，而不要提建议

表 2 的内容摘自旅行社运作支撑系统的需求讨论。这段对话可以说明我描述过的几个错误。

开发人员 客户 评论 - 我希望有个系统支撑旅行社的运作。 - 该系统是要服务于一家旅行社，还是要服务于多家相互协作的旅行社？ - 开发人员提出了他最初想到的一个建议方案。这个问题应该在很久以后再问，例如，当分析师已经了解了客户的业务内容。这个时候问这个问题，真的会增加系统的范围，延长分析工作的时间，但并不能保证客户真正会接受这个价格和方案。
在这个阶段，问这样的问题更合适：_ 你运营着一家还是多家旅行社？_ 这个问题没有提供任何答案暗示，但却同时能为后续需求收集提供一个重要的线索。 - 喔，总而言之，我有这样的发展计划，因此，如果系统能够服务于多家旅行社就最好了。 客户已经对建议方案感兴趣了。 旅行社的工作看起来是什么样子？什么最重要？ - 这个问题不是非常具体。最好是问：有什么的客户服务活动一个接一个的完成？ - 客户可以来办公室也可以在互联网上购买旅行服务。所有的旅行服务都必须从大旅行社的系统中获取，因为我们在这个过程中只是一个中介。我们自己不组织旅行。 客户表示，服务运营有两个流程：在办公室和通过互联网。这些流程应该尽快讨论。 那么，我们正在谈论的模块包括：一个普通的 Web 服务模块和与大旅行社集成的模块？ - 开发人员已经将流程转换成了“模块”。这样，他们就丢失了流程的动态特性，更难确定旅行社连续执行的动作的顺序。 - 是这样，但我还希望能够快速找到旅行社提供的不同产品。它们可以以列表或树结构展示。 客户向前跳跃了一大步，谈及了细节。在这个时候，界面外观不是需要解决的最重要的事情。不过，客户已经表达了一个重要的质量标准：快速简单地找到所有大旅行社的旅行服务。（表 2：扭曲的信息收集过程说明）

如果你想知道谈话对象的真正需求，那么你需要集中精力提出问题，而且不提供答案暗示。

封闭式和开放式问题

让我们从以下两个定义开始。

封闭式问题是那些只能获得预设答案的问题：

• 你愿意现在就谈下新模块吗？——两个可能的答案：是或否。
• 你更愿意现在开会，还是明天四点开会？——两个可能的答案：现在或明天四点。
• 你认为哪种技术更适合这个项目：.NET、JEE 还是 PHP？——三个可能的答案：.NET 或 JEE 或 PHP。

开放式问题是那些对答案限制较少的问题：
- 在这个项目的技术方面，你认为我们该如何处理？
- 你觉得有了这个系统后工作怎么样了？
- 你会如何改进软件开发流程？

如果封闭式问题和开放式问题的区别是是否能够提供一个没有约束的答案，那么这两类问题代表了两个极端。

这两类问题的折中，我们可以称之为“有限问题（narrowed questions）”，也就是那些或多或少允许答案无约束的问题，但这些问题也强加了一个严格定义的狭窄范围，例如：

• 授权模块有什么问题？
• 客户服务流程有什么需要改进？
• 从客户进入银行开始到客户办完业务拿着银行汇款收据离开为止，为了在这段时间里向客户提供服务，必须做什么？

请注意，这三种问题的主要区别是你为谈话对象预留的答案空间。最封闭的问题空间最小，最开放的问题空间最大。

封闭式问题、有限问题和开放式问题是另外三种你可以用于引导需求收集会话的工具，借助这些工具，你可以让会话围绕你认为最为恰当的结构展开。表 3 列出了一些关于如何使用这些问题的建议。

类型 什么时候用 例子 封闭式问题 - 你想要汇总并最终具体化预期。

• 你想要在多个可选项之间作出选择。

• 你要定义方案验收条件。

• 我的理解是，在这个界面上，用户必须有可能做 X、Y、Z。我的理解对吗？

• 使用哪项技术：JEE 还是 PHP？

• 如果 X、Y、Z 都执行了，那么你会认为任务已完成吗？

有限问题 - 你想要在对话结构中深入（更细节的信息）。

• 你希望客户的答案有一个清晰定义的结构。

• 在模块 X 中，什么最重要？

• 从客户进入银行开始到客户办完业务拿着银行汇款收据离开为止，为了在这段时间里服务客户，必须做什么？

开放式问题 - 你开始对话。

• 你想要获取大面上的信息。

• 你想要听到客户对特定主题的反馈。

• 你想要客户“明白地讲出来”。

• 你想要谈话气氛不那么紧张。

• 我怎么才能提供帮助？

• 你对这个项目有什么期望？

• 是什么促使你要改变这个系统？

• 从上次开会到现在，有什么有趣的事情发生吗？

（表 3：你什么时候应该使用封闭式、有限和开放式问题？）

关于作者

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

查看英文原文： Conversation Patterns for Software Professionals - Part 4