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

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

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

客户

软件专家

你能在这个界面上另外增加一个按钮用于生成一份不完全报告吗？ – _ 它应该是什么数据？如果没有数据显示什么？你想过聚合部分数据的结果吗？这可能需要有危险的重构？_好吧……也许我首先该仔细考虑下…… -表 1：一场有关一个特定按钮的对话

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

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

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

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

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

发现需求

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

待解决的问题 预期收益 需求是…… 辅助问题 _ 我想要避免……_ 我想要实现…… 具体的 _ 你如何知道……？
究竟是什么？
如何？
用什么方式？
什么会让你……？
谁？哪里？什么时候？同谁一起？多少？多远？举个例子……_为什么？
为什么那很重要？
如果你无法得到它会怎样？
是什么让你想要……？
困难之处是什么？
你会损失什么？
你想保护自己免受什么？
你想避免什么？ 为了什么？
那会给你带来什么？
你能获得多少 / 什么？
你得到它会怎样？
然后会出现什么可能？
那会带来什么新的东西或不同？
如此你会获得什么好处？ 联系业务的 那跟你的工作 / 业务有什么关系？
那跟你的业务目标有什么关系？客户说：_ 我不想……

……效率太低
……不直观
问题是……
那不可能，因为……
那很难，因为……
恐怕……_ 客户说：_ 我真正关心的是……

这样一来，我就能够……
那会使……成为可能
这将会意味着……
如果那……的话，其好处是……
我很高兴，因为那会……
那会……_ 有动机的 如果你避免了它会有什么结果？
如果你实现了它会有什么结果？
如果你现在被迫接受一个问题，你会选择哪一个？
如果你现在只能实现其中一项收益，你会选择哪一个？表 2：业务需求发现概述

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

strong> 图 1：提出可选方案建议

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

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

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

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

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

客户 软件专家 评论你能在这个界面上另外增加一个按钮用于生成一份不完全报告吗？ - 客户声明了他 / 她最初的立场。软件专家想要提供一种在他看来更好的解决方案，但是……- 你为什么需要这份报告？你想要借助这份报告达成什么工作目的？ ……他首先关注的是发现需求，这会促使客户提出这一功能需求。软件专家询问预期收益，而客户……

我不想等待月末的销售图表。 - ……用一个他 / 她试图避免的问题作出回应。常有的事。通常，人们不会回答问题，而是谈论他们知道的东西。
如果你问了一个有关收益的问题，而客户谈论存在的问题，那么要顺着客户的思路。- 所以，这里的问题是需要等待销售图表很长时间？ 软件专家命名了需求——“等待销售图表很长时间”。是的。 - – 你最需要什么的销售图表？ 软件专家想针对发现的需求明确验收标准，就是说，他想知道客户怎样才会认为问题已经解决。我想知道对关键客户的销售情况。 - – 如果你从我们这里收到一封包含这些图表的邮件，是否可以？我们是否就可以不考虑这个额外的按钮了？ 在了解到标准是“对关键客户的销售情况”之后，软件专家向客户提出了可选的方案，但是……哦，不。因为有了这个按钮，我就可以在任何想要的时候获得图表，而邮件会让我对你形成依赖。 - 结果表明，客户不接受这个建议。就是说，仍然还有一些没有定义的验收标准……- 请告诉我，你需要以多大的频率查看这些有关关键客户销售情况的图表。每月底一次是否太少了？ ……需要加以澄清。至少每周两次。 - 实际上，另一个标准是查看报告的频率。- 那么，如果你每 2 周一次收到一封包含这些图表的邮件，对你而言是不是已经足够了？ 再一次，软件专家提出了一种可选方案，考虑了目前为止定义的所有验收标准。我认为可以。至少目前是这样。 - 成了！只是为了以防万一，客户补充说，这是“现在”的方案。好吧，业务处在不断变化中。表 3：一场有关一个特定按钮的对话

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

关于作者

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

查看英文原文： Conversation Patterns for Software Professionals. Part6