PMBOK与敏捷-从方法论到论方法

发表于:2013-01-16来源:新浪博客作者:蔡晓东点击数: 标签:敏捷
PMBOK与敏捷-从方法论到论方法.方法是用来解决问题的。讨论方法是为了找到更经济更实用的解决问题的路径,而方法论是对解决问题的某一路径的抽象、总结与概述。可以说,方法论是针对某一类问题设计出来的,同一类问题也可能有多个方法论并存。一定要说某个方法论一定要

  方法是用来解决问题的。讨论方法是为了找到更经济更实用的解决问题的路径,而方法论是对解决问题的某一路径的抽象、总结与概述。可以说,方法论是针对某一类问题设计出来的,同一类问题也可能有多个方法论并存。一定要说某个方法论一定要比另一个方法论更优秀,就成了论方法。

  但是,无论如何我们都要明白,由于方法论是基于其面向对象、覆盖范围、设计思路与目标结果等因素而形成的解决方案,所以必然的各有优劣。在面对同一细分类型具体问题时,也必然的会出现在手段/工具上的交互,尤其是跨行业的同质问题之间。比如说面对项目的管理问题。

#项目管理#PMBOK与敏捷-从方法论到论方法

  查看大图

  目前,在项目管理这个问题域内,主要的解决方案包括了英国商务部所有的PRINCE2,国际项目管理协会的IPMP,美国项目管理协会的PMBOK,中国劳动和社会保障部的CPMPOK,以及敏捷。其中IPMPBOK和CPMPOK除了某些专门需求之外,被学习的很少。而在应用领域PMBOK则是绝对的主流。

  因此,在论方法的过程中,PMBOK也成为了主要的被攻击对象,仿佛只要证明自己的解决方案优于PMBOK就会成为NO.1一般。但似乎所有的攻击者都忘记了一个问题——不同的问题与目标制约之下,只有局部优势,木有全面超越。

  比如说现今要在项目管理问题域闹革命的敏捷。从否定项目经理存在的必要性开始,试图通过借助符合其基本思路的工具的组合与应用,实现颠覆PMBOK的目的。

  这真的可能么?我想,这要看PMI的态度。但这里不妨讨论下。

  第一个问题:面向对象。从表面看,PMBOK和敏捷都在面对项目的管理问题,所面向的对象也都符合PMBOK中对项目的定义。但是,符合定义的事情只能叫有资格被冠以某个称谓,却并不代表所有人都会认为其名副其实。例如需要2~3个人合作一天准备的丰盛晚宴,会有多少人真的认为是个项目?

  第二个问题:覆盖范围。PMBOK源于工程制造领域,敏捷源于软件工程领域,PMBOK天然的带有适用范围的优势。而从各自的发展路径来看,PMBOK从最初以亿计的经济规模逐步递减到百万级,其保障自身优势的办法是提出了项目集成的概念;敏捷则从万级的经济规模开始,正在努力去逾越千万级的门槛,其正在通过不断的加入更多新的工具,以支撑自身的发展。

  第三个问题:设计思路。PMBOK中首先提出的一个问题就是组织结构,不是项目内部的组织结构,是企业的组织结构。并且,针对典型的组织结构明确了自身的适用性与可覆盖性。应该说,PMBOK设计的起点在于企业自身的运营模式;而敏捷首先是一个宣言,之后是一些故事,虽然有一些所谓的“敏捷方法”将自身运行所需的结构进行了明确,但其所适用的组织结构以及与组织结构之间的关系,则无人提及。应该说,敏捷设计的起点在于项目自身的运营方式。

  第四个问题:目标结果。PMBOK所强调的是以进度、成本和质量为核心的总体控制能力,追求的是内外部的平衡;敏捷所强调的是持续交付,追求的是客户满意。扩展一下的话,可以看到PMBOK所要的结果是基于干系人之间的妥协而实现的,逻辑上代价由双方分摊;而敏捷所要的结果是以客户方的满意为前提的,逻辑上代价全部由客户方承担。

  从讨论方法论本身而言,以上的四个问题应该已经足够说明情况。下面从工具层面举几个例子,权作是对以上问题结论的一个补充。

  第一个例子:站会。站会这一工作形式的是一种非常有效率的实现信息交互的方式。而这一形式的最大问题在于参与人员的数量规模。当参与人小于一定数量的时候,参与人可以逐个提供信息,发表观点。但当超过某个临界值之后,效率将成几何级下降,且参与者因为接受的信息过多而直接影响其工作效率。

  第二个例子:工作任务表。工作任务表使用的前提是对项目总体处于可控状态。当工作目标,工作量以及可投入资源及资源属性明确的时候,利用WBS可以有效的实现对工作任务的分配与管理,同时以此为基础,对进度、成本进行监控。但对于最终工作目标不确定等情况时,WBS却可能成为枷锁。但显然,大楼的最终设计图是不会大规模或频繁调整的。

  第三个例子:看板。看板是一种直观的展现工作进展情况的管理工具。而看板在追求直观展现这一优势的同时,也收到了信息量的制约,出现同站会类似的问题。即当信息量超过某个临界点,反而会出现信息混乱,关系不清等问题,并导致其丧失优势,甚至失去存在的意义和价值。

  第四个例子:挣值。挣值是一个财务工具,负责对项目的各项经济指标进行演算和呈现。一方面其对于既有的投入进行汇总统计,另一方面其为后期执行提供修正依据。当项目的总体可投入成本一定时,其可以非常有效的对成本控制提供指导。而对于简单追求质量而不考虑成本的项目而言,则此工具会显的相对多余。

  例子举到这里,已经不难发现,其实每一种工具,背后也都有一套支撑的方法论。只不过这些方法论所面对的问题更具体更细分,所以,很多人已经不会在有意识的去称呼那些东西是方法论。就好像之前所说的,符合项目定义的项目,现实中未必有人会想的起来他们是项目。

  话题至此本该结束了。但既然提到了工具以及工具背后的方法论的问题,就觉得应该再多一个问题:为什么会需要工具或是方法论?

  在我看来,这是工作效率与规模化传承问题的解决方案。也就是说,之所以需要工具或是方法论,是因为人们试图解决掉工作效率低下和大规模传承技能的问题。就好像快速使用手册或者简明指南什么的东西。

  也所以,人的价值并不在于会使用多少工具,掌握了多少方法论。而在于其能真正解决掉什么问题,是否有效,其解决方案是否可以被普及。

  最后说一句。所谓神,不过是干了人干不成的事,解决了人没能力解决的问题。但神不是神化出来的,而是做出来的!在天使们的帮助下,做出来的!

原文转自:http://qing.weibo.com/1794616154/6af7ab5a33002oid.html