顧客は考え方が異なるため、ある程度の教育が必要です。顧客は考える：
プロジェクトのどの時点でも変更は問題になりません
詳細は重要ではありません（例外はさらに少ない）
時間はお金がかからない（彼らは合意された固定価格を持っている）
仕様の1文は、実際のニーズに合わせて自由に拡張/読み取りできます。これは契約に影響しません。（ここでは、「常識」の議論がよく見られます-例：「会計管理について話すときは、もちろん、請求書管理画面が必要です-これは常識です！」
主な問題は、顧客（外部または内部/部門に関係なく）が欲しくない、または理解できないことです。ソフトウェアの作成プロセスを理解するのに何年もかかりましたが、私はまだ学んでいます。
あなたの経験は何ですか？顧客を教育するための最良のアプローチは何ですか？
回答:
この昨年の夏、私は顧客と非常によく似た会話をしました。
お客様は、定義された作業に対して競争力のある価格を提供することを望んでおり、ニーズが変化したとき、またはニーズに対する理解が変化したときに、コストを変更して作業の変化を反映させずに仕様を変更したいと考えていました。
見積もりの一部として、不明な変更にどのようにコストをかけるかについて提案があるかどうかを顧客に尋ねました。私たちが解決したソリューションは、15％の項目別の緊急時手当を含めて見積もりを出すことでした。その後、顧客と協力して、変更を優先してその手当を利用します。結局のところ、不測の事態は完全には使用されず、私は行われた作業に対してのみ請求しました。
最終結果は、私が行われた作業に対して支払われ、顧客が予算内で納品されたことを嬉しく思い、そして私がプロの方法で問題を提起したので、実際に行うために競合他社よりも私を選んだ作品。
私はそこにいるすべての潜在的な顧客がこの専門家であり、実際に高品質の仕上がりを大切にしていることを願っています。
お客様を教育します。私があなたの顧客ではないことを願っています;）
真剣に、私はあなたが問題を抱えていることを理解しています、そしてあなたは問題が顧客であると思います。多分そうですが、それは問題ではありません。顧客を変えることは本当に難しいですが、彼らとの仕事のやり方を変える方がずっと簡単です。
問題は、ほとんどの顧客がソフトウェア開発のすべての影響を認識しておらず、ビジネスを詳細に認識していないことです。
ほんのちょっとしたこと：
プロジェクトのどの時点でも変更は問題になりません
「あなたがどこまで間違った道を進んでいたとしても、引き返しなさい。」トルコのことわざ
ことわざが大好きなので、使えると嬉しいです。機会をありがとう;）
ここにいくつかの解決策があります：
あなたは顧客に自分の考えを変える可能性を提供する必要があります。これは、顧客が本当にニーズに合った適切なソフトウェアを入手するのに役立つためです。あなたがそれを開発している間、彼は最終的により多くのアイデアを得るでしょう。
あなたは固定価格契約を結んでいるので、要件を収集して見積もり、それぞれに価格を設定する必要があったと思いますか？
新しいものを構築する必要がある場合は、同じプロセスを使用します。固定価格契約を追加の要件で修正します。役に立たなくなる要件を削除することを受け入れます（もちろん、まだ構築していない場合）。
もう1つのアプローチは、ネゴシエートされたもの（役に立たず、開発されていない要件）をバージョン1として完成させ、バージョン2をその新しいアイデアとネゴシエートすることです。
2番目の解決策は、スクラムのように開発で反復を作成することです。私はこれを固定価格のプロジェクトでまだ経験していないので（固定価格のプロジェクトをもう行っていないため）、それが機能するかどうかはわかりません。スクラム（またはアジャイル）がすべてのソフトウェア開発プロジェクトの解決策であることに多くの疑いがありますが、説明されているプラクティスのいくつかが役立つかもしれません。
固定価格契約を結んでいる場合は、すべてのスコープ変更に費用がかかることを明確にする必要があります。それらの変更を評価し、変更を実装するためのコスト見積もりを提示します。
これはほとんどの業界で広く受け入れられている慣行ですが、一部の顧客はこれに非常に動揺します。
「常識」が主張されている場合でも、より大きな問題があるように聞こえる場合。
何年も前に私が働いて仕様を読み、「XXXを実行することには暗黙の要件があります」などのことを言った顧客のようなものです）。正解は次のとおりです。暗黙の要件はありません。唯一の要件は、仕様書に記載されているものです。要件を追加または変更したい場合は、仕様変更リクエストを送信してください。スコープの変更をお見積もりいたします。
メッセージは最終的には届きましたが、長い時間がかかりました。
解決策の1つは、作業を開始する前に、同意することを定義するためにより多くの作業を行うことです。あなたが言ったように、契約の1つの文はあなたと顧客によって簡単に異なって読むことができます。プロジェクト計画が詳細であるほど、彼らがあなたに望んでいる余分なことは元の契約の一部ではないと言うのは簡単です。
一貫性を保つことも重要です。顧客は、特定の新機能にどれだけの作業が必要かを知りません。迅速に実装可能な機能を無料で追加することに同意した場合、顧客の常識でこれ以上の作業は不要であるという理由で、この他の機能を無料で実行できない理由を後で顧客に説明することは非常に困難です。
固定価格契約のトリックの1つは、固定価格でジョブを実行した場合でも、ジョブにかかる時間の見積もりを入力することです。時間単位で請求しない場合でも、固定価格は無限の労働時間に等しいという幻想を取り除きます。