失敗に向かっているプロジェクトで開発者としてどのように振る舞うべきですか？
私は5メンバーのチームの開発者であり、私たちのプロジェクトは災害に向かっていると思います。その理由をすぐに説明しますが、私の質問は、どうすればよいですか。
締め切りは1.5か月で、どうしてもこのプロジェクトは失敗すると思います。プロジェクトを終了して時間の浪費をやめるべきだと私は思っていますが、政治的にはマネージャーがそれを行うことは不可能だと思います。
この場合、どうすればよいですか？私は余分な努力をするべきですか、それとも私はそれを楽にするべきですか？そして、私はマネージャーに何を言うべきですか？
このプロジェクトが失敗に向かう理由：
- 期限が近づいているため、必須機能の多くが終了していません
- アプリケーションが不安定で、使用が非常に難しい
- システムが非常に複雑で、コードを理解することが非常に難しく、変更が非常に難しい-データモデルが複雑なリレーショナルデータベース（100以上のテーブル）によって駆動されすぎている
- 不明確なリーダーシップ;マネージャーは新しい情報に大きな変更を加えて対応します
- 自動テストや単体テストはほとんどありません
- 他のシステムに大きく依存していますが、統合テストはまだありません
実際、私たちは実際、このプロジェクトを（混乱と共に）1〜2か月前に、同じマネージャーの下で別の開発チームから継承しました。
管理のはしごで、最も簡潔で対立しない方法で懸念事項を伝えます。リスクを要約しますが、それらに結論を押し付けないでください。
経営陣は常に何をすべきかを選択する必要がありますが、状況を評価して伝達するのはあなたの仕事です。物事が南に行くときに紙の道を残すように、電子メールを使用してください。
それが終わったら、誠意を持ってプロジェクトに取り組み続けます。
覚えておいてください、あなたはプロジェクト、その支持者、そしてその背後にある財政的決定について知っているすべてがあるとは限らないかもしれません。馬鹿げているように見える管理上の決定は、実際にはあなたには見えない賢い推論に基づいているかもしれません。
紙の記録を保管してください（例：日記、保存したメールなど）。ファクトと目的観測のみを含めます。すべての結論は、あなたが書いたものを（だれかが）読んだ人に任せてください。
開発者として、あなたがプロジェクトへの障害と見なされていない場合、疑いもなくその指さしからうまく出てくるでしょう。上司はそれほど幸運ではないかもしれませんが、ここでは関係ありません。
一般原則に基づいて、履歴書を更新し、会社外の他の開発者と時折会うようにします。地元の開発者グループに参加していない場合は、2または3に参加してください。友人や知人のネットワークを構築するには何年もかかりますが、長期的には価値があります。それを双方向の道として見てください-あなたが有能な誰かであなたの会社の開口部を埋めることを助けることができるなら、それはあなたが仕事を見つけるのを助ける誰かと同じくらい良いです。
少し時間をかけて2冊の本を読むことをお勧めします。
Death March は、ソフトウェア開発で広まっている病理学的プロジェクト管理スタイルを説明する標準的な本です。スケジュールの圧縮、機能の肥大化、管理ミスにより、多くのプロジェクトは悪い状態に陥ります。あなただけではなく、あなたのプロジェクトが唯一の死の行進ではないことを理解するのに役立ちます。著者Edward Yourdonは、行き止まりのプロジェクトを4つの象限に分類します。時として、唯一の対処戦略は立ち去ることです。この本は、オプションの範囲を理解し、できることとできないことを絞り込むのに役立つと思います。
Catastrophe Disentanglement は、プロジェクトマネージャー向けにさらに書かれています。壊れたプロジェクトをトリアージする方法を理解することを目的としています。何をカットする必要があるか、何をカットバックできるか、それを顧客に売り込む方法は？ 「従来型」のソフトウェアプロジェクト管理では、厄介なプロジェクトが発生します。そもそも、私たちがそれらに取り掛かったのと同じ考え方を使って問題を回避することはできません。この本はDeath Marchよりも少し読みにくいですが、本棚に置いておくとよいでしょう。
キャリア/正気を維持するための3つのシンプルでシニカルな戦略。
列車の事故を見て-列車から降りる：失敗したプロジェクトは士気が高く、忍者が上向きでない限り、管理スキルがキャリアに悪影響を及ぼします。ソフトランディングが見られる場合は、ジャンプしてください。
それでも問題が解決しない場合は、頭を下げてください。人々は非難する人々を探し始めます。彼らを容易にしないでください！懸念をエスカレートさせることは管理チェーンを上回らせることが正しいことかもしれませんが、それは効果がなく、リスクも伴います。あなた自身のマネージャーはあなたの懸念を上に渡す可能性は低く、彼/彼女をバイパスすることはあなたを二人とも見栄えが悪くするだけでなく、あなたを「トラブルメーカー」、つまり最初からプロジェクトを弱体化させたと非難されることができる人のようなブランドにすることができます。もちろんこれは、プロフェッショナルであること、時間内に投入すること、英雄的でないことも意味します。
T + 1の非常口を計画する：自分にいくつかのオプションを提供し、潜在的な内部または外部転送の基礎を今すぐ行います。人に話します;プロジェクトの資金が削減されたときに他の人があなたと何をするかを決めるのを待つ理由や、数か月で移住する人々の避けられない「スタンピード」に殺到する理由はありません。
それは過度に皮肉に聞こえるかもしれませんが、あなたがそれを正しく呼び出したなら、あなたの道に来る不快感に苦しむことの利点はありません。専門的になり、楽観的になるが、常に現実的になる。
この間もなく失敗するプロジェクトは、会社でのキャリアにどのような影響を与えますか？私の経験では、単に成功したプロジェクトに関連付けられているだけでは、個人の卓越性を示すものではありません。
逆境に直面してあなたが示す特質、そして時には特定の失敗であると思われるものは、あなたが思っているよりも上層部に気づかれることがよくあります。そして、私はあなたの直属の上司を超えて話しています。
個人的には、直属の上司が能力不足のために解雇されたのを経験し、その日、私は彼のポジションに昇進したことに気づきました。快適ではありませんでしたが、人々が私を見ていて、私がしたことが好きだったことがわかりました。
多くの場合、失敗したプロジェクトに伴うのと同じ混乱と混乱は、あなたに輝きを与える機会を与えます。
それでは、この方法でプロジェクトを見てください。この失敗したプロジェクトには、私の強みと最高の品質すべてに光が当たる機会があるのでしょうか。この経験から私はどんな教訓を学びますか、それは私をより良い専門家とより良い人にするでしょうか？
基本的に、失敗から引き出された経験の合計が、真の成功の原動力となります。
注：Thomas Owensさんは、このようなプロジェクトで人ができる具体的なことを尋ねました。これらの状況で個人的なガイドラインとして使用したいくつかの一般的な提案があります。苦痛プロジェクトが奇跡的に成功するのに役立ちますか？いいえ。ただし、状況を適切に把握し、悪い状況にもかかわらず個人的な成功を収めるのに役立つことがわかりました。
1）個人の卓越性に焦点を当てる-これまで以上に優れたコードを記述し、品質と機能性のこれまで以上の基準を満たすよう努めます。
2）個人の測定基準に焦点を当てる-後続のバグを生み出すコードをどれだけ作成しますか？その比率をできるだけ低くします。自分に割り当てられたタスクの見積もりを提供するように求められたとき、あなたは一般的に正確ですか、またはタイムラインのバッファリングが多すぎたり少なすぎたりしますか？実際にタスクを割り当てられた場合、配信スケジュールの問題を事前に事前に通知するなど、作業の進行に関して適切なレベルのフィードバックを提供していますか？
3）チームメトリックスに焦点を当てる-これらは、頭の中にあるもののほんの一部です。他のチームメンバーは、取り組んでいるタスクに依存しているために遅れていますか？チーム内の他の人にタスク/サブタスクを委任または分割するのが得意ですか？チームの1人以上のメンバーとコミュニケーションを取るのは難しいと思いますか？私が定期的に改善するために取り組んでいるすべての領域。
このような状況では、はしごの最下段として、プロジェクトを支援するためにできることはあまりありません。
- あなたの仕事がきれいであることを確認してください
- 最大の問題領域を特定するのに役立ちます
- 問題だけでなく、答えを提供するようにしてください。それらを修正しようとしているように見えます。
それはさておき、あなたは本当に1番の世話をする必要があります。
- すべてを文書化する
- すべてのメール、IM会話を保持する
- 可能であれば、プロジェクトから抜け出す方法を見つけてください
失敗したプロジェクトは、魂に有害であり、うつ病を引き起こし、仕事をやりすぎ、自尊心を低下させる可能性があります。
それはすべて遠近法に関連しています。
私は毎日、毎日微笑んでいる別の男の向かいに座って、恐ろしいプロジェクトに取り組んできました。ああ、私は彼の顔からその笑顔を平手打ちしたかった。
プロジェクトの現在の状況に煩わされない人もいます。彼らは自分たちの貢献と仕事を楽しんでおり、自分の興味の領域で協力しています。他のものの間、物事の現在の状態に強い否定的な反応を持っています。それは私たちの日常の仕事に対する私たちの認識された期待のすべてです。
あなたが楽しんでいる仕事の一部をしているかもしれませんが。現在のプロジェクトには明らかに嫌いな要素があります。
これらの問題の要素を特定し、それらに対処する必要があります。
- 締切圧力
- 品質管理
- プロ意識
- 経営者による指導
上記の開発の側面を重要視していないチームや会社はたくさんあります。私が見つけたのは、彼らがしばしば次のように考えることです。
- 締め切りのプレッシャーは、人々をやる気にさせる方法として認識されています。
- 品質にはより多くの費用がかかり、返品制限があります。
- プロフェッショナリズムは、ビジネスの他の領域に適用されます。
- マネージャーはタイムキーパーであり、開発に貢献する人ではありません。
これらの問題はあなたの問題ではありません。それは彼らのものであり、あなたは彼らの行動にエネルギーを無駄にすべきではありません。あなたが崖に向かっていても笑顔で彼の仕事を楽しんでいる男の一人ではないなら、あなたはlike minded開発者の場所を見つけることを考えるべきです。
あなたはもっと幸せになるでしょう。
これまでやってきたほとんどのプロジェクトのようですね。しかし、おそらくあなたが思うほど悪くは終わりません：
1）あなたの仕事をしてください。責任を負う限り、プロジェクト全体についてそれほど心配する必要はありません。
2）CYA。プロジェクトが失敗し、マネージャーが自分以外のすべてを非難し始めると思われる場合は、必要なすべてのことを行ったことを十分に証明していることを確認してください（項目1を参照）。
3）改善のためのいくつかの丁寧な提案をする。警告の鐘を鳴らさないでください。運命や憂鬱にならないでください。丁寧で繊細にしてください。
たとえば、チームが効果的な単体テスト（または任意のテスト）を作成していない場合は、見たいものに近い単体テストをいくつか作成し、特定の問題の解決にどのように役立つか、または時間を節約できるかについて因果的に言及します。
変化に影響を与えたい場合は、具体的な結果をもたらす前向きなステップに焦点を合わせることになります。このプロジェクトが勝者になることは決してないかもしれませんが、おそらくチームは次のプロジェクトのために学ぶことができます。
また：
4）日和見的リファクタリングはあなたの友人です。
プロジェクトの成功を達成するための新しい方法を見つけることに積極的に努めてください。いくつかの代替案をどのように提案できるかを考えてください。今、あなたの上司はおそらくプロジェクトが失敗していることに打ちのめされていますが、誰かが問題の代わりに解決策を手に入れたことを感謝しませんか？
多分機能を千鳥形の成果物に分割する方法はありますか？多くの場合、「必須」の程度があるので、それらを優先順位付けしてマイルストーンにグループ化できるかどうかを確認します。何もないよりも、タイムラインの最後にいくつかの製品がある方が良いです。または、新しい機能に取り組んでいる人と安定性に取り組んでいる人の間でチームを分割することを検討してください。これにより、両方の面でいくつかの進歩を示すことができます。
これらの取り組みが成功した場合、あなたは成功する方法を見つけることができるチームメンバーであることを示し、そうでない場合でも、あきらめないことを実証し、解決策を見つけるために努力します。
- 頑張ってください。しかし、あなたの家族やあなたの健康を犠牲にしてではありません。
- すべての重要な設計決定の記録を保管してください。特に彼らがあなたの仕事に関係しているとき。
- ネットワーキングを維持し、状況が非常に困難になった場合、または大量解雇の犠牲者になった場合は、オプションを開いたままにします。
- notを試して、プロジェクトを「失敗したプロジェクト」と見なしてください。誰もが前向きであり、逆境に直面して懸命に戦う人々を好きです。ですから、できるだけ長くthat personになるようにしてください。ポジティブな見通し、グリット、決断力は常に職場に適しています。
- 失敗したプロジェクトを予想している場合は、事後の会議を予想しています。死後の会議では、全員が責任を負います。すべてのコードを防御する準備をしてください。 [注：原則として、後で簡単に防御できるように、常にクリーンなコードを記述する必要があります。]決定に影響を与えた電子メールまたは設計ドキュメントがある場合は、それがさらに優れています。
- その死後の会議で、前向きでいるよう努めてください。およびonly判断、努力、または技量に疑問がある場合は、メールと設計ドキュメントの証拠を提示します。
私が最も効果的だと思ったのは、ロバート・L・リードの スケジュールのプレッシャーと戦う方法 に関する推奨事項です。 Readの書き込みは次のとおりです。
スケジュールのプレッシャーに立ち向かうための鍵は、それを市場投入までのプレッシャーに変えることです。これを実行して、使用可能な労働力と製品の間の関係を可視化する方法。正直、詳細、そして何よりも、関係するすべての労働力の理解可能な見積もりを作成することが、これを行う最良の方法です。これには、考えられる機能のトレードオフについて適切な管理決定を行うことができるという追加の利点があります。
見積もりが明白でなければならないという重要な洞察は、労働力はほとんど非圧縮性の流体であるということです。コンテナの容量を超えてコンテナに水を詰めることができる以上に、時間内にこれ以上詰め込むことはできません。ある意味で、プログラマーは「いいえ」と言うべきではなく、「欲しいものを手に入れるために何をあきらめますか？」と言うべきではありません。これが他の専門家の行動です。プログラマーのハードワークは目に見えます。非現実的なスケジュールを設定することも、誰にとっても痛々しいほど明白です。プログラマーは騙されない。彼らに非現実的な何かをするように頼むことは失礼であり、士気をそそります。
プロジェクトが「失敗に向かっている」と言った場合、それは、実行する必要があるタスクと、タスクごとにどれだけの労力が必要になるかについての評価に基づいています。その評価をexplicit、understandable、および詳細。タスクをコンポーネント部分に分離します。開発時間をどのように費やすかについて、できるだけ詳しく説明してください。
これを行うと、経営陣との懸念を議論するための強固な基盤ができます。おそらく、評価を完了しなければならないすべての特定のタスクに分解すると、ジョブの実行時間が通常よりも長くなる可能性があることを実証できます。
この詳細なスケジュールについてマネージャーと話し合ったら、柔軟に対応できるように準備してください。マネージャーは、「タスクXには1か月はかかりません。多くても1週間かかります」、または「タスクYは完全に不要なので、スケジュールから切り捨てます」と言うかもしれません。あなたは確かにこれらの点について議論することができますが、はるかに重要なことは、スケジュールのsome現実的なバージョンであなたとマネージャーの間の理解に達することです。そうすれば、たとえばテストのための時間を割り当てられていない場合、単に「予期せず」時間を使い果たすのではなく、テストを行わない明示的なディレクティブが得られます。そして、あなたのマネージャーが時間通りに出荷するために特定のコーナーを明示的に喜んで受け入れることは間違いなく可能です-それが完全に合理的な呼び出しである多くの場合があります！
見積もりは、討論および議論するための具体的な内容を提供します。同じページに移動します。これは、上司があなたの懸念を考慮に入れていることを確信するのに役立ちます。そして、それはあなたの上司が不可能なことを明白に尋ねているならば、それはあなたとあなたの両方にとって完全に明白になるという点にあなたを連れて来ます。プロジェクトがうまく行き、本当に破滅した場合は、それを明確にし、マネージャーがあなたにどのように時間を費やしてほしいかを正確に決定するのはマネージャー次第です。
実用的な（そしてその他の）アドバイスの連なりはすでにここにありますが、私にとってこの謎の鍵は次の2つです（強調は私のものです）。
締め切りは1.5か月
そして
...実際にこのプロジェクトを（混乱とともに）1か月前からanotherから継承しました同じマネージャーの下の開発チーム...
そう....
へようこそ チームパッシー アベンジャーズ
前のチームには、失敗するよりも、やるべきことがあった。そして、どういうわけか、マネージャーはそれに伴いました。このように締め切り間近にチームを変更することは、プロジェクト管理の最善の動きではないので、どういうことでしょうか。
訂正：前のチームは、締め切りの3か月前までに交代しました。
->前の開発チームがどうやって脱出できたかを見つけ、それを実行します。<-
3か月は、この見かけのサイズのシステムを高速化し、アーキテクチャを修正し、テストを追加して終了するのにかろうじて十分な時間です。 もっと時間が必要です
そして、それができない場合は、プロジェクトが無期限に拡張されるか、魔法のエルフなどによって支援されることが絶対に確実でない限り、最後に立っている人になりたくないバッグを保持しています。
厳しい？はい。しかし、以前のチーム/マネージャーによる計画の悪さ（少なくとも！）はあなたのせいではありませんが、「提供の失敗」はになります。
前のチームbailed。 前のチームは縁石に追いやられました。それはあなたに何を伝えますか？それはあなたがターンアラウンドチームであることを私に告げます...そしてあなたのマネージャーはその日を救うためにあなたの英雄に頼っています。
5人のチームで、あと1.5か月です。新しいチームはプロジェクトを1〜2か月しか行っていないため、新しいチームは学習曲線を超えていません。このプロジェクトのサイズを大まかに推測すると、プロジェクトにまったく問題がなかったとしても、新しいチームが学習曲線を超えていたはずはありません（
だから、私は（まだ）あなたは屈服していると思います。
それが事実であり、何が真実であるか、または何を信じたいかを決定できるのはあなただけです-この列車事故の邪魔にならないための説明や謝罪は誰にも負いません。ただし、それについては慎重にする必要があります。
マネージャーがプロジェクトが危険にさらされていることに気づいていないことを真剣に疑っています。つまり、穏やかな説明では否定的な注意しか得られません。あなたのマネージャーが Mr。Rogers でない限り、あなたの未来は危機に瀕しています。
しかし、常に覚えておいてください：インターネット上の見知らぬ人からのキャリアアドバイスを受けないでください。
あなたの上司はおそらく失敗することを知っているので、あなたは他の人よりも良い結果を残しています。マネージャーと協力して、除外できるアプリのパーツ/機能があるかどうかを確認します。
多くの場合、すべてのクライアント要求は「取引キラー」であると考えており、配信を約束するために私たちの道を外れます。誰かがクライアントと協力して深く調査するまで、これらの決定を下すことができない場合があります。これができない場合でも、最も重要だと思うものを提供するようにしてください。時には許可より許しを求める方が簡単です。
私は明らかに失敗した3つのプロジェクトに参加しました。これらは非常に苦痛でしたが、振り返ってみると、3つのうち2つは私のキャリアにマイナスの影響を与えておらず、3つ目も世界の終わりではありませんでした。
ここに私が覚えているいくつかの観察があります。
ジュニアポジションの開発者（「仕様ごとのコード」、「バグの修正」など）は、チームの士気が低下したために落ち着かない限り、あまり影響を受けません。このようなポジションでは、賢明な、時には成功するサバイバル戦略でも、最善を尽くすことができます。
- たとえば、私が経験した失敗の1つは、100を超える既知のバグの明確で系統的な修正によって克服されました（技術リーダーがこの進捗を促進する特にスマートなアプローチと相まって）、最終的に上位管理者がプロジェクトを回復し、それはまた、今度は合理的な成功を収めた新しいリリースのもう1つのチャンスです。
より上級の 影響力のある 職位のプログラマは、プロジェクトの失敗による悪影響を共有する準備ができているはずです。アーキテクト、技術リーダー、上級開発者は通常、プロジェクトの成功または失敗の原因と見なされるのに十分な影響を与えることが期待されます。
上級職では、何が悪かったのか、何が改善されたのかを分析することにより、「間接的に」失敗から利益を得る準備ができているでしょう。
これらの知識の一部、死後のレッスンは、正しく学習された場合に非常に貴重になる可能性があります。上級職での非常に成功したキャリアは、 WP ：
判断は成功からではなく、失敗から来ます。ほとんどの企業は、以前の企業が失敗の代償を払った人を雇いたいと考えています...
より実際的な注意として、「ネクスト/アップデートリリース」アプローチを失敗からの可能な方法として考えることができます。偶然かどうか（私はではない）と思いますが、私のキャリアに影響を与えなかった失敗は両方とも、非常によく似たシナリオで発生しました：release Nは完全な災害でした、リリースN+1許容範囲内であり、リリースN+2以降は、明白な成功でした。
あなたの立場で考えれば、おそらく「次のリリース」のアイデアを準備/促進することに少し力を入れるでしょう。修正したい既知の問題の暫定的なリストのようなものを（そしてコミュニケーション！）してください後に計画的リリース。次のリリースに向けて、非公式の大まかなロードマップを作成します。
これらのアイデアを周囲の人々にどのように伝えることができ、この計画を検討するために経営陣にどのように影響を与えることができるかを考えてください。プロジェクトに優れたマーケティングスキルを持つ人がいる場合は、今後のリリースを「早期アクセス」、「ベータ版」、「カスタマープレビュー」、「導入リリース」などのよりスムーズな用語にまとめることで、障害の損傷を償却するように彼らに働きかけてください。それ。
より高いupsがこのアイデアに耳を貸さないように見える場合に備えて、バックアップ計画を考えてください。上記の「100以上の既知のバグの修正」についての話を覚えていますか？本当に変化する可能性があります。
現在、経営陣は次期リリースのアイデアに耳を貸さないように見えるかもしれませんが、プロジェクトの質の向上の強力な説得力のある証拠に直面して再考するチャンスは十分にあります。
- 計画的なリリースのためにコードをフリーズしてから、完全に削除するという管理上の決定までにかなり長い時間がかかる可能性が非常に高いです。そのときがチャンスです。既知の問題の修正に取り組み、進捗状況を適切に「伝道」する場合、これは（以前に私が行ったように）違いを生む可能性があります。
これはあなたにとって素晴らしい機会です！これについて起業家的な見方をしてみましょう。
経営陣がこのプロジェクトを成功させることを望んでいると仮定すると、あなたは彼らがそうするのを助ける素晴らしい立場にいます。この実現が非常に重要である理由は、あなたが見ている警告の兆候が実際にこのプロジェクトの失敗につながるだろうという確信と自信を育てなければならないからです[1]。
これは、体系的な思考と対人コミュニケーションの重要なスキルを実践するチャンスです。見落としている問題と潜在的な機会を理解して視覚化することで、これらをできるだけ明確かつ簡単に伝えるための戦略を立てることができます。
あなたのスキルを向上させる機会をここで認識してください。
[1]プロジェクトのキャンセルは実際に成功するでしょう。失敗は悪い後に良いお金を使うことになるでしょう。
できること
あなた自身の卓越した言葉でこれを扱ってください、それは「彼らの」プロジェクトですが、あなたのプロジェクトも失敗します。どうして？なぜなら、a）少し失敗するのを助けるかもしれない、b）挑戦の時に、これはあなたが最も学ぶ場所であるc）卓越性のあなた自身の測定基準を通してあなた自身を測定すべきである、最善を尽くしてもプロジェクトを保存できないかもしれないが、あなたはまだ自分を誇りに思うかもしれません
他の開発者と話し合って、彼らの考えを見てください。注意深く実行すれば、多くの人が同じ不満を共有していることに気付くでしょう（人々に反乱や何かを始めたいと思わせないでください）、これはあなただけでなく、他にも
問題を無視することで問題が解決するわけではなく、どのようにしてすべてのオッズに対して問題を解決するかについて話します。少なくともある程度の必需品を入手するか、メインの「ワウファクター」のユースケースを正しく実行することで、このプロジェクトの失敗を少なくすることができます。どうやってするの？まあ、「タフになるとタフタフになる」または「絶望的な時間は絶望的な措置を正当化する」というアイデアやその他の決まり文句、たとえば、OSSの大量使用、極端なプログラミング/アジャイル方法論、週末のハッカソン（ボランティアのみ、人々に週末に働く）。これはリーダーシップを発揮できる時期ですが（チームリーダー/シニアポジションにいない場合は注意が必要です）、この利点を利用して彼らのあざけり者になることができます。誰もがそれを知っています。ここで、問題をチャレンジとして扱い、後で役立つかもしれないいくつかのリーダーシップスキルをここに示すことができます。
あなたの経営陣が知っていることを確認してください、しかし非常に非常に注意深く、彼らが知っている場合、彼らはあなたに非対立的で冷静な方法でこれを伝えてくれることを感謝します彼らについて以前に。感情的な面もなく、明白な事実も、議題もなく、これを奉仕として伝える必要があります。彼らが何をすべきかを尋ねる場合（これは素晴らしい兆候ですが、まれです）、次のセクションを参照してください
あなたができないこと、しかしあなたの経営者はおそらくすべきです
- 「支援する」ためにプロジェクトに人を追加すべきではありません this を参照してください
すぐにお客様に電話して、悪い知らせを伝えます。なぜこれが良い考えなのですか？まあ、私はアジャイルソフトウェア開発のマニフェストを引用しておきますが、それがなくても、滝の愛好家でも悪い驚きを嫌います。このプロジェクトが失敗する運命にあることを顧客が事前に知っている場合、顧客は不幸になりますが、彼らが直面する前に問題があることを伝え、あなたがそれに取り組んでいること、そして対応に最善を尽くしていることをはるかに喜んでいますそれ。顧客は多くのことを実行できますが、それらのほとんどは、ギリギリで成果物がないことを見つけるよりも悪くはありません（または、実行可能ですが、使用できない品質です）。お客様は、テストスタッフの採用を遅らせたり、オフショアIT担当者を雇ったり、社内のトレーニング計画を変更したりすることができるので、正直だったからといって感謝します。
お客様と一緒に、プロジェクトからまだ何かを作る方法を考えてください。最も一般的なものは、物事を精査することですたとえば、設計された方法を開発するには難しすぎる機能がいくつかある場合があります。顧客がいくつかの小さな変更と単純化に同意すると、一部の機能はより単純になります。
彼ら自身のより高い管理を更新してください、それは彼らが彼らの仕事を続けるのを助けるでしょう...
するべきこと[〜＃〜]しない[〜＃〜]do
プロジェクトにさらに人を追加するように依頼します（ this を参照）
終了する/別の仕事を探す（少なくともまだ）、これはあなたが学ぶことができるものであり、いつかあなたがより良い開発者またはより良い管理者になるのは何でしょうか。多くのことをよりよく理解し、より良い時間を管理し、よりよく設計し、より良いコードを記述し、同僚や管理者とよりうまく連携する方法を学びます。他の理由ではなく、そこで仕事をしたくない場合は、この2か月が経過した後で仕事を探してください。
プロジェクト、管理、受け継いだ悪いデザイン、あなたに1時間かかることを説明するのに3時間かかるとメンターすることになった初心者の開発者は、泣き言を言ったり、不満を言ったり、否定したりします。できる。
管理を批判し、トラブルメーカーとしてターゲットになる、彼らは同じボートに乗っていて、あなたが知らないことを知っているかもしれません、あなたができることはそれらを更新することです（常にあなた自身の直属のマネージャーを更新し、彼女/彼をバイパスしないでください）
人（または自分）のせいにする、それは助けにはならない、決して
あまりにも真剣に受け止めてください。医療機器でない限り、締め切りを逃しても誰も死ぬことはありません。それはソフトウェアであり、私たちは生活のための締め切りを逃し、リラックスしています。
それはちょうど私の2セント、YMMV
プロジェクトで発生している問題を見つけ、客観的に可能な限り明確に数値化してください。数値化するすべての「メトリック」で、このメトリックが重要であると考える理由を明確にしてください。特定のメトリックが「許容範囲」内にない場合の結果についてマネージャーに洞察を与える必要があります。各指標について、「良い」、「許容できる」、「問題のある」、「悪い」の値を示すためのガイドラインを示す必要があります。すべての基準を事前に定義します。可能であれば、プロジェクトを成功させるために最低限必要なことを説明し、これを現在のプロジェクトと対比することができます。
- 静的コード品質は、多くの静的分析ツールによって定量化できます。これは、必要に応じてシンプルまたは詳細に保つことができます。最初に推奨するメトリック：
- 循環的複雑度
- コードのサイズ（例：関数/クラスごとの行数、ファイル数、テーブル数...）
- 大きすぎるモジュールを特定する
- 複製。
- コードスタイルの遵守
- 不良率
- モジュールまたはサブシステムごとのKLOCごと（システムの問題のある部分を特定）
- チームメンバー1人あたりの金額を計算することもできますが、自分で計算しておくべきだと思います
- 解決済みvs発見
- バグを解決するのに必要な時間（これが傾いている場合は、このグラフを作成してください）
- これが現在の速度で進み続ける場合、どれくらいの時間が必要かを見積もる
- 計画
- 構築された機能に使用された時間を推定します。機能の複雑さを考慮してください。これは非常に正確である必要はありません。これで伝えたいことは、「機能A、B、Cは、D、E、Fとほぼ同じ複雑さです。機能ABCを使用すると、計画された時間の場合、ABCが170％使用されます。変更がない場合、同じことが予想されます。 DEFに必要な時間」または「平均機能は計算よりもX％時間がかかる」という線に沿って必要です。残りの機能がより簡単に構築できると考える理由はないので、将来の計画でこれを補正する必要があります。現実的でない場合、計画を立てても意味がありません。
- 毎月、できればさらに短いリリーススケジュールを設定してください。内部のみの場合。これは、プロジェクトに必要な時間を推定する上でさらに役立ちます。これにより、非現実的なコミットメントから解放されます（リリースが完了する前に新しい作業をコミットしない場合）。各サイクルの計画を立て、新しい機能が次のサイクルにのみ入るようにしてください（つまり、現在のサイクルに追加することはできません）。
- テストカバレッジ：「通常の」テストカバレッジの値を説明し、現在のカバレッジがどのようになっているかを示します
- ドキュメント：実際にドキュメント化されている割合はどのくらいですか？どのように良いです？
- モジュール性：
- クラスベース（結合と凝集）
- パッケージベース
- サブシステムベース（通信パスはいくつありますか？）
あなたは仕事に行き、成功したかどうかにかかわらず、どんなプロジェクトでもあなたがすることをするべきです。あなたはあなたの仕事を実行するために支払われています。できる限りのことをしてください。あなたがプロジェクトマネージャー/リーダーではないと仮定すると、プログラムをキャンセルするかどうかを決定するのはあなたの責任ではありません。スラックを決定することは、プロジェクトをキャンセルすることを決定することと同じです。それはあなたの仕事の説明の一部ではありません。
ただし、全体像を見ても、週50時間、60時間、またはそれ以上の時間をかけてスケジュールを満たそうとする必要があるという意味ではありません。繰り返しますが、それはプロジェクトの目標を達成する方法を理解するための経営者の仕事です。 50時間以上の週労働は、残業代を支払う意思があり、家族の生活を保留する意思がない限り、合理的な選択肢ではありません。繰り返しますが、達成可能なスケジュールをまとめることは経営者の仕事でした。非現実的なスケジュールを満たすために、従業員に家族の生活を無視するように強制できるとは限りません。
また、スケジュールには残り1か月半と表示される場合があります。それはおそらく「ドロップデッド」の日付ではありません。すべてではないにしても、一部の顧客はその日までにあなたが持っているものを受け取るかもしれません。一部の顧客は、すでにプロジェクトに多額の資金を投入しているため、追加の資金を調達する可能性があります。場合によっては、会社自体が顧客に満足してもらうために追加費用を負担することがあります。それはすべてあなたのコントロールの外です。できる限りのことをしてください。これにより、災害プロジェクトを大きな成功事例に変えることができる、管理オプションが提供されます。私はそれが何度も起こるのを見てきました。
それが避けられない、全くの失敗であると思い込み、プロジェクトをあきらめるのは簡単な方法かもしれません。私はコンサルタントとして、退化、失敗、失敗のさまざまな段階にあるプロジェクトの手助けを求められることがよくあります。私が支払われているものの一部は、そのようなプロジェクトの復活と完成です。
完全な失敗とみなすものは、見方によっては、誰もがそのように認識できない場合があります。理想的な世界では、すべての機能が完成し、他のシステムやテストされたすべてのコード行から独立してエレガントにコーディングされます。リビジョン1のようなプロジェクトは1つも見たことがありません。実際の世界では、プロジェクトを出荷するということは、妥協することを意味し、おそらくいくつかの主要な機能が欠けていることもありますが、製品は出荷できますが、最高のベータ品質になります、少なくとも、最初に修正する必要があることについてのフィードバックが得られます。これの利点は、ソフトウェアが決して実行されないことを経営陣に通知する可能性があり、真空で特定のv 1.0を開発しようとするよりも、アジャイルな方法で反復して変更に対応する方が良いことです。最後に、この立場の開発者にとって、重要なことは、これらの条件で可能な限り優れたコードを開発することだと思います-文書化し、必要に応じて（特に外部依存関係について）テストを記述し、どの機能が本当に重要でなくてはならないか、どの機能が1週間または1か月待つことができるかを伝達するシステム。あなたの懸念について声に出して、あなたが私たちにしたようにそれらを正当化します。プランBを準備するのではなく、製品が出荷された後、あなたや他の貧しい人々がおそらくバグのあるコードをまだ修正していないという事実に備えてください。あなたは永続層コードが悪いと思っています、うまくいけば次のリビジョンでそれを完全に置き換えることができるはずです。最後に、絶望しないでください。そのような状況に対処することは、あなたが支払われているものの一部であり、それは学習プロセスです。この特定のプロジェクトの結果に関係なく、これは将来の貴重な経験としてカウントされます。
私は他の人が言ったことを繰り返すことしかできませんが、私は強調します：常にあなたの最高の仕事のために努力し、紙の証跡を保管してください。 CYAと技術的な理由の両方のため。
あなたの道に来る落下は、経営者の個人的な特性に依存します。しかし、それは無能な嘘つきの管理の受け入れ側にいるのは地獄です。しかし、あなたが自分の（そして仲間の）尊敬をそのままにしておく最悪の場合。
デスマーチの技術的な側面についての良いメモをつけてください。避けられないインタビューの質問を受け取ったとき失敗したプロジェクトに参加したことがあります。なぜ失敗したのか、それを防ぐために何をしましたか骨頭管理は答えではありません-それが理由であっても。