当有人请求一个项目时, 我们必须假设这是非常重要的，他们非常关心你将要开发的产品. So, 可以肯定的是，客户一定会对最终产品产生很多期望, 因此，在分娩时可能会变得情绪化.

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

虽然没有成功的秘诀，当涉及到 远程软件开发，我相信有几件事 必须避免 与信任你的客户保持健康和富有成效的关系.

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

想象一下与客户的沟通就像你与同事的日常沟通一样, 朋友, 或者任何你愿意礼貌对待的人.

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

你不可能每天都聊天，除非你有 很多 谈论, 但是你们会保持某种形式的交流, 出于礼貌和实际考虑:你不想让对方认为你忘记了他们, 但你肯定不想毫无理由地开车穿过半个城市.

在某一时刻, 在你的专业沟通中，你可能也经历过类似的情况, 即使是长期的合作伙伴和同事. 有些项目的执行只需要最少的沟通, 就像说“老样子”一样, 中午, 来确认一顿清淡的午餐. 即使有什么事情发生，对方也一定会让你知道，你也会同意重新安排.

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

如果你开始做一个项目, 尤其是当你面对一个新客户的时候, 如果他们没有你的消息, 他们会开始重新考虑你的工作和承诺. 即使几周后你带着完美的产品出现, 客户对你的印象可能已经不那么理想了.

虽然有时候会觉得很尴尬, 即使你没有什么不寻常的事情要报告，和客户谈谈也无妨! 你是否对用户故事中的一个小细节有任何疑问? 如果你认为这很重要，让他们知道. 你有点晚了，而且不确定你是否能在约定的日期前完成? 尽快给客户打电话! 他们最好马上知道这件事.

你没有任何疑虑，项目完全按计划进行，但客户不怎么说话? 为什么不每隔几天发一封邮件描述一下你的进展呢? 这不会造成任何伤害，因为这些邮件不会给任何人带来麻烦, 此外，你还要记录你的进度，并与客户保持定期沟通.

错误的客户沟通导致不切实际的期望

So, 一开始, 我提到过客户一定对项目有很多期望, 正确的? 正确的. 期.

客户对产品的期望已经很高了. 如果事情不像他们想象的那样发展，客户将不可避免地感到沮丧. So, 为什么会有人承诺做不到呢, 从而产生了更多不切实际的期望?

这里有一个简单的类比: 你在网上买了一台平板电脑，承诺10天交货. 第8天，商店告诉你有问题，延迟一周交货. 为了补偿给你带来的不便，零售商承诺给你75美元的购物券.

你可能没有 真的 接下来几天我都需要那个平板电脑，所以你觉得这是笔好买卖! 现在你可以享受平板电脑了，还可以用商店积分给你的孩子买些好东西. 但第二天商店打来电话，说一切都在一夜之间解决了.

你第二天就能拿到药片了. 没有额外费用，没有商店积分. 现在是 你 这是沮丧!

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

倒带几天，你所期待的只是平板电脑. 难道没有人答应给你更好的待遇吗, 当你的玩具第二天到达时，你会很满意的. 但现在, 你觉得自己无缘无故地错过了机会, 除了商店决定让你知道.

开发者如何, 特别是自由职业者, 在与客户的沟通中避免类似的情况?

不要发疯，一开始想到什么就说什么. Suggestions are not prohibited; 实际上, they are 非常 如果您认为所请求的特定功能不是解决手头问题的好选择，那么欢迎您. 但关键是: 认为第一.

• 倾听客户的意见.

• 分析他们的问题.

• 分析提出的解决方案.

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

• 最后，提出你的建议.

这就是为什么客户沟通技巧可能是棘手的, 因为在前四步中任何一步失败都意味着你可能会浪费你的时间, 更糟糕的是, 你客户的时间.

不要以为你知道客户需要什么

套用 玛丽Schmich17届的同学们，女士们，先生们:听客户的. 如果我只能给你一个建议，那就是倾听客户的意见.

如果你被叫去做一个项目，那是因为有人需要什么. 还有谁比你的委托人更了解这种必要性呢? 这似乎是显而易见的，但有时，在现实世界中，人们会忘记这一点.

让我给你举个例子. 一个零售商要求为他的业务安装一个“软件系统”. 你一看到就知道了, 你会得出这样的结论:他们想要的是注册所有可用产品的东西, 记录每一笔购买, 为客户生成收据, 并定期报告哪些商品售出，哪些商品缺货.

So, 第一次见面时, 你要展示你的效率，向他们展示你准备的东西, 建议的功能, 一个基本的设计，以配合商店的视觉识别和所有. 但随后困惑的客户说, 实际上, 他们需要的是一种算法来计算如何更好地展示货架上的产品, 旨在提高特定品牌和产品的收入!

这里的错误仅仅是没有确定应该解决什么问题. 当然, 在这种情况下, 因为这是在项目的早期阶段, 有足够的时间来弥补, 但有时, 这种错误还会继续发生. 即使它不能像前面的例子那样激烈, 它仍然会损害项目和/或你与客户的关系.

我的建议如下:与你未来的用户交流, 尽可能多, 并咨询项目中的各种利益相关者. 他们对形势有一个很好的概述，他们知道自己需要什么. 试着弄清楚他们现在在做什么, 一路走来的每一步, 并解释软件将如何派上用场. 我喜欢这么说, 当我试图理解客户的愿望时, 我的目标是几乎能够自己完成他们的工作. 如果你接近这一点，那么你就真正发现了他们的需求是什么.

不理解客户的要求

收到关于手头问题的某种文档并不罕见. 有时它只是一个高层次的描述, 而其他时候，它是包含用例和业务规则的详细文档. 无论如何, 不管记录有多清楚, 有一件事你做不到, 就假设上面写的都是绝对事实吗.

什么???

完全. 第一个, 某物对某人来说可能意味着一件事, 在某种情况下, 对于那些不属于那个现实的人来说是完全不同的. 如果你和客户有什么不一样的地方，那就是背景!

Second, not e非常one is a 非常 skilled writer; they try to say A but end up describing B.

So, 看完所有寄给你的东西, 你怎么能确定你读到的是真正的意思呢? 嗯，你要消化所有东西，做笔记，分析所有东西，然后…… 召开会议. (你看到? 这都是关于沟通!)在会议上, 你将谈论这个问题, 用你自己的话描述你所理解的. 在这个阶段，你可能会发现任何误解.

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

好吧, 我仍然不能保证你理解了他们的意思，我的建议仍然有效:花点时间看看你的笔记, 想想整个问题, 组织的一切, 最好是在事件的时间轴上, 然后再次打电话/与客户见面，展示你的理解. 这对你来说可能是重复的, 但有时即使是客户也无法完全了解完成特定任务所涉及的所有过程，然后才会看到软件必须有多复杂.

最后，你必须确定没有歧义或误解.

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

OK, 既然你知道你应该倾听客户的意见并确认你所理解的, 你可以照他们说的去做, 正确的?

错误的!

现在，你终于可以利用你所有的经验问自己: 客户的要求能解决他们的问题吗? 他们问你的真的是他们需要的吗?

你会惊讶地发现有多少次答案是“不”.”

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

如果你和客户都讲道理的话, 然后你要么继续你的解决方案，要么进行头脑风暴，想出一个更好的方案(以防你的想法因为某些原因不能被客户接受)。.

原型——不要写过多的文档

我已经说过你和你的委托人通常观点不同，对吧? 因此, 就像它会影响你对他们文档的理解一样, 这会影响他们对你书面表达的理解. 这也是背景的问题.

So, 我在某种程度上(在更高或更低的层面上)同意, 我们必须记录下我们将要开发的内容. 但是交出几页没有任何视觉元素的文本不会给你带来多大好处. 客户看完会觉得无聊, 会停止关注, 并且可能无法理解您所说的那些复杂业务规则的含义，或者他们解释的内容与您所设想的完全不同.

请记住，如果客户没有技术背景，这些误解可能会更糟.

所有这些因素都会导致同样的问题:当你交付产品时，客户会抱怨，因为它很可能不是他们想要的.

以下是我的建议: 总是建立原型，即使只是一个草图来描绘你的计划. 不管你要做什么定义，都从这里开始. 写推荐信，尽量保持简单.

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

我几乎可以肯定，每个开发人员都经历过以下情况:在项目开始时, 客户说 “我需要软件的背景色是黄色. 董事会已经同意了.” 然后，当软件交付时，他们说 “哦，但是背景色不能是黄色. 我告诉过你必须是绿色的!” 现在，你应该如何处理这个?

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

与客户保持良好的沟通记录总是好的, 只是为了确保你们在同一页，并留下书面线索. 大多数时候，如果事情很简单，你可以给客户发邮件，说， “正如我们在那次会议上商定的那样，系统的背景将是黄色的.” 如果, 在未来, 客户改变了主意, 你可以辩称，你那样做是因为邮件中提到的那次会议, 但如果真的需要修改的话, 你可以执行它, 额外的x个小时(有时, 额外的x美元).

但如果没有什么能证明你是对的, 那么您可能需要做出一个决定(以及吸取一个教训):这个更改是否大到需要更改当前架构或影响其他功能? 如果不是, 也许最好还是继续吧, 这样做, 让客户站在你身边(但要睁大眼睛，以免再次发生). If it does, 然后 a talk with the client will be the best solution; not one focusing on “你是对的，” 但在 我们如何解决当前的问题.”

无论如何, 避免进行大修改的最佳方法是在短时间内交付短的新功能. 因此, 如果有什么需要改变的话, 这可能不会是对现有产品的重大变革.

知道什么时候要遵守最后期限

最后的。, 但重要的是, 你可能犯的最大错误之一就是给你的客户一个完成项目的最后期限. 他们会乞求你犯那个错误!

当然, 作为客户, 你想知道什么时候你可以使用那些你在过去几周(几个月)里一直在讨论的好功能?). 但, 因为项目不是一个定义好的产品, 从开发开始到软件准备使用，可能会发生很多事情.

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

这些都不是开发者的错，而且会严重影响项目的截止日期. 但是如果你, 乐于取悦客户, 我保证过你会在某个日期前把东西交出来，结果, 理由都是对的, 没有这样做, 我可以保证的一件事是，客户将会, 至少有一点, 沮丧. 如果你是一个自由职业者，你必须有效地管理你的时间，就像这样 Toptal 工程博客的一篇文章对此进行了解释. 别忘了客户关系管理也是你的工作.

So, 帮你自己和依赖项目的人一个忙，至少给他们一个开发所有东西需要多长时间的估计, 但一定要清楚，这只是一个估计，而不是最后期限.

也, 我强烈建议(特别是如果你已经给出了一个估计)，你总是告诉客户什么事情比预期花费的时间长，这样他们就可以采取行动帮助你!