conceptdraw是一个非常不错的项目管理策划分析与报告工具。其强项是图形报告功能，非常的出色。这里要说明的是，conceptdraw是做不出那种P3E/C才有的专业化数据报告，而是很漂亮的图形风格的报告，如饼图、状态图、仪表图等等。相比较而言，P3E/C的报告专业、翔实，图形功能也非常出色，比较适合做纸质的专业项目报告；conceptdraw更加适合PPT演示或者概念性展示的电子文档格式的项目报告（这是个人的体会）。

需要了解详情的可以直接去官网，我就个人感兴趣的功能做一个介绍：

mindmap to project plan

这个功能很有与时俱进的味道，他是一种mindmap（思维导图）与project plan（进度计划）双向转换的工具。即：你可以使用思维导图工具进行的项目策划与分析，并且将这一分析结果转换为项目计划。

至于这个功能有多大使用价值就看你对这两种工具的掌握与使用程度了，比如在项目实施阶段，思维导图模式的计划图或许会给你一种系统性思维的方法。

导出WBS

导出为WBS是一个“时髦”的功能了，很多PM工具软件都已经默认地提供这一功能。conceptdraw的这一功能好就好在采取了微软的方式：将WBS做成可编辑的“流程图”（参见WBS建模工具）类似于visio的编辑环境、良好的WBS模板和靓丽的效果会让善于展示作品的人心动的。

不过对我来说，WBS导出功能有一个很大的问题：基本上这是一个“任务分解结构”导出模板，而不是工作分解结构的导出模板。

图片报告

非常漂亮图片报告，这个就不需要文字介绍了，直接上图片吧：

（需要说明的是，我没有对图片中的项目信息进行必要的设置，因此报告图片缺乏必要的细节）

这些图片可以做成PDF格式、HTML格式、各类图像格式、SWF动画格式、PPT格式以及XML格式等等……

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

误解一：可交付成果就是“工程”

工程领域中，项目产品的不确定性没有超出合同双方的经验范围。所以建筑工程承包商可以闭着眼睛告诉客户他们建造的项目产品大体上是什么，客户也基本认可这个大体的范围，即便在细节问题上会有自己的要求（在物理构成上建筑物有97％的共性）。因此，工程领域向来有范例式的WBS构建方法。而这个范例就是工程领域的“定额编码体系”，在建筑领域就是（工程量清单），这种编码体系本身就容易被误解为项目的完整WBS。关于这一点我们稍后讨论。这里仅仅说说其分解特点，“定额编码体系”（工程量清单）的特点就是以可交付成果为导向的分解体系，其大部分分解节点都是以名词为主的（例如钢筋工程，钢筋、预制构件、钢筋笼），即可交付成果通常被理解为有形的工程实体。

在工程领域人员学习WBS的时候，经常会完成一个工程实体分解的WBS。持有这类观点的不在少数，他们在概念里倾向于将工程的PBS替代WBS，其中不乏技术人员和管理者。如果将工程设计WBS分解为：

设计图纸，结构设计图纸，建筑设计图纸，市政工程设计图纸，电气工程设计图纸……

恐怕很难识别设计工作的一些任务，例如，设计前现场勘查，施工过程的现场监督，二次设计图纸的审核等等工作。如果说WBS是一种“范围管理”工具，那么基于产品的分解方法通常比较容易遗漏“过程服务”的成果，这些成果大部分情况下是“无形”的。我们知道产品需求差异会导致设计工作范围的不同，因此在进行设计管理工作的时候就不能仅仅围绕设计的可交付成果展开，还要兼顾面向任务或者活动的部分。实际上，借鉴软件工程的WBS可以看出，设计领域中在项目开始之前进行较为精确的产品分解是不切实际的，所以通常使用任务分解的方式分解WBS。

再有，工程中的采购也难以使用有形的采购产品分解WBS，更多的是采用面向过程的WBS。过程管理对于项目管理是非常重要的，很多时候基于过程的分解更加贴近OBS，或者在更高的WBS层级与OBS匹配。其实过程分解的下一级就是任务分解，而任务分解的下一级就到了工作成果。正如Airstorm在上面所述，服务和产品的叠加才是“工作（works）”，这显然与传统的工程领域知识相矛盾（工程领域中，works专指“工程”或者“永久工程”，参见FIDIC条件），在《系统》一书中介绍WBS概念的时候，特地强调了CWBS【合同分解结构】一词，其概念核心就是是基于产品分解的WBS要通过CWBS（合同分解结构）的方式建立一种管理项目任务的渠道，使得项目工作范围被完整地管理起来。

总结

WBS中的works是一个“包”的概念，是工作任务与工作成果的集合

对待WBS的时候，不应该仅仅将其看作是PBS（产品分解结构），如果必须如此，则需要界定任务分解结构，比较成熟的有合同分解结构CWBS，或者组织分解结构OBS与PBS相结合。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

对于我等来说，可以下载的学习资料能够再丰富一下喽：

• 新版UniFormat II的草稿（45页 PDF）
• 仅仅包含level 1-3层的简化版（7页 PDF）
• 新版本的修订说明（4页 PDF）

我推荐没有uniformat的同学直接下载45页全文，后面2个则是非format具体内容的部分。更多的信息和资料可以进入最上面的链接访问到。 在看过草稿后，我最大的感触是，uniformat子目里面居然包含masterformat的对应编码。这样就很容易做到设计与施工的衔接，我们的造价体系对应方面好像没有这样细致。其他学习中，有需要的赶快行动，到六月份就不一定可以下载到了！

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

• 合理性 时间安排合理、成本支出合理、资源使用合理、风险预控合理等等
• 可实施性 各项活动张弛有序，资金链不会断裂、资源不会过于短缺等等

那么如何做到上述高度概括的要点呢？

首先是合理分解WBS，这部分已经讨论很多了，这里不再赘述。 分解的同时将要根据WBS子项识别出关键实施任务（仅含实施部分）这很容易，原因下面大家会知道。

接下来是 把这些关键实施任务根据逻辑关系排列起来，这里仅考虑实施任务的逻辑（其他次要任务的逻辑可以后期细化）。见下图，你看到了什么？一个非常紧凑的初始实施计划：

然后在每个实施任务前后加上”启动”和”收尾”任务，绝大部分实施任务都具有相应的”启动”和”收尾”任务。注意这实际上是一个过程识别的步骤。在这个时候，你可能需要识别实施任务的准备期是否需要“外部过程”（例如招标采购活动）、是否需要细化前期任务等等。为了简化起见我做了抽象化处理：

图中在工期上对不同项目实施任务的前期启动和收尾任务做一些区分，以表示其不同的任务性质。你可以认为较长的前期任务表示外部过程或者一揽子前期工作等等。这一步看似简单实际上具有相当的难度，如果你在此处没有认真、详细地计划你的项目任务，那么你一定会失去对项目的控制。总之这会反映项目关键接口、任务、合同要素和工作流程等重要特征。

接下来的步骤就是添加成本、合同、采购等等你掌握的信息，下图是将成本按照实施任务的性质和特征分解并叠加的结果。在计划的前期，我很喜欢使用primavera的WBS工具中的step，而不是继续细化WBS，因为早期的“step”具有阶段划分的性质，及时间特征更明显。这样便于摊销项目成本（通常step包含主要的子任务分解，并被计划工程师赋予时间特征），尤其是重大项目，成本/资金计划的准确性是非常重要的。换句话说前期可以使用step套取WBS子项，并根据项目实际情况分配资金。这样得到的计划及快速又“完美”。

上述方法和图示都是抽象的，下列技巧却是实实在在的：

1. WBS结构化分析；
2. 过程识别和流程分析；
3. 必要参数（如成本）的分解和配置。

这种计划方法在项目早期还是很有效的，而且和容易形成模板，这种方法做来的资金计划都非常接近实际情况，都可以宝成具有一定的合理性、可实施性。

更新：

实际上，这篇post是为了解释给newbee的。早期计划中计划与实际情况的契合程度决定了你的计划是否可行。在国内的项目早期计划应该从可行性研究阶段开始，但是国内的可行性研究报告恰恰并不重视项目的早期计划。而且仅从投资计划角度而言，也不是从实际出发制定资金使用计划的。这就造成了其“橡皮图章”特性的一个重要表现。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

建模操作

以前的工具之所以不好用，在很大程度上是没有挖掘建模工作流程以及wbs工具的实际需求。生涩地堆砌绘图工具对WBS建模工程师没有任何实际意义，而对于Visio等绘图工具高手而言，不如直接使用visio的原始图形工具顺手。这个WBS Modeler就充分发挥了visio在图形绘制与wbs建模方面的优势。

数据和报表

WBS Modeler另一个优势就是其整合的数据更有用了，这些数据是计划阶段所必需的。 WBS Modeler整合Ms project数据包括：

• WBS编码
• 成本
• 估算（属性）
• 完成百分比
• 工期
• 资源
• 里程碑（属性）
• 开始/完成日期
• 紧前任务

这些数据的整合，使wbs modeler有能力输出相对复杂些的报表，并且可以管理需求组合报表并形成多个数据层级。令我困惑不已的是报表好像只能输出为html和xml格式的文档，干嘛不直接导入excel呢？

与Ms project比较

这是个很实用的功能，你可以通过“比较planing”这再次导入源mpp文件的数据，并进行比较。wbs modeler会在相应的窗口显示差异。不幸的是，它现在还不可以在不同的mpp版本间比较。

下载

在微软的download center中，Microsoft Office Visio 2007 WBS Modeler目前只有英文版。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

起源

早在1969年英国皇家特许估算师协会(RICS)颁布了第一个房屋建筑的分 类标准，之后许多国家都在制定自己 的分类标准，欧盟制定了CEEC分类。（建设工程项目工作分解结构(WBS)的思考）Uniformat是由美国AIA与美国GSA联合开发的，美国ASTM基于Uniformat制定了ASTM E 1557-05分类标准，名称为 Uniformat II。最早在1989年颁布，最新版本为2005版 。MASTERFORMAT是由美国建筑标准学会CSI 和加拿大建筑标准学会CSC 最早在1972 年颁布，最新版本为2007版。是美加两国八个工业协会和专业学会共同倡导和努力的结果,在北美地区具有深远影响，历史悠久，应用广泛。

目标

Uniformat II的定位是面向工程项目全周期的编码结构用于描述、成本分析和工程管理的建筑信息分类标准。Uniformat II的原文是：

This standard establishes a classification of building lements and related sitework. Elements, as defined here, are ajor components common to most buildings. Elements usually erform a given function, regardless of the design specification, onstruction method, or materials used. The classification
serves as a consistent reference for analysis, evaluation, nd monitoring during the feasibility, planning, and design tages of buildings.

Matserformat 的定位是工程项目实施阶段信息、数据的组织和管理编码体系，同时提供工作成果的详细成本数据。Matserformat的原文是：

MasterFormat 2004 Edition: Numbers and Titles is a master list of numbers and subject titles for rganizing information about construction work results, requirements, products, and activities into a tandard sequence….MasterFormat Numbers and Titles are suitable for use in project manuals, for rganizing cost data, reference keynotes on drawings, for filing product information and other technical ata, for identifying drawing objects and for presenting construction market data.

分类方法

Uniformat 的分类方法是采用层级式的建筑工程系统构成元素划分，他更倾向于再现工程元素的物理构成方式，并以此来组织设计要求、成本数据以及建造方法等信息和数据。这种建筑信息的分解和组织更加符合设计组织（AIA）和管理组织（GSA）的习惯。参考Uniformat的部分子目：

Masterformat的分类方法是采用工种/材料分类，他更倾向于符合建筑工程分工组织实施的方式，并以此来组织设计要求、成本数据以及施工文档等信息和数据。这种建筑信息的分解和组织更加符合工程建造阶段的信息处理习惯。而作为一种映射的成本编码体系，在性质上也更接近我国的工程造价计量体系；作为一种美国通用的招标设计说明编码体系，被许多美国工程师采用用于编制设计说明和招标。参考Masterforma的部分子目：

主要用途

Uniformat着眼于功能元素，主要以描述和反映工程实体的功能构成，进而关联设计成本数据。以此分析设计方案、价值工程、工程进度等等策划、设计因素。在成本计算上，由于没有明确的施工方案，精度偏弱；如果达到同样的精度，其数据体量及其冗余度都较大。但是他的长项是价值工程这类与功能和构建类型相关的成本分析和投资控制而非工程计量。所以Uniformat更多地用于AEC领域方案设计阶段或者项目计划阶段；当然，由于Uniformat的功能分解特性，它在项目全生命周期中都可以找到用武之地，只不过在设计阶段作用尤为突出。

MasterFormat着眼于施工结果，可以直接阐述工程施工的方法和材料，进而关联施工成本数据。在成本计算的角度看，一种特定的建材只在MasterFormat中出现一次，便于统计和计算（这一点非常像国内的概预算体系）所以MasterFormat更多地用于施工图设计阶段或者最终招标阶段。

关联

Uniforamt和Masterformat是互相关联的，在底层数据上它们其实是一致的。下图是二者的对应关系，可以看到，在建筑实体局部编码中，Uniforamt和Masterformat可以做到相互对应：

这种互通特性是美国AIA、CSI等组织不懈努力的结果，CSI一直同时维护着自己的Uniformat和Masterformat版本。从而使得设计到施工的工程管理平滑过度，并保持了各个参与方的高效工作能力。一些公司如MC²则使用高层级Uniformat与低层级的Masterformat混合体系建立数据翔实、准确的工程项目信息体系， 并得到了一定的认可。

BIM应用方面， Uniformat占了很大的比重，原因除了其功能构建分类较为适合BIM模型意外，还与当前使用BIM模型的主流还是设计组织为主有关。随着4D技术的不断完善，相信Masterformat将会逐渐融合到BIM应用中来。下面两幅图是BIM应用软件innovaya的截图：

For Uniformat：

For Masterformat

总结

两种各具特色的建筑信息分类编码体系，各自的分类方法和适用范围不同，在各自的领域中都非常的出色，反映到国内，投资和管理领域更偏向于Uinformat，建筑设计和造价领域更偏向于Masterformat，airstorms就接触过Masterformat格式的设计说明书及其成本数据。感觉现阶段国内业界对于Masterformat格式了解还是多于Uinformat格式。

但是站在工程项目管理的角度，airstorms不太同意《建设工程项目工作分解结构(WBS)的思考》 的说法，因为工作成果同样有内在的联系，所以分解第一层级的定义（以现有工程阶段惯例划分分解层次）过于武断了。《工程项目投资分解体系研究》则应该没有进一步探究Masterformat格式的实际内容，它的施工进度、现场条件等因素考虑得非常详细。所以“M体系较少甚至没有考虑项目具体施工过程中的先后顺序”的论点是不合适的。

严格的说，Masterformat格式完全可以作为CM合同模式下的项目WBS使用；而Uinformat格式则可以作为DB合同模式下的项目WBS使用。

另外，推荐一种更新的格式omniclass， 一种全生命周期WBS体系。airstorms推荐有条件使用整合软件工具的前提下，使用这种WBS。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

Technorati Profile

首先，我们看一个简单的例子，例子中你可以看到一些黄颜色的标注，这些类似与blog的标签功能，将wbs元素以另外一种关联关系连接在一起。在工程项目管理中最实用的就是“合同代码”与wbs元素的关联，它可以关联合同标段、主合同子合同等，也可以标识资源例如部门、人员等信息。我之所以认为合同与Wbs的关联比成本代码与wbs的关联更重要，原因在于合同代码与wbs的关联实际上就是合同包的划分与界定。从大局上看，合同包划分以及合同界面定义在管理层面上要高于成本估算、预算。

除了上述两个关联外，还有一个关联也是非常重要的，就是子项关联。听起来很别扭，但是为了说明问题就得提出一些概念：子项关联就是project ID，project ID是primavera的一个字段名称，它代表项目的不同子项。我们应用子项划分的方式就是按照工程惯例划分不同系统、不同部位或者不同阶段。总之，这是一个技术性的划分。如上图所示的采暖工程，就是一个典型的按系统划分的子项。这些关联与wbs一道组成了工程项目管理的基础，并使wbs具有类似魔方的多维度灵活性，从而在策划、设计、采购、施工等阶段为管理工作提供高效的分析、设计和控制工具。所以我并不太认可时下流行的wbs工具，它们都在平面化了。在反映wbs元素的此类关联的时候就都显得力不从心，较为典型的wbs pro仅仅可以关联成本信息，但这就已经“算是完美”了。至少你还可以分析成本构成，虽然实际做起来实在很困难。

需要注意的是，合同、成本、进度、技术等因素并不是wbs编码系统需要考虑的，也不是wbs分解需要考虑的，它们只是为管理和控制提供高效率的手段，而相互关联，进而构成一个有机的管理体系。

其次，在把玩魔方的时候，大家可能会有殊途同归的感觉，即解法不唯一。这一点也可以用在wbs的分解上面，在“面向成果还是面向活动” 里我们探讨了按照那种导向分解的问题，实际上在那时我没有说明，其实二者是相互关联的。无论你从那个方向分解，最后都要达到这样的效果：

• 任务关联成果
• 任务或成果关联成本、资源、进度、流程
• 任务或成果之间应设置必要的关联（如子项关联）

不同项目有不同的特点，但是比较一致的是，如果达到上述wbs分解效果，则必须分解至少4层。这时，你已经很难区分wbs元素到底是任务还是成果了（比如XX部位表面油漆）。
总结

wbs与合同、成本、进度、技术等因素构成一个相互关联的有机管理体系。处于这类关联核心的是wbs，通过建立关联才能保证wbs的实用性，否则类似与组织结构图式的wbs只能是粗浅的摆设，不能真正起到其应有的作用。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

其实，这要看你在什么层面，从什么角度去使用WBS；以及你的项目所具有的一些特征。这些将决定你如何有效地使用WBS工具去管理你的项目。

下面谈谈我对这个问题的看法：

在这里用这个表格可能更直观地表达我的认识

面向活动的分解方式非常适合于服务类项目的工作分解，而且这类项目的工作结构本身应该不复杂，例如网上流传很广的结婚WBS案例。当然，这不是说面向活动的WBS就一定结构简单，但是WBS的本质并不是“穷举”所有的工作细节，而是科学合理的管理项目工作。你可以参考关于80Hrs规则的文章，来了解WBS的分解精细度问题的答案。

（暂且放下面向成果分解方式的评价）

面向活动的分解方式最大的问题就是对变更的控制力不够，因为就任务本身而言也许他在项目实施过程中不会改变，但是它产生的结果很有可能是会发生变化的。比如：采购任务按照设计图纸要求采购设备。无论你将活动分解得多么详细，你都无法跟踪最终采购设备和图纸标明设备是否存在差异。另外，当你管理的项目是由很多参与方共同完成的（例如AEC工程领域），那么针对任务的分解方式是非常脆弱的，因为你很难规定一个独立承包商的所有任务（即便你有合同约束他们），这有悖于另一个被普遍接受的WBS设计原则100%规则。

面向活动的分解方式同时也容易导致WBS演变为schedule工具，或者WBS容易沦为项目进度计划的工具而不是基本的项目管理工具。这一点在我看到的wbs中甚至成为了一种趋势。[Lax老兄，我可不想与你开展新的论战] 但是我们不得不承认，至少在有限的范围内，有很多人忽略了WBS作为范围管理工具的作用，而更多地将它用于schedul计划和管理。

面向活动的分界方式的重要基础就是任务的成果简单明了，不存在任何可变因素。例如获得“某某部门或领导的批准”，相反如果活动定义为“确定区域供电方案”就有可能包含大量的可变因素。对付这一问题的方法有两个：

1. 将活动继续分解，直到它不再有任何可变因素；
2. 定义活动的可交付成果（还是需要基于成果的分解和定义）。

[这里我要提醒sam: 当WBS含有很多不确定因素的时候，维护WBS结构绝对是件非常繁冗的工作]不同的方案有可能导致不同的工作任务模式。

小结

上述论调似乎在刻意“贬低”面向活动的分解方式，如果你这样认为就大错特错了！事实上面向活动的分解方式特别适合个人对于项目的管理，至少我是这样的。毕竟，个人看待项目管理不能避免的会面向活动。另外，如果项目是完全属于组织内部的，那么面向活动的分解方式可以提高组织的协同效率。

而PMI则倾向于面向成果分解方式，并且在其出版的《Practice Standard for Work Breakdown Structures》 有详尽的阐述。据个人的实践，在AEC领域，面向成果分解的方式是唯一的选择。

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

在2002版的office里面，MS曾经提供了一个visio Vs. project的转换工具。它可以提供功能相对粗糙的WBS图形编辑模版，但是借助于visio的强大编辑功能，我们可以更自由地编辑整个项目复杂的wbs结构。相对而言，visio的排版/图形处理以及形状编辑比起project原有的（网络视图）图形排版工具要耗用多了。但是最大的问题是，功能上，仍然不能满足最普通的wbs编辑/创建需求。所以在那个时候，这个转换工具更像一个组织机构图的模版。

在2007版里MS升级了这个visio Vs. project的转换工具。最大的变化是wbs工具现在集成了工期等wbs元素信息。而这些信息的集成将有利于在visio中独立编制WBS。

相反地，这个转换工具还可以提供从project导出wbs视图。下图变色的WBS元素表示该部分任务已经完成了。

与上一版本的转换工具相比，这次的进步在于进一步提高了集成度。2002版的工具有时候在转换过程中会出现错误，如导入的数据不完整、遗漏任务信息等。相信新版工具在这方面会有进步。

但问题是wbs的编制需要很多数据支撑的，而不仅仅是一个绘图工具可以替代的。这一点上不敢与MS苟同。试想一下，在编制WBS时大部分是自上而下的编制过程，这时也许会需要成本数据的支撑，甚至是集成；以便直接将WBS元素定义和成本分解结合起来。 另外，在编制WBS时我能引用WBS字典吗？—这些都不是visio这个绘图工具所能解决得了的。

总结

还是一个绘图工具，在其内部集成方面应该解决得很好，但是与WBS pro相比 ，好像也没有高明到哪里去啊？唉~~~什么时候可以看到一个真正完整的WBS工具呢！

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)

这个小工具最吸引人的地方在于它可以与MS project 很多版本无缝集成。这是官方网站的贴图：

第一张图不用解释了，第二章则是由WBS chart pro 生成的。看起来工作的很好。

事实上如何一个project management软件都应该含有WBS组件，只不过MS project刚好缺乏一个像WBS chart pro 这样的图形开发WBS模版的工具。MS project的WBS功能模块应该是在大纲级别里面，在那里可以建立基于列表的WBS。

另外一个我没有在官方网站上找到答案：WBS chart pro 声称支持project server。但是又没有明确是以什么样的方式与project server衔接的。是web part吗？这个功能我没有机会用，但是与server的集成应该是很好的功能。
无论如何，这个WBS小工具对于初学者和一些需要图形展示的应用情况还是相当有用的。

更新

很多人要下载地址，我也只用过预览版的，地址：http://www.download.com/WBS-Chart-Pro/3000-2076_4-8668211.html

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright © 2008 作者 clockwork59 at Airstorm (数字指纹:
24fed2e143ca40ef26657495da818d48)