project-management - ガントチャートは1ページよりも大きいので便利ですか？

Question

私はガントチャートを使用して管理されるいくつかのプロジェクトに取り組んできました。これらの中には膨大な数のタスクがあり、プロジェクトマネージャーは適切な選択をする代わりにMSProjectと格闘することにすべての時間を費やしています。

プロジェクト全体を管理するために何か（たとえば、法務、IT、マーケティング）に取り組んでいる複数の別々のチームがある場合、私はポイントを見ることができます。

ガントチャートを使用して成功したソフトウェア開発プロジェクトに参加した人はいますか？

score 8 · Accepted Answer

MS Projectを使用したソフトウェア開発プロジェクトのマイクロ管理は、特にアジャイル環境で誰かができる最も愚かなことの1つです。予測した時間の1/10または10倍の時間がかかりすぎるもの、オーバーランするものが多すぎる、プロジェクト計画会議が多すぎると、有用な作業時間が消費されます。

さらに、ガントチャートの奴隷になることは、特にさまざまな分野のプロジェクトマネージャーにとって、非常に一般的なことです。

ただし、アクション（XYZの設定でアカウントを取得する、Webサイトの文言をチェックするためのコンプライアンスを取得するなど）が特定の期限までに完了するようにするために役立ちます。プログラミングタスクのきめ細かい締め切りも問題ありません。

私の意見では、プログラミングチームをマイクロマネジメントすることで成功した結果を出した人がいると確信しています。

score 5 · Accepted Answer

プロジェクトの計画では、常にガントチャートを使用します。それらは常に便利です-すべてが言われ、実行された後、ガントチャートはプロジェクトを視覚化するための最良のツールの1つです。

ただし、これはツールです。ツールが適切に使用されている場合、それは効果的です。そうでない場合は、逆効果になる可能性があります。

プロジェクトを適切に計画する方法を知る必要があります。タスクのリストに何を含めるべきか、そしてどのように含めるべきかを理解する必要があります。たとえば、ITプロジェクトの場合、個々の割り当てのレベルまで下げることはほとんどの場合役に立ちません（データを使用して保存するためのテーブルを作成します）。ストーリーレベルに保ち（ユーザーがログインできるようにします）、チーム全体をそれに割り当てます。そうすれば、計画がはるかに簡単になります。

後で、いつでも個々のタスクレベルに移動し、別のプロジェクト計画を作成して、別のタスクの割り当てを処理することができます。

score 4 · Accepted Answer

はい、私はそれが成功するのを見ました。それが成功した場合、彼らは階層的アプローチを使用しました。

何百ものタスクを含む単一の大規模なガントチャートではなく、プロジェクト全体のマスターチャートがあり、トップレベルの目標がありました。次に、サブゴールの達成のための別々のチャートがありました。これにより、柔軟性が1つの方法で制限されますが（サブゴールチーム間でリソースのバランスを自動的にとることはできません）、小規模または中規模のチームでの人間の操作方法によく一致するようです。

score 3 · Accepted Answer

私はプロジェクトマネージャープロフェッショナルではありませんが、複雑なプログラム分析ツールの開発プロジェクトを実行しています。

70 年代後半に、ページサイズのガントチャートを作成しました。彼らは十分な詳細を持っていなかったので、私はそれをあきらめました. タスクが 5 つのガントチャートは役に立ちません。

90 年代から、私は 6 ～ 12 か月の実際のプロジェクトを 10 件ほど実行し、約 1 週間のサイズのタスクと、ソフトウェアアーキテクチャ要素に関連する階層に編成された 50 ～ 250 のタスクを 5 人のチームで MS プロジェクトを使用してきました。 -10人。そのような計画は、3 x 5 のフルページのグリッドとして印刷され、これを見えるように壁に貼り付ける傾向がありました。

これらは、プロジェクトの主要な活動を詳細に説明し、説明を書き留め、順序を決め、優先順位を付ける必要があるため、計画目的には最適です。チームはタスクを見て、どのタスクが自分のものかを確認できます。また、チームメンバーと一緒にレビューして、全員が期間とタスクの順序について有用なフィードバックを提供できるようにすることができます。

それらが役に立たなかったのは、プロジェクトの進行状況を真剣に追跡することでした. 孫子は、戦場で無傷で生き残る計画はなく、ガントチャートも例外ではないと語っています。確かに、注意を払って、数週間ごとに計画を注意深く修正し、進捗状況を記録することができます。「本物のプロジェクトマネージャー」ならそうするかもしれません。元の計画のタスクがプロジェクトの約半分までかなりうまく持ちこたえられるように、私たちは十分に注意を払いました。その時までに、人々は問題をかなりよく理解し、追加の再計画が行われましたが、MS プロジェクトではなく、非公式に行われました。

また、MS Project を使用して、重要な時間と見積もりの目的で、多くの同様のタスクを計画しました。これには、ほとんどのコストを可視化して現実的な見積もりを作成するという不幸な副作用があります。現実的な見積もりがプロジェクトの提案を台無しにしてしまうのは驚くべきことです。産業界は、プロジェクトを開始するために悪い過小評価を望んでいるようです。多くの時間と予算を超過するのも不思議ではありません。

私はMSプロジェクト自体と愛憎関係にあります。タスクの説明、タスクの優先順位、およびリソースの割り当てが必要です。しかし、オプションのタスクの優先順位として尋ねる「そのタスクよりもこのタスクを最初に完了することを好む」とは言えません。

しかし、複雑なプロジェクトの見積もりでは、これなしでは生きていけないと思います。アジャイルな人々は、あなたは計画を立てることができないと言うでしょう。彼らが誰を顧客として持っているかはわかりません。計画やお金/時間の予算がなくても、喜んで仕事をさせてくれる顧客を見つけたことがありません。

score 2 · Accepted Answer

また、ガントチャートは1ページよりも小さいので便利ですか？その小さな情報は、ホワイトボードやポストイット、またはあなたが常に目にしているものなら何でも簡単に置くことができます。持っている紙に鉛筆で必要な情報を1分で指定できるのに、ガントツールと格闘し始める必要がある理由は実際にはありません。

score 2 · Accepted Answer

私は、ガントチャート/MSプロジェクトファイルを使用してプロジェクトを正常に管理した1つのプロジェクトに取り組んできました。プロジェクト情報は、ステータスの更新を取得するためにチームと個別に会った開発者以外のマネージャーによって維持されていました。このシステムはかなりうまく機能しているようで、ガントチャートはチーム全体のステータスをすばやく確認するのに役立ちました。そして、このアプローチを使用している会社で働いている私の友人と話すことで、それは彼らのチームにとって非常にうまくいくようです。

開発リーダーがチャートを維持することが期待される他のプロジェクトでは、成功していません。リードは通常、MSProjectと格闘するために余分な時間を費やします。また、文化が問題の解決ではなくスケジュールの遅延を罰することに重点を置いている場合は、ガントチャートを簡単に操作して、納期までスケジュールどおりにプロジェクトを表示できます。そのような場合、ガントチャートは、プロジェクトに価値をもたらさない余分な作業になります。

重要なのは、MSProjectファイルを更新する開発チームの外部の人がいることだと思います。また、ガントチャートは、プロジェクトのステータス、スケジュールの遅延で発生する可能性のある問題、およびリソースのニーズの計画に関するコミュニケーションに使用するツールと見なす必要があります。これらのアイテムを配置すると、ガントチャートが役立ちます。

score 1 · Accepted Answer

私はガントチャートを使用したいくつかのプロジェクトに取り組んできました。はい、それらは便利でした、そしてはい、それらはページより大きかったです。私たちが行ったのは、チャートを1つの大きなチャートにカットアンドペーストし（文字通り、はさみと接着剤で）、壁に貼り付けることでした。

McConnellは、優れたSoftware Project Survival Guideで、チームのすべてのメンバーが順調に進んでいるかどうかを大まかに把握できるものを用意することを推奨しています。これが私たちにとっての目的でした。

score 1 · Accepted Answer

私はガントチャート、特にMS Projectで作成されたチャートの大ファンではありません。非常に少ない情報のために多くのページスペースが使用され、多くても（ほとんどのグラフのように）情報が歪んだり隠されたりします。ガントチャートが、チームが必要なもの、誰がどのタスクに割り当てられているか、どのタスクがスリップしているのか、リスクがどこにあるのかを確認するのに役立つ場合、それは便利ですが、ほとんどのガントチャートはプロジェクトの開始時に作成され、その後は表示されません。または再度使用します。では、元の質問に戻りましょう-サイズは重要ですか???? 最近の本から引用する-それが愚かでうまくいくなら、それは愚かではない

score 1 · Accepted Answer

ガントチャートは、プロジェクトのタイムラインを計画し、X日間の休暇やずれなどを考慮に入れるのに役立つことがわかりました。また、プロジェクト全体ですべてのリソースが100％割り当てられていることを確認するのにも役立ちます。

開発者とチームリーダーの両方として実際にプロジェクトに取り組んでいるとき、チーム全体に明確なタスクを定義して、短い反復で作業するのが最善であることがわかりました。物事がずれたり、変化したり、プロジェクトから人が追加/削除されたりすると、ガントチャートを調整して、プロジェクトの変更の結果を確認できるのは素晴らしいことです。

score 1 · Accepted Answer

GANTT チャートがアジャイル開発に適していないというコメントに心から同意します。

一方で、私が管理していたプロジェクトのガントチャートをまとめるのに費やした苦痛な週末を懐かしく思い出さずにはいられません。そこでは、テクノロジと要件が非常によく理解され、スケジュールが重要でした。

キュービクルセクションの入り口の壁は、このガントチャート (幅 5 A4 ページ) で部分的に覆われていました。これは、クリティカルパスに取り組んでいることを確認するのに非常に役立ちました。 - また、プロジェクトがスケジュールに対してどのように進んでいるかについて、詳細なレポートをプロジェクト委員会に報告することができました。

ガントチャートの有用性は状況によって異なりますが、要件がわかっている場合、特にスケジュールが重要である場合は、非常に役立つと思います。

score 0 · Accepted Answer

ガントチャートは、プロジェクトマネージャーがプロジェクトのステータスを確認し、依存関係とリソースを適切に説明するのに十分な詳細がある場合にのみ役立ちます。

いつでも粘着テープで何枚か貼り付けることができます。

プロジェクトを分析する規律-プロジェクトをフェーズ、ステップ、成果物に分解し、リソース要件を決定することは、きれいなチャートを印刷するよりもおそらくさらに重要です。

私の重要な開発プロジェクトの多くは、プロジェクト計画ツールの賢明な使用から恩恵を受けています。

score 0 · Accepted Answer

はい、私はそれが成功したのを見てきました。それが成功した場合、彼らは階層的アプローチを使用しました。

...

絶対。また、階層がチーム階層にもマッピングされている場合に最適に機能することをお勧めします。たとえば、プロジェクトマネージャーが上位レベルのチャートを作成し、チームリードが中間レベルのチャートを管理し、開発者が独自のガントチャートを管理する可能性がありますが、JIRA などを使用する可能性が高くなります。、これは開発者の観点から単一の焦点を提供し、通常はより見栄えがするためです (つまり、計画のようには見えないため、開発者を怖がらせません;))

score 0 · Accepted Answer

私が MSProject のガントチャートを最もよく利用したのは、プロジェクトの初期段階でのキャパシティプランニングです。大雑把なスケジュール設定、what-if、物事の移動、人の移動、さまざまなマイルストーンの追加などを行うことができます。これにより、合理的な計画を立てているという自信が得られます。

しかし、その後、人々が実際に行わなければならない無数の小さなタスクを毎日追跡するためにそれを使用すると、前述のように、トラブルを求めます. このミクロレベルでタイムスケールを管理するために私が大きな効果を上げてきたのは、Fogbugz のEBS のものです。あなたはそれに取り組む必要がありますが、それは物事を処理し続けるのに本当に役立ちます.

要約すると、ガントはソフトウェア計画の作成には適していますが、日々の詳細な更新には適していません。

ページの質問に関しては、私が行った最も効果的な計画 (つまり、理解できる詳細レベルで計画を人々に伝えた) のほとんどは、A3 の印刷物に収まるように作成できます。たまにA3ページ数枚。しかし、私の経験では、ほとんどの場合、A4 は単に小さすぎます。

project-management - ガントチャートは1ページよりも大きいので便利ですか？

13 に答える 13

Related

Reference