ユーザーが自分で要件をまとめて取得できるようにするか、それらを一緒にガイドしますか？

誰もがこのようなことを経験したと確信しています。プロジェクトを持っているクライアントと会議に参加します。彼らは念頭に置いて/いくつかの要件と彼らが欲しい/必要なもののあいまいな理解を持っていません。この時点で、2つのオプションがあるようです。

1）ユーザーに、「わかりました。まだ説明することさえできなければ、私はあなたのために何かを構築することはできません。あなたが望むものを知ってから数週間で一緒に戻ってみませんか」。

2）ユーザーと数回会って、良いole Socraticの方法でユーザーをガイドすることで、ユーザーが望むものを理解するのを助けます。「Xを追跡する必要がありますか？」、「Yはどうですか？」、「機能Zが必要ですか？」

最初のオプションでは、他の人の仕事をしたり、精神力を獲得したりすることはありませんが、ユーザーは一貫した仕様をあなたに決して提示しないかもしれませんし、期限が近づき続けると永遠にかかるかもしれません。2番目のオプションでは、ビジネスアナリストになるために多くの時間を浪費し、おそらく二度と使用しないビジネス知識を頭の中に詰め込む必要がありますが、次のような仕様が出てくる可能性が高くなります。理にかなっています。

私にとって、これは開発の最も困難な側面の1つであり、この感情の中で私は一人ではないと感じています。あなたの経験では、これらのオプションのどれがよりよく機能する傾向がありますか？

私は時々オプション3を選択することを認めなければなりません

3）クライアントのあいまいな意見に耳を傾け、彼らが望むものを正確に把握するのに数週間を費やすという考えに賛成します。

これは、特に小さな仕事の場合に機能します。これは、クライアントが頭の中にこの素晴らしいアイデアを持っている状況を回避するのに役立つためです。これは、現実の世界では実行できません。

それはいつも私に起こります。「きっとできる…」というのは非常に恐ろしいフレーズです。特に言及されていることは、ほとんどの場合、ベル、ホイッスル、および「素敵な」クラスの機能です。彼らは「バグトラッカーはもちろん、それから...」というステートメントでそれをまったく理解していません。潜在的な作業の大部分は最初の4つの単語にかかっています。

そのため、クライアントのビジョンを取り入れ、常識的なプログラマーを適度に適用し、ニーズに合ったものを構築することが良い場合があります。

元の質問に関して 私はそれがコンテキストに大きく依存していると思います。クライアントに固執している場合（つまり、私が関係している作業契約を介している場合、または代替作業がない場合）、＃2が最も賢明なアプローチです。そうでなければ、1週間で素晴らしい詳細な仕様が表示される可能性が高くなります...これはプログラマーとしてはまったく役に立たないでしょう。

上記とほぼ同じ問題（＃3）と、とにかく＃2を行う必要がある問題。

プログラマーになりたい場合は、他の誰かがクライアントが必要とするものを見つけ出し、それをコーディングするまで待ちます

あなたが開発者になりたい、これがあなたのクライアントであるなら、あなたはあなたのクライアントの手を取り、あなたが一緒にWants and Needsの交差点で幸せなウサギがいっぱいの牧草地を見つけるまで、可能性の濃い怖い森の中を彼らを静かに歩きます。

補遺：このプロセスは「システム分析と設計」、別名コンサルティングと呼ばれ、無料で行われるべきではありません

プログラミングは、ユーザーの問題を解決することを前提としています。だから私にとって、ユーザーに実用的で満足できるソリューションを提供するために「余分な」労力と苦労をすることは、ほとんどの場合、「余分な」面倒を避け、最終的に有用なものを提供しないことに勝ちます。

（もちろん、実際に自分の望むものがまったく分からない実際のユーザーが存在し、有意義な意思決定を下せる状態にすることはできません。しかし、ほとんどの場合、彼らは本当の問題であり、彼らはそれを解決するために努力と現金を費やすことをいとわず、彼らが実際のソリューションに近づくのを助けることができれば幸せです）

要するに、私たちの焦点はユーザーの問題を解決することです。これには、ターゲットを絞った質問をいくつか行い、回答を理解するためにさらに時間をかける必要がある場合があります。時には、密接に協力して、ドメインを一緒にチャート化する必要があります。時には、簡単なスケッチ/プロトタイプ/モックアップを作成してから結果を表示し、「これはあなたが考えていたもののように見えますか？」（その後、彼らが「実際には、まったく違うものについて考えていた...」と言ったときにプロトタイプを捨てて、最初からやり直します... :-)

本当のスキルは、適切なタイミングで適切なアプローチを選択することです。

最後になりましたが、私の経験では、優れたソリューションには、開発者側から少なくともある程度のドメイン知識が必要です。これがなければ、あなたはユーザーとの本当の共通言語を持っていないので、あなたが提供するものが彼らにとって本当に役立つという保証は一切ありません。ユーザーは通常、テクノロジーについてあまり手掛かりを持っていないため、何が可能で何が不可能であるか、またさまざまなアプローチ/機能のコストが何であるかを知らない。彼らが技術を十分に詳細に学ぶことを合理的に期待することはできないので、私たちは橋の端からその余分なステップを踏むべきです。

これは「余分な」努力で見返りはないかもしれませんが、次の2つの理由から投資として見たいと思っています。

• 長期的には開発者としての市場価値を高める良いソリューションを提供するのに役立ちます。
• 異なるドメインは完全に別個ではないため、そのドメインの知識の少なくとも一部は、おそらく将来のギグで再利用可能になるでしょう。

ソフトウェア開発者としてのタスクの一部は、ソフトウェアが使用されるドメインを十分に理解することです。したがって、プロジェクトの初期段階に参加することは非常に価値があります（時間とカスタマーエクスペリエンスの観点から） 。はい、これは徹底的なドメインおよび要件分析を行うことを意味します。ターゲットユーザーを取り込んだり、インタビューしたり、ソフトウェアを使用する場所を歩いたりするのに最適なタイミングです。

しかし、このスキルを身に付けることは、特にドメインがエンジニアリングの分野に関係していない場合、ほとんど芸術的な形です。あなたの明白な質問は顧客に気が遠くなるように見えるかもしれません、あなたのその場での存在は望まれないかもしれません、あなたのターゲット聴衆の社会構造の理解の欠如はまだ壊れやすい接続を崩すかもしれません。

このフェーズの複雑さを理解しないと、多くの場合、ソフトウェア開発者にとっても顧客にとっても失望につながります。私たちは、このフェーズをより速く達成するか、完全に廃止したいと考えています。多くの場合、結果は悲惨なものになります。急いで開始した後、開発中に成功するための利害関係はますます高くなり、図面に戻ることはさらに難しくなります。システムが最終的に完成し、数百万が費やされたとき、顧客もエンジニアリング会社もその失敗を受け入れようとせず、失敗したシステムの強制導入につながります。

別の方法は、ビジネスアナリストに任せてもらうことです。一部の製品ではこれが賢明な場合があり、アナリストはしばしば仲介者になることができますが、より多くの通信チャネルを作成するだけです（したがって、エラーの可能性が高くなります）。

いずれにせよ：コードの一部を書き換えることは、要件の一部を書き換えることを決して上回りません。

ps多分あなたは私が滝の方法を提唱していると思う。私は「前もって大きな設計」を信じていませんが、ドメイン分析の努力は実装の努力に比例するはずです。複数のサイクル（プロトタイプ、リリース候補など）を作成できます。

ユーザーが開発者でない限り、間違いなくオプション2です（オプション2が必要な場合もあります）。

ほとんどのソフトウェア開発ライフサイクルの多くは、要件の収集に焦点を当てています。ほとんどのユーザーは自分が望むものを知らないだけでなく、何が可能かも知らないので、ユーザーと協力してユーザーのニーズを理解することが重要なソフトウェア開発タスクです。

あなたは両方で行く必要があると思いますオプションを選択ます。彼らが出て行って、彼らが望むものを決めることができます。次に、出発点として使用する具体的なアイデアがある場合は、要件を有用なものに改良するためにそれらをガイドします。

プロセス全体が遅くなりイライラするので、彼らが望むものをかろうじて明確に表現できる場合は、オプション＃2に飛び込むことは望ましくありません（彼らがあなたに来たときに何を望むかについて非常に明確なアイデアを既に持っていない限り、私の経験では、これは非常にまれです）。彼らに彼らのアイデアを集めさせます。紙に何か書いてもらい、可能であれば既存のシステムの観点から必要なものを説明してもらいます（例：「blahblah.comのようなWebサイトが必要ですが、これらの違いは...製品XのようなタスクAを実行するツールが必要です」 、ただしUIはタスクBも実行する必要があります... "）。それから、システムを構築するために使用できる非常に具体的な要件に彼らが望むものを洗練し始める良い時です。

一般的に、クライアントは、彼らが必要と考えるものが何であるかを正確に知ってあなたのところに来ます。残念ながら、彼らはあなたが提供すると思う解決策につながる問題を説明するのではなく、彼らがあなたに言うことです。

ニーズを満たす何かを設計するには、それらのニーズを特定する必要があります。それを行うには、誰かがクライアントを抑えて、それらのニーズを抽出する必要があります。他の誰もそれができないなら、あなたはしなければなりません。（他の誰かが彼らができると思うなら、あなたは彼らと一緒に座って、後で本当のニーズを抽出しなければならないかもしれません...）

オプション2を使用すると、多くの会議で、解決策ではなく問題を共有するようにクライアントをトレーニングできます。（たとえクライアントが技術的な能力を持っているとしても-例えば、彼らはこの仕事をする余裕がなく、代わりにあなたがそれをする必要があるとしても-エンドクライアントにとって理想的でない実装に焦点を合わせているかもしれません。）どの開発プロセスを使用しても、仕様を定義する方法で質問に答えられるまで、何度かやり取りする必要があります。

開発サイクルのできるだけ早い段階で欠陥をキャッチすることを忘れないでください。コーディングやテストではなく、要件の間にそれらをキャッチできれば、時間を大幅に節約できます。

オプション1は、作業を行わないようにする優れた方法です。仕事が不要だと思ったとき、またはもっと重要なことをしているときに使いました。

まず、ユーザーはコンピューターで何ができるかわかりません。私たちのほとんどは、コンピューターと計算の理解を学ぶのに何年も費やしてきました。

第二に、ユーザーは必要なものを必ずしも知っているとは限らず、通常、実行可能な意味で自分が何を望んでいるかを知らない

たとえば、現在の家を購入したときに、インテリアデザイナーがメイン（米国初、英国1階）の部屋の壁の色を選択しました。自分でこれらの色を選択したことはなかったでしょう。見栄えの良い家が欲しかったので、手に入れました。デザイナーが私に耳を傾け、私が明確にできる何かを私に与えていたら、それはほとんど同様に出てこなかったでしょう。

ユーザーが好きな方法で必要なことを行う何かをユーザーに提供する唯一の方法は、ユーザー自身で作業することです。