我喜欢规划，但我讨厌规划软件。这真是一个有趣的问题。 当我独自工作时，我倾向于概述项目，评估每个部分，然后就完成了。我的评估往往很准确，项目也能完成。

但是，那只是我编写代码或修理汽车的情况。“Geek Ranch”不仅仅是我一个人在做一个项目。 今天是四个人，但在接下来的几个月里，可能会有 20 个人一起工作，并且有很多外部依赖。 这不是我可以随便写写就能搞定的事情。

让我举个例子。我们需要将电力引入建筑工地。我们被告知，电力公司 Union Finosa 在看到“施工迹象”之前不会连接任何东西。这似乎很合理。好消息是，我们要建造的第一栋建筑是一栋辅助建筑。它将容纳备用发电机、一些电池、逆变器，并在大型施工和运营期间提供一些存储空间。

因此，显而易见的答案是开始建造公用设施建筑。为此，我们需要将材料运到那里，制定计划并组建施工队。由于我们希望尽可能地并行进行，我们希望公用设施已订购（它们已经订购了，但似乎我们必须再次进行一番周旋），以便在我们等待其他一切就绪时可以安装电线杆。

但是，道路已经损坏了。因此，在我们可以运入建筑材料之前，我们首先需要铺设一些 vados（那是一种水泥“凹陷”，以便水可以穿过道路而不会破坏它）。我的商业伙伴 Gixia 在 11 月安排了道路维修。或者，更准确地说，她以为她安排好了。但是，那个本来要去做这件事的人消失了。

我可以继续说下去，但你明白我的意思了。这里涉及很多人、很多资源、提前期和相互依赖关系。不幸的是，这需要项目管理软件。所以，我又开始寻找“正确的答案”了。（在此，感谢那些回复了我的上一篇文章，并提供了一些建议的人。）

这不是我第一次寻找项目管理软件。事实上，大约 10 年前，我就看过一些基于 Windoze 的软件，包括 Microsoft Project。当时，我完全震惊于 Microsoft Project 不允许你在项目之间共享资源。我最终选择了一些其他软件包，它们可以满足我们的需求——但它是在一台没有连接任何东西的 Windoze 机器上运行的。很快就明显看出，这种单机解决方案不是答案。我们升级到一块大白板，人们去洗手间时会看到它。那效果好多了。

白板的例子比你想象的更重要。我发现任何项目管理系统中最难的部分是让它真正被使用起来。如果我们认为每个人都可以访问的基于 GUI 的系统是常态，那么我描述的基于 Windoze 的系统位于可访问性频谱的一端，而白板则位于另一端。因此，诀窍是在不牺牲太多可访问性的情况下获得有用的功能。由于我不会是唯一的用户，所以这个决定不仅仅是“什么吸引了技术人员”。

我的考虑

第一个是 PHProjekt。我以前用过它，发现它功能非常强大。我特别喜欢的是你可以将笔记和论坛（以及更多内容）与项目关联起来。 话虽如此，虽然它似乎非常适合一群技术人员从事软件项目，但很明显它不具备团队所需的可访问性，因为团队中会包括一些只具备“用户”计算机技能且母语不是英语的人。请注意，PHProject 能够处理多种语言，因此英语方面的评论反映的是团队，而不是软件本身。

接下来是 TaskJuggler。它最初主要是一个报告系统，你使用文本编辑器构建任务信息。虽然这对我很有吸引力，但显然这不是这个项目需要的。 如今，TaskJuggler 提供了更多基于 GUI 的界面。你仍然需要将文本输入到文件中，但 GUI 会处理将你引导到正确的文件。对于技术人员来说，这非常不错。对于非技术人员来说，这可能会令人 раздражать，但还是可用的。

因此，这是一个严肃的选择。缺点是它没有像 PHProject 那样提供将“其他信息”集成到项目中的方法。此外，在测试中，我设法创建了一些 TaskJuggler 告诉我这是“不可能的依赖关系”的东西，但我就是看不出它是什么。

Projity 的 OpenProj 自称是 Microsoft Project 的替代品。我已经很久没有看过 Microsoft Project 了，但是当我再次看的时候，它非常没用。好吧，OpenProj 让我回忆起我为什么会产生这种看法。唉。

我快速浏览了一下 jxProject。之所以快速浏览，是因为虽然它几乎是免费的，但它不是开源的。价格并没有让我担心，但我只是不需要一个在需要时我无法修复的软件。又从列表中划掉一个。

我想特别提及一下 Trac。它是我理想中的优秀软件，不会妨碍你的工作。它使用 Wiki 来存储“其他信息”，并添加了 Subversion 的接口。它非常适合软件项目管理，但显然不是构建 Geek Ranches 的工具。

在我们跑题的时候，看看 Timeline。来自他们的网站

Timeline 是一个基于 DHTML 的 AJAX 小部件，用于可视化基于时间的事件。它就像是基于时间信息的 Google 地图。

Timeline 不会安排项目，但它可能在查看日程安排时很有用。而且，嗯，它非常酷。

回到正题，接下来我看了 Gnome 项目的 Planner。它还远未完成，并且缺乏用户文档，但它似乎是通用项目管理所需功能的一个良好开端。缺点是没有办法将“其他东西”附加到正在进行的事情上。

既然我给了 Gnome 一个机会，我想我也必须看看 KDE 世界提供了什么。好吧，答案是 KOffice 项目的 KPlato。不幸的是，我认为网页上的第一句话几乎概括了情况。

KPlato 是一个项目管理应用程序。在这个首次公开发布的版本中，我们专注于项目的规划和调度。

让我们就说，下次我寻找正确答案时，还有另一个可能的选择。

最后，我（再次）看了 dotproject。它实际上是一个非常不错的系统，具有很多功能。 优点是它支持将文件与项目关联起来。我的感觉是 dotProject 可以满足我们的需求。

那么，为什么犹豫呢？嗯，这是一个庞大的系统。我预见到自己会设置好一切，然后成为那个还必须更新一切的人。因此，项目管理为其他人实现了自动化，但代价是我的时间。

请允许我承认，我在再次开始使用 dotProject 之前就说了上面那句话。我尝试在其中输入一些信息。我喜欢它。它包括论坛和很多不错的东西。不幸的是，我做了一个错误的假设——项目可以有子项目。我首先输入了一些子项目（修理道路、接入公用设施、建造主楼等）来试用一下。然后我想创建一个它们都属于的项目，名为“第一阶段”。没门。

这并不意味着我会放弃 dotProject，但这确实意味着我需要稍微考虑一下结构。任务可以有子任务，因此显然“第一阶段”需要成为项目，而我所想的所有子项目都变成任务。由于任务可以有子任务，这应该可行。让我们看看。

接下来怎么办？

可怕的是，无论我想管理什么类型的项目以及我看中了哪些软件选择，通常我都只能到这一步。也许这只是我的态度问题——我想开始工作，而不是把计划变成一项事业。

到目前为止，我们一直使用 Wiki 来存储有关项目的所有信息。Wiki 中的几乎所有内容都是我放在那里/由我更新的。这很好地表明，项目管理信息的情况也将如此——无论我如何或在哪里存储它。

这让我得出一个奇怪的，希望是暂时的结论。我打算在 Wiki 中写更多东西。具体来说，我将创建一个专门用于各种子项目的版块。在这些页面中，我将添加任务依赖于什么、谁将参与其中、需要什么样的时间等等。换句话说，一个包含子项目资源需求的项目计划。

我希望，至少对于大多数任务而言，这个 Wiki 描述加上开始日期就足够了。这并不意味着不需要总体项目进度表，但尽管这听起来可能令人沮丧，我们浴室附近确实有空间放一块大白板。

如果白板的想法变得不切实际，我将再次考虑 TaskJuggler、DotProject 和 Planner。它们似乎可以在没有太多启动开销的情况下取代白板。