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

软件专家 需求

摘要

如何说服你的客户/上级/团队接受你的想法？——在我同团队共事的过程中，这是人们问的最多的问题之一。本文将介绍一些有效的技术，帮助你提出相对于客户的建议方案而言你认为更好的方案。我们还会判断一下，那是否真是关于说服力。

正文

如何说服你的客户/上级/团队接受你的想法？——在我同团队共事的过程中，这是人们问的最多的问题之一。本文将介绍一些有效的技术，帮助你提出相对于客户的建议方案而言你认为更好的方案。我们还会判断一下，那是否真是关于说服力。（你可能会发现查阅本系列前面的部分很有用：第一部分、第二部分、第三部分、第四部分、第五部分。）

请看下面表格中的对话片段：

表1：一场有关一个特定按钮的对话

客户问了一个几乎是任何软件专家都熟悉的问题——你还能增加什么吗？在本文中，我们对软件专家的反应更感兴趣，他问了相当多的问题来弄清楚业务人员的期望。这看上去是一个很合理的反应。然而，如果仔细观察下退出对话的客户的反应，那么你也许会开始有所怀疑。

向客户这样一个非技术人员提出许多细节问题（据我了解，在一些情况下，单封邮件中问题的数量都接近100，到了对人有伤害的程度）会被视为攻击性行为。就像那样！回想一下你最近一次访问一名汽车修理工、一名电工，或者更显著的，一名医生。当一名专科医师使用大量你不懂的词汇向你传达诊断信息时，就像这样：等等等等说个不停，你是什么感觉？让我们停一下，思量下一名专科医生带来的这种完全无助而又依赖的不安感受。

你知道我所说的问客户若干技术问题会被视为攻击性行为是什么意思吗？如果是团队成员，那就是另外一回事了。你可以向他们提出成千上万的 技术问题，而那仍然会是一次高质量的对话。他们已准备好回答这类问题，而且也具备必要的知识。而客户，并不具备这种知识。

我注意到，团队有时候会将提出许多问题作为说“不”或者推迟最后期限的一种策略。本文的第一项技术是：如果你想说“不”，那就说“不”。如果你想说“稍后”，那就说“稍后”。说“不”体现了一种坚决的主张。这可能会令客户不高兴，并引发一次激烈的讨论或艰难的谈判。说“不”的好处是，我们知道争论点在哪，我们可以开始寻找解决方案。采用一种间接的方式说“不”，就像前文所说的那样，问许多带有攻击性的问题会将关注点引到一些完全无关紧要的细节上。这种方式当然不会增加业务价值。

鉴于我力劝你不要问题许多技术问题，你可能想知道如何向你的客户提供一种可选的（或者在你看来更好的）方案？这完全取决于你提出这些问题的目的。如果你是想把事情搞清楚，那么你提的问题会不同于你想推迟最后期限时所提的问题。其次——这是本文的重点——提供可选方案建议以及提出技术问题，但要选择合适的时机。

发现需求

在文章《软件专家的对话模式》第一部分和第二部分中，我详细描述了什么是需求，如何辨别需求以及如何提炼需求。表2列出了有关需求最重要的信息。

表2：业务需求发现概述

首先，发现并命名客户需求，然后接着提出可选方案建议——这是同客户交谈的主要原则。图1说明了这种行为模式。

图1：提出可选方案建议

第一步是确定客户的立场，就是说，回答问题“客户声明想要什么”？第二步是发现隐藏在客户立场背后的需求。根据表2，那可能是希望获得的收益或者需要避免的问题。下一步，命名主要需求，而且应该是具体的、联系客户业务的、有动机的。

据我观察，通常，我们往往会在确定了客户的立场后立即提出可选方案。这大多数时候会导致冲突。不只一个论点，而是形成了两极分化，彼此抛出了多个论点。

第三步有一点难度。这个时候需要定义满足需求的标准了，也就是问题解决或收益实现的标准。标准无非是需求验收测试。换句话说，它们表明客户如何知道需求已经得到满足。只有在命名了需求并定义了验收标准后，才是向客户提供可选的、更合适的方案的恰当时机。

有时候，即使在命名了需求，定义了验收标准之后，也会出现客户不同意你所提出的可选方案建议的情况。那说明，仍然有一些标准，你没能识别出来。只需要问一下：除了<<已知的标准>>，还有其他的什么需要实现/避免吗<<需求>>？

表3显示了文章开头提到的有关“额外的按钮”的对话，该对话已经是按照表2所列的提出可选方案的模式进行的。

表3：一场有关一个特定按钮的对话

读者以为如何——这篇文章谈的是关于说服力吗？从理论上讲，软件专家已经改变了客户的想法，因此，他“说服”了客户。不过，需要注意，这关系到对客户需求的识别和理解——而不是提供数量合适的论据。论据在帮助已经被说服的人确认他们的决定时有用。相比之下，发现需求，定义标准，是找出一种对双方（客户和你）都有利的方案所需要做的。

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