プロジェクトに注意する切迫した運命の警告サインは何ですか？[閉まっている]

失敗したプロジェクトに取り組んだことは、使用されている言語、業界、経験に関係なく、ほとんどのプログラマーに共通する数少ないものの1つです。

これらのプロジェクトは、素晴らしい学習体験、魂を砕く災害（またはその両方！）になる可能性があり、さまざまな理由で発生する可能性があります。

• 心の上部管理の変更
• スキル不足/リソース不足のチーム
• 開発サイクル中に優れた競合他社が出現
• オーバー/アンダーマネジメント

そのようなプロジェクトをいくつか実行したら、プロジェクトが失敗する運命にある時期を早い段階で正確に認識できますか？

私にとって、大きな兆候は、機能クリープと組み合わされたハードで速い外部締め切りを持っていることです。計画がうまく練られていて、スケジュールどおりに進行しているプロジェクトが、後期の機能要求がロールインし、最終的な「成果物」に追加されると、恐ろしくレールから外れます。これらのリクエストの提案者は、「もう1つだけ」を求めずに部屋を出ることがめったにないため、コロンボのニックネームを獲得しました。

あなたの頭の中に差し迫った破滅の警告音を鳴らすためにあなたが警戒する警告サインは何ですか？

ヒロイックコーディング

夜遅くにコーディングし、長時間労働し、長時間残業することは、何かがうまくいかなかったことの確かな兆候です。さらに、私の経験では、プロジェクトの任意の時点で誰かが遅く働いているのを見ると、悪化するだけです。彼は自分の1つの機能をスケジュールどおりに戻すためだけにそれを行っているかもしれず、成功するかもしれません。ただし、そのようなカウボーイコーディングはほとんどの場合、計画の失敗の結果であり、必然的にそれをすぐに引き起こします。そのため、プロジェクトの早い段階で見ると、最終的には悪化します。

プログラマーが「コードは恐ろしい、最初からやり直す必要がある」という議論に勝ち始めたとき。成熟したアプリケーション。

あなたはそれをより良く構築できると思うかもしれませんし、問題をより完全に理解するかもしれませんが、あなたは本当にしません。ああ、そしてそれらすべてのpatchesいパッチ？これらは、実際の問題の修正であり、書き直しで再導入される可能性があります。

さらに、ある日、プロジェクトマネージャーに、6か月の作業の後、アプリケーションが開始時に持っていた機能の最大85％とバグの150％に近い理由を説明する必要があります。

問題解決者としての新しいツール。

人々がなじみのないツールを使用することを計画し始めたとき、私は気にしませんが、私はそれに目を光らせています。彼らがこれらのツールの宣伝されている利点をすべてスケジュールに入れ始めると、心配になります。楽しい例：

• オブジェクト指向言語を使用しようとするため、1か月のスケジュールを削ることができます（私たちが持っているのはすべてC開発者ですが）。
• この新しいスクラムを試してみましょう。これにより、すべてのプロセスの問題が修正されます。
• プロジェクトの途中であることがわかりますが、ORMを新しいものに変更したらどうなりますか？

新しいテクノロジーとプラクティスは素晴らしいですが、あなたはほとんどすべての利点をゲートから得ません。

私にとって唯一の最大の問題であり、すぐに見つけることができる問題は、ビジネスが書面による要件を時間の無駄と見なすことです。

だから基本的に; 書面による要件なし

それは死のキスです。

管理切断

期限、機能、人員配置などの責任者がプロジェクトの実施責任者から切り離された場合。これは以下につながる可能性があります。

• 顧客が機能コストを理解していない人と話しているときの機能クリープ
• Man-Month Syndrome。新しい開発者が、助けというよりも邪魔になるほど遅くプロジェクトに投入される
• 実装の結果ではなく、期限の決定のビジネス上の結果に対処しなければならない人々によって作成された非現実的な期限。
• 顧客と開発者とのコミュニケーションが途中の管理によって妨げられている場合、問題を解決しない製品。
• 開発者と管理者の間で潜在的な問題が十分に早期に伝達されないリスク管理が不十分です。

そのため、プロジェクトに経営陣が関心がない、コミュニケーションが不十分、顧客の声を聞いていない、または開発チームの声を聞いていない、丘を駆け抜けているように見えるとき。

1. 主要な開発者が去り、経営陣が気にしないとき

2. 主要な開発者が去り、他の開発者が気にかけないとき

ナンバーワンは、通常、チームのダイナミクスに大きく手を触れていないマネージャー（「10倍のスーパースター」、まともなプログラマー、彼らがお互いにどのようにやり取りするかなど）を示しています。

2番目は、通常、残りの開発者の深刻な関心の欠如を示しています。

初めて誰かが、通常経営陣は「私たちには時間がありません。」と言います。

通常、ドキュメントやコードレビュー（統計的にすべてのテストを含む他のどのバグよりも多くのバグを見つけて修正する）など、時間がないものの前に

顧客、マーケティング、または管理者に日付を選んでもらい、想像上のスケジュールに逆戻りしてみてください

経営が弱すぎてビジネスに「いいえ」と言えない場合。

それは決して達成されない期限につながり、IT部門に対する自信の欠如につながり、開発者がハックを作成する（つまり、誰かのマシンで実行されているdbにアクセスする...）につながる重要なシステム」を移行する必要があります...

私が考えることができる最初の悪い兆候は、経営者が悪いニュースをチェーンやクライアントに伝えることを望んでいない場合です。つまり、希望的観測による経営です。開発者は、それよりも数週間または数か月先の締め切りに間に合わないことを証明したのに、クライアントに何も伝えたいとは思わない。必要性が十分に事前に説明されている真の理由がある場合に、期限を延期しないクライアントを見たことはほとんどありません。締め切りの日に会わないことと、翌日には会うことはありませんが、2か月先のことであると言われたとき、私は腹を立てているクライアントをよく見ました。この時点で、彼らはあなたのプロセスに疑問を呈します。

障害が発生していることのもう1つの確実な兆候は、現在のシステムを既に理解している人々ではなく、プロセスの最も困難で最も複雑で最も重要な部分に新しい開発者を割り当てることです。次に、彼らが本当に仕事をきちんと完了しているか、または質問があるかどうかを確認するために注意深く見ないでください（質問がない場合は、大きな赤い旗）。新入社員は、自分が持っていると主張するスキルを本当に持っていることがわかるまで監視する必要があります。プロジェクトの重要な部分を手に入れ、数か月間すべてが順調だと全員に伝え、締め切りの1週間前に予告なしに終了した新しい従業員の仕事をやり直しましたそして彼がしたことは何も役に立たなかった。

別の確実な失敗の兆候は、開発者が最初に行われている他のことに依存する部分に取り組んでおり、それらのことは行われていないか、開始されていないことです。経営陣が作業を正しい順序で割り当てることができない場合、あなたはチューブを下ろしています。

もちろん、締め切りを毎回遅らせることなく機能のクリープは、物事が悪くなる最も一般的な兆候の一つです。私のプレートに20時間の作業を追加すると、期限が20時間移動します。そうでない場合、プロジェクトは失敗し、保証されます。

私のキャリアで私が見た確かな兆候は、経営陣がスケジュールで時間を補うためにより多くの身体を持ち込むことについて話し始めたときです。プロジェクトヘルプで実際にこれ以上の遺体を見たことはありません。

非技術系のマネージャーが、技術的な決定を下すことを主張し始めたとき、彼らは決して行う資格がありません。大きくて大きな赤い旗！

最も明らかな兆候は、高い離職率です。誰もが新しい仕事を探しているとき、おそらくあなたもそうすべきです。

他の非常に明白な兆候は、進歩の欠如です。1年が経過し、目標に近づいていないように思われる場合は、運命にあります。これは、要件を実装するよりも速く変更される場合に特に発生します。

チームメンバーの退屈。

あなたは「90％完了」し、納品は来週ですが、残っているのは「テスト」だけなので大丈夫です。

• 誰もが肉体的にも精神的にも疲れている
• 顧客/ユーザーは明らかに、タイムスケールまたは彼らが見ているものについて不満を抱いています。
• 元々美しいデザインは今では妥協を感じます
• 比較的重大なバグがいくつかあるため、出荷することを辞任します。バグは実際には修正したいのですが、できません。
• あなたが誇りに思っているのは、あなたが輸送しているものではなく、輸送の行為です-プロの誇りよりも生存者の精神に近い
• チームは、機能しない特定のものが存在することを恐れており、それらのセクションを無視し、そこにあるかもしれないものを恐れているため、最善を望んでいます。
• 誰もが自分たちがそれ以上であると確信している（そして彼らは正しい）
• 人々は燃え尽きる兆候（一般的な悲観、無関心、怒り）を見せています

（ジム・マッカーシーのソフトウェア開発のダイナミクスから引用）。

カウボーイコーダー、大きなエゴ、およびその経営陣の受け入れ

プロジェクト計画で、1か月を超えるプロジェクトの設計、開発、テスト、および展開の1回の繰り返し（古典的なウォーターフォール）が必要な場合は、1マイルかかります。

完全にアジャイルである必要はありませんが、開発サイクルを短くすることで、すべての人（顧客、管理者、開発者自身）に進捗を示し、避けられない事態が発生した場合の要件の変更に対処できます。

範囲でWildを実行する開発者

これは、他の開発者（または、残念ながらあなた）が設計とは大幅に異なるコンポーネントを開発し、これがシステム/ UATテストに完全に反映されるまで気づかないときに発生しました。私はバグを話していません。重要なシステムコンポーネントについては、機能が欠落しているか、機能を要求されておらず、大幅な手直しをせずにUATを渡すことはありません。この問題は次のことを示しています。

• 品質システムが壊れています。関係する開発者が設計/実装段階で問題を取り上げなかったのはなぜですか。コードはレビュー/検査ごとではありませんでしたか？単体テストと統合テストでこれが取り上げられなかったのはなぜですか？ある種の一貫したユニット/統合テストを実施していない場合、あなたはうんざりしています。
• プロジェクトマネージャー/技術リーダーは、開発チームを管理していません。開発者が必要なものを提供できない場合、完全なソリューションを提供することはできません。

プロジェクトの主要な開発者が何週間もコードをチェックインせず、重大なマイルストーンが近づいているとき。

それは契約の仕事であり、より上級の開発者とその仕事のPMは、より大きなカットを得るためにチームを組むことを決めたので、他の開発者は3週間の重要なコード人質を保持しました。最終的に、私たちは無能なPM（プロジェクトを台無しにするために6か月を費やしていた）を解雇し、開発者と話をしました。

言うまでもなく、プロジェクトの残りは自虐的な死の行進であり、仕様の凍結は遅れ、顧客にはPMがプロジェクトを去ったひどいスケジュールを補うための多数の譲歩機能が与えられ、プロジェクトの質が低下しましたそのため、すべての周り。

PMは、クライアントとのミーティングを中止し、ヒッピーな発言をするためだけに、CDR（クリティカルデザインレビュー）のために飛び立つ神経さえ持っていました。彼はプロジェクトの下で旅費の支払いを要求したとき、彼は自分自身で淫行するよう丁寧に言われました。

ここで見つかった、そのプロジェクトに影響を与えた他の回答のうち少なくとも5つを簡単に特定できます。つまり、最初の本格的なコーディングプロジェクトで多くのハードレッスンを学びました。

私が最初にサインしたのは、彼らが次の10週間にどれだけの時間外労働をするかを尋ね、サラリーマンにプロジェクトの成功と期限に合わせた時間外労働のボーナスを提供したときでした。

私が見た他の主要な兆候：要件の定義はスケジュールを超えており、終了日は変更されていません。始める前に遅れていました。彼らは設計から時間を奪ったので、データベース設計とサイト設計なしで開始しましたが、とりわけ、まだ設計および作成されていないテーブルへのインポートを行うことで、時間通りに納品する予定です。

クリティカルパス上のアイテムが順番ではなく同時に実行される場合。（ツールXを使用する必要があり、プログラマAがそれを構築し始めたばかりの場合、タスクが遅れます。）

マネージャーが感謝祭でコードをコミットしているとき。

午後11時より後、午前6時より前の日時スタンプを持つメールの取得を開始したとき。

複雑さをどのように処理するかについてのすべての質問に、「まだ心配しないでください」という同じ答えが出されたとき。

彼らがまだ要件を変更しているときは、QAに行くかライブに移行する前に変更します。

毎日の会議を開始し、進行状況の欠如について話し合うのに数時間かかる場合。ああ、それは私が一日中会議をしているからでしょう。毎日5分間の会議、1時間以上続く毎日の会議、罰金ではありません。

データベースチームとアプリケーションチームが互いに対話しない場合。

クライアントが約束された情報を時間通りに提供できないとき。特に、それらがデータインポートファイルであり、データベース内のそのデータがコードの動作を確認するために必要な場合。

マネージャーのオフィスの外にストップライトを設置して、その日に彼に近づくことが安全かどうかを知らせることを検討するとき。

一般に、期限が近づいているときに失敗したプロジェクトを見つけるのは簡単だと思います。あなたが言ったように、機能のクリープと固定された期限を組み合わせることは、プロジェクトを殺す確実な方法です。

ただし、重要なのは、失敗したプロジェクトを事前に発見することです。この場合の唯一の本当の「運命の兆候」は、「いつ終わるのか」という定義が完全に欠けていることだと思います。オフセットでこれを知らない限り、IMOが失敗する運命にあります。

私は過去5年間で3つの死の行進に参加しました。切迫した運命の私の直感に貢献したいくつかの事柄を以下に示します。

• 同社は、ジュニア開発者に新しい機能を設計および開発させ、より高価なシニア開発者にバグを修正するように割り当てます。
• 同社は、必要なドメインの専門知識を持たない第三世界の企業に重要なソフトウェアコンポーネントを外部委託しています。
• クランチタイムのサイクルは非常に密接に結びついているため、人々の健康は破壊されています。
• チームが率いるピルは、毎晩眠りにつくために自分自身に薬を飲ませて、仕事をやめます。
• クライアントは、変更要求を分析するよりも速く送信します。
• 数週間で数年の作業を提供することになっていますが、管理者は機能の凍結を拒否しています。
• ハードウェアサプライヤは、スケジュール通りに実行可能な製品を提供するのに明らかに問題を抱えており、会社の意思決定者は代替案を検討しません。
• プロトタイプデバイス開発者は、おそらく非現実的なスケジュールを満たす可能性のゴーストを持っているので、気分を良くするためにトップの幹部に与えられます。
• 1週目：「ああ、くだらない、コードにバグがあります。誰もが新機能の実行をやめ、バグを修正します。」2週目：「あら、私たちは機能のスケジュールに間に合わないでしょう。誰もがバグの修正をやめて、新しい機能を書きます。」無期限に繰り返します。
• 開発は1つの国で行われ、QAはすべて世界の途中で別の国で行われるため、バグに関する往復の通信には常に24時間かかり、少なくとも1人の関係者が複雑な技術的な問題について話し合っています習熟していない言語で。

私にとっては、機能セットの責任者（管理者、製品所有者、顧客など）が気にするのをやめるか、彼らの答えについて絶望的な空気を持っているようです。機能についての質問は、無関心と落胆で満たされます。プロジェクトへの投資や自信を失ったことは明らかです。

これは、私が取り組んでいたプロジェクトが「心の上部管理者の変化」に見舞われたときに起こりました。私はそれがどのように機能するかについて質問していましたが、突然誰も本当の意見を持っていませんでした。

しばらくしてプロジェクトはキャンセルされ、私が書いた美しいコードはすべて破棄されました。

ポールヴィックは数年前にブラックホールプロジェクトについて素晴らしい記事を書いた。アドバイスはすべて関連があると思います。（項目と要約の長さを編集しました。）

• 途方もなく壮大な目標。「人々がコンピューターを操作する方法を根本的に再考する」など。
• 完全に非現実的な締め切り。通常、これは、元のコードベースを元のコードベースよりもはるかに短い時間で書き直すことができると考えているためです。
• 互換性に関する非現実的な信念。信じるように、あなたは余分な努力なしですべての小さな癖を書き直して保存することができます。
• 到着しないと思われる主要な締め切りから常に「6か月」。または、到着した場合は、プロジェクトの最後に別のマイルストーンが追加されます。
• 大量のリソースを消費する必要があります。通常、1つ以上の確立された製品から生命線を吸い取ります。
• まだ証明されていない最新のテクノロジーを使用してください。そのため、新しいテクノロジーのスケーラビリティの問題をすべて洗い流すことができます。

「すべては大丈夫です。心配する必要はありません。」経営陣がそれを言っているのを聞くたびに、「私たちはみんなめちゃくちゃだ」に。通常、マネージャーは無関係の会議で偶然にそれを投げるのを聞きます（「ああ、ところで、すべて順調です。心配する必要はありません！」）が、それを明確に呼び出す会議を持つことはさらに大きな赤旗です。

マネージャーがこれらの線に沿って何かを言うのを聞いたことがなく、それが嘘であることが判明していません。

死んだプロジェクトからのいくつかのポイントは私が含まれていました：

• 経営陣はチームを倍増させて、より速く仕上げます。
• 開発者は、期限に間に合うようにバグを「埋める」ことを開始しますが、それは明らかですが、コードレビュー中に無視されます。

管理者がプロジェクトを異なる方向に同時に引っ張ると、キャリッジは静止したままになります。

私はかつて2人の男が管理するプロジェクトに関与していました。彼らはお互いに話をしなかったか、それぞれが解決するエゴを持っていますが、彼らは私たちの仕事を毎週約反対方向に指揮していました。どんな結果も得られないことに気付くのに長くかかりませんでした。嬉しいことに、私の参加はほんの数ヶ月しか続きませんでした。

この簡潔な記事「ITプロジェクトが適切に進む場合」を参照してください。

記事に記載されている要素が1つもない場合は、アラームのベルを鳴らします。

そのため、プロジェクトに以下のすべてがあることを確認してください。そうでない場合は、心配する必要があります。

（上記の記事を引用するには:)

1. 「第1は、達成されるべきものの明確なビジョンに基づいているということです。」

2. 「2番目の特徴は、ビジネス全体に関わるさまざまな関係者、特に上級管理職の支援とコミットメントに関するものです。」

3. 「3つ目は、取り組むべき問題を理解することです。」

4. 「最後の共通の特徴は、十分なリソースとスキルが利用可能になったことです。」

統計的には、ソフトウェアプロジェクトの開始は、圧倒的多数がそうであるように、失敗するという公正な兆候です...