クライアントが非現実的な期待を抱いている場合はどうしますか？[閉まっている]

クライアントサイトではデータの機密性が必要であり、私たちが自分のオフィスで働きたくないので、私は過去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が言ったように、顧客は元の要件に対するこのような変更を承認する必要があります。

必要なスケジュールを開催できない場合は、それらに書き込みます。何らかの変更が発生した場合は、結果を含めてそれらに書き込みます。等々。

これは「あなたにそう言った」ためではありません。混乱がついに壁に当たったとき-彼らはとにかくそれを聞かないでしょう。これは、顧客が契約を履行しなかったと顧客があなたを訴えた場合、または支払いを拒否したために会社が顧客を訴えた場合の保険です。

あなたの説明から、あなたは古典的なデスマーチプロジェクトに参加しているようです：

では、プロジェクト管理、死の行進は、実物にdysphemistic、ダークユーモアのアナロジー伴う病理学的なプロジェクトのいくつかのタイプのいずれかである死の行進を、ひどく酷使されていること、および（多くの場合、特に最も）明らかに悪い結果のリスクが高いプロジェクト（すなわち、プロジェクトの失敗、および個人およびグループの評判の損傷の脅威）の根拠のない理由で酷使されている。したがって、「死の行進」という名前は、最終的に成功するが、持続不可能な過労の家のストレッチを含むプロジェクトに、または（おそらくより）知的な知識のあるメンバーが見ることができるプロジェクトが失敗する運命にある（または失敗のリスクが非常に高い）が、それにもかかわらず、メンバーは上司によって行動を余儀なくされることを...

現象はよく知られており、進行方法については多くの文献があります-もちろん、エドワードユアドンの著書 『死の行進：完全なソフトウェア開発者のための『ミッションインポッシブル 』プロジェクトのガイド』などです。

上記で引用したウィキペディアの記事は、死の行進プロジェクトに関係する/興味のある人々のために、より多くの情報、研究、推奨事項を探すための良い出発点となります。

あなたの靴を歩いて、私が最初に考慮したいのは、上記の記事への参照を私のマネージャーに渡すことです。

そうすれば、何が起こっているのかを知っていることを彼らに知らせることができ、おそらく、「見ます、現在の状態はXYourdonの章で説明されているものに近いです。密接に関連する章Yなどとともに...」

（あまりありそうにないが）マネージャーがこの研究分野に気付いていない場合、参照することで、状況を特定し、その対処方法を決定するのに役立つ思考に十分な食料を与えることができます。

正直に言って、もしあなたがこれを行うことができるなら、最善の解決策はやめることです。このような状況はあなたにとって有毒であり、どんなに一生懸命努力しても、時間とともに良くなることはめったにありません。

損失を減らし、別のギグを見つけるのが最善です。しかし、あなたの経験を振り返り、このスレッドに関する他の回答からアドバイスを受けてください。

それは深刻 issue in project management。成果物リストを作成し、クライアントに優先順位を付けるProject Manager必要があるようです。

最も重要なのは、あなたのPMでshould discussあり、お客様の見積もりの​​時間枠（問題/解決策の設計と分析を含む）に同意することです。

持つclear estimation of your work loadとプロジェクトの成果の項目は、だけでなく、ストレスからあなたを和らげる追加します心の平和自分の仕事に自信を。

スプリント（2〜3週間）でアイテムを配送し、クライアントでUAT（ユーザー受け入れテスト）を行うことにより、アジャイルアプローチを使用してみてください。スプリントを開始する前に、常にスプリントの計画を立てることを忘れないでください。

編集：コメントから、これがプロジェクトマネージャーの実際の失敗であることは明らかです。あなたのような深刻なプロジェクトに適切なテストや開発環境が設定されていないことは、SDLCプロセスにとって大きな穴ですproject。

これは管理の失敗であることに同意しますが、それはあなたの側の失敗でもあります。この段階で修正するのは非常に難しいので、これから抜け出すために必要なもののいくつかは、将来のプロジェクトを処理する方法です。

まず、プロジェクトの開始時に要件のベースラインドキュメントを主張する必要があります。凝ったものやフォーマルなものである必要はありませんが、クライアントが期待するものを指定するまで何も正常に構築できません。書面でこれがない場合、顧客が最終結果に満足する可能性はほぼ0％です。したがって、これは非常に重要です。また、このドキュメントのあいまいさを探して、できるだけ早くそれらをクリアすることもあなたの仕事です。これらのいずれかに遭遇し、それを解釈する方法がわからない場合、それが何を意味するのかを推測しないでください。はい、これはより多くの人々との会話とより多くの会議と少ないコーディングを意味します。しかし、不明確な要件を解決するのにかかる時間は、誤ってコーディングしてから再コーディングするよりもはるかに短い時間です。さらに、多くの場合、無料で再コーディングを提供する必要がありますが、それはあなたが働いている会社にとっては良くありません。

次に、作業を行うのにどれくらい時間がかかり、それが期限を設定するかを伝えます。要件を満たすために作業を行うのにかかる時間以外の時間に基づいた期限を受け入れることはありません。そうした場合、あなたは再び死の行進になります。締め切りに間に合わない時間を詳細に説明することで、締め切りに間に合わないことを説明します。クライアントがいくら望んでも、1人の開発者だけで1週間に200時間の開発時間を割り当てることはできません。期限が動かない時点で、次の反復にどのアイテムを移動するかを尋ねます。

プロジェクト時間の見積もりを行うとき、開発時間はプロジェクト時間のごく一部であることを忘れないでください。また、会議と電子メール/電話による通信、テスト、展開、ドキュメント、サーバーの物理的なセットアップ、ワークステーション、ソフトウェアを考慮する必要があります。さらに、締め切りの計画では、8時間ではなく1日6時間しか利用できないと想定できます。これは、休暇、死別、病気の時間、やむを得ない遅延（許可を得るまで待つ必要がある場合など）を考慮するためです。ネットワークなど）、トレーニング、プロジェクトに関連しない作業（タイムシート、HR会議など）。人々が期限に間に合わない最大の理由の1つは、毎日8時間だけ開発と作業を行うという前提を立てていることです。これは単に現実的な仮定ではありません。

そして、彼らが別の作品を追加するたびに、どれだけ時間がかかるか、そして追加の仕事が期限をどれだけ動かすかを彼らに伝えます。期限を移動するように要求するのではなく、新しい要件のために動いていることを伝えます。今、あなたは、このために上司を経る必要がありますが、それはまず第一に確認してくださいあなたのマネージャがプロジェクトに追加されますすべての要件が変更された時、どのくらい知っている作るためにあなたのreponsiblity。このすべてが書き込み中になっていることを確認してください。そうすれば、必要に応じて自分を守ることができます。

次に、11時間の営業日や週末に悪用されないようにしてください。これは短期間（6か月ごとに1週間未満）で大丈夫ですが、長期的にはこれは受け入れられません。疲れた人はコーディングが遅くなり、ミスが増えます。高品質の作業を定期的に11時間よりも8時間頻繁に行うことで、より多くの成果を上げることができます。そして週末。

このような状況では、ガントチャートが非常に優れていることがわかりました。クライアントに現在のスケジュールを示すことができ、新しい機能や変更を追加した場合の効果を示すのに役立ちます。機能xがy日までに配信に影響することをクライアントに通知しても、クライアントに登録されないことがあります。グラフ上に明確に表示することで、彼らはそれをよりよく把握できます。

理想的には、これはプロジェクトの最初から行う必要があります。この時点までの「遅延」を説明することはあまり有用ではないかもしれませんが、プロジェクトを進めるのに役立つかもしれません。

ウィキから：

ガントチャートは、プロジェクトのターミナル要素とサマリー要素の開始日と終了日を示します。