如何穿越团队协作的五重障碍.docVIP

如何穿越团队协作的五重障碍 　　自古以来，那些地位尊崇的理念、宗旨和经验，和长盛不衰的经济、社会和情感的价值，都是由共同工作于团队中的人们创造的。就算某些艺术、哲学和科学领域的非凡成就，看上去是由那些单打独斗的卓越个人所作，我仍怀疑他们也一样有其他人助一臂之力，这些人无私奉献而寂寂无名(也许在幕后)，都是作为团队而共同工作在一起。从大国混战、社会动荡、政治反抗、建立帝国、为自由抗争和建立国家并保卫边疆，到金字塔、泰姬陵、艾菲尔铁塔、自由女神像、悉尼港大桥以至伦敦眼摩天轮等诸多雄伟奇迹的创造，每一样都仰赖于团队协作才得以诞生与存在。当然，团队协作的范畴并不排除简单、俗世而日常的事务，它们虽然上不了报纸头条，却极为重要：平淡者如下田耕作，安排野餐以至家庭活动，都离不开团队。 　　团队协作既然对我们的日常生活有如此深刻的作用，我们很自然就期望团队的产出直接受其协作质量的影响。不幸的是，单凭良好愿望或是听天由命，团队协作是不会产生的，而很多时候根本就无法产生!团队协作的质量受很多因素的影响，比如团队成员个体的积极性，团队成员间的信任度，团队使命的清晰度，对目标的统一理解，资源的缺乏，团队成员间糟糕的沟通，等等。因此可以毫不奇怪地说，要让团队一拍即合，适当的投资是必需的。可是，尽管有最先进的流程和工具，团队的机能障碍还是频繁地严重影响团队的表现，危及它有效执行的能力。大多数软件经理缺乏相关能力去感知这些深层社会学问题的信号，也就无法处理其影响。对这些问题任何敷衍潦草的反应，都只会使其更难应付。 　　在本文中我分析了团队机能障碍的模式，这一模式由Patrick Lencioni在其基于业务情景的精彩寓言体著作《团队的五种机能障碍——领导力之寓言》中提出。在书中所称的模式中，他识别了五种影响团队绩效的机能障碍。这些机能障碍并非是全然独立的，而是互相关联，如后图所示般上下层叠。 　　也就是说，信任缺失导致惧怕冲突，而惧怕冲突又导致承诺不足，如此以往。虽然Patrick在探讨该模式时，借助于一个没有充分发挥潜能的业务团队，我倒发现这些理念放之四海而皆准，也适用于一个软件开发团队的情境。可能哪里也找不到像软件开发这样能凸显团队协作的效用和重要性的了。 　　软件开发是一项团体运动，有自己的公平竞争政策(“职业道德”)，整套游戏规则(“流程”)和对团队协作的高度重视。软件开发流程，或者管理开销(以流程或组织认为合适的任何类型和份额而存在)，或者更简单点的，比如统一的集成开发环境(IDE)、通用编码规范、配置管理工具……实际上任何东西的存在都为了同一个理由：让团队作为整体，大于其组成部分的集合。但是，我们也知道软件项目的失败率惊人地高，即便业内对于“失败”的构成及其真实统计数据没有共识，大家都心知肚明，失败率总归要比该有的高!就算偶有例外，可考虑到软件业雇佣的员工大都聪慧过人，如果在项目失败理由清单中名列前茅的是技术低能、粗心愚蠢或者有意破坏这样的原因，我也还是会非常奇怪。那么，为什么还有如此多的软件团队没能达成其预设目标呢?我相信在其他因素相同的情况下，软件项目失败中一个重大却尚未被足够重视的原因，就是团队的机能障碍。 　　团队流程决定了“工作的方式”，对团队的效力有很大影响。过去十年间，敏捷方法广泛流行，已经成了主流。维基百科对其定义为： 　　“……敏捷方法普遍推崇：一种项目管理流程，它鼓励频繁的检查和调适;一种领导哲学，它鼓励团队协作、自我组织和责任担当;一套工程最佳实践，它允许快速交付高质量的软件;一个业务方法，它把开发工作与客户需求和公司目标相匹配。” 　　上述这些带来的对团队和个人的赋权，达到了迄今我们在软件业所见过的最高程度。我将其看成流程改进中的又一重要进步，它将决策权从经理下放到被赋权的自指挥团队，因而使团队协作在其中扮演比以往更重要的角色。但是，敏捷不是一个社会学流程，它是软件开发中一种面向团队的哲学，虽然有团队社会学的痕迹，但若是武断地来看，就很容易忽略这一点。 　　考虑到敏捷原则正逐渐成为业内开发流程的事实标准，我分析了敏捷实践如何应对软件团队的五种机能障碍。让我们从金字塔底部开始一一展开。 　　信任缺失 　　“第一重机能障碍是团队成员间的信任缺失。这实质上源于他们不愿在团体中轻易受到攻击的心态。团队成员如果不对其失误和弱点真正地开诚布公，就不可能打下信任的基础。” 　　一个团队远不只是一群乌合之众，不管其中的个体如何能干。每个团队成员摆上台面的，都是独特且经常互补的技能，而这些技能的全体集合，帮助团队达成其目标。在一个由各种“劳动分工”方式创立的传统团队中，其成员间存在强大的攀比压力，没有机会发展“基于弱点的信任”。团队成员在过往绩效表现可持续的基础上受到“信任”。但是，在现代行业中，不可能假设或期望任何人具备所有所需技能，在