客户沟通中的常见错误：如何不挫败客户

本文概述

• 与客户进行基本沟通时不会失败
• 错误的客户沟通促进了不切实际的期望
• 不要假设你知道客户的需求
• 不明白客户的要求
• 为什么你不假思索就不交付客户要求的一切
• 原型-不要编写广泛的文档
• 不要再浪费时间说服客户了
• 知道什么时候提交截止日期

当有人要求一个项目时, 我们必须假设它非常重要, 并且他们会深切关心你将要开发的产品。因此, 可以安全地假设客户一定会对最终产品抱有很高的期望, 因此在交付产品时可能会产生感动。

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

尽管在远程软件开发方面没有成功的秘诀, 但我相信必须避免一些事情来与客户保持健康和富有成效的关系, 这些关系赢得了你的极大信任。

与客户进行基本沟通时不会失败

想象与客户的交流, 就像每天与同事, 朋友或你要礼貌地与他人交流一样。

如果一个老朋友来访, 你同意在几周后的中午”在你的老地方”享用当地美食, 你是否会出现在那儿？同时, 你是否会保持联系, 请提前几天进行确认？或者, 也许你会认为他们太忙了, 不想无缘无故打扰他们？你希望他们到达时通知你吗？

除非你有很多话题, 否则你不可能每天都聊天, 但出于礼貌和实用性, 你将保持某种形式的交流：你不希望其他人以为你忘记了他们, 但是你绝对没有充分的理由不想在城镇中途开车。

在某些时候, 即使是长期的合作伙伴和同事, 你在专业交流中也可能会遇到类似的情况。一些项目的执行需要最少的沟通, 就像说”平时, 中午见”, 以确认便当。即使有事情发生, 对方也一定会通知你, 并且你同意重新安排时间。

但是, 在软件开发领域, 事情并没有那么简单或线性。

如果你开始从事项目工作, 特别是在与新客户打交道时, 如果他们从未收到你的来信, 他们将开始对你的工作和承诺产生第二个想法。即使你在几周后出现了完美无瑕的产品, 客户对你的看法也可能已经不太理想。

尽管有时候感觉有些尴尬, 但即使你没有任何异常举报要与客户交谈也不会受到伤害！你是否对用户故事的一个小问题有任何疑问？如果你认为这很重要, 请告诉他们。你迟到了一点, 不确定是否能够达到你约定的预计日期？尽快致电客户！最好是他们马上就听说。

你没有任何疑问, 并且项目按计划进行得很顺利, 但是客户谈不上什么？为什么不每隔几天发送一封描述你的进度的电子邮件？这不会造成任何危害, 因为电子邮件不会对任何人造成干扰, 此外, 你还将记录自己的进度并保持与客户的定期沟通。

错误的客户沟通促进了不切实际的期望

因此, 在一开始, 我提到客户一定会对项目有很多期望, 对吗？对。期。

客户已经对该产品寄予厚望。如果不按照他们的想象去做, 客户将不可避免地感到沮丧。那么, 为什么有人会承诺超出他们的能力范围, 从而产生更加不切实际的期望？

快速进行比较：你在线购买了平板电脑, 并保证可以在10天内交货。商店会在第8天告知你有问题, 并将交货时间推迟一周。为了弥补给你带来的不便, 零售商承诺给你$ 75的商店信用额度。

无论如何, 接下来几天你可能真的不需要平板电脑, 因此你认为这很划算！现在, 你可以享受平板电脑的乐趣, 还可以使用商店信用额为孩子购买一些精美的东西。但是商店第二天打来电话, 说一切都在一夜之间解决了。

第二天你将获得平板电脑。没有额外费用, 没有商店信用。现在是你感到沮丧！

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

倒带几天, 你所期望的只是该平板电脑。如果没有人答应给你更好的交易, 第二天到货时, 你会对玩具感到满意。但是现在, 除了商店决定让你知道之外, 你觉得自己没有任何理由错过了。

开发人员, 尤其是自由职业者, 如何在与客户的沟通中避免类似的情况？

首先, 不要发疯并说出所有想到的内容。建议不被禁止；实际上, 如果你认为特定的请求功能不是解决当前问题的理想选择, 则非常欢迎他们。但是关键是：首先考虑。

• 听客户。

• 分析他们的问题。

• 分析提出的解决方案。

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

• 最后, 继续提出你的建议。

这就是为什么客户沟通技巧比较棘手的原因, 因为仅在前四个步骤之一中失败就意味着你可能最终浪费了时间, 更糟的是浪费了客户的时间。

不要假设你知道客户的需求

玛丽·施密希(Mary Schmich)的解读：” 17岁的女士们, 先生们：倾听客户的声音。如果我只能为你提供未来的一个建议, 那就听听客户的意见。

如果有人要求你参加项目, 那是因为有人需要某些东西。还有谁比你的客户更了解这种必要性？这看起来似乎很明显, 但有时在现实世界中, 人们会忘记它。

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

因此, 在你的第一次会议上, 你想展示自己的效率, 并向他们介绍你准备的内容, 拟议的功能, 与商店的视觉标识以及其他相关的基本设计。但是, 这位困惑的客户说, 实际上, 他们需要的是一种算法, 用于计算如何更好地在货架上展示产品, 目的是提高特定品牌和产品的收入！

这里的错误仅仅是无法确定你应该解决的问题。当然, 在这种情况下, 由于该项目还处于初期阶段, 因此有足够的时间来纠正它, 但是有时这种错误还会继续发生。即使它不能像前面的示例那样激烈, 它仍然会损害项目和/或你与客户的关系。

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

不明白客户的要求

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

什么？？？

究竟。首先, 在某些情况下, 某事物可能对某人意味着一件事, 对于不属于该现实的人们而言, 则意味着完全不同的事物。如果你和客户之间没有共同点, 那就是上下文！

其次, 并不是每个人都是一个非常熟练的作家。他们试图说出A, 但最后却描述了B。

因此, 在阅读完你发送的所有内容之后, 如何确定阅读的内容确实是他们的意思？好吧, 你将消化所有内容, 做一些笔记, 分析所有内容, 然后……召开会议。 (你看到了吗？这全都是沟通！)在会议上, 你将讨论问题, 并用自己的语言描述你所了解的内容。在这一阶段, 你可能会发现任何误解。

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

好吧, 仍然不能保证你理解它们的含义, 并且我的建议仍然有效：花些时间记录笔记, 考虑整个问题, 组织所有事情, 最好是在某种事件时间表中, 然后再次与客户陈述你的理解。这可能对你来说是重复的, 但有时即使客户也不了解完成特定任务所涉及的所有流程, 然后你会看到软件的复杂程度。

最后, 你必须确定没有歧义或误解。

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

好, 既然你知道你应该听取客户的意见并确认你的理解, 那么你可以继续进行他们要求你做的所有事情, 对吗？

错误！

现在是时候, 你终于可以使用自己拥有的所有经验并问自己：客户要求你解决什么问题吗？他们是不是真的问过你需要什么？

你会惊讶地看到答案是否为”否”。

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

如果你和客户都比较合理, 那么你将继续进行解决方案或进行集思广益的会议以提出更好的解决方案(以防你的想法因某些原因而不能被客户接受)。

原型-不要编写广泛的文档

我已经说过, 你和你的客户通常没有相同的看法, 对吗？因此, 就像它影响你对他们文档的理解一样, 它也会影响他们对你书面内容的理解。这也取决于背景。

因此, 我同意以某种方式(更高或更低), 我们必须记录我们将要开发的内容。但是, 交出几页没有任何视觉元素的文字不会带来多大好处。客户对阅读它会感到无聊, 会停止关注, 并且可能无法理解这些复杂的业务规则的含义, 否则他们会解释与你所设想的完全不同的事物。

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

所有这些因素都可能导致同样的问题：在你交付产品时, 客户会抱怨, 因为这可能不是他们所想的。

我的建议是：始终制作原型, 即使只是草图来绘制你的计划。无论你要进行什么定义, 都从这里开始。进行引用并尝试使其简单。

不要再浪费时间说服客户了

我几乎可以肯定, 每个开发人员都经历过以下情况：在项目开始时, 客户说：”我需要软件的背景色为黄色。董事会已经达成协议。”然后, 当软件交付时, 他们说：”哦, 但是背景颜色不能是黄色。我告诉过你它必须是绿色的！”现在, 你应该如何处理呢？

可以肯定的是, 在任何情况下仅仅坚持认为自己是对的, 而他们是错的是没有用的。如果有的话, 这只会给你和客户带来困难。

与客户保持良好的沟通记录总是很不错的, 只是确保你在同一页面上并留下书面痕迹。在大多数情况下, 如果简单的话, 你可以给客户发送电子邮件, 说：”按照我们在那次会议上达成的协议, 系统的背景将是黄色的。”而且, 如果将来客户改变主意, 你可以说你这样做是因为电子邮件中提到了该会议, 但是如果确实需要进行修改, 则可以额外执行x个小时来执行该修改(有时需要多付x美元)。

但是, 如果没有什么证据可以证明你是对的, 那么你可能要做出一个决定(以及一个值得学习的教训)：如此大的变化是否需要对当前架构进行更改或影响其他功能？如果没有, 那么最好是继续做下去, 然后将客户拉到身边(但要睁大眼睛, 这样就不会再发生了)。如果是这样, 那么与客户交谈将是最好的解决方案。不是专注于”你的正确做法”, 而是”我们如何解决当前问题”。

无论如何, 防止必须进行重大修改的最佳方法是在短时间内提供简短的新功能。因此, 如果必须进行任何更改, 那么它可能不会是已经存在的重大变化。

知道什么时候提交截止日期

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

当然, 作为客户, 你想知道何时才能使用过去几周(几个月？)以来一直在讨论的所有出色功能。但是, 由于项目不是定义好的产品, 因此从开发开始到软件准备就绪, 可能会发生很多事情。

首先, 无法预测不可预测的事物。你很有可能必须处理你不希望看到的事情。这可能是客户承诺未按时购买的许可证, 或者你需要使用但在应有的时间未发布的其他一些内部软件, 或者环境与开始时同意的不同, 否则客户改变了主意(很少), 而你不得不重做几件事。

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

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

另外, 我强烈建议(尤其是如果你已经给出了估算值), 你总是告诉客户什么时候花的时间比预期的长, 以便他们可以采取行动帮助你！