アプリケーション仕様を簡素化する必要があることを非技術系クライアントに納得させる方法は？

多くの場合、文字通り何百もの不要な機能を備えたアプリケーションを使用して新しいクライアントが来るという状況に直面しますが、プロジェクトを成功させるには物事を大幅に簡素化する必要があることは明らかです。どのようにして、クライアントに、より多くのMinimum Viable Product（MVP）アプローチを取り、簡素化するよう説得しますか？

編集：

したがって、現在の一番の答えは、クライアントに巨大なアプリケーションの時間/コストの見積もりを提供することです。この状況の本当の問題に対処していないので、私はこの答えがあまり好きではありません。そして、それは大規模なアプリケーションを特定し、それを始めから構築しようとするのは悪い習慣です。最初は小規模でシンプルなMVP基盤を構築する方がはるかに快適です。そして、その基盤に小さな機能を一つずつ追加します。それでは、クライアントにこの方法でソフトウェアを構築する方法を説得するにはどうすればよいですか？

これらの何百もの機能を高品質で実行するのにかかる費用/時間を見積もることによって。口のある場所にお金を置くクライアントは非常に少ないです。

2つの言葉：ユーザーストーリー。

私は、クライアントがAClue®を得るのを助けるための最速の方法を持っていることを学んだ彼らはそれぞれ、彼らが望むすべての機能またはページのユーザーストーリーを通して私を話しています。次のようないくつかのことが起こります。

1. 彼らは、ページ/機能が実際に何をすべきかについて考えなければなりません。
2. より多くの詳細を求めると（ "そして?? ...そして?? ..."）、彼らはMagic Space Monkeys™を飛ばしてやることによって全体が生まれてくるのではないことを理解し始めます。週末にかけて。
3. 彼らは、作成プロセスの真のパートナーになります。つまり、すでに80％完了しているものについて考えを変えると、a）スケジュールの遅延、b）コストの増加が発生する理由を理解することになります。

真剣に。所有者によるユーザーストーリー は、プロセスに少なくともある程度の健全性をもたらすために私が知っている最高のツールの1つです。

コストと生産までの時間の側面について議論する際に、要件のランキング（「持っている必要がある」、「持つべき」、「持っている必要がある」）を求めます。バージョン1で「必要」である場合、残りの要件を最初のバージョンに続くスプリントとして達成できるバックログのセットに入れます。必須でない「持っている」ものがパックの奥に行き、それらのスプリントに到達するまでに、より重要な新しいもの（製品の実際の経験から）がトップに浮かぶことを願っています。

クライアントは、ビジネスのコストと製品を迅速に入手することの重要性を考慮しており、それらをバックログに入れることで「持っている素敵なもの」を直接却下していないことを理解する必要があります。

OP編集に対応するための編集：クライアントに、最小限の実行可能な製品を早期にリリースすることをお勧めする理由を納得させるために、製品が実際のユーザーによって使用されるまで、それが成功するかどうかを知ることは難しい（特にユーザビリティの点で）ことを説明します。顧客が初期の製品をユーザーベース全体に公開することにheしている場合は、顧客のターゲットサブセットのみが利用できる「限定ベータ」を行うことをお勧めします。このアプローチの裏側は、製品が使用できないという判断が遅れる、長くて費用のかかる開発サイクルであることを伝えます。37 Signalsは、これについていくつかの良いリファレンスを作成しました：Get Real and Rework。Getting RealはWebで無料で入手できます。

状況に対する不満の核となる原因は、おそらく、顧客が使用する認識と誤解を招く/誤った用語の1つです。顧客は通常、要件のリストを持ってあなたに来ませんが、彼らがそれについて考えることができるすべての一つ一つのウィッシュリストは彼らにとって有用かもしれません。顧客はまだ各機能が本当に必要かどうかを本当に考えるために時間を費やしていないので、これらはすべての要件ではありません。

これは必ずしも問題ではない

顧客がこれらすべての機能にお金を持ち、それを手放す意思があり、顧客が実際に抱えている実際の問題を解決することにあまり関心がない場合、これは非常に有利なプロジェクトになる可能性があります。非常にまれにしか発生しません。ほとんどの開発者にとっては、プロジェクトが最終的に顧客にとって成功しないことを事前に感じることができるため、魂を殺す作業です（開発者としてあなたにとって経済的に成功したとしても）。また、多くの不確実性を伴う固定費プロジェクトになる可能性が高いため、リスクが高くなります。また、大規模プロジェクトのリスクを誤って判断することは本当に問題です。

それが問題である場合はどうなりますか？

あなたがそのようなまれな状況にいないと仮定しましょう。この場合、ウィッシュリストの2つの主な欠点に対処する必要があります。

1. 顧客がこのような膨大な要件のリストを作成するコストについて正しい考えを持っている可能性は低いため、実際に必要な金額の契約を取得することはまずありません。
2. このウィッシュリストが、顧客が解決しようとしている実際の問題を正確かつ簡潔に説明しているとは考えられません。

私の経験では、修正するために2に対処する必要があります。実際の問題にドリルダウンすると、開発者は、顧客自身が考えもしなかった方法で問題を解決する創造的な飛躍をするために必要な入力を得ることができます。これらのソリューションは、完全なウィッシュリストの実装よりもはるかに安価で迅速です。

どのように修正しますか？
Matthew Flynnが答えで言っているように-最初に顧客に要件を優先させることから始めます。これは必ずしも簡単ではありませんが、強制的に実行させます。必要に応じて、「誰かがあなたの頭に銃を持っている場合、どの単一の要件を守りますか」というフレーズを使用します。多くの場合、このプロセス中に、個々の要件が何を意味するのかを顧客が本当に明確に把握していないことに気付くでしょう。その場合、Peter Rowellが提案することを実行し、ユーザーにUser Storiesで作業してもらいます。あなたと顧客は問題と要件をよりよく理解し始め、優先順位付けに戻ることができます。顧客の問題を解決するのに十分な知識があると感じるまで、必要な回数だけこれらの手順を繰り返します。

それは、ソリューションを開発するという質問にどのように答えますか？ 要件の優先順位リストを作成したら、顧客に段階的な開発プロセスを提案するために必要な情報を入手できます。アジャイルと呼ぶ必要はありませんが、各要件（または分割不可能な要件のセット）ごとに契約を細かく分割し、顧客による検証とともに1つずつ提供することを提案できます。または、全面的に利用して、オンラインおよびオフラインで利用可能な多くのリソースを使用して、アジャイル開発スタイルの1つに協力することが顧客にとって最善の利益であることを納得させることができます。いずれの場合でも、これらの要件の構成要素を優先度順に明確に提案する形式で契約/プロジェクト提案を提供できます。それぞれに独自のコストと結論があります。そのニンジンを顧客の前に持って、

最初に、その要件が現実的でないことを説明し、カウンター要件のセットを提示します。これにより、問題がより簡単かつ迅速に解決され、コストとリスクが削減されることを説明します。これを技術的な議論にしようとしないでください。クライアントはそれを気にしません。クライアントは、ビジネスケースを解決し、良い製品を時間内に取得することに関心があります。クライアントが動揺しない場合は、契約に同意して作業を行うか、このフォームでプロジェクトの責任を果たせない理由をクライアントに拒否して説明します。

他の人々が提案したものと似ていますが、わずかに異なりますが、顧客がすべて有効である可能性があることをお勧めしますが、優先順位を付ける必要があります。最初に行う必要がある項目。2番目に実行する必要がある項目。最も重要なことは、時間を使い果たした場合、どのアイテムが持っていなくても害が少なくなることです。1から732（またはその他）までの各アイテムに優先順位を付け、その順序で完了します。

過剰な要件のために予算を超過し、スケジュールより遅れたアプリケーションの歴史的な例は、FBIの仮想ケースファイルです。これは、数十の既存のアプリケーションを置き換えることを目的としており、それらはすべて、切り替え時に一度に完全に動作する必要がありました。プロジェクトは最終的にキャンセルされました。成功したのは、フレームワークを設計し、個々のアプリケーションを段階的に新しいシステムに置き換えることでした。代わりに、政治と内戦により、すべてのアプリケーション関係者は自分のアプリが最も重要であると主張し、誰もが既存のアプリに追加したいすべての機能から「必須」で仕様をゴールドブリックしました。最終的に、毎日書き込まれる変更要求の量は、実際に毎日書き込まれるコードの量を超えました。

2つのケースで「すべてを手に入れなきゃ」という作品を見ました。1つは、大規模な金融クライアント（すべてのもののウォーターフォールを使用）で、40の異なるシステム（当社が40の1つを作った）を交換し、一気に稼働させました。統合テストとコミュニケーションは大きな問題でした。私の推定では、彼らは電話会議で1日あたり約10万ドルを燃やした（通話中の全員の請求レートを数えるとき）。どちらの場合も、何が届けられるのかを強力な交渉者が打ち出し、すべての人の足を地面に釘付けにしました。ゴールポストの移動、再交渉はありませんでした。両方のジョブは時間通りに、そして仕様通りになりました。1つは予算をはるかに超えるもので、もう1つは予算内でした。そのためには、チームが何を提供できるかを知っている非常に優秀なプロジェクトマネージャーが必要です（機能Qには3が必要だと言える人）。

優れたPM、交渉担当者、および指標が不足しているため、クライアントを段階的な配信に向けて進めることをお勧めします。それでも金レンガ全体を一度に欲しい場合は、他のコンサルタント会社を見つける手助けをすることで、より良いサービスを提供できます。時々、最良の答えは「私たちはあなたを助けることができない」です。

短い回答：顧客の声に耳を傾け、顧客との中間的なアプローチを見つけます。

顧客の声に耳を傾け、予算とタイミングに応じて、プロジェクトをフェーズ（リリース、リリース2など）に分割することをお勧めします。

その後、アプリケーションが提供する必要がある機能の成果物、予算、および優先順位付けの各フェーズの推定を継続できます。

したがって、作業の範囲と成果物を定義するのが方法です:)

他の回答が述べているように、優先順位付けは非常に重要です。これを行う便利な方法は、MoSCoW-methodを使用することです。しかし、リスト全体を分割することから始めたい場合があります。そうしないと、機能リスト自体があなた（またはあなたの顧客）の理解の問題を与えてしまいます:)

この隣には、問題全体を見るという問題があります。おそらく、顧客と一緒に座って次の手順を実行することでこれを解決できます。

• 機能をグローバルに移動し、それらからカテゴリを抽出します
• カテゴリに優先順位を付け（MoSCoWを使用）、場合によっては階層（デフォルト機能を備えた1つの基本カテゴリ、主要な主題のカテゴリ、主要な主題の特定のバリエーションのカテゴリ）を定義します。これにより、前の手順で定義したカテゴリが変更される場合があります（新しい洞察のおかげです）。
• 各機能を1つずつ確認し、カテゴリに割り当てます
• top-xカテゴリのアイテムに優先順位を付けます（MoSCoWを使用）。

これにより、要求された機能の見やすく簡潔なトップダウンビューが提供され、ベースから開始して他の機能で拡張するさまざまな反復を定義するハンドルバーが提供されます。