クライアントが非現実的な期待を持っている場合はどうしますか？
クライアントサイトで過去6か月間プロジェクトに取り組んできました。データの機密性が要求され、自分のオフィスでの作業を望まないためです。
私がこのクライアントサイトに一人で行ったとき、2か月でプロジェクトを完了する必要があると言われました。
クライアントはソフトウェア会社ではないため、さまざまなポリシーのため、Eclipse、Tomcatなどをインストールする権限をマシンに付与するだけで20〜25日かかりました。環境のセットアップが遅れた後でも、彼らはまだ私が同じ2か月の期間でプロジェクトを完了することを期待していました。
要件に関するドキュメントは提供されませんでしたが、私はクライアントサイトで作業しているため、要件について話し合うために定期的に会議を行っていました。
6か月が経過してもアプリケーションはまだ完成しておらず、誰もが私を非難していますが、最初の数回のミーティングで説明した機能よりもはるかに多くの機能を追加したことに気付いていません。
この間、私は多くのことをやり直さなければなりませんでした。フォームを2つのセクションに分けます。数週間後、混乱を招くため、2つのフォームを再度マージするように依頼されました。
アプリケーションの範囲は毎日増加していますが、彼らはまだ遅れたのは2ヶ月のプロジェクトだと思っています。対象範囲が拡大したと私が彼らに言ったとき、彼らは私が最初に要件を求めなかった理由を尋ねます。
私はすでに毎日11から12時間働き、3から4時間旅行し、今では土曜日にも来ると期待しています。
私はここですべてをしなければなりません：要件、設計、コード、およびテストを取ります。
このような場合にどうすればいいですか？
追加の詳細：成果物のリストはありましたが、それらも重要であるとの説明がいくつか追加されました。彼らはまた、いくつかの成果物を変更しました。彼らはUATサーバーさえ持っておらず、IPアドレスを介して私の開発マシン自体でテストしています。
これはあなたのマネージャーの失敗です。あなたは、請負業者として、事前に書面で一連の明確な要件なしに、会社によってそのような厳しい期限のある状況に置かれるべきではありませんでした。この「機能が追加された」後にナンセンスになることはありません-発生するたびに、あなたが与えたそれら。
上司は、彼との会議を計画しているため、顧客から特定の要件のセットを取得する必要があります。プロジェクトはA、B、C、D、Eを実行する必要があります。そして、それが完了すると、プロジェクトは完了です。顧客の署名は、そのリストに同意するドキュメントに記載されている必要があります。あなたは最初からそれを持っていたはずです。
あなたのマネージャーがあなたをバックアップせず、これであなたをサポートしない場合-私はこれを頻繁に言わない-別の仕事を探し始めます。あなたはおそらく混乱全体のスケープゴートになるだろうから。また、11時間勤務と3時間通勤を希望する場合は、あなたがより価値のある非常に献身的な個人であることは明らかです。
このような状況で重要なのは、CYAペーパートレイルを構築することです。特に複雑なビジネス関係では、それを書かずに何もすべきではありません。彼らがあなたを働かせるためにさえ20日を要したけれども、それが複雑になるという大きな赤い旗ですが、最初のスケジュールに固執します。
あなたは追加機能が必要な会議を開きますか？後で書き留め、各アイテムに「現在のスケジュールから+ X日」のタグを付け、関係者全員にメールで送信します。お客様の内部メールシステムのみを使用する場合は、to：、cc：、bcc：の受信者リストを含めてさらに印刷し、慎重にアーカイブしてください。それ以外に、GrandmasterBが言ったように、顧客は元の要件へのそのような変更をサインオフする必要があります。
必要なスケジュールを保持できない場合は、そのスケジュールを書いてください。何らかの変更が発生した場合は、結果を含めて変更を書いてください。等々。
これは「私はあなたにそう言った」ためではありません。混乱がついに壁にぶつかったとき-彼らはとにかくそれを聞きません。これは、顧客が契約を履行しなかったと考えて顧客が訴訟を起こしたとき、または会社が支払いを拒否して顧客を訴訟したときの保険です。
あなたの説明から、あなたは古典的な Death Marchプロジェクト に参加しているようです：
プロジェクト管理 では、死の行進は、実際の 死の行進 と同じような、精神異常で暗いユーモアの類推を伴う、いくつかのタイプの病理学的プロジェクトのいずれかです。過酷な過労、および（多くの場合、最も特に）悪い結果のリスクが明らかに高いプロジェクト（つまり、プロジェクトの失敗、およびおそらく個人やグループの評判の損傷の脅威）の根拠のない理由で過酷に過労している。したがって、「死の行進」という名前は、最終的には成功するが、持続不可能な過労のホームストレッチを伴うプロジェクト、または（おそらくより頻繁に）インテリジェントで情報を得たメンバーが失敗する運命にある（または失敗のリスクが非常に高い）が、それでもメンバーは上司から行動を強制されている...
現象はよく知られており、進む方法について多くの文献があります-もちろん、独創的なエドワード・ユアドンの本を含むDeath March：The Complete Software Developer's Guide to Surviving 'Mission Impossible' Project。
ウィキペディアの記事 上記の引用は、死の行進プロジェクトに関係する/興味のある人のための詳細情報、調査、推奨事項を探すための良い出発点になります。
あなたの立場に立って、私が最初に検討するのは、上記の記事への参照をマネージャーに渡すことです。
そうすれば、私は何が起こっているのかを知っていることを知らせ、おそらくこの概念のために提供されているフレームワーク（たとえば、）について案内してくれるかもしれません。 Yourdonの章Xにあります。密接に関連する章Y etc ... "とともに確認してください。
（あまりありそうもないことですが）マネージャーがこの研究分野を認識していない場合、紹介することで状況を特定し、その対処方法を決定するのに役立つ多くの考えを彼らに与えることができます。
深刻なissue in project management。 Project Managerは動作するはずです成果物リストおよび優先順位付けクライアントと一緒に動作します。
ほとんど重要、あなたのPM should discuss見積もりの時間枠（問題/解決策の設計と分析を含む）をクライアントに同意します。
clear estimation of your work loadとプロジェクトの成果物により、ストレスから解放されます。また、peace of mindを追加して、作業に自信を持たせます。
アジャイルアプローチ を使用して、アイテムをスプリント（2〜3週間）で配信し、クライアントでUAT（ユーザー受け入れテスト）を実行します。スプリントを開始する前に、常にスプリントの計画を立ててください。
編集：コメントから、これは明らかですプロジェクトマネージャーの失敗です。あなたのような深刻なプロジェクトに適切なテスト環境や開発環境を設定しないことは、projectおよびSDLCプロセスへのbig Holeです。
正直なところ、これが可能であれば、最善の解決策は終了することです。このような状況はあなたにとって有毒であり、それらはまれにどんなに頑張っても、時間とともに良くなる。
損失を減らし、別のギグを見つけるのに最適です。しかし、あなたの経験を振り返り、このスレッドで他の回答からアドバイスを受けてください。
これは管理上の失敗であることに同意しますが、それはあなたの側の失敗でもあります。この段階では修正するのが非常に難しいので、これから抜け出すために必要なことのいくつかは、将来のプロジェクトを処理する方法です。
まず、プロジェクトの開始時に要件ベースラインドキュメントを要求する必要があります。派手で形式的である必要はありませんが、クライアントが期待されるものを指定するまで、何も正常に構築することはできません。書面でこれがない場合、顧客が最終結果に満足する可能性はほぼ0％です。したがって、これは非常に重要です。また、このドキュメントのあいまいさを見つけて、できるだけ早く解決することもあなたの仕事です。これらのいずれかに遭遇し、それを解釈する方法がわからない場合は、それが何を意味しているのかを推測せずに、あなたとクライアントがそれが何を意味するかについて同じページにいることを確認してください。はい、これはより多くの人々と話し合い、より多くの会議を行い、コーディングを減らすことを意味します。しかし、不明確な要件をクリアするのに、コードを間違ってコーディングし直すよりもはるかに短い時間で済みます。さらに、あなたはしばしば彼らに無料で再コーディングを与える必要があり、それはあなたが働いている会社にとっては良くありません。
次に、作業にかかる時間と期限を設定することを伝えます。要件を満たすために作業を行うのにかかる時間数以外に基づく期限は受け入れません。そうすれば、再び死の行進になります。所要時間の詳細な説明をすることで、どのように締め切りに間に合わないかを説明します。クライアントがどれだけ望んでも、1人の開発者しかいない場合、200時間の開発時間を1週間に収めることはできません。締め切りが不動になるその時点で、次のイテレーションに移動する必要があるアイテムを尋ねます。
プロジェクト時間の見積もりを行う場合、開発時間はプロジェクト時間のごく一部に過ぎないことを忘れないでください。また、会議、電子メール/電話通信、テスト、導入、ドキュメント、サーバー、ワークステーション、ソフトウェアの物理的なセットアップについても説明する必要があります。さらに、締め切りの計画では、1日の利用可能時間が8時間ではないと想定できます。これは、休暇、死別、病欠、不可避の遅延（許可を得るために待たなければならない場合など）を考慮するためです。ネットワークなど）、トレーニング、プロジェクトに関連しない作業（タイムシート、HRミーティングなど）。人々が期限を守らない最大の理由の1つは、彼らが毎日8時間だけ開発を行い、それで確実に働くことを想定していることです。これは単に現実的な仮定ではありません。
そして、彼らが別の作品を追加するたびに、あなたはそれがどれだけ長くかかるか、そして追加の作業がどれだけ締め切りを動かすかを彼らに伝えます。期限を移動するように依頼するのではなく、新しい要件のために移動していると伝えます。これでマネージャーを経由する必要がありますが、それはまず第一に要件が変更されるたびにマネージャーがプロジェクトに追加する量を知っていることを確認する責任です。これがすべて書かれていることを確認してください。そうすれば、必要に応じて身を守ることができます。
次に、自分が11時間稼働の週末や週末に虐待されないようにします。これは短期間には問題ありません（6か月ごとに1週間未満）が、長期的には受け入れられません。疲れた人はコードが遅くなり、間違いが多くなります。定期的に11時間よりも定期的に8時間作業することで、より高い品質でより多くのことを成し遂げることができます。そして週末。
このような状況では、ガントチャートが非常に優れていることがわかりました。それらは、クライアントに現在のスケジュールを示すことができ、新しい機能や変更を追加した場合の効果を示すのに役立ちます。機能xがy日までの配信に影響することをクライアントに伝えると、クライアントに登録されない場合があります。グラフ上に明確に表示することで、よりよく把握できます。
理想的には、これはプロジェクトの最初から行う必要があります。ここまでの「delays」について説明するのはそれほど有益ではないかもしれませんが、プロジェクトを進める上で役立つかもしれません。
Wiki から：
ガントチャートは、プロジェクトの終了要素と要約要素の開始日と終了日を示します。