誰かがプロジェクトを要求するとき、それは非常に重要であり、彼らが取り組む製品に深く関心を持っていると想定しなければなりません。したがって、お客様は最終製品に高い期待を抱かざるを得ず、納品に関しては感情的になる可能性があると考えて間違いありません。

プロジェクト全体を通して、クライアントは提供されたパフォーマンスに非常に興奮してあなたを愛しているかもしれません、そして翌日彼らは何かが間違っていることに気づき、愛情が消えるでしょう。ほとんどの場合、それは顧客とのコミュニケーションがうまくいかなかったという問題です。

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

クライアントとの基本的なコミュニケーションに失敗はありません

同僚、友人、またはあなたが礼儀を捧げる他の人と毎日コミュニケーションをとるのと同じように、顧客とコミュニケーションをとることを想像してみてください。

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

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

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

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

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

不快に感じることもありますが、異常な報告がなくても、お客様とお話ししても問題ありません。ユーザーのストーリーの小さなポイントについて質問がありますか？それが重要だと思うなら、彼に知らせてください。あなたは少し遅れて走っていて、あなたが同意したその推定日に会うことができるかどうかわからないですか？できるだけ早くお客様に電話してください。すぐに聞いた方がいいです。

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

不十分な顧客コミュニケーションは非現実的な期待を助長します

冒頭で、クライアントはきっとプロジェクトに大きな期待を寄せると言っていましたよね？あなたはそれらを持っているでしょう。ポイント。

顧客はすでに製品に多くのことを期待しています。思い描いた通りにならないと、必然的にお客様は欲求不満になります。では、なぜ誰かが提供できる以上のことを約束し、それによってさらに非現実的な期待を生み出すのでしょうか？

これが簡単な類似点です： あなたはオンラインでタブレットを購入し、彼らは私たちに10日間の配達を約束しました。 8日目に、ストアから問題が発生したことが通知され、配達が1週間遅れます。不便を補うために、小売業者の約束はあなたに75ドルの店の信用を与えます。

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

翌日タブレットを入手します。エキストラやストアクレジットはありません。今、あなたはイライラしています！

'それ？あなたは昨日私にもっと良い取引をするだろうと言っただけです！公平じゃない！私はすでに子供たちに話しました...」

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

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

マネジメントバイアウトとは

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

• お客様の話を聞いてください。

• 問題を分析します。

• 提案されたソリューションを分析します。

• 予算/スケジュールどおりであることを確認してください。

• 最後に、先に進んであなたの提案を提出してください。

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

顧客が何を必要としているかを知っていると思い込まないでください

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

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

ノードjsフルスタックフレームワーク

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

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

ここでのエラーは、解決するはずの問題を特定していないだけです。もちろん、この場合、プロジェクトの初期段階であるため、正しく処理するのに多くの時間がかかりますが、この種のエラーが後で発生する場合もあります。前の例ほど劇的ではない場合でも、プロジェクトやクライアントとの関係に損害を与える可能性があります。

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

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

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

それ？？？

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

第二に、彼らはすべて非常に熟練した作家ではありません。彼らはAと言おうとしますが、結局Bについて説明します。

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

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

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

結局、曖昧さや誤解がないことを確認する必要があります。

顧客が求めるものすべてを考えずに提供すべきではない理由

さて、あなたは顧客の話を聞いてあなたが理解したことを確認することを知ったので、あなたは先に進んで彼らがあなたに求めたことを何でもすることができますよね？

不正解です！

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

答えが「いいえ」であることに何度も驚かれることでしょう。

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

あなたとクライアントが合理的である場合は、ソリューションを続行するか、ブレインストーミングセッションを行って、より良いものを見つけます（何らかの理由であなたのアイデアがクライアントに受け入れられない場合）。

プロトタイプ-たくさんのドキュメントを書かないでください

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

したがって、何らかの方法で（より高いレベルまたはより低いレベルで）、開発しようとしているものを文書化する必要があることに同意します。しかし、ビジュアルなしで複数ページのテキストを配信しても、あまり効果はありません。顧客はそれを読むのに飽きて、あなたに注意を払うのをやめて、おそらくそれらの複雑なビジネスルールが何を意味するのか理解できないか、彼らが想像していたものとはまったく異なる何かを解釈するでしょう。

パワーポイントのプレゼンテーションのヒントとコツ

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

これらの要因はすべて、同じ厄介な結果をもたらす可能性があります。顧客は、製品を納品するときに、彼らが考えていたものではない可能性が高いため、不満を言うでしょう。

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

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

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

実際、いずれにせよ、あなたが正しく、彼らが間違っていたと主張することは、何の役にも立ちません。どちらかといえば、それはあなたと顧客に困難な時間を与えるだけです。

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

しかし、あなたが正しいことを示すものが何もない場合は、おそらく（レッスンを学ぶことに加えて）決定する必要があります：変更が非常に大きいため、現在のアーキテクチャの変更が必要になるか、他の機能に影響しますか？ ？そうでない場合は、先に進んでそれを実行し、顧客をそばに置いておくのがおそらく最善です（ただし、目を大きく開いて、二度と起こらないようにします）。その場合、お客様との会話が最善の解決策になります。焦点を当てているものではありません 「彼はどうだった？」 、しかしで 「どうすれば現在の問題を解決できますか」 。

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

納期にいつコミットするかを学ぶ

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

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

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

それは実際には開発者のせいではなく、プロジェクトのタイムラインに深刻な影響を与える可能性があります。しかし、お客様を喜ばせて、特定の期日までにすべてを配達することを約束し、何らかの理由でそれができなくなった場合、私が保証できることの1つは、お客様が少なくとも少しイライラすることです。あなたがフリーランサーであるならば、あなたは説明されるようにあなたの時間を効率的に管理する必要があります ApeeScapeDevブログ記事 。顧客関係管理もあなたの仕事であることを忘れないでください。

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

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