要记住一句话：人品无关，结构使然!

　　项目组织有结构、有层次关系就会产生固有的矛盾。根据前面的论述，这种矛盾与人品无关，结构使然。

　　以前在培训微软解决方案框架(MSF)的时候，曾经多次在课堂上做过一个相同的活动，这个活动是这样的：

　　每个小组按照下图角色出5个人，只能按照下图的箭头所表示的途径进行交流，这模拟了一种常见的分层级的组织结构。这5个人组成一个团队和其他小组进行比赛，他们需要共同找出每个人手中都有的图形，过程中不允许说话，最快的组获胜。每次做完这个活动之后，除了总结项目中应该如何进行沟通之外，我还要求他们讨论组员的行为还有哪些可以改进。最后我把各个组的改进建议收集上来，按照角色进行分类。结果一个有趣的现象出现了。

　　我惊讶地发现，每个角色所抱怨其他组员的内容几乎一样。这个活动在不同的课堂上进行，而不同的课堂的抱怨也几乎一致。

　　A角色的人总是抱怨：

　　(1) 为什么这么简单的事情你们用了这么长时间?

　　(2) 能不能提高一下你们的执行力。

　　(3) 最好充分理解我的指示，不要自以为是。

　　(4) 你们发生什么了我根本不知道，有问题了也不跟我说，直到最后无法交差了我才知道。

　　C、D、E角色的人总是抱怨：

　　(1) 到底发生了什么?

　　(2) 上面到底要做什么他们自己知道吗?

　　(3) 我的意见从来得不到上面的尊重，最后证明，我的意见是正确的。

　　(4) 在这样的小组真是压抑。

　　(5) 能不能先想好了要做什么再让我们做，不要中途老是变。

　　B角色总是抱怨：

　　(1) 我很忙，压力很大。

　　(2) 底线要到了，压力很大。

　　(3) 下面的人总是抱怨我，压力很大。

　　(4) 上面的人总是催我，压力很大。

　　(5) 我很忙。

　　不用问，B就是那个苦命的项目经理，他很忙，压力很大，在上下的夹击下成了“三明治”。

　　这个活动充分证明了组织结构对项目成员会产生比较一致的影响，这种影响也会让他们倾向于产生相同的心理状态。所以说，这些心理状态就是我前面说到的人品无关，结构使然。这种矛盾的结构注定了这种矛盾也会一直存在下去。

　　一定要注意“人品无关”这句话，因为在课堂上，做完这个活动之后，几乎没有人会认为他们的抱怨的根源主要来自于这种层次结构，他们都会特别自信地说，如果那个某某角色可以改进一下他们工作态度或者习惯，我们会完成得更好。还有一种倾向就是试图用技术手段来彻底解决结构问题，比如说，一直到课程结束之后仍然有学员争论，如果采用画图方法就可以完全克服这个层次结构带来的弊端。他其实没有想到，即使采用所有组员都画图的方法，那么如何让每个人都充分了解需要采用这种方法并且正确地实施下去的过程中，产生的抱怨绝对不会比完成任务本身所产生的抱怨少。

　　如何解决这种结构矛盾?有一种观点就是优化流程，明确各个流程节点的绩效，明确每个人的职责。这些的确可以缓解一部分矛盾，但是不可能真正化解。就像前面说到的那个木桶，那种“重力场”的作用还在，这些流程和规定只是在通过消耗能量来维持一种平衡。如果没有木桶的晃动，也就是没有项目中的各种困难、人员的约束、里程碑底线的压力、资金的紧张以及需求的不断变更等，那么木桶中的粒子是平衡的。但是如果木桶开始晃动，那么在这个重力场的作用下，粒子就会逐渐克服那些能量的束缚，走向自己的位置。表现在项目组的人员身上，就是产生几乎一致的心理特征。

　　流程不行，彻底消除这种矛盾，只能改结构了。但是也不要忘了，不同的组织结构会带来不同的矛盾。有的时候我们用更大的矛盾来解决当前的矛盾的做法会让我们深受其害。

　　关于这点，微软的MSF做了很好的尝试，那就是创造出了一种没有层级关系的项目组织结构。

　　MSF将一个项目中不同阶段的工作人员分为六个角色,通过这六个角色,项目可以迅速、完善地实施。这也体现了项目开发的六个重要质量指标,它们在全球是一致的。这六个角色分别是:

　　(1) 产品管理(product management)。他了解用户特征,尤其是商业特征,明确用户的需求以及需求的期望值。之所以强调用户需求的期望值,是因为用户的商业化特征比较强,需求无尽,无法界定到底如何才算需求得到了满足。而确定了需求期望值后,用户的商业目的就非常明确,实施起来也比较顺畅。

　　(2) 程序管理(program management)。他负责制订计划, 每天找出完成该计划的风险所在,排除风险,每天交付应该完成的内容,确保计划按质、按量实施。

　　(3) 用户体验(user experience)。设计友好的用户界面,对用户进行培训,确保用户能够、并且愿意和喜欢使用开发出的产品。开发者在开发前期就参与用户需求分析和项目计划制定,他最清楚具体的开发过程。在开发期开始后,他负责进行代码开发,在每一个阶段,交付每一项内容的代码。

　　(4) 开发(development)。根据规格说明书创建解决方案。

　　(5) 测试(test)。负责开发出的代码的测试。测试者并不是要找到每一个开发者的每一段代码的每一个错误(BUG),而是要找到代码错误之间的关系,解决最根本的错误,掌握错误的状态,从而迅速排除错误。

　　(6) 发布管理(release management)。发布管理人员负责将实验室的产品商品化,变成实际可以运行的产品,达到最初制定的商业目的,取得商业效益。这项工作在以往的项目中可能比较简单,因为实验室的环境可能和实际环境几乎一致或差别不大。而现在却不同了,实验室环境可能十分简单,而实际环境可能非常复杂,比如分布式环境、Internet/Intranet环境等,尤其是大企业,实际环境比实验室环境复杂得多,因而将实验室产品运用到实际环境中是一项非常重要的工作。这项工作没有完成好,往往使整个项目前功尽弃,功亏一篑。

　　在此基础上，项目团队没有真正的领导，程序管理人员的角色和项目经理的角色的最大区别是他更倾向于提供这些管理的服务给其他角色成员。那么，谁负责指挥项目组其他成员呢?答案就是轮流坐庄。在项目的不同阶段，由不同角色的人来领导项目团队，推动项目。

　　阶段 推动发起人远景/范围认可 产品管理项目计划认可 程序管理范围完成 开发/用户体验发布就绪 测试/发布管理部署完成 发布管理

　　这种组织结构，伴随着微软的成长，逐步完善和发展，加上明细的项目生命周期阶段的划分，构成了MSF的基石。它克服了层级结构产生的各种抱怨和效率低下，有利于促进组员之间进行很好的沟通。同时，加上MSF团队的理念：人人为我，我为人人。提倡为其他项目成员提供贡献和帮助，大家共同完成任务。这种结构，鼓励共享，鼓励沟通，具有十分旺盛的生命力。

　　那么，既然有了微软的亲自实践，消除了层级，明确了阶段及任务，鼓励共享和沟通，这种组织结构就是完美的组织结构了吗?答案还是那个成为管理大师的经典答案：“不一定!”

　　这些都是在没有变更(木桶的晃动)的假设下存在的，如果项目进行得特别顺利，那么这种结构的确没有什么问题。但是项目是不可能不产生问题的。如果项目产生了问题，那么这种结构也会暴露出自身的结构矛盾，例如各个项目成员会把责任推给上游成员，上游成员倾向于认为下游成员的能力不足等等。而这些也正好是作者在调查使用了MSF这种做法的安徽省某个电子政务项目所得出的结论。