scope - プロジェクトスコープの柔軟性？

Question

クライアントがプロジェクトの範囲外の要件を要求した場合、プログラマーはどの程度柔軟に対応する必要がありますか？

Answer 1

一般的な視点:

生計を立てる必要があります。クライアントにはコンピューティング ソリューションが必要です。クライアントには、提供するソリューションが自分のニーズに合っていることを確認する権利があります。合意に達した後の変更と追加は、ユーザーの要件をシステム設計に分析する能力に反映されます。これらの要件を十分に深く詳細に調査することができませんでした。これを細心の注意を払って行い、書面による承認を得る必要があります。クライアントからのシステム設計に関する合意。

法的観点:

プロジェクトの範囲を明確にし、クライアントにその範囲の契約書に署名してもらう必要があります。契約を結ぶと、契約に含まれていないものはすべて新しいプロジェクトになります。

ビジネスの視点:

（現在および将来のクライアントと）ビジネスを続けたいですか？新たに必要な機能を追加することによる現在のプロジェクトへの影響を評価する必要があります。影響が小さい場合は実行しますが、クライアントに好意的であることを書面で伝えます。影響が大きい場合は、クライアントと交渉して問題の概要を説明し、現在の契約を変更するか、新しい契約を作成する必要があります。あなたがしたくないことは、あなたのクライアントに敵対することです.

最後に、「クライアントは常に正しい」です。- (あきらめて立ち去らなければならないところまで。)

Answer 2

この質問に包括的な答えを与えることはできません。プロジェクトによって異なります。

例：

クライアントには燃やすお金があり、タイムラインが長く、外出先で他のプロジェクトはありません。私は非常に柔軟です。

クライアントは$$、短いタイムライン、外出中の他のプロジェクトにタイトで、私はほとんど柔軟性がありません。

プロジェクトに選択されたプロセスなど、他の要素も関係します。たとえば、アジャイルプロセスでは柔軟性が高くなり、ウォーターフォールアプローチでは柔軟性が低くなります。

Answer 3

あなたの質問への答えは、これら2つの影響を受けずにプロジェクトの範囲を変更することはできないため、時間とコストに対してクライアントがどれだけ柔軟であるかにかかっていると思います。

スコープクリープは、プロジェクトを進化させ、プロジェクトの結果に全体的にプラスの影響を与える場合、良いことです。スコープの変更を管理するには、正式な変更プロセスを実施する必要があります。

Answer 4

システムが実行する機能のリストを事前に定義します。

クライアントが新しい機能を追加する場合は、それに応じてコストと時間を増やします。

クライアントが関数をスコープ外に残すことを決定した場合、まだ実装していない場合はコストと時間を減らします。

Answer 5

それが固定入札プロジェクトである場合、私は交渉の余地があり、ある領域の範囲を縮小することと引き換えに、または予算の増加と引き換えに、または他の考慮事項と引き換えに、ある領域の範囲を拡大することに同意します.

私が時間単位で請求しているクライアントの場合、プロジェクトの元の定義の範囲内であるかどうかに関係なく、私が費やした時間に対して請求するため、クライアントは必要に応じて範囲を拡大できます。