|
一定要注意“人品无关”这句话，因为在课堂上，做完这个活动之后，几乎没有人会认为他们的抱怨的根源主要来自于这种层次结构，他们都会特别自信地说，如果那个某某角色可以改进一下他们工作态度或者习惯，我们会完成得更好。还有一种倾向就是试图用技术手段来彻底解决结构问题，比如说，一直到课程结束之后仍然有学员争论，如果采用画图方法就可以完全克服这个层次结构带来的弊端。他其实没有想到，即使采用所有组员都画图的方法，那么如何让每个人都充分了解需要采用这种方法并且正确地实施下去的过程中，产生的抱怨绝对不会比完成任务本身所产生的抱怨少。项目管理者联盟
如何解决这种结构矛盾?有一种观点就是优化流程，明确各个流程节点的绩效，明确每个人的职责。这些的确可以缓解一部分矛盾，但是不可能真正化解。就像前面说到的那个木桶，那种“重力场”的作用还在，这些流程和规定只是在通过消耗能量来维持一种平衡。如果没有木桶的晃动，也就是没有项目中的各种困难、人员的约束、里程碑底线的压力、资金的紧张以及需求的不断变更等，那么木桶中的粒子是平衡的。但是如果木桶开始晃动，那么在这个重力场的作用下，粒子就会逐渐克服那些能量的束缚，走向自己的位置。表现在项目组的人员身上，就是产生几乎一致的心理特征。项目管理者联盟文章
流程不行，彻底消除这种矛盾，只能改结构了。但是也不要忘了，不同的组织结构会带来不同的矛盾。有的时候我们用更大的矛盾来解决当前的矛盾的做法会让我们深受其害。项目经理博客
关于这点，微软的MSF做了很好的尝试，那就是创造出了一种没有层级关系的项目组织结构。项目管理者联盟
MSF将一个项目中不同阶段的工作人员分为六个角色,通过这六个角色,项目可以迅速、完善地实施。这也体现了项目开发的六个重要质量指标,它们在全球是一致的。这六个角色分别是:转自项目管理者联盟
(1) 产品管理(product management)。他了解用户特征,尤其是商业特征,明确用户的需求以及需求的期望值。之所以强调用户需求的期望值,是因为用户的商业化特征比较强,需求无尽,无法界定到底如何才算需求得到了满足。而确定了需求期望值后,用户的商业目的就非常明确,实施起来也比较顺畅。blog.mypm.net
(2) 程序管理(program management)。他负责制订计划, 每天找出完成该计划的风险所在,排除风险,每天交付应该完成的内容,确保计划按质、按量实施。PgMp.mypm.net
(3) 用户体验(user experience)。设计友好的用户界面,对用户进行培训,确保用户能够、并且愿意和喜欢使用开发出的产品。开发者在开发前期就参与用户需求分析和项目计划制定,他最清楚具体的开发过程。在开发期开始后,他负责进行代码开发,在每一个阶段,交付每一项内容的代码。项目管理者联盟
(4) 开发(development)。根据规格说明书创建解决方案。training.mypm.net
(5) 测试(test)。负责开发出的代码的测试。测试者并不是要找到每一个开发者的每一段代码的每一个错误(BUG),而是要找到代码错误之间的关系,解决最根本的错误,掌握错误的状态,从而迅速排除错误。项目管理培训
(6) 发布管理(release management)。发布管理人员负责将实验室的产品商品化,变成实际可以运行的产品,达到最初制定的商业目的,取得商业效益。这项工作在以往的项目中可能比较简单,因为实验室的环境可能和实际环境几乎一致或差别不大。而现在却不同了,实验室环境可能十分简单,而实际环境可能非常复杂,比如分布式环境、Internet/Intranet环境等,尤其是大企业,实际环境比实验室环境复杂得多,因而将实验室产品运用到实际环境中是一项非常重要的工作。这项工作没有完成好,往往使整个项目前功尽弃,功亏一篑。
在此基础上，项目团队没有真正的领导，程序管理人员的角色和项目经理的角色的最大区别是他更倾向于提供这些管理的服务给其他角色成员。那么，谁负责指挥项目组其他成员呢?答案就是轮流坐庄。在项目的不同阶段，由不同角色的人来领导项目团队，推动项目。项目管理者联盟
阶段 推动发起人远景/范围认可 产品管理项目计划认可 程序管理范围完成 开发/用户体验发布就绪 测试/发布管理部署完成 发布管理training.mypm.net
这种组织结构，伴随着微软的成长，逐步完善和发展，加上明细的项目生命周期阶段的划分，构成了MSF的基石。它克服了层级结构产生的各种抱怨和效率低下，有利于促进组员之间进行很好的沟通。同时，加上MSF团队的理念：人人为我，我为人人。提倡为其他项目成员提供贡献和帮助，大家共同完成任务。这种结构，鼓励共享，鼓励沟通，具有十分旺盛的生命力。项目管理者联盟
那么，既然有了微软的亲自实践，消除了层级，明确了阶段及任务，鼓励共享和沟通，这种组织结构就是完美的组织结构了吗?答案还是那个成为管理大师的经典答案：“不一定!”项目管理者联盟
这些都是在没有变更(木桶的晃动)的假设下存在的，如果项目进行得特别顺利，那么这种结构的确没有什么问题。但是项目是不可能不产生问题的。如果项目产生了问题，那么这种结构也会暴露出自身的结构矛盾，例如各个项目成员会把责任推给上游成员，上游成员倾向于认为下游成员的能力不足等等。而这些也正好是作者在调查使用了MSF这种做法的安徽省某个电子政务项目所得出的结论。项目经理圈子 项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
