私は5人のメンバーからなるチームの開発者であり、私たちのプロジェクトは災害に向かっていると信じています。理由をすぐに説明しますが、私の質問は次のとおりです。

締め切りは1.5か月で、私たちが何をしようとも、このプロジェクトは失敗するでしょう。私はただプロジェクトを終了して時間を無駄にするのをやめるべきだと思うが、政治的に私たちのマネージャーがそうすることは不可能だと思う。

この場合、どうすればよいですか？余分な努力をする必要がありますか、それとも簡単に取る必要がありますか？そして、私はマネージャーに何を言うべきですか？

このプロジェクトが失敗に向かう理由：

• 期限が近づいているため、必要不可欠な機能の多くは終了していません
• アプリケーションが不安定で使用が非常に難しい
• システムは非常に複雑で、コードを理解するのが非常に難しく、変更するのは非常に難しい-データモデルは複雑なリレーショナルデータベース（100以上のテーブル）によって駆動されている
• 不明確なリーダーシップ。マネージャーは、大きな変更を伴う新しい情報に対応します
• 自動テストやユニットテストはほとんどありません
• 他のシステムに大きく依存していますが、統合テストはまだありません

実際、私たちは実際にこのプロジェクトを（混乱と共に）数か月前から同じマネージャーの別の開発チームから1〜2か月前に継承しました。

管理の梯子の上で可能な限り最も簡潔で非対立的な方法で懸念を伝えます。リスクを要約しますが、それらに結論を課さないでください。

経営陣は、何をすべきかを常に選択する必要がありますが、状況を評価して伝達するのはあなたの仕事です。物事が南に行くときに紙の道を残すように、電子メールを使用してください。

それを終えて、誠意を持ってプロジェクトに取り組み続けてください。

プロジェクト、その支援者、およびその背後にある財務上の決定について知っていることのすべてを知っているわけではないことに留意してください。あなたにとって愚かに見える経営上の決定は、実際にはあなたには見えない賢い推論に基づいているかもしれません。

紙の証跡（例：日記、保存したメールなど）を保管します。事実と客観的観測のみを含める。すべての結論は、あなたが書いたものを読んでいる人（もしあれば）に任せてください。

開発者として、あなたがプロジェクトの障害とみなされていないなら、あなたは間違いなく起こる指差しからうまく出てくる可能性が高いです。上司はそれほど幸運ではないかもしれませんが、ここでは関係ありません。

一般的な原則に基づいて、履歴書を更新し、社外の他の開発者と時々会うようにしてください。地元の開発者グループに参加していない場合は、2または3に参加してください。友人や知人のネットワークを構築するには何年もかかりますが、長期的には価値があります。必ず2方向の通りとして見てください-あなたの会社の空きを有能な人で埋めることができれば、それはあなたが仕事を見つけるのを助ける人と同じくらい良いことです。

少し時間をかけて2冊の本を読むことをお勧めします。

Death Marchは、ソフトウェア開発で広く普及している病理学的プロジェクト管理スタイルを説明する標準的な本です。スケジュールの圧縮、機能の肥大化、または管理の誤りにより、多くのプロジェクトは最終的に悪い状態に陥ります。自分が一人ではなく、プロジェクトだけが死の行進ではないことを理解するのに役立ちます。著者のエドワード・ユアドンは、行き止まりのプロジェクトを4つの象限に分類し、それぞれに異なる対処戦略があります。対処方法は、立ち去ることだけである場合もあります。この本は、あなたの選択肢の範囲を理解し、あなたができることとできないことを絞り込むのに役立つと思います。

Catastrophe Disentanglementは、プロジェクトマネージャー向けに書かれています。壊れたプロジェクトをトリアージする方法を見つけることを目的としています。何をカットする必要があるか、何をカットバックできるか、そしてそれを顧客に売り込む方法ですか？「従来の」ソフトウェアプロジェクト管理は、私たちを厄介なプロジェクトに巻き込みます。そもそも私たちがそれらに巻き込まれたのと同じ考え方を使用して、問題を逃れません。この本は、 Death Marchよりも読むのが少し難しいですが、本棚に置くには良い本です。

キャリア/健全性を維持するための3つのシンプルでシニカルな戦略。

1. 列車の事故を確認してください-列車を降りてください：失敗したプロジェクトは士気がひどく、忍者に上向きの管理スキルがない限り、キャリアにマイナスの影響を与えます。ソフトランディングが見える場合は、今すぐジャンプしてください。

2. それがうまくいかない場合は、頭を下げてください。人々は非難する人を探し始めます-彼らのためにそれを簡単にしないでください！懸念を管理チェーンにエスカレートすることは正しいことかもしれませんが、それは非効率的で危険です。あなた自身のマネージャーがあなたの懸念を伝え、彼/彼女を迂回することはあなたを二人とも見苦しくなるだけでなく、あなたを「トラブルメーカー」、すなわちそもそもプロジェクトを弱体化させることで非難される人などのブランドにすることができません。もちろん、これはプロフェッショナルであり、あなたの時間を費やすが、英雄的ではないことを意味する。

3. T + 1の非常口を計画します。いくつかの選択肢を与え、潜在的な内部または外部転送の基礎を今すぐ行います。人に話します; プロジェクトの資金が削減されたときに他の人があなたをどうするかを決めるのを待ったり、2、3か月で移住する人々の避けられない「 '印」に圧倒される理由を待つ必要はありません。

過度に皮肉に聞こえるかもしれないが、あなたがそれを正しく呼んだ場合、あなたの道に来る不快感に苦しむことはありません。プロであり、楽観的でありながら、常に現実的であること。

この間もなく失敗するプロジェクトは、会社でのキャリアに、そしてそれを超えてどのような影響を与えますか？私の経験では、成功したプロジェクトに関連付けられているだけでは、あなた自身の個人的な優秀さの指標ではありません。

逆境に直面してあなたが示す特質や、時にはある種の失敗のように見えるものは、多くの場合、あなたが思っている以上に、上位者に気づかれます。そして、私はあなたの直属の上司を超えて話している。

私は、直属の上司が無能で解雇されるのを見た経験がありますが、同じ日に昇進しました。気持が悪いが、それは人々が私を見ていて、私がしたことを気に入っていることを示した。

多くの場合、失敗したプロジェクトに伴う同じ混乱と混乱は、あなたに輝く機会を与えます。

このようにプロジェクトを見てください。この失敗したプロジェクトは、私の強みと最高の品質のすべてに光を当てるために、どのような機会を与えてくれますか？私はこの経験からどのような教訓を学んでいますか？

本質的に、失敗から得られた経験の合計が真の成功の原動力となります。

注：Thomas Owensは、このようなプロジェクトで人ができる具体的なことを尋ねました。これらの状況で個人的なガイドラインとして使用したいくつかの一般的な提案があります。苦痛のプロジェクトが奇跡的に成功するのに役立ちますか？いいえ-しかし、物事について適切な視点を保ち、悪い状況にもかかわらず個人的な成功を見つけるのに役立っていることがわかりました。

1）個人の卓越性に焦点を当てる-より良いコードを記述し、品質と機能のより高い基準を満たすよう努めます。

2）個人的なメトリックに焦点を当てる-どのくらいのコードを書くのか、それはその後のバグを生むか？その比率をできるだけ低くします。あなたに割り当てられたタスクの見積もりを提供するように求められたとき、あなたは一般的に正確ですか、またはタイムラインを過度に/過少にバッファリングしたと思いますか？実際にタスクを割り当てたときに、納期の問題を事前に事前に通知するなど、作業の進行について適切なレベルのフィードバックを提供していますか？

3）チームの指標に焦点を当てる-これらは私の頭の上のものです。他のチームメンバーは、作業中のタスクに依存しているために遅れていますか？タスク/サブタスクをチームの他のメンバーに委任または分割するのが得意ですか？チームの1人または複数のメンバーとコミュニケーションを取ることは難しいと思いますか？私が定期的に改善するために取り組んでいるすべての分野。

このような状況では、はしごの最下段として、プロジェクトを支援するためにできることはあまりありません。

• あなたの仕事がきれいであることを確認してください
• 最大の問題領域を特定するのに役立ちます
• 問題だけでなく、答えを提供してください。あなたがそれらを修正しようとしているように見えます。

それとは別に、あなたは本当に1番の世話をする必要があります。

• すべてを文書化する
• すべてのメール、IMの会話を保持する
• 可能な限りプロジェクトから抜け出す方法を試してみてください

失敗したプロジェクトは、魂に有毒であり、うつ病、過労、自尊心の低下を引き起こす可能性があります。

それはすべて遠近法に関連しています。

私は毎日、彼の顔に笑みを浮かべていた別の男の向かいに座って恐ろしいプロジェクトに取り組んできました。ああ、私は彼の顔からその笑顔を平手打ちしたかった。

一部の人々は、プロジェクトの現状に悩まされていません。彼らは貢献と仕事を楽しみ、関心のある分野で協力しています。他のものの間、物事の現在の状態に強い否定的な反応を持っています。それはすべて、私たちの日常の仕事に対する私たちの知覚された期待についてです。

楽しみながら仕事をしているかもしれませんが。現在のプロジェクトには、明らかに嫌いな要素があります。

これらの問題要素が何であるかを特定し、対処する必要があります。

• 締め切り圧力
• 品質管理
• プロ意識
• 経営陣による指導

上記の開発の側面を重要視していない多くのチームや企業があります。私が見つけたのは、彼らがしばしば以下を考えることです。

• 締め切り圧力は、人々をやる気にさせる方法として認識されています。
• 品質にはさらにコストがかかり、返品制限があります。
• プロフェッショナリズムは、ビジネスの他の分野にも適用されます。
• マネージャーはタイムキーパーであり、開発に貢献する人ではありません。

これらの問題はあなたのものではありません。それは彼らのものであり、あなたは彼らの行動にエネルギーを浪費すべきではありません。崖に向かっているにも関わらず、笑顔で仕事を楽しんでいる人でないなら、like minded開発者の居場所を見つけることを考えるべきです。

あなたはもっと幸せになるでしょう。

プロジェクトの成功を達成するための新しい方法を見つけることに積極的に取り組むようにしてください。いくつかの代替案を提案する方法を考えてください。現在、あなたの上司はおそらくプロジェクトが失敗していることについてbeatられていますが、誰かが問題ではなく解決策を提供してくれることに感謝しませんか？

機能をずらして成果物に分割する方法はありますか？多くの場合、「必須」の度合いがありますので、それらに優先順位を付けてマイルストーンにグループ化できるかどうかを確認してください。何もないよりも、タイムラインの最後にいくつかの製品がある方が良い。または、新しい機能に取り組んでいる人々と安定性に取り組んでいる他の人々との間でチームを分割することを検討してください。これにより、両方の面である程度の進歩を示すことができます。

これらの努力が成功すれば、あなたはあなたが成功する方法を見つけることができるチームメンバーであることを示します。

私が行ってきたほとんどのプロジェクトのようですね。しかし、おそらくあなたが思うほどひどく終わらないでしょう：

1）あなたの仕事をしてください。責任を果たす限り、プロジェクト全体についてあまり心配する必要はありません。

2）CYA。プロジェクトが失敗し、マネージャーが自分以外のすべての人を非難し始めると思われる場合は、あなたが必要なことをすべて行ったことの十分な証拠があることを確認してください（項目1を参照）。

3）改善のためにいくつかの丁寧な提案をします。警告のベルを鳴らさないでください。運命と暗がりではなく、丁寧で繊細なことをしてください。

たとえば、チームが効果的な単体テスト（またはテスト）を作成していない場合は、表示したい内容に近い単体テストをいくつか作成し、それが特定の問題の解決にどのように役立ったか、または時間を節約したことを因果関係に言及します。

変化に影響を与えたい場合は、具体的な結果をもたらすポジティブなステップに焦点を合わせます。このプロジェクトは決して勝者になるとは限りませんが、チームは次のプロジェクトのために学ぶことができます。

また：

4）日和見的リファクタリングはあなたの友人です。

1. 頑張ってください。しかし、あなたの家族やあなたの健康を犠牲にしてではありません。
2. すべての重要な設計決定の記録を保持します。特に彼らがあなたの仕事に関係しているとき。
3. 状況が非常に困難になった場合、または大量解雇の被害者になった場合は、ネットワークを維持し、オプションを開いたままにしてください。
4. 試していない「失敗プロジェクト」として、プロジェクトを考えること。誰もが逆境に直面して前向きで頑張る人が好きです。だから、できるだけ長く、その人になろう。前向きな見通し、グリット、決意は職場にとって常に良いものです。
5. 失敗したプロジェクトを予想している場合は、事後会議を予想しています。事後会議では、全員が説明を求められます。すべてのコードを守る準備をしてください。[注：原則として、後から簡単に防御できるように、常にクリーンなコードを作成する必要があります。]決定に影響を与えた電子メールまたは設計文書がある場合は、さらに優れています。
6. その事後会議では、前向きな姿勢を保つようにしてください。そして、あなたの判断、努力、または技量が疑わしい場合にのみ、電子メールと設計文書の証拠を提示します。

私が最も効果的だと思ったのは、スケジュールのプレッシャーと戦う方法に関するロバートL.リードの勧告です。Readの書き込みは次のとおりです。

スケジュールのプレッシャーと戦うための鍵は、単にそれを市場投入までの時間のプレッシャーに変えることです。これを実行して、利用可能な労働力と製品との関係を可視化する方法。これを行う最善の方法は、関係するすべての労働者について、正直で詳細な、そして何よりも理解しやすい見積もりを作成することです。機能のトレードオフの可能性について、適切な管理上の決定を下せるという追加の利点があります。

見積もりが明確にしなければならない重要な洞察は、労働はほとんど非圧縮性の流体であるということです。コンテナのボリュームを超えてコンテナにさらに多くの水を詰め込める以上に、一定の期間にこれ以上詰め込むことはできません。ある意味では、プログラマーは決して「ノー」と言うべきではなく、「欲しいものを手に入れるために何をあきらめますか」と言うべきです。明確な見積もりを作成することの効果は、プログラマーに対する敬意を高めることです。これが他の専門家の行動です。プログラマーのハードワークが表示されます。非現実的なスケジュールを設定することも、誰にとっても痛々しいほど明白です。プログラマーは愚痴をこぼすことはできません。彼らに何か非現実的なことをするように頼むのは失礼であり、士気を失わせます。

プロジェクトが「失敗に向かう」と言うとき、それはどのタスクを実行する必要があるか、そして各タスクがどれだけの労力を必要とするかの評価に基づいています。評価を明確で理解可能で詳細にしてください。タスクをコンポーネント部分に分けます。開発時間をどのように費やすかについて、できるだけ詳しく説明してください。

これを行うと、経営陣と懸念事項を議論するための強固な基盤が得られます。おそらく、評価を完了しなければならない特定のすべてのタスクに分割すると、ジョブに必要以上の時間がかかることを示すことができます。

この詳細なスケジュールについて上司と話し合ったら、柔軟に対応できるように準備してください。上司は、「タスクXには1か月はかからず、せいぜい1週間しかかかりません」、または「タスクYはまったく不要で、スケジュールから削減します」と言うかもしれません。あなたは確かにこれらの点を議論するが、何はるかに重要なことに、あなたとあなたのマネージャーとの間の理解に到達することであることができ、いくつかのスケジュールの現実的なバージョン。そうすれば、たとえばテストのために時間を割り当てられていない場合、単に「予期せず」時間を使い果たすのではなく、テストしないように明示的に指示することになります。そして、あなたのマネージャーが時間通りに出荷するために明確に特定のコーナーをカットすることを合法的に喜んですることは間違いなく可能です-それは多くの場合です」

推定値は、議論と議論のための具体的な内容を提供します。同じページに移動します。マネージャーがあなたの懸念を考慮に入れたことに自信を感じるのに役立ちます。そして、それはあなたのマネージャーが明らかに不可能を求めている場合、それはあなたとあなたの両方に完全に明白になるポイントにあなたを連れて行きます。プロジェクトがうまく行き、本当に運命にあるなら、あなたはそれを明確にしたでしょう、そして彼があなたにあなたの時間を過ごして欲しいかを正確に決定するのはあなたのマネージャー次第です。

あなたのマネージャーはおそらく失敗することを知っているので、あなたは他の人よりもましだ。マネージャーと協力して、除外できるアプリのパーツ/機能があるかどうかを確認します。

多くの場合、すべてのクライアントリクエストは「ディールキラー」であると考えており、配信を約束するために邪魔になります。誰かがクライアントと協力してより深く調査するまで、あなたはこれらの決定を下すことができないかもしれません。これを行うことができない場合でも、最も重要だと思われるものを提供するようにしてください。許可よりも許しを求める方が簡単な場合があります。

私は明らかに失敗した3つのプロジェクトに参加しました。これらは非常に苦痛でしたが、振り返ってみると、3つのうち2つが私のキャリアにマイナスの影響を与えることはなく、3つ目でも世界の終わりではありませんでした。

ここに私が思い出すいくつかの所見があります。

下位の開発者（「仕様ごとのコード」、「バグの修正」、そのようなもの）は、チームの士気が下がって緩んだ場合を除き、あまり影響を受けません。このようなポジションでは、賢明な、時には成功するサバイバル戦略でさえ、あなたができる限り最善を尽くすことができます。

• ^{たとえば、私が経験した失敗の1つは、100以上の既知のバグを単純かつ系統的に修正することで克服されました（技術リードによるこの進歩を促進する特にスマートなアプローチと組み合わせて）新たなリリースのチャンスであり、合理的な成功を収めました。}

より上級で影響力のある立場にあるプログラマーは、プロジェクトの失敗の負の結果を共有する準備ができているはずです。建築家、技術主任、上級開発者は通常、プロジェクトの成功または失敗の原因と見なされるほど大きな影響を与えることが期待されます。

上級職では、何が悪かったのか、何が改善できたのかを分析することで、障害から「間接的に」得る準備ができているはずです。

これらの知識、死後の教訓は、正しく学べば非常に貴重です。上級職での非常に成功したキャリアは、WPでのこの素晴らしい回答で説明されているように、これらがどれだけ学ばれたかによって異なります。

判断は成功からではなく、失敗から生じます。ほとんどの企業は、以前の企業が失敗に見舞われた人々を雇いたい...

より実用的な注意として、「次/更新リリース」アプローチが障害からの可能な方法であると考えることができます。偶然かどうか（そうではないと思います）が、私のキャリアを損なうことのなかった失敗は両方とも、非常によく似たシナリオを通りました。リリースNは完全な災害であり、リリースN+1は許容範囲内N+2でした。

あなたの靴を歩いて、私はおそらく「次のリリース」のアイデアを準備/促進するためにいくらかの努力をするでしょう。計画的なリリース後に修正したい既知の問題の暫定的なリストのようなものを作成（および通信）してください。次のリリースのために、非公式で大まかなロードマップを作成します。

これらのアイデアを周囲の人々に伝える方法、この計画を検討するために経営者に影響を与える方法を考えてください。プロジェクトにマーケティングスキルのある人がいる場合、今後のリリースを「早期アクセス」、「ベータ版」、「顧客プレビュー」、「導入リリース」などのよりスムーズな用語にまとめることで、障害による損害の償却に関与させますそれ。

より高いアップがこのアイデアに耳障りに見える場合のバックアップ計画を考えてください。「100を超える既知のバグの修正」に関する上記の話を覚えていますか？本当に物事が変わる可能性があります。

経営陣は現在、次のリリースのアイデアに耳を貸していないように見えるかもしれませんが、プロジェクトの品質向上の強力な説得力のある証拠に直面して、彼らが再考する良い機会があります。

• ^{計画されたリリースのためにコードをフリーズしてから、完全に削除する管理決定までにかなり長い時間がかかる可能性が非常に高いです。そのときがチャンスです。既知の問題を修正し、進捗状況を適切に「伝道する」ことに力を注ぐと、これが違いを生む可能性があります（かつて私が行ったように）。}

ここにはすでに実用的な（そしてそうでなければ）アドバイスがたくさんありますが、私にとってこのミステリーの鍵は次の2つの項目です（強調鉱山）：

締め切りは1.5か月です

そして

...実際、同じマネージャーの下の別の開発チームから1〜2か月前にこのプロジェクトを（混乱と共に）継承しました...

そう....

Team Patsy The Avengers へようこそ

前のチームには、失敗するよりもやるべきことがありました。そして、どういうわけかマネージャーはそれと一緒に行きました。締め切りに近づいたチームを変更することは、プロジェクト管理のベストな動きではありません。

修正：期限の3か月前に、以前のチームが交代しました。

-> 以前の開発チームがどのように脱出できたかを調べ、それを実行します。<-

3か月は、この見かけのサイズのシステムを高速化するのに十分な時間であり、アーキテクチャの修正がはるかに少なく、テストを追加して終了します。もっと時間が必要です

そして、それができない場合、プロジェクトが無期限に延長されるか、魔法のエルフなどによって支援されることが絶対に確実でない限り、あなたはバッグを持って立っている最後の男になりたくありません。

厳しい？はい。しかし、以前のチーム/マネージャーによる不十分な計画（少なくとも！）はあなたのせいではありませんが、「配達失敗」はになります。

前のチームは保釈しました。前のチームは縁石に蹴られました。それはあなたに何を伝えますか？それはあなたがターンアラウンドチームだということを私に伝えます...そしてあなたのマネージャーはあなたの英雄を頼りにしてその日を救います。

5人のチームで、あと1.5か月です。新しいチームはプロジェクトを1〜2か月しか持っていないため、新しいチームは学習曲線を超えていません。このプロジェクトのサイズを大まかに推測すると、プロジェクトにまったく問題がなかったとしても、新しいチームが学習曲線を超える方法はないように思えます。

だから、私は（まだ）あなたがシャフトされていると思います。

その場合-そしてあなただけが真実か、あなたが信じたいことを決めることができるなら-あなたは誰にもこの列車の難破の道から抜け出すための説明や謝罪を負わない。しかし、あなたはそれについて慎重である必要があります。

マネージャーがプロジェクトが危険にさらされていることに気付いていないことを真剣に疑います。つまり、穏やかな説明は否定的な注意しか得られないということです。あなたのマネージャーがロジャース氏でない限り、あなたの未来は危険にさらされています。

しかし、常に覚えておいてください：インターネット上の見知らぬ人からのキャリアのアドバイスを受けないでください。

これはあなたにとって素晴らしい機会です！これについて起業家の視点を見てみましょう。

経営陣がこのプロジェクトの成功を望んでいると仮定すると、あなたは彼らがそうするのを助ける素晴らしい立場にいます。この実現が非常に重要な理由は、あなたが見ている警告サインが実際にこのプロジェクトの失敗につながるという確信と自信を育てなければならないからです[1]。

これは、体系的な思考と対人コミュニケーションで重要なスキルを実践するチャンスです。見逃されている問題と潜在的な機会を理解して視覚化することで、これらをできるだけ明確に伝えるための戦略を立てることができます。

ここであなたの機会を認識して、あなたのスキルを向上させてください。

[1]プロジェクトをキャンセルすると、実際に成功します。失敗は、悪い後に良いお金を費やすことになります。

あなたにできること

• これをあなた自身の優れた用語で扱ってください。それは「彼らの」プロジェクトですが、あなたのプロジェクトも失敗しますが、所有権を取ります。どうして？a）失敗が少し少なくなるのを助けるかもしれない、b）挑戦の時、これはあなたが最も学ぶ場所であるc）卓越性のあなた自身の測定基準によってあなた自身を測定するべきである、最善を尽くしてもプロジェクトを保存しないかもしれないが、自分を誇りに思うかもしれません

• 他の仲間の開発者と話をして、彼らがどう思うか見てみましょう。多くの人が同じ欲求不満を共有していることに気付くでしょう。注意深くやれば（人々に反乱や何かを始めたいと思わせないでください）、これはあなただけでなく他の人も

• 問題を無視することで問題が解決するわけではありません。どのようにすれば問題を解決できるかについて話します。プロジェクトは惨めに失敗しません。どうやるか？よく、「困難なときは困難になる」または「絶望的な時間は必死の手段を正当化する」などの決まり文句、および例えば、OSSの大規模な使用、極端なプログラミング/アジャイル方法論、週末のハッカソン（ボランティアのみ、人々を強制しない）週末）。これはあなたがリーダーシップを発揮できる時です（チームリーダー/シニアポジションにいない場合は慎重に）が、あなたはこの利点を活用して彼らのモッキンジャイになることができます。誰もが知っています。

• 経営陣が知っていることを確認しますが、非常に、非常に慎重に、彼らが知っている場合は、非対立的で穏やかな方法でこれを伝えることを感謝します。前にそれについて。あなたは彼らにこれをサービスとして伝えてください。感情的な側面はなく、単なる事実だけでなく、議題もありません。彼らがあなたがすべきだと思うことを尋ねる場合（これは素晴らしい兆候ですが、まれです）、次のセクションを参照してください

あなたができないこと、しかしあなたの管理はおそらく

• 彼らは見る「を助けるために」プロジェクトに多くの人々を追加してはいけません、これを

• すぐにお客様に電話して、悪い知らせを伝えてください。なぜこれが良い考えですか？まあ、アジャイルなソフトウェア開発のためのマニフェストを引用しておきますが、それがなくても、滝の愛好家でさえ悪い驚きを嫌います。このプロジェクトが失敗する運命にあることを顧客が事前に知っている場合、彼らは不幸になりますが、彼らが顔を吹く前に問題があることを伝え、あなたがそれに取り組んでおり、適応するために最善を尽くすそれ。顧客は多くのことを行うことができますが、それらのほとんどは成果物を持っていない土壇場で見つけるよりも悪くはありません（または、彼らはそれを行いますが、品質は使えません）。お客様は、テストスタッフ、オフショアITスタッフの採用を遅らせたり、社内トレーニングプランを変更したりできるので、お客様が正直であったという理由だけで感謝しています。

• 顧客と一緒に、プロジェクトから何かを作る方法を考えてください。最も一般的なのは物を飾ることです。たとえば、設計方法を開発するのが難しすぎる機能があり、顧客が小さな修正と単純化に同意する場合、一部の機能はより単純になります。

• 彼ら自身のより高い管理を更新してください、それは彼らが彼らの仕事を続けるのを助けるでしょう...

してはいけないこと

• プロジェクトへのより多くの人々を追加するために掲載します（これを）

• 終了/別の仕事を探します（少なくともまだ）、これはあなたが学ぶことができるものであり、いつかあなたをより良い開発者またはより良いマネージャーにするものです。多くのことをより良く理解し、より良い時間管理、より良い設計、より良いコードの書き方、そして仲間や管理とのより良い連携を学びます。他の理由ではなく、そこで働きたくない場合は、この2か月が終わった後に仕事を探してください。

• プロジェクト、管理、引き継いだ悪いデザイン、初心者の開発者について、1時間かかることを説明するのに3時間かかることをメンターに教えてください。できる。

• 経営者を批判し、トラブルメーカーとして標的になり、彼らは同じ船に乗っており、あなたが知らないことを知っているかもしれません、あなたができることはそれらを更新することです

• 人々（またはあなた自身）を責め、それは助けにならない、決して

• それを真剣に受け止めてください。医療機器でない限り、締め切りに間に合わなければ誰も死ぬことはありません。それはソフトウェアです。

それはちょうど私の2セントです、YMMV

プロジェクトで発生している問題を見つけ、客観的に可能な限り明確に定量化してください。すべての「メトリック」で、このメトリックが重要であると考える理由を明確にしてください。特定のメトリックが「許容範囲」内にない場合の結果がどうなるかについて、マネージャーに洞察を与えたいと思います。どの値が「良好」、「許容可能」、「問題あり」または「不良」であるかを示すために、各メトリックのガイドラインを提供する必要があります。すべての基準を事前に定義します。可能であれば、プロジェクトが成功するために最低限必要なものを説明し、これを現在のプロジェクトと比較することができます。

• 静的コードの品質は、多くの静的分析ツールによって定量化できます。必要に応じて、これをシンプルまたは詳細に保つことができます。あなたが始めることをお勧めするメトリック：
  • 循環的な複雑さ
  • コードのサイズ（例：関数/クラスごとの行数、ファイル数、テーブル数...）
  • どのモジュールが大きすぎるかを特定する
  • 複製。
  • コードスタイルの順守
• 不良率
  • モジュールまたはサブシステムごとのKLOCごと（システムの問題のある部分を特定）
  • チームメンバーごとにいくら計算することもできますが、自分でそれを維持する必要があると思います
  • 解決済みvs見つかった
  • バグを解決するために必要な時間（おそらくこれが傾斜している場合、これをグラフ化する）
  • おそらく、これが現在のレートで継続する場合、どれくらいの時間が必要かを見積もる
• 計画中
  • 構築された機能に使用される外挿時間。機能の複雑さを考慮してください。これは非常に正確である必要はありません。これで伝えたいのは、「機能A、B、CはD、E、Fとほぼ同じ複雑さです。機能を使用すると、ABCは計画時間の170％を使用します。 DEFには時間が必要です」または「平均的な機能は計算よりもX％時間がかかります。残りの機能を構築する方が簡単だと考える理由はありません。今後の計画でこれを補正する必要があります。現実的でない場合、計画を立てても意味がありません。
  • 毎月、またはできればさらに短いリリーススケジュールを用意してください。内部のみの場合。これは、プロジェクトに必要な時間を推定するのにさらに役立ちます。これにより、非現実的なコミットメントを回避することもできます（リリースが完了する前に新しい作業にコミットしない場合）。各サイクルについて計画を立て、新しい機能が次のサイクルにのみ入るようにします（つまり、現在のサイクルに追加することはできません）。
• テストカバレッジ：「通常の」テストカバレッジ値を説明し、現在のカバレッジがどの程度かを示します
• ドキュメント：実際にドキュメント化されている割合はどれくらいですか？どのように良いです？
• モジュール性：
  • クラスベース（結合と結合）
  • パッケージベース
  • サブシステムベース（通信パスはいくつありますか？）

あなたは仕事に行って、成功したかどうかに関係なく、プロジェクトで行うことを行う必要があります。あなたはあなたの仕事を行うために支払われています。能力を最大限に発揮してください。あなたがプロジェクトマネージャー/リードでないと仮定すると、プログラムをキャンセルするかどうかを決定するのはあなたの責任ではありません。スラックを決定することは、プロジェクトをキャンセルする決定をすることと同じです。それはあなたの仕事の説明の一部ではありません。

ただし、全体像では、スケジュールを満たそうとするために週に50時間、60時間以上働く必要があるという意味ではありません。繰り返しになりますが、それはプロジェクトの目標をどのように達成するかを把握する管理職の仕事です。50時間以上の労働時間は、残業代を支払う意思がなく、家族生活を保留にしない限り、妥当な選択肢ではありません。繰り返しになりますが、達成可能なスケジュールをまとめることは経営者の仕事でした。彼らは、非現実的なスケジュールを満たすために従業員に家族生活を無視させることを強制できるとは考えられません。

また、スケジュールでは残り1か月半と表示される場合があります。これはおそらく「ドロップデッド」の日付ではありません。一部の顧客は、それがすべてではない場合でも、その日までにあなたが持っているものを取るかもしれません。一部の顧客は、プロジェクトに既に多額の資金を投入しているため、追加の資金を調達する可能性があります。時には、会社自体が顧客の満足を確保するために追加費用を取る場合があります。それはすべてあなたのコントロールの外です。能力を最大限に発揮して仕事をしてください。これは、災害プロジェクトを大きな成功物語に変える可能性のある管理オプションを提供します。私はそれが何度も起こるのを見てきました。

私は他の人が言ったことを繰り返すことができますが、私は強調して強調します：常にあなたの最高の仕事のために努力し、紙の道を保ちます。CYAと技術的な理由の両方のため。

道に迷うことは、経営陣の個人的な性格に依存します。しかし、それは無能で嘘をついた管理の受け側にあるのは地獄だと言っておきましょう。しかし、最悪の場合は、自己（およびピア）の敬意をそのまま残します。

デスマーチの技術的側面を十分にメモしてください。避けられないインタビューの質問を受け取ったとき、あなたは失敗したプロジェクトにいたことがあります。なぜ失敗し、それを防ぐために何をしましたか？骨頭管理は答えではありません-それが理由であっても。

それは避けられない完全な失敗であると仮定し、プロジェクトをあきらめるだけの簡単な方法かもしれません。コンサルタントとして、私は多くの場合、退化、失敗または失敗のさまざまな段階にあるプロジェクトを支援するように招待されます。

完全な失敗とみなすものは、視点によっては、誰もがそのように認識されない場合があります。理想的な世界では、すべての機能が完成し、他のシステムやテストされたすべてのコード行から独立してエレガントにコーディングされます。rev 1のように見える単一のプロジェクトを見たことはありません。実際には、プロジェクトを出荷することは妥協することを意味し、いくつかの重要な機能を失うことさえありますが、製品は出荷できますが、ベータ品質であっても、少なくとも、最初に修正する必要があるものに関するフィードバックを取得します。これの利点は、ソフトウェアが実行されないことを管理者に通知できることであり、特定のv 1.0を真空で開発しようとするよりも、アジャイルな方法で変更を繰り返して対応する方がよいことです。最後に、このポジションの開発者として、重要なことは、これらの条件で可能な限り良いコードを開発することだと思います-文書化し、必要であればテストを自分で書き（特に外部の依存関係について）、システムの知識を使用して、どの機能が本当に重要であり、持っており、どれが一週間または一ヶ月待つことができます。あなたが私たちにしたように、あなた自身の懸念について声に出して、正当化してください。プランBの準備をするのではなく、あなたと他の貧しい人々がおそらく製品の出荷後にバグや未完了のコードをすべて修正するという事実に備えてください-上記のように、これはモジュラー分離方式でコードを書くことを意味します-永続化層のコードは悪いと思うので、次のリビジョンで完全に置き換えることができれば幸いです。最後に、絶望しないでください-そのような状況に対処することはあなたがしていることの一部です 再び支払われ、それは学習プロセスです。この特定のプロジェクトの結果に関係なく、これは将来の貴重な経験としてカウントされます。