自分が何を望んでいるかわからないクライアントと協力する

私は最近、既存のシステムで作業する仕事を始めました。調整と更新、および新しいコードが必要です。私はいくつかの保守/機能追加プロジェクトを今やっていますが、それらのいくつかは実際に要求されたものとは大きく異なってしまいました。そのため、リクエスターが望む場所に到達するために、アイテムを数回プログラムする必要がありました。

今、私はそれが行われる必要があるものであれば、機能を再プログラミングすることを気にしません。ただし、プロジェクトの所要時間を短縮したいと思います。ボトルネックは、実行する必要のあるものに対する要求者の認識にあるようです。リクエスタがより迅速に必要とするものを把握するために私ができることについて何かアイデアはありますか？

いくつかのアドバイス：

• ソリューションではなく、問題に耳を傾けます。多くのクライアントは、彼らの問題を解決する方法を教えてくれます。聞いてはいけません。あなたはプログラマであり、問​​題の解決策を見つけることがあなたの仕事です。代わりに、クライアントが抱えている問題に耳を傾け、それを解決する最善の方法を見つけてください。他の人が言ったように、クライアントは自分が何を望んでいるのかを本当に知らない。

• 質問する。質問を終えたら、さらに質問してください。クライアントが詳細について考えないことはめったにありません。必要な情報を取得する唯一の方法は、それらから情報をこじ開けることです。

• 書面で物事を得るクライアントの状況によっては、これは後であなたが提供したものが「彼らが求めたものではない」と不平を言い始めたときに本当に重要になる可能性があります。他に何もなければ、詳細な仕様を書き出すことで、必要な情報がすべて揃っていることを確認し、クライアントとクライアントのあいまいさを解消することができます。

• コミュニケーションが重要です。クライアントと話をしたり、情報を取得したり、コードをノックアウトしたり、完了するまで話をしたりしないでください。常にクライアントと連絡を取ってください。プロセス全体で質問します。進捗状況を見せてフィードバックをもらいます。長い目で見れば、みんなの生活が楽になります。

あなたがコミュニケーションについて取り上げた自助の本のほとんどは、あなたにこれのいくつかのバリエーションを与えるでしょう：

• 最初に理解し、次に理解する

それは7つの習慣の本から来ていますが、それらはすべて「アクティブリスニング」メソッドのバリエーションです。目標は単に理解することではなく、あなたが理解したことを彼らに伝えることです。

彼らが必要とするものについて良い考えができたら（特に彼らが実装の詳細を説明し始める場合、彼らが望むものから遠ざけなさい-それは彼らの仕事ではなくあなたの仕事です）、私は彼らにシステムを使用しているさまざまな人々の物語の例を与え、それらとジャイブ。

それから私はそれを実装します。彼らがその機能を見ると、彼らはそれが彼らが望むものではないことを実際に認識するだろうと完全に期待しています。すべてを柔軟に保ちます。唯一の定数は変更です。通常、最初の更新後の2回目のクイック更新の後、ほとんどのラフエッジを解決しますが、到達できない理想に漸近的に近づいていることが常にわかります。最終的には、重要でないものを手放して、より価値の高いターゲットに移行する必要があります。

あなたの痛みが分かります....

悪いニュースは、あなたが扱っているクライアントの種類に応じて、これは通常のビジネスかもしれません。

一般的な一般的な問題は、基本的にクライアントが彼らが欲しいものを知らないということです。彼らは通常、ビジネス目標の観点から何を達成したいのかを知っていますが、多くの場合、ソフトウェアソリューションの観点から見た場合の見当がつかないのです。そのため、多くの場合、クライアントは考えを変え続け、ソリューションを微調整し、再調整することを望んでいるため、プロジェクトが最初の推定値の5倍の長さで前後にバウンドするこの反復サイクルに陥ります。そして、はい、最終結果が最初の目標とはまったく異なるものに変化することは珍しいことではありません。

数年前にこの出来事の壮大な例がありました-最初にコードに10週間かかったプロジェクトが15ヶ月の繰り返し作業になりました。その場合、主にクライアント企業の異なるマネージャーと部門が異なるものを望んでいたため、彼らは仕事を送り返し続け、微調整して再調整しました（私たちのソフトウェアはサブスクリプションベースであり、これが主要なクライアントであったため、これは私たちの背中に金銭的な皮はありませんでした-本当に大きな技術的な迷惑です）。

だから基本的に私のアドバイスはこれです：

これがあなたの特定の業界とこれらのクライアントのやり方であるなら（それは大きなIFです）、ただそれに慣れてください。アジャイルでメンテナンス志向の仕事だと考えてください（これが私の現在のギグの多かれ少なかれです）。:)

これが物事が行われることを意図された方法ではなく、あなたが長いターンアラウンドのせいになっているなら、あなたの上司に話してください。通信の問題があり、クライアントから提供されている仕様が、希望するソリューションを実装するのに十分ではないことを説明します。顧客が欲しいものを提供するために必要な情報をすべて取得していない場合、クライアントに必要なものを提供していないことのせいになっている状況に自分を見つけたくないでしょう。

まず第一に、あなたはクライアントがそれを見るまで本当に探しているものを知らないという事実を受け入れるべきです。機能Xが必要だとすぐに言うかもしれません。機能Xを見せれば、本当に必要なのは機能Yまたは機能Xの別のバリエーションであることに気付くでしょう。

顧客が本当に望んでいるものをより迅速に把握する良い方法は、コミュニケーションと顧客コラボレーションに焦点を合わせたアジャイルマニフェストを採用し、それに従うことです。開発サイクルを反復に分割し、反復の終わりごとに機能のプロトタイプをクライアントに示します。そうすれば、クライアントからのフィードバックに応じて、機能にあまり多くのリソースを投資する必要なく、即座にフィードバックを得て変更することができます。そうすれば、あなたとクライアントの両方が製品の結果に満足するでしょう。

チームや会社にとって移行は難しいと思いますが、それは急速に変化する要件に対処する最良の方法の1つです。

多くの同様のストーリーがここにあります。別の開発会社の下請業者として働いても、彼らが望むものを正確に知っているクライアントを見つけたことはありません。

私は、彼らが望んでいない、または避けたいことについて本当に良い考えを持っている人と一緒に仕事をするのに十分満足しています。私は通常、そこから彼らが満足している何かに取り組むことができます。

私の経験は、主にアプリケーション/プラットフォーム開発です。ありがたいことに、Webデザイナーのように美学の問題に対処する必要はほとんどありません。

多くの迷惑な書き換えの後、私は今、私が完全な開示と呼ぶものを操作します。

したがって、顧客の要件と要望を議論した後、私は常に彼らが望むと思うものと、その要件を満たすためにどのように進むかを書き上げます。それから私は彼らに私が書いたものを送り、彼らが仕事を始める前に肯定で答えるまで待ちます。

大規模なプロジェクト（5日以上かかる場合）の場合は、プロトタイプも作成します。これにより、私の側で大規模なコードを変更することなく、彼らの心を変える機会が与えられます。

常に機能するとは限りませんが、少なくとも私は、クライアントが自分の考えを変えており、間違って実装しているのではないと知っている立場にいます。