团队协作的五大障碍及其在互联网企业中的思考

一、团队协作特指什么？

       这里的团队协作，是指跨多个团队之间的协作，而不是团队内成员之间的协作。

       (注：大小团队是相对的，也是我们工作所常面对的。对于大团队内部的多个小团队之间的协作，如果我们是从小团队视角来看，则在本次讨论范畴内。反之，从大团队视角看，则属于大团队内部事，所以不算。）

二、团队协作离我们远吗？

      一点也不远，且越来越被重视。

       随用户挑剔度的提升和公司自身对产品不断打磨的诉求，互联网产品，尤其是成熟产品（非创新类产品），承载着产品的整个商业模式，其背后的团队是蛮“重”的。以下以我厂某产品为例（见下图），在标配的多个团队基础上，随著往下切分、横向拆分、生态衍生、对外合作后，我们的产品日常各版本或重大项目，都常遇团队合作的场景，甚至于沟通地图的准备是件非常费时的事情。

     于是，“跨团队”、“跨组织”等关键词开始频繁出现在敏捷及项目管理圈子里，体现了相关项目规模大、难度高、复杂性超强。只是，很可惜，很多时候，我们听到的都是feature team、全栈式团队这些纯方法（纯方法是相对于人（包括团队协作）、工具的一大类别，特指方法论及其应用）的运用，似乎只要用好这些方法、模型，问题就迎刃而解了。真是这样的吗？且看。

三、团队协作的五大障碍之缘起

      大约两年前，我在与产品线一位负责人做工作沟通，当我们谈论如何在团队协作已取得阶段性成果后怎么再扩大成果时，这位负责人主动跟我推荐了一本书——《团队协作的五大障碍》（Patrick Lencioni著），我立即就买了，花了一两周抽空看完了，我更多被故事情节中主人翁如何化解危机，关键时刻的处事智慧所折服。后来工作上，一旦遇到涉及团队合作领域的，我都会多些停顿和思考，比如：

1）同样的方法，同样的技术难度的两个项目，为何一个项目，能事半功倍，另一个却事倍功半？

2）怎样去处理表面上波平浪静，却暗流涌动的多团队协作项目？

3）怎样去引导团队之间适度的碰撞想法，达成共识？

4）怎样的团队合作水平，不太影响项目成败，是可接受的？

5）怎样让并没有明显协作硬伤的多团队，各进一步，设定目标，继续提升协作水平？

     近期，我重温这本《团队协作的五大障碍》。全书是一则引人入胜的管理寓言。故事中，为了拯救这家濒临倒闭的企业，董事长从外部请来了主人翁凯瑟琳，凯瑟琳不负众望，克服重重危机，把一个四分五裂的公司高级管理团队建设成一支真正的团队，并最终迎来企业成功。

     该书并没有正面去划分团队协作的成熟度模型，而是另辟蹊径，从最常见的五大障碍出发，梳理起一套模型体系，并具体罗列了如果具备/不具备其中每条障碍时团队协作的表现形式，如何克服该障碍，以及与上一条障碍之间的关系等，具有较高实操性。所以，这本书，同时是针对团队协作五大障碍的一本字典，教会大家如何诊断，如何治疗。

四、当我们在谈论团队协作的五大障碍时，我们在谈论什么？

1、讨论模型本身

     五大障碍所形成的金字塔如下图：

     这五大障碍不仅危险，而且非常常见，合起来，形成一套模式。常见到什么程度，可以这么说，大多数企业都没有能实现真正的团队协作。五大障碍不是相互独立，而是合成模式的。其依赖逻辑如下：

1）缺乏信任，是第一大障碍，当然它也不是无源之水，比如不愿/不敢公开承认自己的缺点，会导致缺乏信任。缺乏信任，就会导致惧怕冲突；

2）因为团队之间惧怕冲突，则只会讨论些无关痛痒的话题，于是导致欠缺投入，因为一旦投入做事/讨论，难免会有一些冲突；

3）因为欠缺投入，所以共识只是表面的，那么逃避责任就是自然而然的；

4）当普遍都在逃避责任时，who care共同利益，and then，无视结果；

     上述连锁反应自然而然。反之，当我们建立起团队间的信任关系，就很有机会赢来良性循环。

2、如何在实际工作中运用模型

1）理解层面

     当项目遇到困难，例如我们推荐的方案被无端搁置时，我们可以打开思路，想想团队协作这个话题，是否在这方面存在严重的障碍。举个例子，项目的合作双方都不采用工作前置法，我们作为敏捷教练，很容易想到去推介和实施一些诸如任务拆分、工作前置、高优先行等敏捷方法。殊不知，这些思路本质上来源于生活，大家都懂，但是，双方仍然不用。这是为什么呢？为什么呢？为什么呢？经过多次撞墙后，我们最终发现，问题出在两团队之间的相互信任不够，因为相互不够信任，所以谁也不愿意分拆任务，担心工作量投入打了水漂。

2）策略层面

      团队协作这个话题，有点像能力建设，正面去与咱们服务的产品线/具体同学沟通时，可能会造成气氛紧张，比如，凭什么说我能力弱，凭什么说我与别的团队合作的不好？这个领域是很难去做的，所以还得看人，看时机，讲策略。这里先不做展开。总之，运用好团队协作的五大障碍这套模型，以及寓言故事中所流淌的冲突解决智慧，才是王道。

3）行动层面

      我们工作是要帮助产品线成功，我们的武器库里，有方法论，有工具，也有团队协作的改进意识和方法（隶属人的大范畴）。为什么要格外强调这第三类武器？

a）人是项目战斗力的源泉。在跨多团队的项目中，如果不能解决相互信任的常见障碍，则障碍就会如癌细胞般扩散，直到所有跨相关团队的任何项目都磕磕碰碰，甚至失败告终。《团队协作的五大障碍》中凯瑟琳多次提到：“我们必须首先是一支团结协作的团队”，同样，在互联网企业内部跨团队项目密集出现时，“我们必须首先是一支跨团队团结协作的大团队/多团队”！这是一切做事的土壤。

b）团队协作的改进与方法、工具解决的问题层面不同，常常无法相互替代。本质上，团队协作的改进，解决的是“愿不愿做”这一底层范畴。方法论，比如敏捷、精益、看板，视觉思维等，解决的是“怎么做”的高层范畴。工具呢，比如某项目管理工具，解决的是“怎么更自动、更实时”等更高层面。层面越低，越是基础；层面越高，越是锦上添花。从做事的角度，当我们刚开始touch一个项目和相关的多团队时，我们不仅怀揣方法和工具，也要有一颗关注团队协作是否有障碍的心。

c）敏捷领域不断会涌现出些新方法、新框架，我们需要花很多精力去跟进，这样才不至于落伍。于是，我们自己很容易在分配精力上有所摇摆，甚至刻意去回避项目中一切与“人”相关的topic。常见原因主要有：一是如果不在日常工作成果中套用一些最牛逼的方法论框架，都不好意思跟人打招呼，说我是搞敏捷的，这有点为了方法而方法；二是觉得团队协作领域没有一套成熟的可信服的成熟度模型，例如怎么打分baseline，怎么度量，不能量化的事情坚决不做，因为量化改进显得更牛逼；三是觉得这个话题太敏感，水太深，能躲则躲吧，怕被站队。只是，团队协作的问题，如恰原书中所说，大部分团队并未成为真正的团队，团队协作的障碍普遍存在，所以，在行动上，借此机会，想呼吁大家，我们一起，多留心、多思考，只有团队协作的土壤肥沃了，我们及我们所服务团队才能事半功倍，走向成功。

五、实战时若遭遇团队协作五大常见障碍，该怎么做？

     （参照小范围天使读者的反馈，这一部分是后来补充的，着重增强实战性。）

       我们先看下Patrick Lencioni在《团队协作的五大障碍》中是如何解决五大障碍的。首先，书中更关注是对于五大障碍及其关系识别、症状诊断等，提供了一些基本的元素级的解决手段：

      上述方法，来自原书，很具体。以缺乏信任这第一条障碍为例，集体外出实践是我们实际工作中很常用的解决方式，同时，团队领导的风格对于团队协作的影响很大。

      实际工作中，在解决团队协作障碍时，常常是融合应用各种方法技巧。在此基础上，我补充如下几条建议：

1、在五层障碍的金字塔模型中，建议由上而下找表象，自下到上查原因；

      五层金字塔中，越底层的障碍，越是原因，越是上层的障碍，越是导致的现象。比如，缺乏信任，容易导致惧怕冲突，惧怕冲突，容易导致缺乏投入等。

      从病情初诊来看，可以对金字塔从上而下扫描；从解决问题来看，我们应该从下而上去查根因。

2、向上沟通，必要时，甚至上升至双方共同的老大出面；

      在遇到障碍时，做向上沟通，无异于有困难就扔给老大，这是很多人所忌讳的。于是，这又成了一个很好的过滤器，真的到必须上升到足够高的大领导时，一切也就迎刃而解，其中，很多的得失、利益、底线，在大领导出面前，就已经在煎熬中明朗了。

3、时间是一方良药；

      被动等待，是一筹莫展或浪费生命，但还有种等待，名曰主动等待，这是种智慧。时间常常是方良药，有时双方争执不可开交，互不让步，在一个时间片段后，忽然，人变了，汇报关系变了，代表利益变了，此一时彼一时。

4、组织重组，团队合二为一；

      原先，是团队与团队间的协作，存在这样那样的障碍。现在两支/多支团队合并了，于是成了团队内部问题，协作复杂度骤降。这条疗效好是好，但可遇不可求，并可能会带来些副作用，比如不利于小团队管理，合并后团队的boss很辛苦。