プログラマーはクライアントを「考え」るべきですか？

要件の収集が嫌いになるまでになりました。顧客は自分の利益のために曖昧すぎる。クライアントに完了までの作業を示すことができるアジャイル環境では、機能に対する定期的な小さな修正/更新を行うことができるため、それほど悪くはありません。

環境内の「ウォーターフォール」タイプ（最初に要件、次にほぼ完全な製品）では、状況がくなる可能性があります。この種の環境により、私は常に要件に疑問を抱くようになりました。EG顧客は、「入力を自動的に数値1に変換する」ことを望んでいます（注文の数量を参照）。しかし、彼らが考えていないのは、「入力」は単純なタイプOである可能性があるということです。テキストボックス内の「x」は「woops」になる可能性がありますが、これらの「歯磨き粉」製品の1つは必要ありません。しかし、必要なものがたくさんあるので、私は何時間も耐えて修正し、彼らが望むものを壊すことができます。これは単に健康的ではありません。

企業で働いていて、私たちを助けるアジャイルモデルに合うように文化を調整しようとすることができました（私の仕事のグレード以上の小さな仕事はありません）。または、敷物の下にい詳細を一掃し、最高のものを望みます。私の顧客はコードに近づきすぎているのでしょうか？

あまりにも多くの質問に悩まされることなく、「クライアントのために考える」という問題をどのように扱うのでしょうか？

ほとんどの場合、顧客は他に何ができるかを知りません。彼らは、私たちにとってそれが明確になるように、必要なものを説明する必要がなかった。彼らの心では、それは明らかです。ユーザーの入力を数字の1に変換することを考えているという事実でさえ、彼らが思考に慣れている方法を本当に超えています。

本当にそうあるべきです。彼らが望むものを正確に記述する方法が本当に新しい場合、彼らは彼らのためにそれを書く必要はないでしょう。結果として、私たちの責任は、プロセスを通じて彼らを助けることです。このプロセスには意思決定が必要であるため、意思決定プロセスを容易にするための推奨事項も必要です。

そのため、顧客を曖昧にして、高いレベルで話してみましょう。彼らは彼らのビジネスを知っていて、それが彼らの得意なことです（うまくいけば、彼らはあなたの請求書を支払うことができないでしょう...）。彼らが話したことを取り上げ、しばらくの間考えてください。最終的には、必要なものがテスト可能で一貫性があることを確認しながら、彼らが望むものや必要なものを得るための素晴らしいアイデアを得ることができます。

チャンクで作業することを強くお勧めします。クライアントと会うときは、相互に関連する一連の要件を満たし、クライアントが望むことをどのように行うかを説明します。また、選択した理由を説明してください。その後、顧客はあなたが提供したものを見て、それを微調整できます。「私はそれを考えたことがありませんが、それは本当に役立つでしょう」のような応答を受け取った場合、あなたはクライアントがどう考えるかについてのパルスを持っていることを知っています。注：これは特徴ではなく、クライアントが抱えるビジネス上の問題に最適な機能を選択することです。

クライアントが明示的に言ったことと矛盾するように見えるものがあれば、その理由を説明します。クライアントが考えもしなかったいくつかの問題を明らかにする必要があります。また、あなたの代替手段が彼らが望む/必要なものをどのように与え、それらの潜在的な問題を回避します。少し押し戻されるかもしれませんが、実際に使用できる製品を提供しようとしていることに気づくと、顧客の信頼も高まります。彼らが何らかの反発を与えた場合、それは彼らが何か特定の方法を望んだ理由を説明することを強制します。これにより、クライアントをより深く理解し、必要に応じて要件を調整できます。

クライアントをすり減らす最速の方法は、小さな質問を次々に尋ねることです。一連の会議を計画およびスケジュールして、アプローチを確認します。技術的要件（チームが製品の構築に使用するもの）を所有し、クライアントがビジネス要件を所有し、それらを相互に関連付けることができる限り、ギャップを埋める方法があります。

あまりにも多くの質問から「腹を立てている」場合は、より良いクライアントを獲得してください。

顧客は自分が何を望んでいるか分からない。彼らはそれを見るとき、彼らの解決策を必ずしも認識しません。それが問題であり、それがあなたが解決しようとしている仕事です。彼らの要件をソフトウェアパッケージとして提供できるものに変換します。

それを行うには、あなたが何をしているかについて学ぶ必要があります。「テキストボックスに数字を入力するとどうなるか」を尋ねるべきではありません。「この数字が重要な理由は何ですか？」彼らに仕事のやり方を教えてもらいます。そして、彼らが何を望んでいるのか分からないので、彼らが言うことを聞かないでください、しかし彼らが何をするか、そして彼らの目がどこに行くかを見てください。

詳細についてはこちらをお読みください：http : //www.joelonsoftware.com/articles/fog0000000356.html

ある種の企業の従業員であると仮定すると、クライアントと自分の間でこれらの詳細を仲介するのに役立つ優れたビジネスアナリストが必要なようです。それを実現するのに十分な影響力がないと思いますので、次の最善のアドバイスは、クライアントが働いているドメインについてもっと学ぶことです。ビジネスと彼らが働くプロセスを理解することで、あなたは彼らがそれを説明しているゆるい、そしておそらく間違った方法にもかかわらず、彼らが本当にしたいことのより良い考えを持っています。それにより、彼らが求めているものを分析することができ、後で別の会議に戻って、彼らが望むものの解釈と、彼らが本当に欲しいものを与えるための可能な提案をすることができます。同じクライアントで一貫して作業している場合、

それが非常に困難、苦痛、非常に不快、または非現実的だと思われる場合、私の最後のアドバイスは、ビジネスアナリストがいる場所で新しい仕事を探し始めることです。

要件を収集している場合、これらの質問をするのはあなたの仕事です。

はい、クライアントはいらいらするかもしれませんが、その場合、「これらの質問すべて」を尋ねている理由を説明する必要があります。そのビジネスを自動化するコードを書く前に、そのビジネスを理解する必要があります。クリンチャーは、あなたがそうしなければ、彼らが実際に望んでいることをしないシステムを開発するために多くのお金を費やすことになるでしょう。

これの副作用は、クライアントが要件を洗練するのを助けることになってしまうことです。

これは、Big Design Up FrontまたはAgileを実行している場合に適用されます。

悲しいことに、クライアントが自分でできないか、できないかを考えるのはあなたの仕事です。

私は両方の可能な結果がありました：

• 顧客は、あなたが実際に彼があなたに言っていることを考えていることを喜んでいる、彼は彼が正しい手の中にいると感じている

• 顧客は自分の要件についてもう一度考えさせられるため、イライラします。しかし、その後、このタイプの顧客は遅かれ早かれ、とにかくあなたに腹を立てます。彼があなたが最初に彼のために考えなかったことが遅すぎるとわかるならば、彼は確かに非常に腹が立つでしょう。私は言うでしょう：可能であれば、このタイプの顧客を避けてください:-)

迅速なアプリケーション開発（RAD）も、この問題に対処します。

彼らが必要とするものについてのあなたの最善の推測に基づいて、プログラムのための非常に大まかな非機能的なUIを作ることによって、「クライアントのために考える」ことから始めてください。次に、彼らにそれを見せて、彼らの実際のニーズを満たすまで繰り返し作業します。

彼らが望むものを知らないということではありません。それは彼らがそれを見るまで彼らが望むものを知らないということです、そして時々あなたは彼らが望むものを除外によって決定することができます。つまり、彼らが望んでいないものを見せ、彼らがそれを批判する方法に注意を払っています。

BFUD（Big Up Frontデザイン）の主な問題は、顧客に何を得るかを明示的に記述する契約を強いることにより、開発者を非難から隔離することです。残念ながら、これはプロジェクトの誰もが本当に必要なものについて良い考えを持っていないときに行われます。最終的に、これは顧客がサインオフしたためにあなたが構築したものを受け入れさせるだけです。

顧客が成果物に満足していない場合、それはピュロスの勝利に過ぎません。

顧客の仕事は、必要なものをあなたに伝えることです。あなたの仕事は、彼らが必要なものをプログラムできるほど十分に彼らが必要とするものを理解することです。すべての入力を1に変更する問題に対する明らかな質問は、「なぜすべての入力を1に変更したいのか」ということです。その後、顧客はその背後にある理由を説明できるため、ニーズを理解し、必ずしも求めているものではなく、必要なものを提供できるようになります。あなたが彼らが必要とするものを知っていると確信しているなら、私はあなたが必ずしも彼らの考え方を「修正」する必要があるとは思わない。彼らはその製品と「完璧だ」というものを使用します。しかし、あなたが彼らが必要とするものを確信していない限り、あなたはあなたが考えていることを説明し、顧客とそれを解決する必要があります。あいにく 両方の部分で実際のリスニングを伴う多くのコミュニケーションなしで、プロセスのこの部分を実行する方法はありません。状況に悩まされたり、本当に言いたくないことや言いたくないことを言ったりすることに注意してください。

正直に言うと、「大きな機能」でない限り、ドメインの知識が最も豊富な人に何が起こるべきかを推測してもらい、それを実装してもらいます。受け入れテストで具体化されます-これが目的です。