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

需求收集 对话模式 提问技巧

摘要

在软件专家的对话模式系列文章的第四部分，Michał Bartyzel主要探讨了如何提出恰当的问题。

正文

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

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

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

• 对话1

团队：下个冲刺会有什么变化吗？
产品经理：我认为没什么变化……
……

• 对话2

团队：你希望在下个冲刺中做什么改变？
产品经理：唔……我还没有考虑呢。
……

• 对话3

团队：待办事项列表中的哪个故事还与下个冲刺的目标有关？
产品经理：我们探讨过目标……？
……

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

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

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

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

问题要切中要害

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

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

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

有意识地选择方向

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

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

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

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

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

“是”还是“应该是”？

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

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

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

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

时态：过去、将来和现在

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

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

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

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

提问题，而不要提建议

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

（表2：扭曲的信息收集过程说明）

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

封闭式和开放式问题

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

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

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

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

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

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

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

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

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

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

关于作者

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