客户沟通中的常见错误：如何不让客户感到沮丧

当有人请求一个项目时，我们必须假设它非常重要，并且他们非常关心您将要开发的产品。 因此，可以安全地假设客户必然会对最终产品产生很多期望，因此在交付时可能会变得情绪化。

在整个项目过程中，客户可能会对交付的功能感到非常兴奋并爱上你，但在第二天他或她会发现有些东西不起作用，这种感情就会消失。 通常情况下，这只是客户沟通出错的问题。

尽管在远程软件开发方面没有成功的秘诀，但我相信有一些事情必须避免，才能与非常信任您的客户保持健康和富有成效的关系。

与客户的基本沟通不要失败

想象一下与客户的交流，就像您与同事、朋友或任何其他您会礼貌的人的日常交流一样。

如果一位老朋友来家拜访，而您同意在中午“在老地方”享用当地美食，那么几周后，您会出现在那儿吗？ 您会在此期间保持联系，提前几天打电话确认吗？ 或者你可能会认为他们太忙了，不想无缘无故地打扰他们？ 您希望他们在到达时通知您吗？

除非您有很多话要说，否则您不太可能每天都聊天，但是出于礼貌和实际考虑，您会保持某种形式的交流：您不希望对方认为您忘记了他们，但您绝对不想无缘无故地开车穿过城镇。

在某些时候，您可能在专业交流中也遇到过类似的情况，即使是与长期合作伙伴和同事。 有些项目是在最少的沟通下执行的，就像说“往常一样，中午见”来确认一顿清淡的午餐。 就算有事，对方一定会通知你，你也同意改期。

然而，在软件开发的世界里，事情并不是那么简单或线性的。

如果您开始从事一个项目，尤其是在与新客户打交道时，如果他们从未收到您的来信，他们将开始重新考虑您的工作和承诺。 即使您在几周后展示了完美无瑕的产品，客户可能已经对您的看法不太理想。

尽管有时难免会感到尴尬，但即使您没有任何不寻常的事情要报告，与客户交谈也没有什么坏处！ 您对用户故事的一小部分有任何疑问吗？ 如果您认为这很重要，请让他们知道。 您有点晚了，不确定您是否能够满足您约定的预计日期？ 尽快给客户打电话！ 最好他们马上听到。

您没有任何疑虑，项目完全按计划进行，但客户却不怎么说话？ 为什么不每隔几天发送一封电子邮件来描述您的进度？ 它不会造成任何伤害，因为电子邮件不会对任何人造成滋扰，而且您将记录您的进度并与客户保持定期沟通。

有缺陷的客户沟通助长了不切实际的期望

所以，一开始，我提到客户对这个项目肯定有很多期望，对吧？ 正确的。 时期。

客户已经对产品寄予厚望。 如果它没有按照他们想象的方式进行，客户将不可避免地感到沮丧。 那么，为什么会有人承诺超出他们的能力，从而产生更不切实际的期望呢？

这是一个快速的类比：您在网上购买了一台平板电脑，并承诺 10 天交货。 第8天，店家告诉你有问题，延迟一周发货。 为了补偿您给您带来的不便，零售商承诺给您 75 美元的商店信用。

在接下来的几天里，您可能并不真的需要那台平板电脑，所以您认为这是一笔划算的交易！ 现在您可以享受平板电脑了，还可以使用商店积分为您的孩子购买好东西。 但第二天店家打来电话，说一切都在一夜之间解决了。

第二天你会得到平板电脑。 没有额外费用，没有商店信用。 现在沮丧的是你！

“什么？ 就在昨天你告诉我我会得到更好的交易！ 这不公平！ 我已经告诉孩子们了……”

倒退几天，你所期待的只是平板电脑。 如果没有人向您承诺更好的交易，那么第二天到货时您会对您的玩具感到满意。 但现在，除了商店决定让您知道之外，您觉得自己无缘无故地错过了。

开发人员，尤其是自由职业者，如何避免在与客户沟通时出现类似情况？

不要发疯，首先说出你想到的一切。 建议不被禁止； 实际上，如果您认为某个特定的请求功能不是解决手头问题的好选择，那么他们是非常受欢迎的。 但关键是：先思考。

• 听客户的。

• 分析他们的问题。

• 分析建议的解决方案。

• 确保它在预算/时间表之内。

• 最后，继续并提出您的建议。

这就是为什么客户沟通技巧可能很棘手，因为仅在前四个步骤中的一个失败意味着您最终可能会浪费您的时间，更糟糕的是，您的客户的时间。

不要假设你知道客户需要什么

释义 Mary Schmich，17 年级的女士们先生们：倾听客户的意见。 如果我只能为您提供一个关于未来的建议，那就是倾听客户的意见。

如果你被要求做一个项目，那是因为有人需要一些东西。 谁能比您的客户更了解这种必要性？ 这似乎很明显，但有时，在现实世界中，人们会忘记它。

让我举一个例子。 一位零售商要求为其业务提供“软件系统”。 一旦你看到它，你就会得出结论，他们想要的是注册所有可用产品，记录每次购买，为客户生成收据，并定期报告售出的商品以及哪些商品已用完股票。

所以，在你的第一次会议上，你想展示你的效率，并向他们展示你准备的东西、提议的功能、与商店视觉识别相匹配的基本设计等等。 但随后疑惑的客户说，实际上，他们需要的是一种算法来计算如何更好地在货架上展示产品，旨在为特定品牌和产品增加收入！

这里的错误只是没有确定你应该解决什么问题。 当然，在这种情况下，由于它是在项目的早期阶段，有足够的时间来纠正它，但有时，这种错误会发生在更远的地方。 即使它不像前面的例子那样激烈，它仍然会损害项目和/或您与客户的关系。

我的建议如下：尽可能多地与您的未来用户交谈，并咨询项目中的各个利益相关者。 他们对情况有很好的了解，他们知道自己需要什么。 试着弄清楚他们目前在做什么，每一步，并解释软件将如何派上用场。 我想说的是，当我试图了解客户的愿望时，我的目标是几乎能够自己完成他们的工作。 如果您接近这一点，那么您就真正发现了他们的需求。

不了解客户的要求

收到有关手头问题的某种文档的情况并不少见。 有时它只是一个高级描述，而有时它是包含用例和业务规则的详细文档。 无论如何，无论记录多么清晰，你不能做的一件事就是假设那里所写的一切都是绝对真实的。

什么？？？

确切地。 首先，在特定的环境中，某事对某人来说可能意味着一件事，而对于不属于那个现实的人来说，则是完全不同的事情。 如果有什么你和客户没有共同点，那就是上下文！

其次，不是每个人都是非常熟练的作家； 他们试图说A，但最终描述了B。

那么，在阅读了您收到的所有内容之后，您如何确定您所阅读的内容确实是他们的意思？ 好吧，您将消化所有内容，做一些笔记，分析所有内容，然后……召开会议。 （你看到了吗？这都是关于沟通的！）在会议上，你会谈论这个问题，并用你自己的话描述你所理解的。 在这个阶段，您可能会发现任何误解。

“哦，但就我而言，我没有得到任何文件。 我只是和客户坐在一起，他们在我做笔记的同时向我解释了一切。”

好吧，仍然不能保证你理解他们的意思，我的建议仍然有效：花点时间做笔记，考虑整个问题，组织一切，最好是在某种事件时间表中，然后再次打电话/见面客户来呈现你所理解的。 这听起来可能对您来说是重复的，但有时甚至客户也无法全面了解完成特定任务所涉及的所有流程，然后会看到软件必须有多复杂。

最后，您必须确定没有歧义或误解。

为什么你不应该不假思索地交付客户要求的一切

好的，既然您知道您应该听取客户的意见并确认您的理解，您就可以继续按照他们的要求去做，对吧？

错误的！

现在是您终于可以利用所有经验并问自己的时候了：客户要求您解决他们的问题吗？ 他们问你的真的是他们需要的吗？

你会惊讶地看到有多少次答案是“不”。

在交付客户要求的内容之前，我们需要分析问题，如果您不同意雇主的建议，那么您的工作和职业责任就是明确这一点。 当然，你应该解释为什么你认为他们的提议不好，以及你的替代方法将如何解决这些缺点。 再次，沟通是关键。

如果您和客户是合理的，那么您将继续您的解决方案，或者进行头脑风暴会议以提出更好的解决方案（以防您的想法由于某种原因不被客户接受）。

原型——不要编写大量文档

我已经说过，您和您的客户通常没有相同的观点，对吗？ 因此，正如它会影响您对他们的文档的理解一样，它也会影响他们对您以书面形式提供的内容的理解。 这也是一个上下文问题。

所以，我同意以某种方式（在更高或更低的层面上），我们必须记录我们将要开发的内容。 但是处理几页没有任何视觉元素的文本对你没有多大好处。 客户会厌倦阅读它，停止关注，并且可能无法理解您所说的那些复杂的业务规则的含义——或者他们会解释与您的设想完全不同的东西。

请记住，如果客户没有技术背景，这些误解可能会更加严重。

所有这些因素都可能导致相同的问题结果：当您交付产品时，客户会抱怨，因为它很可能不是他们的想法。

这是我的建议：总是原型，即使它只是一个草图来绘制你的计划是什么。 无论您必须做出什么定义，都从那里开始。 做参考并尽量保持简单。

不要浪费时间说服客户你是对的

我几乎可以肯定每个开发者都经历过这样的情况： 项目开始时，客户说“我需要软件的背景颜色是黄色的。 董事会已经同意了。” 然后，当软件交付时，他们说“哦，但是背景颜色不能是黄色的。 我告诉过你它必须是绿色的！” 现在，你应该如何处理这个问题？

当然，在任何情况下，坚持你是对的而他们是错的都是没有用的。 如果有的话，它只会给你和客户都带来困难。

与客户保持良好的沟通记录总是好的，只是为了确保您在同一页面上并留下书面痕迹。 大多数时候，如果事情很简单，你可以给客户发电子邮件，说： “正如我们在那次会议上同意的那样，系统的背景将是黄色的。” 如果将来客户改变主意，您可以辩称您这样做是因为电子邮件中提到的那次会议，但如果确实需要进行修改，您可以执行它，额外 x 小时（有时，额外的 x 美元）。

但是，如果没有任何东西可以证明您是对的，那么您可能需要做出决定（以及要吸取的教训）：是否需要对当前架构进行更改或影响其他功能的变化如此之大？ 如果没有，最好还是继续，做，让客户在你身边（但要睁大眼睛，这样就不会再发生了）。 如果是这样，那么与客户交谈将是最好的解决方案； 不是关注“你是怎么做对的”，而是关注“我们如何解决当前的问题”。

无论如何，避免进行大修改的最佳方法是在短时间内交付简短的新功能。 因此，如果有什么需要改变的话，它可能不会是对已经存在的东西的重大转变。

知道何时承诺截止日期

最后但并非最不重要的一点是，您可能犯的最大错误之一就是给您的客户一个截止日期，让您完成项目。 他们会求你犯这个错误！

当然，作为客户，您想知道什么时候可以使用您在过去几周（几个月？）中讨论过的所有这些不错的功能。 但是，由于项目不是一个已定义的产品，从开发开始到软件准备好使用，可能会发生很多事情。

首先，人们无法预测不可预测的事情。 你很可能不得不处理一些你没有预料到的事情。 可能是客户承诺的未按时购买的许可证，或者您需要使用的其他一些内部软件，但在应该发布的时候没有发布，或者环境与一开始同意的环境不同，或者客户改变了他们对（几个）功能的想法，你不得不重做几件事。

这些都不是开发人员的错，并且会严重影响项目的截止日期。 但是，如果您愿意取悦客户，承诺您会在某个日期之前交付所有东西并最终出于所有正确的原因而没有这样做，我可以保证的一件事是客户将至少有一点， 沮丧的。 如果你是一名自由职业者，你必须有效地管理你的时间，正如这篇 Toptal 工程博客文章所解释的那样。 不要忘记客户关系管理也是您的工作。

因此，请帮自己和依赖该项目的人一个忙，至少给他们一个估计开发所有东西需要多长时间，但始终清楚地表明这只是一个估计，而不是最后期限。

另外，我强烈建议（特别是如果您已经给出了估计）当某件事花费的时间比预期的要长时，您总是告诉客户，这样他们就可以采取行动来帮助您！