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

（原文地址：http://www.programmer.com.cn/464/）

 

软件开发是一项团体运动，有自己的公平竞争政策（“职业道德”），整套游戏规则（“流程”）和对团队协作的高度重视。

 

 

信任缺失

“第一重机能障碍是团队成员间的信任缺失。这实质上源于他们不愿在团体中轻易受到攻击的心态。团队成员如果不对其失误和弱点真正地开诚布公，就不可能打下信任的基础。”

一个团队远不只是一群乌合之众，不管其中的个体如何能干。每个团队成员摆上台面的，都是独特且经常互补的技能，而这些技能的全体集合，帮助团队达成其目标。在一个由各种“劳动分工”方式创立的传统团队中，其成员间存在强大的攀比压力，没有机会发展“基于弱点的信任”。团队成员在过往绩效表现可持续的基础上受到“信任”。但是，在现代行业中，不可能假设或期望任何人具备所有所需技能，在任何状况下都能成功。

Patrick所说，互信团队中的成员们，能够承认他们的弱点和失误，请求他人的帮助，接受对他们职责领域的质询和评价，做出负面结论前先假定他人无辜，承担提供反馈意见和帮助的风险，欣赏和发掘他人的技能和经验，集中时间和精力于重要问题而非勾心斗角，提出和接受道歉时毫不犹豫，对会议和其他集体工作的机会满怀期待。

敏捷鼓励适应性的软件开发，它大量依赖于对过去绩效的反馈来改善未来的表现。敏捷鼓励所有利益相关者——开发者，业务人员，赞助人和客户——之间面对面的沟通和互动。它还鼓励频繁（通常每天进行一次）的进展更新，以及迭代结束时对过去进展状况和未来改善之处的反思。这种定期的开放沟通和反馈可以成为非常有效的信任建设活动。

敏捷团队通常都较小，团队成员具备互补的技能和任务，而非多人同时拥有互相竞争的技能和任务。他们也高度自治，允许以民主方式做出决策，而不是被客户和管理层强加没有合理论据和逻辑思考的指示。团队自己负责承诺，同时小型团队都位于单一地点，这中气氛可以让团队成员互相依靠，从而达成承诺。特定的实践，如结对开发，其根本理念是尽早查出软件缺陷，而不是以缺陷数据判定个体成员的绩效，这有助于更深入地发展信任关系。为此，团队的生产率指标“速率”，不是归功于个人，而是归功于团队。所有这些做法，都极有可能在团队成员间建立信任。

 

 

惧怕冲突

“无法建立信任是有破环性的，因为第二重机能障碍——惧怕冲突——就是由此而定调。缺乏信任的团队无法展开无需多虑而充满热烈激情的想法辩论，他们退而求诸云遮雾罩的探讨和小心谨慎的说辞。”

进行富有成效的冲突，这是一种能力，而该能力会因缺乏互信而受损。大家唯恐提出不同意见被视为反团队行为。这最终变成了一个自我挫败的问题，因为对冲突的惧怕不仅损害了团队的决策力和进展，也加深了业已存在的信任缺失。团队需要进行富有成效的冲突。

在Patrick看来，进行有成效冲突的团队，能够开展生动有趣的会议，提炼和开发全员的想法，迅速解决实际问题，尽量减少勾心斗角，挑明关键主题进行讨论。

敏捷要求团队全员都参与到估计与计划、情况更新和回顾会议中去。Scrum中每日站立会议的发言，是针对团队而非任何经理。团队的进展公开透明，非常容易识别进度落后（这可能危及团队兑现承诺）的团队成员，而下一步并非申斥其进展缓慢，而是要施以援手，必要时进行建设性的争论来找出解决问题的办法。因为“基于弱点的信任”这时已经建立，所以团队成员珍视健康的冲突，而无需惧怕斥责。

 

 

承诺不足

“健康冲突的缺乏是个问题。第三重机能障碍保证会因此出现，那就是承诺不足。如果团队成员没有在热烈而开放的辩论过程中广而告之他们的观点，就算他们在会议中掩饰争拗，也罕能接受最后决策并承诺于中。”

Patrick认为：能做出承诺的团队，能够明晰方向和优先级，围绕共同目标匹配整个团队，发展从失误中学习的能力，抢在竞争者前利用机会，毫不犹豫地前进，也对改变方向毫无踌躇或负罪感。

敏捷最强的一点在于，它是一个面向团队的方法，其中每件事务都由团队主导和负责——从同意冲刺工作清单、工作量估计、衡量和追踪进展，直到最终交付。敏捷团队中没有个人的承诺——一个敏捷团队的进展和成功完全由其兑现的团队承诺来衡量。敏捷也非常重视从过去的经验、尤其是错误中学习，并采取特定步骤来加以完善。回顾会议流程的确立，就是要确保在每轮冲刺和最后项目结束时，从团队得到这些反馈。敏捷还注意鼓动团队成员拥抱不确定性。传统的软件流程对如何处理高度不确定或者快速改变／进化的问题有着严格的限制，而绝大部分人可能都把参与这样高风险的项目当作是职业坟墓。然而同样真实的是，就算最后项目失败，这种项目本身多数都是能够发展事业的工作，具备大量的学习机会。通过敏捷实践，进行短期计划、逐个解决问题，从而降低了失败或重大返工的风险，这有助于一个团队从如此不确定的情况中获得最佳结果。因此，团队当然感到更有信心去承担这么有风险的事业，而且就算中途无可避免地需要改弦更张，敏捷也能毫不困难地拥抱这些改变。

 

 

逃避担责

“由于缺乏真正的承诺和认同，团队成员发展出了第四重机能障碍：逃避担责。没有对于清晰行动计划的承诺，即便是最专注和最有驱动力者，也经常在同伴的行动做派与团队效益背道而驰之时，踌躇于是否出言提醒。”

不担承诺的团队可能在责任担当上表现欠佳。信任缺失时，团队成员经常向个人目标努力，而与团队目标南辕北辙。他们经常倾向于只对自己那部分工作承担责任。可以预料，会有很多相互指责，或是将错误归咎于外因的情形。但是，责任和担责相伴相生，就像我们要求团队自我指导和对其赋权那样，我们也同样程度地要求他们担起应有的责任来。

Patrick所言，互相问责的团队保证了绩效低下者感受到改善的压力，团队成员毫不犹豫地质疑他人的工作方法以图迅速发现潜在问题，在统一的高标准上建立互相尊重，并避免围绕绩效管理和惩治行动而产生过度的官僚主义。

敏捷关注团队全员参与计划和追踪等项目的方方面面。另外，敏捷团队较小，于是整个团队都了解其各个成员几乎每天的绩效情况。虽说其理念不是要对个人施加负面压力，但绩效较差者在此情形下还是会受到大量的攀比压力，去提高其表现。当然，敏捷团队的其他成员会提供各种帮助，但不是要惩戒（或容忍）表现较差者，而是要保证团队努力工作并倾尽所能兑现承诺。另外，虽然敏捷是一种团队方法，它并未削弱关键成员的重要性。与任何团队环境一样，关键成员很容易获得尊重和同事的仰视，这种尊重有助于团队树立模范典型（在小型敏捷团队中很容易发现他们）。

 

漠视结果

“无法互相问责给第五重机能障碍创造了生长条件。在团队成员将其个人需求（如自负心理，职业发展，或者表彰奖赏）甚至于其小团体的需求置于团队总体目标之上时，漠视结果就产生了。”

团队中没有互信，或者大家只顾埋头自己的进展，团队就经常会在兑现承诺时出问题。可是，不能一贯专注于“整体结果”，就不可能交付好的软件。

Patrick描绘了一个专注于整体结果的团队，它留得住有成就感的雇员，减少了个人主义的行为，急切地同甘共苦，从个人利益服从于团体利益中获益，并避免人心涣散。

敏捷倡导具备跨职能知识的个人与业务人员密切合作，“通过尽早和持续交付有价值的软件来使客户满意”。敏捷原则寻求围绕自组织团队中受激励的成员来建立项目。其意图是最终交付团队之承诺，而它侧重团队成员间对他人技能的相互依赖，所要求的代价只是对个人傲慢与偏见的压制。进一步说，短期频繁地交付可工作的软件，有助于减低重大失败的可能性，而每个让团队向目标进一步迈进的迭代都是愉悦之源。最后，团队回顾的实践能够帮助它“反思如何才能更有效，随之调整优化其行为方式”。当团队的低层次机能障碍消除了，就有了互信的坚实基础，和对团队承诺的负责担当，这让团队始终关注于整体结果，而无个人追求其私心杂念。