project-management - 比单页大的甘特图有用吗？

Question

我参与过一些使用甘特图管理的项目。其中一些有大量的任务，项目经理把所有的时间都花在与 MS Project 搏斗上，而不是做出好的选择。

如果有多个独立的团队致力于某件事（例如法律、IT、营销）来管理一个项目，我可以理解这一点。

有没有人参与过成功使用甘特图的软件开发项目？

Answer 1

使用 MS Project 对软件开发项目进行微观管理是人们可以做的最愚蠢的事情之一，尤其是在敏捷环境中。太多的事情花费了你预测的 1/10 或 10 倍的时间，太多的事情超出了预期，太多的项目计划会议占用了有用的工作时间。

此外，甘特图的奴隶是很常见的事情，尤其是对于来自不同学科的项目经理。

但是，它们对于确保在特定期限内完成操作（设置 XYZ 帐户、获得合规性以检查网站上的措辞等）很有用。编程任务的粗粒度截止日期也很好。

在我看来，我确信有些人从微观管理编程团队中取得了成功。

Answer 2

我们在项目规划中总是使用甘特图。它们总是有用的——在一切都说完之后，甘特图是可视化项目的最佳工具之一。

然而，它是一种工具。如果工具使用得当，它是有效的。如果不是，它可能会适得其反。

您需要知道如何正确规划您的项目。您需要了解任务列表中应包含哪些内容以及如何包含在内。例如，对于一个 IT 项目，它几乎总是无用的，深入到单个分配的级别（使用数据创建一个存储表）。将其保留在故事级别（允许用户登录），将整个团队分配给它，计划将变得更加容易。

稍后，您可以随时进入单个任务级别，并且可以创建单独的项目计划来处理单独任务的分配。

Answer 3

是的，我已经看到它成功了。在成功的情况下，他们使用了分层方法。

与其拥有一个包含数百个任务的大型甘特图，不如为整个项目提供一个带有顶级目标的主图。然后有单独的图表来完成子目标。尽管这以一种方式限制了灵活性（您不能自动平衡子目标团队之间的资源），但它似乎更适合人类运作良好的方式：在中小型团队中。

Answer 4

我不是专业的项目经理，但我为复杂的程序分析工具运行开发项目。

我在 70 年代后期绘制了页面大小的甘特图。他们从来没有足够的细节，所以我放弃了。有 5 个任务的甘特图是没用的。

从 90 年代开始，我在大约 10 个实际项目中使用了 MS 项目，这些项目的长度为 6 到 12 个月，任务大约为 1 周，并且将 50 到 250 个任务组织成与软件架构元素相关的层次结构，团队为 5 -10 人。此类计划打印为 3 x 5 整页的网格，我们倾向于将其粘贴在可以看到的墙上。

这些对于计划目的非常有用，因为它们迫使您详细说明项目的主要活动，写下描述，排序和优先级。团队可以查看任务，查看哪些是他们的，您可以与团队成员一起查看，以便每个人都可以提供有关持续时间和任务顺序的有用反馈。

他们没有用的是认真跟踪项目进度。孙子告诉我们，没有任何计划能在战场上完好无损，甘特图也不例外。确实，只要小心，人们可以每隔几周仔细修改计划并标记所取得的进展。“真正的项目经理”可能已经这样做了。我们非常小心，以至于最初的计划任务在大约一半的项目中得到了很好的支持，到那时人们已经很好地理解了这个问题，并且进行了额外的重新计划，但非正式地而不是 MS 项目。

我还使用 MS Project 计划了许多类似的任务，以用于严重的时间和估计目的。这具有产生现实估计的不幸副作用，其中大部分成本是可见的。令人惊讶的是，现实的估计如何扼杀了项目提案。行业似乎希望严重低估启动项目；难怪这么多超支时间和预算。

我对 MS 项目本身又爱又恨。它需要任务描述、任务优先级和资源分配。但我不能说，“我更喜欢这个任务比那个任务先完成”，这会作为一个可选的任务优先级来询问，我不能将资源部分分配给一个任务，部分分配给另一个任务，并获得任何合理的时间表。

But for complex project estimation, I don't see how you can live without this. The agile people will tell you you can't plan; I don't know who they have as customers. I've never found a customer that was willing to let me work without a plan or a dollar/time budget he would hold me to.

Answer 5

比单页还小的甘特图有用吗？这些小信息可以很容易地放在白板或便利贴或任何你一直在看的东西上。当您可以在一分钟内用铅笔在您拥有的任何纸张上指定必要的信息时，您没有任何理由开始使用任何 GANNT 工具。

Answer 6

我参与过一个项目，其中使用甘特图/MS 项目文件成功管理该项目。项目信息由非开发人员经理维护，他单独与团队会面以获取状态更新。该系统似乎运行良好，甘特图为整个团队提供了快速查看状态。在与我的一位在使用这种方法的公司工作的朋友交谈时，这似乎对他们的团队非常有效。

在我参与过的其他项目中，开发负责人预计会维护图表，但没有成功。领导通常会花费额外的时间与 MS Project 搏斗。如果文化专注于惩罚进度延误而不是解决问题，那么甘特图可以很容易地被操纵以显示项目在交付日期之前按计划进行。在这些情况下，甘特图变成了一项额外的工作，对项目没有任何价值。

我认为关键是要让开发团队之外的人来更新 MS Project 文件。甘特图应该被视为一种工具，用于就项目状态、可能的进度延误问题和资源需求计划进行沟通。有了这些项目，甘特图会很有帮助。

Answer 7

我发现甘特图对于规划项目的时间线并允许 X 天的假期、延误等非常有用。它们也非常适合确保在整个项目中 100% 分配所有资源。

在实际工作时，作为开发人员和团队负责人，我发现最好在短迭代中工作，并为整个团队定义明确的任务。当事情滑落、变化或从项目中添加/删除人员时，能够调整甘特图并查看项目更改的结果非常好。

Answer 8

我参与了几个使用甘特图的项目。是的，它们很有用，是的，它们比一页还大。我们所做的是将图表剪切并粘贴（字面意思是用剪刀和胶水）成一张大图表，然后贴在墙上。

McConnell 在他出色的软件项目生存指南中建议让团队的每个成员都可以查看一些东西，以粗略了解他们是否走上正轨，这就是为我们准备的。

Answer 9

我完全同意关于甘特图不适合敏捷开发的评论——我们一开始对实施的细节没有清晰的了解。

另一方面，我不禁深情地记得一个痛苦的周末，我为我正在管理的一个项目整理了一张甘特图，该项目的技术和要求都非常了解，而且时间表很关键。

我们的隔间部分的入口墙部分覆盖了这张甘特图（5 A4 页宽），并且它对于确保我们正在朝着关键路径工作非常有用 - 完成需要立即完成的事情- 并且还使我能够向项目委员会报告项目如何按计划进展的详细报告。

甘特图的用处绝对取决于上下文，但我想说，如果您知道自己的要求，特别是如果您非常重视您的日程安排，它们可能会非常有用。

Answer 10

我不是甘特图的忠实粉丝，尤其是在 MS Project 中创建的甘特图 - 如此少的信息占用了如此多的页面空间，并且最多（像大多数图表一样）信息被扭曲或隐藏。如果甘特图帮助团队审查需要什么，谁被分配到什么任务，哪些任务正在下滑，风险在哪里 - 那么它很有用 - 然而 - 大多数甘特图是在项目开始时开发的，然后从未见过或再次使用。那么，回到最初的问题——尺寸重要吗？？？？引用最近的一本书 -如果它很愚蠢并且有效，那么它并不愚蠢

Answer 11

甘特图只有在项目经理有足够的详细信息来查看项目的状态以及正确考虑依赖关系和资源时才有用。

你总是可以用胶带把几张纸粘在一起。

分析项目的纪律——将项目分解为阶段、步骤、可交付成果、确定资源需求可能比打印出漂亮的图表更重要。

我的许多重要的开发项目都受益于项目规划工具的合理使用。

Answer 12

是的，我已经看到它成功了。在成功的情况下，他们使用了分层方法。

...

绝对地。我还建议当层次结构也映射到团队层次结构时效果最好，例如项目经理创建高级图表，团队负责人管理中级图表，开发人员可能管理他们自己的甘特图，但更有可能使用 JIRA 之类的东西，因为从开发人员的角度来看，这提供了一个单一的焦点，并且通常更容易接受（即它看起来不像一个计划，所以不会吓到他们；））

Answer 13

MSProject 中甘特图的最佳用途是在项目的初期阶段进行容量规划。您可以进行广泛的刷机计划和假设，移动东西，移动人员，添加各种里程碑等。这可以让您确信自己正在制定合理的计划。

但是，如前所述，在日常跟踪人们实际必须做的无数小任务时使用它是自找麻烦。我曾经在这个微观层面管理时间尺度方面发挥了巨大作用的是Fogbugz 的EBS 东西。你必须努力工作，但它确实有助于处理事情。

重复总结 - 甘特图非常适合开发软件计划，但不适用于日常详细更新。

至于页面问题，我做过的大多数效果最好的计划（即以可以理解的详细程度将计划传达给人们）可以制作成适合 A3 打印输出。偶尔几张A3纸。但根据我的经验，A4 在大多数情况下都太小了。