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