客戶溝通中的常見錯誤：如何不讓客戶感到沮喪

當有人請求一個項目時，我們必須假設它非常重要，並且他們非常關心您將要開發的產品。 因此，可以安全地假設客戶必然會對最終產品產生很多期望，因此在交付時可能會變得情緒化。

在整個項目過程中，客戶可能會對交付的功能感到非常興奮並愛上你，但在第二天他或她會發現有些東西不起作用，這種感情就會消失。 通常情況下，這只是客戶溝通出錯的問題。

儘管在遠程軟件開發方面沒有成功的秘訣，但我相信有一些事情必須避免，才能與非常信任您的客戶保持健康和富有成效的關係。

與客戶的基本溝通不要失敗

想像一下與客戶的交流，就像您與同事、朋友或任何其他您會禮貌的人的日常交流一樣。

如果一位老朋友來家拜訪，而您同意在中午“在老地方”享用當地美食，那麼幾週後，您會出現在那兒嗎？ 您會在此期間保持聯繫，提前幾天打電話確認嗎？ 或者你可能會認為他們太忙了，不想無緣無故地打擾他們？ 您希望他們在到達時通知您嗎？

除非您有很多話要說，否則您不太可能每天都聊天，但是出於禮貌和實際​​考慮，您會保持某種形式的交流：您不希望對方認為您忘記了他們，但您絕對不想無緣無故地開車穿過城鎮。

在某些時候，您可能在專業交流中也遇到過類似的情況，即使是與長期合作夥伴和同事。 有些項目是在最少的溝通下執行的，就像說“往常一樣，中午見”來確認一頓清淡的午餐。 就算有事，對方一定會通知你，你也同意改期。

然而，在軟件開發的世界裡，事情並不是那麼簡單或線性的。

如果您開始從事一個項目，尤其是在與新客戶打交道時，如果他們從未收到您的來信，他們將開始重新考慮您的工作和承諾。 即使您在幾週後展示了完美無瑕的產品，客戶可能已經對您的看法不太理想。

儘管有時難免會感到尷尬，但即使您沒有任何不尋常的事情要報告，與客戶交談也沒有什麼壞處！ 您對用戶故事的一小部分有任何疑問嗎？ 如果您認為這很重要，請讓他們知道。 您有點晚了，不確定您是否能夠滿足您約定的預計日期？ 盡快給客戶打電話！ 最好他們馬上聽到。

您沒有任何疑慮，項目完全按計劃進行，但客戶卻不怎麼說話？ 為什麼不每隔幾天發送一封電子郵件來描述您的進度？ 它不會造成任何傷害，因為電子郵件不會對任何人造成滋擾，而且您將記錄您的進度並與客戶保持定期溝通。

有缺陷的客戶溝通助長了不切實際的期望

所以，一開始，我提到客戶對這個項目肯定有很多期望，對吧？ 正確的。 時期。

客戶已經對產品寄予厚望。 如果它沒有按照他們想像的方式進行，客戶將不可避免地感到沮喪。 那麼，為什麼會有人承諾超出他們的能力，從而產生更不切實際的期望呢？

這是一個快速的類比：您在網上購買了一台平板電腦，並承諾 10 天交貨。 第8天，店家告訴你有問題，延遲一周發貨。 為了補償您給您帶來的不便，零售商承諾給您 75 美元的商店信用。

在接下來的幾天裡，您可能並不真的需要那台平板電腦，所以您認為這是一筆划算的交易！ 現在您可以享受平板電腦了，還可以使用商店積分為您的孩子購買好東西。 但第二天店家打來電話，說一切都在一夜之間解決了。

第二天你會得到平板電腦。 沒有額外費用，沒有商店信用。 現在沮喪的是你！

“什麼？ 就在昨天你告訴我我會得到更好的交易！ 這不公平！ 我已經告訴孩子們了……”

倒退幾天，你所期待的只是平板電腦。 如果沒有人向您承諾更好的交易，那麼第二天到貨時您會對您的玩具感到滿意。 但現在，除了商店決定讓您知道之外，您覺得自己無緣無故地錯過了。

開發人員，尤其是自由職業者，如何避免在與客戶溝通時出現類似情況？

不要發瘋，首先說出你想到的一切。 建議不被禁止； 實際上，如果您認為某個特定的請求功能不是解決手頭問題的好選擇，那麼他們是非常受歡迎的。 但關鍵是：先思考。

• 聽客戶的。

• 分析他們的問題。

• 分析建議的解決方案。

• 確保它在預算/時間表之內。

• 最後，繼續並提出您的建議。

這就是為什麼客戶溝通技巧可能很棘手，因為僅在前四個步驟中的一個失敗意味著您最終可能會浪費您的時間，更糟糕的是，您的客戶的時間。

不要假設你知道客戶需要什麼

釋義 Mary Schmich，17 年級的女士們先生們：傾聽客戶的意見。 如果我只能為您提供一個關於未來的建議，那就是傾聽客戶的意見。

如果你被要求做一個項目，那是因為有人需要一些東西。 誰能比您的客戶更了解這種必要性？ 這似乎很明顯，但有時，在現實世界中，人們會忘記它。

讓我舉一個例子。 一位零售商要求為其業務提供“軟件系統”。 一旦你看到它，你就會得出結論，他們想要的是註冊所有可用產品，記錄每次購買，為客戶生成收據，並定期報告售出的商品以及哪些商品已用完股票。

所以，在你的第一次會議上，你想展示你的效率，並向他們展示你準備的東西、提議的功能、與商店視覺識別相匹配的基本設計等等。 但隨後疑惑的客戶說，實際上，他們需要的是一種算法來計算如何更好地在貨架上展示產品，旨在為特定品牌和產品增加收入！

這裡的錯誤只是沒有確定你應該解決什麼問題。 當然，在這種情況下，由於它是在項目的早期階段，有足夠的時間來糾正它，但有時，這種錯誤會發生在更遠的地方。 即使它不像前面的例子那樣激烈，它仍然會損害項目和/或您與客戶的關係。

我的建議如下：盡可能多地與您的未來用戶交談，並諮詢項目中的各個利益相關者。 他們對情況有很好的了解，他們知道自己需要什麼。 試著弄清楚他們目前在做什麼，每一步，並解釋軟件將如何派上用場。 我想說的是，當我試圖了解客戶的願望時，我的目標是幾乎能夠自己完成他們的工作。 如果您接近這一點，那麼您就真正發現了他們的需求。

不了解客戶的要求

收到有關手頭問題的某種文檔的情況並不少見。 有時它只是一個高級描述，而有時它是包含用例和業務規則的詳細文檔。 無論如何，無論記錄多麼清晰，你不能做的一件事就是假設那裡所寫的一切都是絕對真實的。

什麼？？？

確切地。 首先，在特定的環境中，某事對某人來說可能意味著一件事，而對於不屬於那個現實的人來說，則是完全不同的事情。 如果有什麼你和客戶沒有共同點，那就是上下文！

其次，不是每個人都是非常熟練的作家； 他們試圖說A，但最終描述了B。

那麼，在閱讀了您收到的所有內容之後，您如何確定您所閱讀的內容確實是他們的意思？ 好吧，您將消化所有內容，做一些筆記，分析所有內容，然後……召開會議。 （你看到了嗎？這都是關於溝通的！）在會議上，你會談論這個問題，並用你自己的話描述你所理解的。 在這個階段，您可能會發現任何誤解。

“哦，但就我而言，我沒有得到任何文件。 我只是和客戶坐在一起，他們在我做筆記的同時向我解釋了一切。”

好吧，仍然不能保證你理解他們的意思，我的建議仍然有效：花點時間做筆記，考慮整個問題，組織一切，最好是在某種事件時間表中，然後再次打電話/見面客戶來呈現你所理解的。 這聽起來可能對您來說是重複的，但有時甚至客戶也無法全面了解完成特定任務所涉及的所有流程，然後才會看到軟件必須有多複雜。

最後，您必須確定沒有歧義或誤解。

為什麼你不應該不假思索地交付客戶要求的一切

好的，既然您知道您應該聽取客戶的意見並確認您的理解，您就可以繼續按照他們的要求去做，對吧？

錯誤的！

現在是您終於可以利用所有經驗並問自己的時候了：客戶要求您解決他們的問題嗎？ 他們問你的真的是他們需要的嗎？

你會驚訝地看到有多少次答案是“不”。

在交付客戶要求的內容之前，我們需要分析問題，如果您不同意雇主的建議，那麼您的工作和職業責任就是明確這一點。 當然，你應該解釋為什麼你認為他們的提議不好，以及你的替代方法將如何解決這些缺點。 再次，溝通是關鍵。

如果您和客戶是合理的，那麼您將繼續您的解決方案，或者進行頭腦風暴會議以提出更好的解決方案（以防您的想法由於某種原因不被客戶接受）。

原型——不要編寫大量文檔

我已經說過，您和您的客戶通常沒有相同的觀點，對嗎？ 因此，正如它會影響您對他們的文檔的理解一樣，它也會影響他們對您以書面形式提供的內容的理解。 這也是一個上下文問題。

所以，我同意以某種方式（在更高或更低的層面上），我們必須記錄我們將要開發的內容。 但是處理幾頁沒有任何視覺元素的文本對你沒有多大好處。 客戶會厭倦閱讀它，停止關注，並且可能無法理解您所說的那些複雜的業務規則的含義——或者他們會解釋與您的設想完全不同的東西。

請記住，如果客戶沒有技術背景，這些誤解可能會更加嚴重。

所有這些因素都可能導致相同的問題結果：當您交付產品時，客戶會抱怨，因為它很可能不是他們的想法。

這是我的建議：總是原型，即使它只是一個草圖來繪製你的計劃是什麼。 無論您必須做出什麼定義，都從那裡開始。 做參考並儘量保持簡單。

不要浪費時間說服客戶你是對的

我幾乎可以肯定每個開發者都經歷過這樣的情況： 項目開始時，客戶說“我需要軟件的背景顏色是黃色的。 董事會已經同意了。” 然後，當軟件交付時，他們說“哦，但是背景顏色不能是黃色的。 我告訴過你它必須是綠色的！” 現在，你應該如何處理這個問題？

當然，在任何情況下，堅持你是對的而他們是錯的都是沒有用的。 如果有的話，它只會給你和客戶都帶來困難。

與客戶保持良好的溝通記錄總是好的，只是為了確保您在同一頁面上並留下書面痕跡。 大多數時候，如果事情很簡單，你可以給客戶發電子郵件，說： “正如我們在那次會議上同意的那樣，系統的背景將是黃色的。” 如果將來客戶改變主意，您可以辯稱您這樣做是因為電子郵件中提到的那次會議，但如果確實需要進行修改，您可以執行它，額外 x 小時（有時，額外的 x 美元）。

但是，如果沒有任何東西可以證明您是對的，那麼您可能需要做出決定（以及要吸取的教訓）：是否需要對當前架構進行更改或影響其他功能的變化如此之大？ 如果沒有，最好還是繼續，做，讓客戶在你身邊（但要睜大眼睛，這樣就不會再發生了）。 如果是這樣，那麼與客戶交談將是最好的解決方案； 不是關注“你是怎麼做對的”，而是關注“我們如何解決當前的問題”。

無論如何，避免進行大修改的最佳方法是在短時間內交付簡短的新功能。 因此，如果有什麼需要改變的話，它可能不會是對已經存在的東西的重大轉變。

知道何時承諾截止日期

最後但並非最不重要的一點是，您可能犯的最大錯誤之一就是給您的客戶一個截止日期，讓您完成項目。 他們會求你犯這個錯誤！

當然，作為客戶，您想知道什麼時候可以使用您在過去幾週（幾個月？）中討論過的所有這些不錯的功能。 但是，由於項目不是一個已定義的產品，從開發開始到軟件準備好使用，可能會發生很多事情。

首先，人們無法預測不可預測的事情。 你很可能不得不處理一些你沒有預料到的事情。 可能是客戶承諾的未按時購買的許可證，或者您需要使用的其他一些內部軟件，但在應該發布的時候沒有發布，或者環境與一開始同意的環境不同，或者客戶改變了他們對（幾個）功能的想法，你不得不重做幾件事。

這些都不是開發人員的錯，並且會嚴重影響項目的截止日期。 但是，如果您願意取悅客戶，承諾您會在某個日期之前交付所有東西並最終出於所有正確的原因而沒有這樣做，我可以保證的一件事是客戶將至少有一點， 沮喪的。 如果你是一名自由職業者，你必須有效地管理你的時間，正如這篇 Toptal 工程博客文章所解釋的那樣。 不要忘記客戶關係管理也是您的工作。

因此，請幫自己和依賴該項目的人一個忙，至少給他們一個估計開發所有東西需要多長時間，但始終清楚地表明這只是一個估計，而不是最後期限。

另外，我強烈建議（特別是如果您已經給出了估計）當某件事花費的時間比預期的要長時，您總是告訴客戶，這樣他們就可以採取行動來幫助您！