回顾

在工程行业，可见的广泛应用编码体系几乎都是来自于计算机数据库技术成熟之前。之后再也没有出现过更加灵活的，适应性更广的编码体系。为了说明这个问题，需要跳脱出自己的行业：

图书业很久以来就有一种叫做图书编目的编码体系，但是亚马逊或者当当上面已经找不到这种编码了。这意味着编码体系从形式上被更好的技术或者方法替代了。在互联网出现之前，没人觉得把世间所有内容关联起来是可行的。直到hyperlink这种近乎于天方夜谭的概念被科学家们落地成为一项通用技术语言。早年间的数据库语言至少是我学习数据库的时候，任何表单都必须有一个主键（index），否则就不能被索引甚至关联到其他表单。这个做法早就已经被IT行业抛弃，原因是出现了类似于hyperlink的技术，即仅仅关联内容再也不需要硬编码了。（编码依然主要，这里略过，主要逻辑在于对工程信息的建构模式）

面向对象

工程行业有一种对工作任务进行建构的技术叫做WBS（工作分解结构），这是一种典型的西式逻辑思维的产物，将一切工作有序地建构在一个树状网络（多叉树）里。这种方式是工程行业多年来一直沿用的方法，粗看上去相当强大。但是问题也恰恰在于所谓的强大之中。

IT行业中，面向对象的方法就是一个很好的对事物进行有效抽象并建模的技术。其基本方法在于：定义对象自身（属性、类、方法等等）、挖掘对象所处场景及其行为逻辑（用况图，时序图等等）、建构面向对象的信息模型、最后使之在现实场景中按照建构好的业务逻辑收集处理数据，完成自动化或者半自动化的信息业务流程。

再反过来看所谓的WBS，问题在于自成体系并繁冗复杂，无法与背后执行任务的实体（人、设备或者组织）建立灵活的关联（不同的工作实体其实工作方法、效率、使用的材料特性都可能不同）。所以导致了大量的看似标准，但本质上无法自洽的伪业务逻辑。例子：道面摊铺，随着工程机械的进步，工作流和标准工序都不同了。但是由于WBS是单维度的，它的更新是游离于设备乃至工法更新的，所以可能标准工序是5道，但是不同世代的机械可能烟花成了3道工序甚至更少。但是WBS依然雷打不动地标准化地还是5道工序在列。可以看出维护一个强大系统在传统工程行业里面非常厚重、繁冗、迟缓、艰难、离散。

多叉树-理想化的数理逻辑

WBS本质上是简单的多叉树形式，其背后的逻辑在于“父子“关系，一种单一继承模式的归类通项式。这样的单维度模式产生的困扰是巨大的，以至于wbs结构的分解方式就存在持久的争议。我比较认同的是所谓的面向交付成果的分解方式。但是可惜，当多部门多工种协同的时候，一个任务对不同的实体其内涵是不同的，你很难将跨部门跨专业的单一任务无穷尽的分解下去，这样会导致结构失衡（某些工序分解下去毫无意义因此会停滞在某个level上面，但是与之协同的工作则必须近一步穷尽）。例如，刀头校准可能是机床操作手一系列的动作，而对另外一侧的供料操作手而言，校准只是其进行供料操作的一个信号而已。那么一套协同工作可能是WBS表单中第三层级第五层级和第十二层级的不同工作的集合。

在这里不在赘述，仅仅简单阐述观点：1、建构-解构的单维度继承通项式必须保留，但是范围必须受控；2、很多所谓的分解甚至编码不如使用Tag技术完成对其进行标示的目的；3、深刻探讨WBS目的，为其场景创造甚至更新技术本体。

那么到底怎样的事物体系是可以被建构成多叉树的呢？

空间关系

简单而言，工程建造过程中空间体系是具备一定程度的“多叉树”通项式。我们可以把一个住宅的空间体系分解为栋-层-功能空间。但是注意，工程建造的空间体系仍然不是一维的。因为空间体系一直都是基于3D的空间耦合模式。举例：一个会议室，它可以是建筑功能空间：会议功能，具备一定的声学、光学环境属性特征；也可以是机电系统空间：其热学环境处理模式需要依据整体环境和会议空间的具体模式而定，例如500人会议室，很可能需要消弭突然人群聚集带来的大规模显热能量输入；也可以是结构体系空间：会议室位于结构空间的那一部分，支持其空间的结构体系是那些也是另外一种空间维度。

如上所述，空间的构成关系非常适合多叉树模式，但是它不是单维度的（多叉树本身可以是多重维度）。而建构这种构成逻辑的方法就不再是WBS方法了，而必须是借助BIM这样的工具对工程实体进行空间耦合解构乃至重新建构。

棋盘、跳马与皇后问题

在棋盘里码放棋子特别像很多的工程建设任务：安装。例如是一个围棋棋盘，有两个工种（黑、白），各自按顺序码放棋子。这个过程最简单的方式是黑白两个工序各自在自己的区域按照从左到右或者从上到下的顺序码放。这样的码放在计算机记录视角看来是有着强烈的规则和可预测性的。但是显然这根本不是现实棋局的样子。现实棋局中，棋手是博弈的，棋子的码放按照计算机记录结果的视角去看，每一个棋盘格子的码放好像没有了规律，任何格子被码放上棋子都好像是随机过程。但是如果你把棋手的博弈过程看作是业务逻辑，那么下棋的顺序其实就存在了“规律”，甚至在一定程度可以预测。

经典的早期计算机问题之一是所谓的皇后问题。即规则的正方形棋盘，边长N*N。求解皇后是否可以遍历棋盘上所有的格子（这里不探讨计算机解法，探讨其背后相似的处理问题的机制）。这个时候，皇后就好像是某个工序的某种机械设备，或者是特定的工法。使得它在工作面中必须按照特定的业务逻辑移动或者迁移。而“皇后”（某种工程机械）遍历“棋盘”（可以是一段地势起伏的建造环境）的特定方式按照这里的表述方法，就是空间时序流。

车同轨

求解上述问题的办法在于需要将“空间时序流”当作“对象”处理。而且，还是所谓的“虚对象”。虚对象在这里最为恰当的例子来源于秦始皇的统一六国国策之一：车同轨。

车同轨中的轨在本源上不是我们现代人看到的铁路铁轨，古代的“辙”才是对应铁轨的概念。那个时候的轨指的是什么呢？它指的是车轮之间，车轴与地面之间围合的平面连续延长得到的虚空间。即：轨本质上定义了车辆的主要参数指标：轮距和车架高。而这个轨所代表的连续虚空体则是最好的空间时序流对象。

综上，空间时序流对象是依附于空间的虚实体，“轨”（虚实体）的特征与其“车辆参数”（实体对象参数）存在空间耦合关系。空间时序流对象的空间过程有自己特立的产出成果，这个成果一般不同于虚实体。台湾著名童谣留下脚印两对半，本质上恰恰是特定模式（老年手杖）的空间时序流产出物。即：老人与小孩在沙滩漫步时存在一个空间时序流：“漫步轨”，而这个空间过程的产出物：“脚印”（两对半）则仅仅属于上述虚实体。

<未完待续>

可交付成果在PMBOK中有比较清晰的定义，Airstorm这里就不在背书了。直接谈谈容易出现的误解，对于可交付成果的误解集中在2各方面：一是可交付成果的概念本身；二是可交付成果在WBS中的作用。

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

工程领域中，项目产品的不确定性没有超出合同双方的经验范围。所以建筑工程承包商可以闭着眼睛告诉客户他们建造的项目产品大体上是什么，客户也基本认可这个大体的范围，即便在细节问题上会有自己的要求（在物理构成上建筑物有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相结合。

CSI（Construction Specifications Institute）的官方网站上的消息，CSI正在公开征集对新版UniFormat II草案的意见。新版UniFormat II将于2008年底正式发布，这个版本将替代1998年的版本，并与MasterFormat 2004相协调。这次征集的部分仅仅包含建筑工程部分的修改，CSI的工作组将于一年后将修订的范围扩展到所有行业。而征集意见的截止日期是2008-6-15。

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

这个题目的确有些虚张声势，不过，身边的一些朋友不久前讨论过早期“完美”计划的必要条件。最后归结为两点：

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

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

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

(more…)

在之前的visio Vs. project的WBS转换工具中，提到了当时visio 2007内建的WBS图形工具，不过感觉还是很不好用。MS公司还推出了一款由bVisual和CPS公司开发的visio插件“WBS Modeler”，开发者给它冠以“visual project planing and reporting tools”的美名。试用了一下，感觉用在建模阶段还算方便。

(more…)

如果你搜索国外的工程项目WBS，那么一定会找到Uniforamt和Masterformat这两种建筑工程WBS格式。实际上Uniforamt和Masterformat是两种不同的建筑信息组织分类方法产生的编码系统，而功能上它们都可以成为工程项目管理的WBS。

起源

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

先看看这张图片，这是一个四阶魔方。之所以用魔方来做题目，主要是要介绍wbs编码以及wbs应用方面的概念。魔方有复原或者还原之说，就是将魔方恢复成下图的状态。期间会使用很多数学技巧。我们在使用wbs的时候虽然不会使用复杂的数学技巧，但是对于wbs的架构特征的多重性还是与魔方有着相近的地方。

Technorati Profile

(more…)

不久前陷入了一次关于WBS工作分解结构设计规则的论战，争论到底应该面向可交付成果分解项目工作还是面向活动。

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

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

(more…)

随着对ofiice project 2007的持续关注，我找到了一些新版project关于WBS创建工具的文章：Integrating Visio 2007 and Project 2007 。里面详细介绍了新版office在PM领域有关WBS的创建方案.

在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工具呢！

之前用过的WBS小工具：WBS chart pro

这个小工具最吸引人的地方在于它可以与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