ガントチャートのポイントは何ですか？[閉まっている]

私の（技術者ではない）同僚が、現在計画している新しいプロジェクトのガントチャートで脅迫しています。これは私たちに何を提供する可能性があり、それは有用なツールになりますか？

ウィキペディアが言うように、ガントチャートは、プロジェクトの計画に役立つ棒グラフのタイプ（多くの場合、「ラインタイプ」）です。多くの場合、大きな（本当に大きな）紙の壁に手動で描かれます。これは、その形式で簡単に変更できるためです。

これは非常に単純なタイプの計画ツールです。Excelまたはそれと同等のもので作成できます。プロジェクトの特定のフェーズに必要な時間が大まかに見積もれる限り、かなり効果的です。遅延がある場合-問題ありません-1行が長くなり、他の行は同じままで、新しいプロジェクト終了日があります。
重複するフェーズ（時間的に）は、1つのフェーズの開始が別のフェーズの終了に依存しているのと同じくらい簡単に見られます。

それだけです。

もちろん、Gannt（または世界の私の一部で通常呼ばれる「タイムチャート」）の問題は、プロジェクトの開始時に壁にうまく作成され、熱心に感じることです。そして、幸せな...そして、1つの遅延が発生し、チャート上でそれを変更し、あなたはまだ幸せに落ちています...その後、別の遅延が発生し、再びそれを作成し、あなたはまだかなり良い気分です.. 。100xの遅延が発生します...あなたは_______（検閲済み）のように感じています。

つまり、実際にそれらの短い期限に固執している場合、それは良いプロジェクト計画ツールにすぎません。ここで時間を無駄にするのをやめて、仕事に取り掛かってください！

よく作成され維持されているガントチャートは、優れたツールになります。主な利点は、どのタスクが他のタスクに依存しているかを示し、プロジェクトが遅延によってどのように影響を受けるかを予測し、他のタスクを待っているために無駄な時間を強調することです。

過去にガントチャートをソフトウェアプロジェクト管理に使用できました。また、人々がフラストレーションで彼らを捨てるのを見ました。

プロジェクト管理ツールは、誰かが実際に尋ねている質問に答えている場合にのみ役立ちます。私の場合、私は2つの質問を絶えず聞かれ、ガントチャートで答えることができました。

• マネージャー：ソフトウェアが出荷可能な状態になるのはいつですか？
• 開発者：割り当てられたタスクを完了しました。今、どのタスクを割り当てていますか？

それでは、ガントチャートが役立つために必要な要素は何ですか？

複数のチームメンバー

それは明らかです。チームメンバーが1人だけの場合、必要なのは1列のタスクのリストだけです。次々にそれらを行うだけです。

タスクが何であるかの知識

これは別の明白な声明のように思えますが、タスクに分割できるほど十分に定義されていないソフトウェアプロジェクトの数には驚かれることでしょう。実際には、事前の仕様とある程度の事前の設計が必要です。一部のアジャイル/エクストリーム手法では、ガントチャートを使用できませんでした。これは、その後の3週間の反復でどのタスクが行われるかわからないためです。

チャートを維持する時間と動機

誰かが物を維持するために時間を費やす必要があります。多くの場合、誰かが詳細なガントチャートの作成に数日を費やし、それを無視します。たぶん彼は一ヶ月後にそれを取り出し、神経質に笑ってそれを捨て、二度とそれについて話すことはないでしょう。

タスクと最適な見積もりを取得したら、それらをチャートに配置します。そして、最初のタスクが完了したら、それをチャートにマークしてから、他のすべてのタスクを揺り動かして、推定が間違っていたという事実を補正する必要があります。そして、2日後にもう一度やり直します。そして再び、さらに2日後に。そしてもちろん、何かを忘れたり欠陥が現れたことが判明した場合は、チャートに新しいタスクを配置する必要があります。

それは重要な継続的な時間のコミットメントのように聞こえるかもしれません、そしてあなたは正しいです。これを行う動機はどこから来るのでしょうか？

誰かが実際に結果を気にします

ガントチャートを使用して成功したのは、毎週プロジェクト管理会議が行われたときでした。マネージャーは、各チームリーダーにプロジェクトをいつ実施するかを尋ねるように部屋を歩き回りました。プロジェクトが遅れて実行されている場合、リソースは再割り当てされます。最初の2回の会議では、いつ配信されるのかわからず、「3か月以内に」あいまいになりました。これに戸惑い、戦略を変え、各会議の前に最新で正確なガントチャートを作成したことを確信させました。

副作用として、これは私のプロジェクトをより良く整理し、より効率的にし、私のチームメンバーの意欲を高めました。

プロジェクトプランニングを現在のように人気のないものにすることで、ガントを追跡することほど功績はありません。ガントの追跡は、有害と見なされるだけでなく、悪と見なされるべきです。その理由は次のとおりです。

理由その1：動機

追跡ガントを使用すると、計画の各ステップについて、どのくらいの時間がかかるか、実際にどれくらいかかるかを確認できます。フェーズXは3月までに開始されるはずであったことを毎日、またステータスミーティングで知ることができますが、明らかに5月までは開始されません。驚くばかり。最初の計画を立てたときに、プロジェクトの進行に合わせて計画を変更する必要があることを既に知っていました。新しい情報が明らかになります。人やリソースは予測不能などです。では、なぜ、すべてのステータスミーティングで、実生活での初期の予測がいかに貧弱であるかを常に思い出させることが重要なのはなぜですか。

理由＃2：元の計画に固執する

プロジェクトのガントチャートを追跡するというアイデアは、新しい情報に基づいて作業計画を絶えず調整することに焦点を当てるのではなく、指を指して予測ミスを強調できるため、古い計画に固執することを選択することを意味しますプロジェクトの初期計画段階に伴う膨大な不確実性の必然的な結果。結局、計画を根本的に変更することを許可すると、ガントを追跡できなくなりますか？それは同じ一般的な形を持ち、同じステップで構成されている必要があります。さもなければ、追跡するものはありません...計画に固執することは、最近「ウォーターフォール」が実際に軽term的な用語と見なされる最大の理由です。事前の計画は、元の計画に固執することと混同されます。

理由その3：彼らは何も教えない

あなたが計画しているプロジェクトが予測可能に似ていて反復的でない限り、このプロジェクトの遅れが実際にあなたが次のプロジェクトを計画する方法を変えるつもりではない。結局のところ、それはガントが最初に使用されたものです-タスクが非常に明確に定義され、その期間が非常に予測可能な工場の生産ラインで作業を計画します。

追跡によってソフトウェア開発のガントチャートに追加される値はゼロです。おそらくゼロ未満です。過去の見積りは新しいプロジェクトに無関係であるだけでなく、後から振り返って見積能力を実際に向上させることができるという幻想は危険です。確かに、CSの学生は、実際の生活で統合に多くの時間がかかることを本当に知らないかもしれません。しかし、生涯に2つ以上のプロジェクトに携わってきた人は誰でも、プロジェクトの遅延の通常の容疑者をすでによく知っています。プロジェクトが遅れる本当の理由は、一般的な推定に適用する必要のある数学的エラー要因ではありません。それは、初めて何かをすることと、それがどのようにパンアウトするかを正確に知らないことに伴う固有の不確実性です。

実際、この見当違いの角度から問題を攻撃しようとするプロジェクト管理システムがあります。彼らはあなたの予測対実際のパフォーマンスを測定し、統計分析を使用して全体的な推定を修正しようとします。「ダニーは常にすべてを14.3％過小評価している」かのようです。ダニーは愚かではなく、彼の予測のエラーが予測可能であると仮定することは確かにばかげています。それは、原始的な「治癒」-推定に要因を追加する-と問題の原因を混同します。「正しい」係数が乗算されていないため、推定は不正確ではありません。あなたの計画は単に不完全です。すべての計画は独自の方法で不完全です。

理由その4：彼らはあなたの注意を間違ったものに集中させます

時間通りに納品するために何をする必要があるかに焦点を当てる代わりに、不正確な予測を正当化することに焦点を合わせています。より詳細な計画に焦点を合わせ、計画を新しい情報に適応させるのではなく、時代遅れの計画を再作成します。作業計画の部分が誤って推定されたため、プロジェクトが遅れることはほとんどありません。物事のがらくたが元の計画から単に残されたため、彼らは遅れています。追跡ガントはこれをさらに悪化させます。なぜなら、すべてのステータス会議で貧弱な見積もりとして強調されてしまう場合、計画に詳細を挿入する必要があるのはどのような動機ですか？これにより、ガントチャートの追跡可能な大量の作業に専念できます。適応に集中して正しい軌道に乗せるのではなく、

また、十分に精巧な計画を管理するのに十分なツールがないという問題もあります。ツールを使用すると、途中で頻繁に無視されるすべての手順を公開できる場合は、適切な初期計画（および推定）を構築する可能性がはるかに高くなります。従来のガントは、開発者がプロ​​ジェクト管理の現実の似顔絵として正当に見ている低解像度の獣です。必要なのは、できるだけ早い段階で作業計画にできるだけ多くの情報を簡単に追加し、不確実性の霧がプロジェクトから徐々に消えていくのと同じくらい簡単に計画を調整できるツールです。あなたが必要とする最後のものは、不正確な過去の予測の絶え間ない低解像度のリマインダーです。ガントの追跡は、物事を成し遂げるためではなく、指を向けてロバを覆うのに適しています。

ガントチャートソフトウェアにより、複雑な相互依存関係を分析し、オーバーランと遅延の影響を予測できます。

ただし、ほとんどのソフトウェアプロジェクトでは、相互依存関係と外部入力がほとんどないため、予測の鍵は、ソフトウェアチームが3週間かかると言ったときに使用する適切な乗数を知ることです。

他の人が言ったように、ガントチャート（一般に非公式にプロジェクト計画と呼ばれる）はタスクとそれらのタスク間の相互依存関係をマッピングする方法であり、目的はプロジェクトの最小合計経過時間を確立することです。

管理の観点から見ると、重要な出力はクリティカルパスの識別、つまり、タスクが遅れるとプロジェクトが遅れるタスクのリストです。

非常に簡単な例-2人のプログラマが3つのタスクでプロジェクトに取り組んでいるとしましょう（コードモジュールAは1人のプログラマが10日かかり、コードモジュールBは1人のプログラマが5日かかり、aとbは両方のプログラマが2日かかります）。最初の2つのタスク（コーディングモジュールAとB）は並行して処理され、3つのタスクすべてを完了することを目的としているため、プロジェクトはすべて12日間で完了します。

この場合、クリティカルパスはモジュールAをコーディングしてから統合テストを行います。モジュールBのコーディングは、実際に5日遅れて（または5日オーバーラン）開始できます。時間どおりに終了したとしても、モジュールAのコーディングにはさらに時間がかかります。一方、コーディングモジュールAまたは統合テストがいつでもスリップした場合、プロジェクト全体がスリップします。

この種のことを知ることは、リソースを展開する方法と、特定のタスクの遅延がプロジェクト全体に影響を与える可能性があるかどうかを理解するのに役立ちます。

彼らは便利ですか？明らかにはい。ただし、重要な注意事項が1つあります。それらに入力される情報が適切である場合に限ります。つまり、

• タスクリストが完成しました
• 見積もりは正確です
• タスク間の依存関係は包括的であり、
• チームを代表し、タスクに正しくマップされたリソース。

そして、そこからチームはチャートに取り組んで適切な順序でタスクを実行する必要があります（割り当てられたタスクが何か/他の誰かを遅延させる可能性があるため、より興味深いことはしません）。

すべてを実行したら、はい、それは本当にあなたを助けることができますが、正確かつ現実的であることを保証するために作業を前もって行わなければなりません。

ガントチャートが大好きで、Macがそれらを作成するためのより良いソフトウェアの選択肢があれば、私はそれらを常に使用します。

依存関係を確認するのは大変です。「プロジェクトのデータバックフィル部分を完了させないと、whatsitの機能強化の構築を開始できません。」

プロジェクトがソフトウェア開発プロジェクトである場合、ガントチャートはあまり役に立たず、ほとんど時間の無駄になります。ソフトウェア開発の流動的な性質のために設計されていません。

• 通常、タスクは順序に依存しません。それらは任意の順序で実行できます。
• タスクの順序により、タスクの完了に必要な時間が変わる場合があります。
• タスクは、バグなどの他のタスクを生成できます

要するに、作業を行うよりも計画の更新に多くの時間を費やすことになります。

要件を管理するだけで、他のすべてが自動的に処理されます。

YMMV