|
方法是用来解决问题的。讨论方法是为了找到更经济更实用的解决问题的路径，而方法论是对解决问题的某一路径的抽象、总结与概述。可以说，方法论是针对某一类问题设计出来的，同一类问题也可能有多个方法论并存。一定要说某个方法论一定要比另一个方法论更优秀，就成了论方法。bbs.mypm.net
但是，无论如何我们都要明白，由于方法论是基于其面向对象、覆盖范围、设计思路与目标结果等因素而形成的解决方案，所以必然的各有优劣。在面对同一细分类型具体问题时，也必然的会出现在手段/工具上的交互，尤其是跨行业的同质问题之间。比如说面对项目的管理问题。www.mypm.net
目前，在项目管理这个问题域内，主要的解决方案包括了英国商务部所有的PRINCE2，国际项目管理协会的IPMP，美国项目管理协会的PMBOK，中国劳动和社会保障部的CPMPOK，以及敏捷。其中IPMPBOK和CPMPOK除了某些专门需求之外，被学习的很少。而在应用领域PMBOK则是绝对的主流。项目管理者联盟
因此，在论方法的过程中，PMBOK也成为了主要的被攻击对象，仿佛只要证明自己的解决方案优于PMBOK就会成为NO.1一般。但似乎所有的攻击者都忘记了一个问题——不同的问题与目标制约之下，只有局部优势，木有全面超越。项目管理培训
比如说现今要在项目管理问题域闹革命的敏捷。从否定项目经理存在的必要性开始，试图通过借助符合其基本思路的工具的组合与应用，实现颠覆PMBOK的目的。项目管理者联盟
这真的可能么?我想，这要看PMI的态度。但这里不妨讨论下。项目管理者联盟
第一个问题：面向对象。从表面看，PMBOK和敏捷都在面对项目的管理问题，所面向的对象也都符合PMBOK中对项目的定义。但是，符合定义的事情只能叫有资格被冠以某个称谓，却并不代表所有人都会认为其名副其实。例如需要2~3个人合作一天准备的丰盛晚宴，会有多少人真的认为是个项目?bbs.mypm.net
第二个问题：覆盖范围。PMBOK源于工程制造领域，敏捷源于软件工程领域，PMBOK天然的带有适用范围的优势。而从各自的发展路径来看，PMBOK从最初以亿计的经济规模逐步递减到百万级，其保障自身优势的办法是提出了项目集成的概念;敏捷则从万级的经济规模开始，正在努力去逾越千万级的门槛，其正在通过不断的加入更多新的工具，以支撑自身的发展。pmp.mypm.net
第三个问题：设计思路。PMBOK中首先提出的一个问题就是组织结构，不是项目内部的组织结构，是企业的组织结构。并且，针对典型的组织结构明确了自身的适用性与可覆盖性。应该说，PMBOK设计的起点在于企业自身的运营模式;而敏捷首先是一个宣言，之后是一些故事，虽然有一些所谓的“敏捷方法”将自身运行所需的结构进行了明确，但其所适用的组织结构以及与组织结构之间的关系，则无人提及。应该说，敏捷设计的起点在于项目自身的运营方式。项目管理者联盟
第四个问题：目标结果。PMBOK所强调的是以进度、成本和质量为核心的总体控制能力，追求的是内外部的平衡;敏捷所强调的是持续交付，追求的是客户满意。扩展一下的话，可以看到PMBOK所要的结果是基于干系人之间的妥协而实现的，逻辑上代价由双方分摊;而敏捷所要的结果是以客户方的满意为前提的，逻辑上代价全部由客户方承担。项目管理者联盟
从讨论方法论本身而言，以上的四个问题应该已经足够说明情况。下面从工具层面举几个例子，权作是对以上问题结论的一个补充。项目管理者联盟
第一个例子：站会。站会这一工作形式的是一种非常有效率的实现信息交互的方式。而这一形式的最大问题在于参与人员的数量规模。当参与人小于一定数量的时候，参与人可以逐个提供信息，发表观点。但当超过某个临界值之后，效率将成几何级下降，且参与者因为接受的信息过多而直接影响其工作效率。service.mypm.net
第二个例子：工作任务表。工作任务表使用的前提是对项目总体处于可控状态。当工作目标，工作量以及可投入资源及资源属性明确的时候，利用WBS可以有效的实现对工作任务的分配与管理，同时以此为基础，对进度、成本进行监控。但对于最终工作目标不确定等情况时，WBS却可能成为枷锁。但显然，大楼的最终设计图是不会大规模或频繁调整的。项目管理者联盟
第三个例子：看板。看板是一种直观的展现工作进展情况的管理工具。而看板在追求直观展现这一优势的同时，也收到了信息量的制约，出现同站会类似的问题。即当信息量超过某个临界点，反而会出现信息混乱，关系不清等问题，并导致其丧失优势，甚至失去存在的意义和价值。PgMp.mypm.net
第四个例子：挣值。挣值是一个财务工具，负责对项目的各项经济指标进行演算和呈现。一方面其对于既有的投入进行汇总统计，另一方面其为后期执行提供修正依据。当项目的总体可投入成本一定时，其可以非常有效的对成本控制提供指导。而对于简单追求质量而不考虑成本的项目而言，则此工具会显的相对多余。项目管理者联盟
例子举到这里，已经不难发现，其实每一种工具，背后也都有一套支撑的方法论。只不过这些方法论所面对的问题更具体更细分，所以，很多人已经不会在有意识的去称呼那些东西是方法论。就好像之前所说的，符合项目定义的项目，现实中未必有人会想的起来他们是项目。项目管理者联盟
话题至此本该结束了。但既然提到了工具以及工具背后的方法论的问题，就觉得应该再多一个问题：为什么会需要工具或是方法论?项目管理者联盟
在我看来，这是工作效率与规模化传承问题的解决方案。也就是说，之所以需要工具或是方法论，是因为人们试图解决掉工作效率低下和大规模传承技能的问题。就好像快速使用手册或者简明指南什么的东西。项目管理者联盟
也所以，人的价值并不在于会使用多少工具，掌握了多少方法论。而在于其能真正解决掉什么问题，是否有效，其解决方案是否可以被普及。项目管理者联盟
最后说一句。所谓神，不过是干了人干不成的事，解决了人没能力解决的问题。但神不是神化出来的，而是做出来的!在天使们的帮助下，做出来的!项目管理者联盟 项目管理论坛
|
