クライアントのコミュニケーションにおけるよくある間違い：クライアントを苛立たせない方法

公開: 2022-03-11

誰かがプロジェクトを要求するとき、それは非常に重要であり、彼らはあなたが取り組む製品を深く気にかけていると想定しなければなりません。したがって、クライアントは最終製品に多くの期待を抱くはずであり、したがって、納品に関しては感情的になる可能性があると考えるのが安全です。

プロジェクトの過程を通じて、クライアントは提供された機能に非常に興奮し、あなたを愛しているかもしれません。翌日、クライアントは何かが機能しないことを発見し、その愛情は消えます。多くの場合、それは単にクライアントのコミュニケーションがうまくいかなかったという問題です。

リモートソフトウェア開発に関して成功の秘訣はありませんが、あなたの手に大きな信頼を置いているクライアントとの健全で生産的な関係を維持するために避けなければならないことがいくつかあると思います。

クライアントとの基本的なコミュニケーションに失敗しないでください

同僚、友人、または礼儀を拡張する他の人との日常的なコミュニケーションと同じように、クライアントとのコミュニケーションを想像してみてください。

古くからの友人が家を訪れていて、数週間後の正午に「昔の場所で」地元の珍味を楽しむことに同意した場合、あなたはそこに現れますか？それまでの間、連絡を取り合いますか？数日前に電話で確認してください。あるいは、彼らが忙しすぎて、正当な理由もなく彼らに迷惑をかけたくないと思うかもしれませんか？彼らが到着したときにあなたに知らせることを期待しますか？

話し合うことがたくさんない限り、毎日チャットを続けることはないでしょうが、礼儀と実用性の問題として、何らかの形のコミュニケーションを維持します。他の人にあなたが彼らのことを忘れたと思わせたくない、しかし、正当な理由がないのに、町の途中まで車で行きたくないのは間違いありません。

クライアントコミュニケーションの図：クライアントとの効果的なコミュニケーションの欠如

ある時点で、あなたはおそらく、長年のパートナーや同僚とさえ、あなたの専門的なコミュニケーションにおいても同様の状況を経験したでしょう。一部のプロジェクトは、「いつもの正午に、そこでお会いしましょう」と言って軽い昼食を確認するのと同じように、最小限のコミュニケーションで実行されます。何かあったとしても、相手が必ず知らせてくれるので、スケジュールを変更することに同意します。

ただし、ソフトウェア開発の世界では、物事はそれほど単純でも直線的でもありません。

あなたがプロジェクトに取り組み始めた場合、特にあなたが新しいクライアントと取引しているとき、彼らがあなたから連絡をもらわなければ、彼らはあなたの仕事とコミットメントについて考え直し始めます。あなたが数週間後に完璧な製品を見せたとしても、クライアントはすでにあなたの理想的とは言えない認識を持っているかもしれません。

ぎこちなく感じることもありますが、いつもと違う報告がなくても、クライアントと話をしても問題ありません。ユーザーストーリーの1つの小さなポイントについて疑問がありますか？それが重要だと思うなら、彼らに知らせてください。あなたは少し遅れて走っていて、あなたが同意したその推定日を満たすことができるかどうかわからないのですか？できるだけ早くクライアントに電話してください！彼らはすぐにそれについて聞いたほうがいいです。

疑いの余地はなく、プロジェクトは完全にスケジュールどおりですが、クライアントはあまり話をしませんか？数日おきに進捗状況を説明するメールを送信してみませんか？電子メールは誰にとっても迷惑にならないので、害はありません。さらに、進捗状況を文書化し、クライアントとの定期的なコミュニケーションを維持します。

欠陥のあるクライアントコミュニケーションは非現実的な期待を助長します

ですから、冒頭で、クライアントはプロジェクトに対して多くの期待を抱くはずだと言いましたよね？右。限目。

クライアントはすでに製品に多くのことを期待しています。それが彼らの想像通りに進まなければ、クライアントは必然的に欲求不満になります。では、なぜ誰もが提供できる以上のことを約束し、それによってさらに非現実的な期待を生み出すのでしょうか？

これが簡単な類似点です。オンラインでタブレットを購入し、10日間の配達が約束されました。 8日目に、お店から問題があるとの連絡があり、配達が1週間遅れます。 不便を補うために、小売業者は75ドルのストアクレジットを提供することを約束します。

とにかく、おそらく次の数日間はそのタブレットを本当に必要としなかったので、それはお得だと思います！これで、タブレットを楽しむことができます。さらに、ストアクレジットを使用して、子供に素敵なものを購入することもできます。しかし、店は翌日、すべてが一晩で整理されたと言って電話をかけます。

翌日タブレットを入手します。余分なものも、ストアクレジットもありません。今、イライラしているのはあなたです！

"何？ ちょうど昨日、あなたは私がもっと良い取引をするだろうと私に言いました！ 不公平だ！ 私はすでに子供たちに話しました…」

数日巻き戻して、とにかくあなたが期待していたのはタブレットだけでした。誰もあなたにもっと良い取引を約束していなかったら、翌日到着したときにあなたはあなたのおもちゃに満足していたでしょう。しかし今、あなたはあなたに知らせるという店の決定以外に、あなたは正当な理由もなく逃しているように感じます。

クライアントコミュニケーションの図：専門的なコミュニケーションスキルが非現実的な期待を防ぎます

開発者、特にフリーランサーは、クライアントとのコミュニケーションにおいて同様の状況をどのように回避できますか？

頭がおかしくなるのではなく、そもそも頭に浮かぶことすべてを言うことによって。提案は禁止されていません。実際、要求された特定の機能が目前の問題を解決するための非常に良いオプションではないと思われる場合は、非常に歓迎されます。しかし、重要なのは、最初に考えることです。

クライアントの話を聞いてください。
彼らの問題を分析します。
提案されたソリューションを分析します。
予算/スケジュールの範囲内であることを確認してください。
最後に、先に進んであなたの提案を提示してください。

これが、クライアントのコミュニケーションスキルが難しい場合がある理由です。最初の4つのステップのいずれかで失敗すると、時間が無駄になり、さらに悪いことに、クライアントの時間が無駄になる可能性があるためです。

クライアントが何を必要としているかを知っていると思い込まないでください

メアリーシュミッヒの言い換え、'17年のクラスの紳士淑女：クライアントの話を聞いてください。将来に向けたヒントを1つだけ提供できれば、クライアントの話を聞くことができます。

あなたがプロジェクトを求められたのなら、それは誰かが何かを必要としているからです。そして、誰があなたのクライアントよりもその必要性についてよく知っているでしょうか？当たり前のように見えるかもしれませんが、現実の世界では、人々はそれを忘れることがあります。

例を挙げましょう。小売業者は、自分のビジネスのための「ソフトウェアシステム」を求めています。それを見るとすぐに、彼らが望んでいるのは、利用可能なすべての製品を登録し、行われたすべての購入を記録し、顧客の領収書を生成し、定期的に販売されたものと不足しているアイテムについて報告することであるという結論にジャンプします株式。

したがって、最初の会議では、効率的であることを示し、準備したもの、提案された機能、ショップの視覚的アイデンティティに合わせた基本的なデザインなどを提示する必要があります。しかし、困惑したクライアントは、実際に必要なのは、特定のブランドや製品の収益を上げることを目的として、棚に製品をより適切に表示する方法を計算するアルゴリズムであると言います。

ここでのエラーは、単に解決するはずの問題を特定していないことです。もちろん、この場合、プロジェクトの非常に早い段階であったため、それを正しく行うには十分な時間がありますが、この種の間違いがさらに発生することもあります。前の例ほど抜本的ではありませんが、プロジェクトやクライアントとの関係に悪影響を与える可能性があります。

私の提案は次のとおりです。将来のユーザーと、可能であれば多くのことを話し、プロジェクトのさまざまな利害関係者に相談してください。彼らは状況の概要をよく理解していて、何が必要かを知っています。彼らが現在何をしているのか、あらゆる段階で理解し、ソフトウェアがどのように役立つかを説明してください。私がクライアントの希望を理解しようとしているとき、私の目標はほとんど自分で彼らの仕事を遂行できるようにすることだと言いたいです。この点に近づくと、彼らのニーズが何であるかが本当にわかります。

クライアントが何を求めているのか理解していない

手元にある問題に関するある種の文書を受け取ることは珍しいことではありません。単に高レベルの説明である場合もあれば、ユースケースとビジネスルールを含む詳細なドキュメントである場合もあります。いずれにせよ、記録がどれほど明確であっても、あなたができないことの1つは、そこに書かれているすべてが絶対的な真実であると仮定することです。

何？？？

丁度。まず、ある文脈では、何かが誰かにとって1つのことを意味し、その現実に属していない人々にとってはまったく異なることを意味する可能性があります。そして、あなたとクライアントが共通していない何かがある場合、それは文脈です！

第二に、誰もが非常に熟練した作家であるわけではありません。彼らはAと言おうとしますが、結局Bを記述します。

それで、あなたが送られたすべてを読んだ後、あなたが読んだものが本当に彼らが意味したものであることをどのように確信しますか？さて、あなたはすべてを消化し、いくつかのメモを取り、すべてを分析し、そして…会議を呼びます。（なるほど？コミュニケーションがすべてです！）ミーティングでは、問題について話し、理解したことを自分の言葉で説明します。この段階で、おそらく誤解を特定できるでしょう。

「ああ、でも私の場合、書類は何もありませんでした。 私はちょうどクライアントと一緒に座って、私がいくつかのメモを取っている間、彼らは私にすべてを説明しました。

まあ、あなたがそれらの意味を理解したという保証はまだありません、そして私の提案はまだ立っています：あなたのメモで時間をかけて、問題全体について考え、できればイベントのある種のタイムラインですべてを整理してから、もう一度電話/会ってくださいあなたが理解したことを提示するクライアント。繰り返しのように聞こえるかもしれませんが、クライアントでさえ、特定のタスクを実行するために必要なすべてのプロセスの完全なビジョンを持っておらず、ソフトウェアがどれほど複雑である必要があるかを理解する場合があります。

最後に、あいまいさや誤解がないことを確認する必要があります。

クライアントが求めるものすべてを考えずに提供すべきではない理由

さて、クライアントの話を聞いて理解したことを確認する必要があることがわかったので、先に進んで、クライアントから求められたすべてのことを実行できますよね？

違う！

今こそ、あなたが持っているすべての経験を最終的に利用して、自分自身に問いかけることができる瞬間です。クライアントがあなたに求めたのは、彼らの問題を解決するつもりですか？ 彼らがあなたに尋ねたのは本当に彼らが必要としているものですか？

答えが「いいえ」であるのを何度見ても驚くでしょう。

クライアントが求めたものを提供する前に、問題を分析する必要があります。雇用主が提案した内容に同意できない場合は、これを明確にするのはあなたの仕事と専門家の責任です。もちろん、次に、なぜ彼らの提案が良くないと思うのか、そしてこれらの欠点に対処するためにあなたの代替アプローチが何をするのかを説明する必要があります。繰り返しになりますが、コミュニケーションが鍵となります。

あなたとクライアントが合理的である場合、あなたはあなたの解決策を進めるか、より良いものを考え出すためにブレーンストーミングセッションを持ちます（あなたのアイデアが何らかの理由でクライアントに受け入れられなかった場合に備えて）。

プロトタイプ-広範なドキュメントを作成しないでください

あなたとあなたのクライアントは一般的に同じ見方をしていないと私はすでに言いましたよね？したがって、それが彼らの文書の理解に影響を与えるのと同じように、それはあなたが書面で提供するものの彼らの理解に影響を及ぼします。それも文脈の問題です。

ですから、どういうわけか（より高いレベルまたはより低いレベルで）、私たちが開発しようとしているものを文書化する必要があることに同意します。しかし、視覚的な要素なしで数ページのテキストを渡すことは、あまり役に立ちません。クライアントはそれを読むことに飽きて、注意を払うのをやめ、おそらくそれらの複雑なビジネスルールが何を意味するのか理解できないでしょう。あるいは、彼らはあなたが想像していたものとはまったく異なる何かを解釈するでしょう。

クライアントに技術的なバックグラウンドがない場合、これらの誤解はさらに悪化する可能性があることに注意してください。

クライアントとのコミュニケーションの図：クライアントとのコミュニケーションを文書化することの重要性

これらすべての要因により、同じ問題のある結果が生じる可能性があります。製品を納品すると、クライアントは、それが彼らが考えていたものではない可能性が高いため、不平を言うでしょう。

これが私が提案することです：あなたの計画が何であるかを描くための単なるスケッチであっても、常にプロトタイプを作成してください。 そして、あなたがしなければならないどんな定義も、そこから始めてください。 参照を作成し、それを単純に保つようにしてください。

あなたが正しいことをクライアントに納得させるために時間を無駄にするのをやめましょう

すべての開発者が次の状況を経験していることはほぼ間違いありません。プロジェクトの開始時に、クライアントは「ソフトウェアの背景色を黄色にする必要があります。 理事会はすでに合意しています。」 次に、ソフトウェアが配信されると、「ああ、でも背景色を黄色にすることはできません。 緑でなければならないと言ったよ！」 さて、あなたはこれにどのように対処すべきですか？

確かに、いずれにせよ、あなたが正しく、彼らが間違っていたと主張することは無駄です。どちらかといえば、それはあなたとクライアントの両方に苦労を与えるだけです。

同じページにいて、書面による証跡を残すためだけに、クライアントとのコミュニケーションの良い記録を持っていることは常に良いことです。ほとんどの場合、それが単純なものであれば、 「その会議で合意したように、システムの背景は黄色になります」とクライアントに電子メールで送信できます。そして、将来、クライアントが気が変わった場合は、メールに記載されている会議のためにそのようにしたと主張できますが、その変更が本当に必要な場合は、さらにx時間実行できます（そして時々、余分なxドル）。

しかし、自分が正しいことを証明するものが何もない場合は、おそらく決定を下す必要があります（そして学ぶべき教訓もあります）：現在のアーキテクチャの変更を必要とする、または他の機能に影響を与えるような大きな変更ですか？そうでない場合は、先に進んでそれを実行し、クライアントをあなたのそばに置くのがおそらく最善です（ただし、それが二度と起こらないように目を大きく開いてください）。もしそうなら、クライアントとの話し合いが最善の解決策になります。 「あなたがどのように正しかったか」ではなく、 「現在の問題をどのように解決できるか」に焦点を当てた人です。

いずれにせよ、大きな変更を加える必要をなくす最善の方法は、短い新機能を短期間で提供することです。したがって、何かを変更する必要がある場合、それはおそらく既存のものの主要な変換ではありません。

期限を守る時期を知る

最後になりましたが、あなたが犯す可能性のある最大の間違いの1つは、プロジェクトを完了するための期限をクライアントに与えることです。そして、彼らはあなたにその間違いをするように頼むでしょう！

もちろん、クライアントとして、過去数週間（数か月？）にわたって議論してきたすべての優れた機能をいつ使用できるようになるかを知りたいと思います。ただし、プロジェクトは定義済みの製品ではないため、開発が開始されてからソフトウェアを使用できるようになるまで、多くのことが発生する可能性があります。

まず第一に、予測不可能なことを予測することはできません。 予期していなかったことに対処しなければならない可能性が非常に高くなります。クライアントが約束したライセンスで、時間どおりに購入されなかった場合や、使用する必要があるがリリースされていないはずのその他の内部ソフトウェアである場合、または環境が最初に合意されたものと異なっていた場合があります。または、クライアントが（いくつかの）機能について考えを変え、あなたはいくつかのことをやり直さなければなりませんでした。

それは実際には開発者のせいではなく、プロジェクトの期限に深く影響する可能性があります。しかし、もしあなたがクライアントを喜ばせることをいとわず、ある日までにすべてを届けて、最終的にはそうしないというすべての正当な理由で終わると約束したなら、私が保証できることの1つは、クライアントが少なくとも少しはなるだろうということです、イライラ。このToptalEngineeringブログの記事で説明されているように、フリーランサーの場合は、時間を効率的に管理する必要があります。クライアント関係管理もあなたの仕事であることを忘れないでください。

ですから、あなた自身とプロジェクトに依存している人に賛成して、少なくともすべてを開発するのにかかる時間の見積もりを彼らに与えてください。しかし、それは単なる見積もりであり、期限ではないことを常に明確にしてください。

また、（特にすでに見積もりを出している場合は）何かが予想よりも長くかかっている場合は常にクライアントに伝えて、クライアントがあなたを助けるために行動できるようにすることを強くお勧めします！